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

[Andrew Martin]

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