[asterisk-users] "Retransmission Timeout" results in dropped calls after 32 seconds

[Joshua Colp]

Andrew Martin wrote:
> ----- Original Message -----
>> From: "Joshua Colp"<jcolp at digium.com>
>> To: "Asterisk Users Mailing List - Non-Commercial Discussion"<asterisk-users at lists.digium.com>
>> Sent: Wednesday, May 13, 2015 10:10:25 AM
>> Subject: Re: [asterisk-users] "Retransmission Timeout" results in dropped calls	after 32 seconds
>>
>> Andrew Martin wrote:
>>> ----- Original Message -----
>> <snip>
>>
>>>
>>> Most noteworthy is that the phone seems to send the OK for cseq 103, but it
>>> seems that the asterisk server never received this OK, which is why it kept
>>> re-transmitting the INVITE (103). Is this OK supposed to go to the asterisk
>>> server, or to the other phone? If it is supposed to go to the asterisk
>>> server,
>>> I suppose the explanation could be network turbulence prevented this OK
>>> from
>>> getting back to the server - does this seem like what happened? If so, what
>>> should be happening differently to ensure that this call doesn't get
>>> dropped?
>> The traffic is between the phone and Asterisk. As to why, I have no
>> idea. The packets aren't getting to Asterisk - that's all I can say. I
>> doubt it's network turbulence. Likely getting lost/blocked somewhere.
>>
> Since some packet loss is a possibility, I assume the protocol has mechanisms
> for dealing with it. What should be happening differently in the communication
> when packet loss occurs? Should the phone just be re-sending the OK, instead of
> printing "<0>  | ERROR | receive a request with same cseq??" to its log? Or should
> Asterisk be starting with a new cseq on each INVITE retry?

The 200 OK should be retransmitted until an ACK is received. It honestly 
looks like the phone can't talk to Asterisk and it's just generally 
screwing up signaling.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org