Upgrade from version 1.6.24 to 1.8.12 – Retransmission timeout error

Home » Asterisk Users » Upgrade from version 1.6.24 to 1.8.12 – Retransmission timeout error
Asterisk Users 7 Comments

Hi list,

we are upgrading our Asterisk production server from 1.6.24 to 1.8.12
version and face the following problem: one of our peer
(voicetrading.com) doesn’t accept our calls anymore, we receive a
timeout error “Packet timed out after 32000ms with no response”.

Switching back to 1.6 make things working again!

In sip.conf we have nat=no, peer conf is:







We aren’t registered, our IP is authorized by their system.

Debug of sessions ( is our server is their)

Working one with 1.6:

Audio is at port 26002
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Reliably Transmitting (no NAT) to
INVITE sip:0000033666666666@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK58aef527;rport
Max-Forwards: 70
From: “TOOTAi” ;tag=as52190c5c
Call-ID: 2c974a0a2b08abe320ed388433e47d7e@
CSeq: 102 INVITE
User-Agent: TOOTAiAudio
Date: Sun, 27 May 2012 16:10:40 GMT
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 199

o=root 284043376 284043376 IN IP4
c=IN IP4
t=0 0
m=audio 26002 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

7 thoughts on - Upgrade from version 1.6.24 to 1.8.12 – Retransmission timeout error

  • Administrator TOOTAI wrote:

    Asterisk 1.8.12 is not getting responses to the INVITES it sends.
    Comparing the INVITES, the only significant difference I see is that
    Asterisk 1.6.24 includes the “rport” field in the Via header and
    Asterisk 1.8.12 does not:

    1.6.24 – Via: SIP/2.0/UDP;branch=z9hG4bK58aef527;rport
    1.8.12 – Via: SIP/2.0/UDP;branch=z9hG4bK0c8907be

    Try setting “nat=force_rport” in sip.conf. Please reply back to the
    list with the results.

    There may be other differences between the versions that you haven’t
    accounted for. Read the CHANGES and UPGRADE.txt files in the root of
    the Asterisk source tree for details.


    Matthew Roth
    InterMedia Marketing Solutions
    Software Engineer and Systems Developer

  • Hi Matthew

    Le 28/05/2012 19:28, Matthew J. Roth a écrit :

    We tested this setting this WE, effectively this problem disappear but
    another appears: call get connected but no audio. We installed Asterisk
    10.3.1 -> connection and no audio too, so same behaviour.

    We did read those files, don’t see which parameter we could have forget.
    media_address nor nat=comedia seems options for us. Hereunder a debug
    from call with force_rport: as you can see, the RTP audio is coming from
    another IP (77.77.777.77) We think asterisk doesn’t accept this and
    don’t know which parameter could solve this.

    < --- SIP read from UDP: --->
    SIP/2.0 200 Ok
    Via: SIP/2.0/UDP;branch=z9hG4bK04e390b0;rport
    Contact: sip:0000033666666666@
    Call-ID: 72d5d3df06c07cc6037786ee59f574df@
    CSeq: 102 INVITE
    Server: (Very nice Sip Registrar/Proxy Server)
    Content-Type: application/sdp
    Content-Length: 159

    o=CARRIER 1338276550 1338276550 IN IP4 77.77.777.77
    s=SIP Call
    c=IN IP4 77.77.777.77
    t=0 0
    m=audio 41462 RTP/AVP 0
    a=rtpmap:0 PCMU/8000
    < ------------->

  • Administrator TOOTAI wrote:


    Asterisk is fine with RTP coming from another IP. It used to work for
    you on 1.6.24. Here are the relevant bits from the “200 OK”

    1.6.24 – o=CARRIER 1338135052 1338135052 IN IP4
    c=IN IP4
    1.8.12 – o=CARRIER 1338276550 1338276550 IN IP4 77.77.777.77
    c=IN IP4 77.77.777.77

    Is that really the response that you received? 77.77.777.77 is not a
    valid IP address (the 3rd octet is greater than 255), so if that’s
    what you’re getting than your configuration is fine and the remote
    end (or some proxy) is now the problem.


    Matthew Roth
    InterMedia Marketing Solutions
    Software Engineer and Systems Developer

  • Administrator TOOTAI wrote:

    Considering that you made progress on your initial problem by setting
    “nat=force_rport” (resulting in connected calls with no audio) and now
    you’re mentioning the use of “externaddr”, I’d recommend a very
    careful reading of the “NAT SUPPORT” section of sip.conf.sample in the
    configs directory of the Asterisk source tree. In Asterisk 1.8, there
    is a new configuration option named “media_address” which may be of
    particular interest.

    This is confusing because your first email said you had “nat=no” in
    your working 1.6.24 setup, but everything you’re saying indicates a
    NAT problem to me. A diagram showing all network elements between
    your Asterisk server and the remote host would be helpful. To avoid
    further confusion, please include full and unaltered logs, SIP traces,
    and configurations in future posts.


    Matthew Roth
    InterMedia Marketing Solutions
    Software Engineer and Systems Developer

  • It sounds like a NAT issue to me too. Why don’t you do a quick test and
    put the Asterisk box on a public IP if you can. If it works, you will
    have narrowed down the issue to a NAT problem. You could have a nat
    router with a broken SIP ALG.

  • Le 30/05/2012 15:02, Andres a écrit :

    Back to the story: even out of VM -which means on a public IP- the
    timeout problem till appears. And more odd, if a communication start,
    the call get hanged up because of this timeout 🙁

    All peers and users are setted with nat=yes, phones connected to
    Asterisk have directmedia=nonat and peers gateways have directmedia=yes.

    Remember, we only face this problem with Dellmont services and asterisk
    1.8/10. Previous asterisk versions are working well.

    Does someone else use Dellmont services (VoipBuster, SipDiscount,
    Intenetcalls, Voicetrading, …) with asterisk 1.8 or 10? If yes and
    without problem, would it be possible to share configurations?

    Thanks for your help.

  • Le 02/06/2012 19:18, Administrator TOOTAI a écrit :

    For the archives.

    Problem was with Dellmont services: no audio or calls stopping after 120
    seconds. They gave me another IP for setting outgoing calls and now
    everything is going smoothly with both versions.

    Thanks for help.