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

Hello,

I am running Asterisk 11 on CentOS 6.4 with SIP clients (Yealink phones). All
the SIP clients are on a LAN, so no NAT is involved. I have been experiencing
an intermittent problem where a call will be successfully answered, but then
dropped by Asterisk 32 seconds after it is answered (with a "Retransmission
timeout reached on transmission" error). Here is an example of this
happening
in the asterisk console: 
http://pastebin.com/7LDwHAJe

This problem only happens a fraction of the time, so I have been unable to
enable SIP debugging before it happens to get a capture. However, usually the
caller will just call back immediately and then the call will work without a
problem. It sounds like SIP Timer B is what causes the call to be dropped if an
ACK to the INVITE is not received within 32 seconds. How can I determine if
this is the case and how can I resolve this "Retransmission timeout"
problem?

Here is my sip.conf:
general]
directmedia=no
directrtpsetup=no
dtmfmode=rfc2833
context=internal
allowsubscribe=no
qualify=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
localnet=10.10.32.0/255.255.248.0


[123]
secret=111111
host=dynamic
type=friend


Thanks!

Andrew Martin

----- Original Message -----
> From: "Andrew Martin" <amartin at xes-inc.com>
> To: "Asterisk Users Mailing List - Non-Commercial Discussion"
<asterisk-users at lists.digium.com>
> Sent: Friday, May 8, 2015 5:12:28 PM
> Subject: [asterisk-users] "Retransmission Timeout" results in
dropped calls	after 32 seconds
> 
> Hello,
> 
> I am running Asterisk 11 on CentOS 6.4 with SIP clients (Yealink phones).
All
> the SIP clients are on a LAN, so no NAT is involved. I have been
experiencing
> an intermittent problem where a call will be successfully answered, but
then
> dropped by Asterisk 32 seconds after it is answered (with a
"Retransmission
> timeout reached on transmission" error). Here is an example of this
happening
> in the asterisk console:
> http://pastebin.com/7LDwHAJe
> 
> This problem only happens a fraction of the time, so I have been unable to
> enable SIP debugging before it happens to get a capture. However, usually
the
> caller will just call back immediately and then the call will work without
a
> problem. It sounds like SIP Timer B is what causes the call to be dropped
if
> an
> ACK to the INVITE is not received within 32 seconds. How can I determine if
> this is the case and how can I resolve this "Retransmission
timeout" problem?
> 
> Here is my sip.conf:
> general]
> directmedia=no
> directrtpsetup=no
> dtmfmode=rfc2833
> context=internal
> allowsubscribe=no
> qualify=no
> disallow=all
> allow=ulaw
> allow=alaw
> allow=gsm
> localnet=10.10.32.0/255.255.248.0
> 
> 
> [123]
> secret=111111
> host=dynamic
> type=friend
> 
By doing a number of test calls today, I have managed to reproduce this while
sip debugging was on, so I have that information available now as well:
http://pastebin.com/ZJqzdvY3

This was a call from 113 to 146 via a queue. Note that the asterisk server is
at 10.10.32.251. I see the following:
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
SIP/2.0 180 Ringing
SIP/2.0 180 Ringing
SIP/2.0 200 OK
ACK sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
SIP/2.0 200 OK
ACK sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
INVITE sip:146 at 10.10.32.96:5062 SIP/2.0

This appears to start out with a successful SIP conversation (ending with the
first ACK), so it is unclear to me why we have two new sets of INVITEs sent
afterwards. 

Also in case it is relevant, the asterisk server has two NICs set up in a bond
with bond-mode 1 (active/backup).

Does this additional debug information provide any clues to why this 
intermittent "retransmission timeout" error is occurring?

Thanks,

Andrew

Andrew Martin wrote:
> ----- Original Message -----
<snip>
>
> By doing a number of test calls today, I have managed to reproduce this
while
> sip debugging was on, so I have that information available now as well:
> http://pastebin.com/ZJqzdvY3
>
> This was a call from 113 to 146 via a queue. Note that the asterisk server
is
> at 10.10.32.251. I see the following:
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> SIP/2.0 180 Ringing
> SIP/2.0 180 Ringing
> SIP/2.0 200 OK
> ACK sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> SIP/2.0 200 OK
> ACK sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
> INVITE sip:146 at 10.10.32.96:5062 SIP/2.0
>
> This appears to start out with a successful SIP conversation (ending with
the
> first ACK), so it is unclear to me why we have two new sets of INVITEs sent
> afterwards.
Asterisk has sent a re-INVITE to have the media flow directly. The 
device (seems) to respond with the 200 OK (you can tell based on the 
CSeq) for the initial INVITE, and not for the re-INVITE. As Asterisk 
gets no response to its re-INVITE it gives up and terminates the dialog.

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