asterisk users - May 2015 - "Retransmission Timeout" results in dropped calls after 32 seconds

Andrew Martin wrote:

<snip>
>>
> Joshua,
>
> As a mitigation for this problem, could I increase the "timerb"
option in sip.conf
> to a large value, say 1 hour (instead of the default 32 seconds)? What
other
> consequences would there be from this change?
I don't know if chan_sip will allow this, but if it does... it'll keep 
transmitting over and over... it would be better to get to the bottom of 
the problem. Do a packet capture on the machine running Asterisk and see 
where the packet goes. That's the only thing left really. It's also 
possible something got fixed in relation to directmedia between your 
version and latest 11.

-- 
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

----- Original Message -----
> From: "Joshua Colp" <jcolp at digium.com>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users at lists.digium.com>
> Sent: Tuesday, May 12, 2015 5:42:57 PM
> Subject: Re: [asterisk-users] "Retransmission Timeout" results in
dropped calls	after 32 seconds
> 
> Andrew Martin wrote:
> 
> <snip>
> 
> >>
> > Joshua,
> >
> > As a mitigation for this problem, could I increase the
"timerb" option in
> > sip.conf
> > to a large value, say 1 hour (instead of the default 32 seconds)? What
> > other
> > consequences would there be from this change?
> 
> I don't know if chan_sip will allow this, but if it does... it'll
keep
> transmitting over and over... it would be better to get to the bottom of
> the problem. Do a packet capture on the machine running Asterisk and see
> where the packet goes. That's the only thing left really. It's also
> possible something got fixed in relation to directmedia between your
> version and latest 11.
> 
Joshua,

Looking at the packet capture from the asterisk server during this time,
I see the following sequence of SIP packets:
INVITE (102) - initial call connecting
RINGING (102) - initial call connecting
RINGING (102) - initial call connecting
OK (102) - initial call connecting
ACK (102) - initial call connecting
OK (102) - initial call connecting (seems like a duplicate OK)
INVITE (103) - re-INVITE to go to bypass mode
ACK (102) - initial call connecting (seems like a duplicate ACK)
INVITE (103) - re-INVITE to go to bypass mode (retry #1)
INVITE (103) - re-INVITE to go to bypass mode (retry #2)
INVITE (103) - re-INVITE to go to bypass mode (retry #3)
INVITE (103) - re-INVITE to go to bypass mode (retry #4)
INVITE (103) - re-INVITE to go to bypass mode (retry #5)


Looking at the logs from the yealink phone (http://pastebin.com/aAWs4j6i),
I see a few differences:
INVITE (102) - initial call connecting
TRYING (102) - initial call connecting
RINGING (102) - initial call connecting
INVITE (102) - initial call connecting (seems like a duplicate INVITE)
RINGING (102) - initial call connecting
OK (102) - initial call connecting
ACK (102) - initial call connecting
INVITE (103) - re-INVITE to go to bypass mode
TRYING (103) - re-INVITE to go to bypass mode
OK (103) - re-INVITE to go to bypass mode
ACK (102) - initial call connecting (seems like a duplicate ACK)
ACK (102) -initial call connecting (seems like a duplicate ACK)
INVITE (103) - re-INVITE to go to bypass mode (retry #1)
ACK (102) -initial call connecting (seems like a duplicate ACK)
INVITE (103) - re-INVITE to go to bypass mode (retry #2)
INVITE (103) - re-INVITE to go to bypass mode (retry #3)
INVITE (103) - re-INVITE to go to bypass mode (retry #4)
INVITE (103) - re-INVITE to go to bypass mode (retry #5)
INVITE (103) - re-INVITE to go to bypass mode
INVITE (103) - re-INVITE to go to bypass mode


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?

Thanks,

Andrew

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.

-- 
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