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

[Steven J. Douglas]

Hi Lincoln,

The fact that you can hear and respond to the voice mail (even if its 
for the first 20 seconds), means that your phone has received the OK 
message properly. The problem is the missing ACK after receiving OK. 
When asterisk did not receive the ACK after a few retries of the OK, it 
terminated the call. This resulted in your RTP streams getting the icmp 
error messages.

Assuming that you are capturing every packet that goes on between 
Asterisk and the phone, there are two possibilities.

1. The phone has a bug.
2. The ACK was sent somewhere else. Normally the ACK message destination 
is constructed from the response to the INVITE. In this case, it will be 
the OK message.

If you suspect its the second case, you can capture the traffic for both 
a good voicemail call and a failed voicemail call. Then by comparing the 
messages, you might get a hint. If you need help, you can send the 
packet capture to me privately (not through the list as it might be a 
large file) and I can help vet it for you.

Unfortunately there is no flag that you can set to confirm a session 
based on OK being transmitted and not wait for ACK.

Regards,
Steve

Lincoln King-Cliby wrote:
>> -----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 
>