Help - MeetMe hangs up after a few seconds

Asterisk Asterisk Support
1

Folks,

In my setup, I do not have any zaptel devices. I am just using DAHDI. I have the latest version of Asterisk and DAHDI.

Things have been working fine. Today, I decided to add MeetMe.

The only modification I have made to the default meetme.conf is added a conference room
conf => 1234,1234,2222

My extensions.conf simply has a line:
exten => 600,1,MeetMe(1234,sM)

When I dial extension 600 from my Cisco phone, I am taken to the conference room where I enter my admin code 2222. An announcement is made that I am the only caller (as expected) and a default on-hold music starts. After about 15 to 20 seconds, I simply get disconnected.

I am running asterisk with -vvvvvvvvvvgc and here is the relevant output:

-- Executing [600@FromCiscoPhone:1] MeetMe("SIP/101-b7d032d8", "1234,sM") in new stack

== Parsing ‘/etc/asterisk/meetme.conf’: == Found
– Created MeetMe conference 1023 for conference ‘1234’
– <SIP/101-b7d032d8> Playing ‘conf-getpin.ulaw’ (language ‘en’)
– <SIP/101-b7d032d8> Playing ‘conf-onlyperson.ulaw’ (language ‘en’)
– Started music on hold, class ‘default’, on SIP/101-b7d032d8
– Hungup ‘DAHDI/pseudo-1748462190’
== Spawn extension (FromCiscoPhone, 600, 1) exited non-zero on ‘SIP/101-b7d032d8’
– Stopped music on hold on SIP/101-b7d032d8

tail -f /var/log/messages does not show anything interesting either.

I can reproduce the same problem with or without music-on-hold.

Can someone please help me understand why I get disconnected in the middle of the wait?

Thank you in advance for your help.

Regards,
Peter

2

I doubt it but can the phone be doing it. Run a sip trace and see where the BYE is coming from.

3

Hi Dovid,

Thank you for your help.

Here are the last few lines of the trace from tcpdump:

192.168.15.109.20010 > 192.168.15.7.10036: UDP, length 172
192.168.15.109.20010 > 192.168.15.7.10036: UDP, length 172
192.168.15.109.20010 > 192.168.15.7.10036: UDP, length 172
192.168.15.109.20010 > 192.168.15.7.10036: UDP, length 172
192.168.15.109.52793 > 192.168.15.7.5060: SIP, length: 359

192.168.15.7 is where Asterisk is running. 192.168.14.109 is the IP of the Cisco phone.

Thinking that is is a problem with Cisco phone, I tried dialing from x-lite soft phone. This one too results in the same problem.

Any insight?

Regards,
Peter

4

Here are the last few packets between x-lite phone and asterisk. Notice that Asterisk (192.168.15.7) is sending BYE to the SIP phone. This makes me think there is some time parameter is causing this problem, perhaps in MeetMe.conf.

Please share your thoughts.

Regards,
Peter

14:42:00.011405 IP 192.168.15.110.20002 > 192.168.15.7.10008: UDP, length 172
0x0000: 4500 00c8 5cd0 0000 8011 3d8f c0a8 0f6e E…=…n
0x0010: c0a8 0f07 4e22 2718 00b4 8c02 8000 20c6 …N"’…
0x0020: 0006 9474 04c5 8455 fefe ffff fe7e fffd …t…U…~…
0x0030: feff fefe 7f7e feff 7efe fe7f 7e7f 7f7f …~…~…~…
0x0040: ff7e 7dff feff feff 7eff fe7e 7efe ff7e .~}…~…~~…~
0x0050: 7e7f ~.
14:42:00.011536 IP 192.168.15.7.10008 > 192.168.15.110.20002: UDP, length 172
0x0000: 4500 00c8 0000 4000 4011 9a5f c0a8 0f07 E…@.@…_…
0x0010: c0a8 0f6e 2718 4e22 00b4 a08b 8000 13fe …n’.N"…
0x0020: 0004 7298 75eb 19c9 4475 ee48 3e40 3c40 …r.u…Du.H>@<@
0x0030: d6ea d5b9 cd5e 5c58 7153 58c9 c8cb dbdd …^\XqSX…
0x0040: d5fe ff42 53c8 4346 ef43 57ef 68df c7cb …BS.CF.CW.h…
0x0050: 5547 UG
14:42:00.012085 IP 192.168.15.7.5060 > 192.168.15.110.20000: SIP, length: 422
0x0000: 4500 01c2 8fcb 0000 4011 499a c0a8 0f07 E…@.I…
0x0010: c0a8 0f6e 13c4 4e20 01ae a185 4259 4520 …n…N…BYE.
0x0020: 7369 703a 3130 3540 3139 322e 3136 382e sip:105@192.168.
0x0030: 3135 2e31 3a32 3030 3030 2053 4950 2f32 15.1:20000.SIP/2
0x0040: 2e30 0d0a 5669 613a 2053 4950 2f32 2e30 .0…Via:.SIP/2.0
0x0050: 2f55 /U
14:42:00.018565 IP 192.168.15.110.20003 > 192.168.15.7.10009: UDP, length 160
0x0000: 4500 00bc 5cd1 0000 8011 3d9a c0a8 0f6e E…=…n
0x0010: c0a8 0f07 4e23 2719 00a8 dc6a 80c8 0006 …N#’…j…
0x0020: 04c5 8455 ce52 9fa7 fb22 d0e5 0006 9474 …U.R…"…t
0x0030: 0000 0724 0004 b94c 81ca 001e 04c5 8455 …$…L…U
0x0040: 013d 3336 3435 4242 3430 3942 3738 3434 .=3645BB409B7844
0x0050: 3139 19
14:42:00.246403 IP 192.168.15.110.20000 > 192.168.15.7.5060: SIP, length: 372
0x0000: 4500 0190 5cd2 0000 8011 3cc5 c0a8 0f6e E…<…n
0x0010: c0a8 0f07 4e20 13c4 017c 4d68 5349 502f …N…|MhSIP/
0x0020: 322e 3020 3230 3020 4f4b 0d0a 5669 613a 2.0.200.OK…Via:
0x0030: 2053 4950 2f32 2e30 2f55 4450 2031 3932 .SIP/2.0/UDP.192
0x0040: 2e31 3638 2e31 352e 373a 3530 3630 3b62 .168.15.7:5060;b
0x0050: 7261 ra

5

Anyone?

I have been running asterisk with a very long -v option. However, there is no indication on why the hang up occurs.

I would appreciate it if anyone has any thought on what other things I must look at.

Regards,
Peter

6

It’s hard to read the tcpdump. Try using ngrep or sip debug from the Asterisk CLI. SIP is a text based protocol and it’s a lot easier to just read the sip “messages” that go back and forth.

Also what does your sip.conf look like ? It could be because there is no rtp coming from the phone Asterisk hangs up the call.

7

ok. I turned out SIP debug as:

CLI> sip set debug ip 192.168.15.109

192.168.15.109 is the IP of my Cisco phone.

Here is the output.

I hope this helps understand the problem.

I truly appreciate your help. Dovid.

Peter

<------------>
== Parsing ‘/etc/asterisk/meetme.conf’: == Found
– Created MeetMe conference 1022 for conference ‘1234’
– <SIP/101-b7c02a50> Playing ‘conf-getpin.ulaw’ (language ‘en’)

<— SIP read from UDP://192.168.15.109:53049 —>
ACK sip:600@192.168.15.7 SIP/2.0
Via: SIP/2.0/UDP 192.168.15.109:5060;branch=z9hG4bK62bd7f23
From: “101” sip:101@192.168.15.7;tag=000e83e5473b01e236cb520b-72eb6946
To: sip:600@192.168.15.7;tag=as6ea76c1b
Call-ID: 000e83e5-473b0044-7ff46bae-5c39416a@192.168.15.109
Max-Forwards: 70
Date: Fri, 11 Sep 2009 22:31:00 GMT
CSeq: 102 ACK
User-Agent: Cisco-CP7940G/8.0
Authorization: Digest username=“101”,realm=“asterisk”,uri="sip:600@192.168.15.7",response=“e4a98062904ff156fea2800ab81194e0”,nonce=“6dc1ec94”,algorithm=MD5
Remote-Party-ID: “101” sip:101@192.168.15.7;party=calling;id-type=subscriber;privacy=off;screen=yes
Content-Length: 0

<------------->
— (12 headers 0 lines) —
– <SIP/101-b7c02a50> Playing ‘conf-onlyperson.ulaw’ (language ‘en’)
– Hungup ‘DAHDI/pseudo-1919209510’
== Spawn extension (FromCiscoPhone, 600, 1) exited non-zero on 'SIP/101-b7c02a50’
Scheduling destruction of SIP dialog ‘000e83e5-473b0044-7ff46bae-5c39416a@192.168.15.109’ in 32000 ms (Method: ACK)
set_destination: Parsing sip:101@192.168.15.109:5060;transport=udp for address/port to send to
set_destination: set destination to 192.168.15.109, port 5060
Reliably Transmitting (no NAT) to 192.168.15.109:5060:
BYE sip:101@192.168.15.109:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.15.7:5060;branch=z9hG4bK73598a3f;rport
Max-Forwards: 70
From: sip:600@192.168.15.7;tag=as6ea76c1b
To: “101” sip:101@192.168.15.7;tag=000e83e5473b01e236cb520b-72eb6946
Call-ID: 000e83e5-473b0044-7ff46bae-5c39416a@192.168.15.109
CSeq: 102 BYE
User-Agent: Asterisk PBX 1.6.1.1
X-Asterisk-HangupCause: Unknown
X-Asterisk-HangupCauseCode: 0
Content-Length: 0

<— SIP read from UDP://192.168.15.109:53050 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.15.7:5060;branch=z9hG4bK73598a3f;rport
From: sip:600@192.168.15.7;tag=as6ea76c1b
To: “101” sip:101@192.168.15.7;tag=000e83e5473b01e236cb520b-72eb6946
Call-ID: 000e83e5-473b0044-7ff46bae-5c39416a@192.168.15.109
Date: Fri, 11 Sep 2009 22:31:59 GMT
CSeq: 102 BYE
Server: Cisco-CP7940G/8.0
Content-Length: 0

<------------->
— (9 headers 0 lines) —
SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog ‘000e83e5-473b0044-7ff46bae-5c39416a@192.168.15.109’ Method: ACK

8

It seems that the call is dying as soon as you are being told that you are the only person in the room. Did you build Dahdi Dummy or do you have any hardware on the server for timing ?

9

Dahdi dummy.

Here are the results from dahdi_test:

dahdi_test

Opened pseudo dahdi interface, measuring accuracy…
99.997% 99.970% 99.974% 99.973% 99.974% 99.976% 99.974% 99.975%
99.972% 99.965% 99.974% 99.995% 99.995% 99.995% ^C
— Results after 14 passes —
Best: 99.997 – Worst: 99.965 – Average: 99.979192, Difference: 99.979193

I also turned on debug flag within dahdi:

echo 1 > /sys/module/dahdi/parameters/debug

#cat /sys/module/dahdi/parameters/debug
1

Here is the output from /var/log/messages when the conference started and hung up:

Sep 14 10:18:04 einstein kernel: usbcore: deregistering interface driver xpp_usb
Sep 14 10:18:04 einstein kernel: dahdi_transcode: Loaded.
Sep 14 10:18:04 einstein kernel: INFO-xpp: revision trunk-r6963 MAX_XPDS=64 (8*8)
Sep 14 10:18:04 einstein kernel: INFO-xpp: FEATURE: without BRISTUFF support
Sep 14 10:18:04 einstein kernel: INFO-xpp: FEATURE: with PROTOCOL_DEBUG
Sep 14 10:18:04 einstein kernel: INFO-xpp: FEATURE: with sync_tick() from DAHDI
Sep 14 10:18:04 einstein kernel: INFO-xpp_usb: revision trunk-r6963
Sep 14 10:18:04 einstein kernel: usbcore: registered new interface driver xpp_usb
Sep 14 10:18:04 einstein kernel: dahdi_dummy: High Resolution Timer started, good to go

Regards,
Peter