“Retransmission Timeout” Results In Dropped Calls After 32 Seconds

Home » Asterisk Users » “Retransmission Timeout” Results In Dropped Calls After 32 Seconds
Asterisk Users 15 Comments

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.32.0/255.255.248.0

[123]
secret1111
host=dynamic type=friend

Thanks!

Andrew Martin

15 thoughts on - “Retransmission Timeout” Results In Dropped Calls After 32 Seconds

  • Andrew Martin wrote:

    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.

  • Andrew Martin wrote:

    That should be all that is required. If that were broken I’d expect issue reports to implode – what’s the configuration?

  • Andrew Martin wrote:

    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.

  • Andrew Martin wrote:

    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.

  • Andrew Martin wrote:

    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.

  • Hi,

    In my experience, all Yealink phones work just fine with Asterisk, we have hundreds (perhaps even low-thousands) out there with customers on Asterisk
    1.2, 1.6.2, 1.8 and 11.

    If you are accurately representing the SIP trace on the phone and the SIP
    trace on Asterisk, then I would strongly suggest a SIP ALG exists in the network between the two devices and that SIP ALG does not understand SIP
    properly. The two halves simply do not match, so something must surely be interfering.

    In my experience it is often an innocent looking Cisco router. Cisco’s SIP
    implementation is “SIP By Cisco” rather than “RFC compliant SIP”. If that is the case Cisco call it a “SIP fixup” and you just need to disable it.

    Hope that helps, Steve