[asterisk-users] "No Reply to Our Critical Packet" SIP Calls Dropped in Voicemail

Lincoln King-Cliby lincoln at controlworks.com
Tue Feb 3 12:25:11 CST 2009


> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Steve J. Douglas
> Sent: Tuesday, February 03, 2009 3:30 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] "No Reply to Our Critical Packet" SIP Calls > Dropped in Voicemail
>
> Hi Lincoln,
>
> Asterisk was expecting ACK after sending the 200 OK message. After 
> repeated attempts at sending the 200 OK message and not receiving ACK, 
> it terminated the call. Are you able to do a packet capture on the phone 
> end? Mostly likely the phone is sending the ACK, but its either sent to 
> somewhere else or your firewall is blocking it (not likely since you are 
> able to receive the call in the first place). The packet capture on the 
> phone end will probably show you the smoking gun.


Hi Steve, as I noted in an earlier reply the * box and the phone are on the same switch, subnet, and VLAN -- there's no routing or firewall between the two. 

I enabled port mirroring on the switch for the port that the phone is plugged into and ran Wireshark while a call was placed. I'm not really 100% sure of what I -should- be seeing so I'm not sure if what I'm seeing is correct or not. 

The call progress that I'm seeing is starting at 16.550698 seconds into the capture:  
1237 Phone -> Asterisk: INVITE sip:Voicemail at 10.2.0.2
1238 Asterisk -> Phone: 407 Proxy Authentication Required
1239 Phone -> Asterisk: ACK sip:Voicemail at 10.2.0.2
1240 Asterisk -> Phone: 100 Trying
1241 Asterisk -> Phone: 200 OK, with session description

At that point a ton of RTP packets are exchanged with a couple ARP lookups from the phone asking for the Asterisk server.  (packets 1245-1247 @ 16.6066 seconds, 1295-1297 @ 17.5701 seconds)

Then there's

1299 Asterisk -> Phone: 200 OK, with session description (@ 17.520362 seconds) 

With more RTP packets (including a couple with DTMF payloads) followed by

1402 Asterisk -> Phone: 200 OK, with session description (@ 18.572025 seconds) 

More RTP packets and DTMF follows with 

1607 Asterisk -> Phone: 200 OK, with session description (@ 20.570493 seconds) 

More RTP and at 21.570456 seconds there's a "RTCP" "Sender Report Source Description" from Asterisk to the phone, and at 21.745548 there's an NTP sync from the Phone to one of our network time servers. 

Much more RTP follows with

2011 Asterisk -> Phone: 200 OK, with session description (@ 24.573025 seconds)

Much more RTP follows with one more "RTCP" "Sender Report Source Description" and then there's 

2412 Asterisk -> Phone: 200 OK, with session description (@ 28.570687 seconds) 

--- you get the idea --- 

2814 Asterisk -> Phone: 200 OK, with session description (@ 32.570784 seconds) 

Then starting at packet 3217 there are a series 6 of ICMP "Destination unreachable (Port Unreachable)" messages from the Asterisk server to the phone, with an RTP packet from the Phone to the Asterisk server before each Destination unreachable message. 

After that series the phone sends a series of 44 RTP packets to the * Box without getting anything back. 

There's then a lone ICMP Destination Unreachable (Port Unreachable) message. 

This sequence repeats about 10 times until the user hangs up, at which point: 

3721 Phone -> Asterisk: BYE sip:Voicemail at 10.2.0.2 (@46.335605 seconds) 
3722 Asterisk -> Phone: Status: 481 Call/leg transaction does not exist

Now, on the other hand, a phone-to-phone call (actually the user calling my phone to let me know it failed), I do see an ACK very early on

That process is 
Phone->Asterisk Invite
Asterisk->Phone 407 Proxy Authentication Required
Phone->Asterisk ACK
Phone->Asterisk Invite
Asterisk->Phone 100 Trying
Asterisk->Phone 180 Ringing
Asterisk->Phone 200 OK with session description
(RTP Packets are exchanged)
Phone->Asterisk ACK
(RTP Packets are exchanged) 

Any idea why the phone would be ACKing phone-to-phone calls but not ACKing phone-to-voicemail calls? Any way to make Asterisk not drop a call just because it wasn't ACKed even though packets are still going back and forth?

Thanks again for any help!

Lincoln 



More information about the asterisk-users mailing list