Asterisk 1.8.7 call disconnect after 10-15s

system · February 18, 2012, 7:29am

Hey everyone,

New to this forum. I have been using Asterisk with my web sip soft phone and x-lite phone for a short while. This is my current setup:
============

Just recently, I changed to another Internet Service Provider and since then I have had issues with SIP Phones connecting to Asterisk from the local network. The issue is that the call goes through, but after 12-15s it gets disconnected. It was working fine on the old ISP. I can’t seem to figure out what the problem is.

Tried attempting to register with asterisk from a different softphone, but I can’t even register with asterisk. This time, wireshark logs show that:

Softphone sends Register message to asterisk
Asterisk responds with 401 Unauthorized (0 Bindings)
Softphone is supposed to send a Register message with the Authorization header, but it keeps sending Register without the header (like the one in step 1) and asterisk keeps responding with 401 Unauthorized. After a while registration times out.

All this started after I switched to my new ISP. What could be the technical issue here. Thanks in advance.

The asterisk console on the server prints these messages.

[Feb 17 12:18:28] WARNING[2902] chan_sip.c: Retransmission timeout reached on transmission MWUyMDBmYTYzZGY4ZjU2NmY1YWM3MDRmMGE2N2I2NGE. for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 13184ms with no response
[Feb 17 12:18:28] WARNING[2902] chan_sip.c: Hanging up call MWUyMDBmYTYzZGY4ZjU2NmY1YWM3MDRmMGE2N2I2NGE. - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).

These are the SIP messages:
AAA.AAA.AAA.AAA - Asterisk Public IP
CCC.CCC.CCC.CCC - Client IP (SIP Phone)


<------------->
--- (9 headers 0 lines) ---

<--- SIP read from UDP:CCC.CCC.CCC.CCC:51762 --->


<------------->

<--- SIP read from UDP:CCC.CCC.CCC.CCC:51762 --->
REGISTER sip:AAA.AAA.AAA.AAA SIP/2.0
Via: SIP/2.0/UDP CCC.CCC.CCC.CCC:51762;branch=z9hG4bK-d8754z-7e46f3a16ca24a01-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0>
To: "9001"<sip:9001@AAA.AAA.AAA.AAA>
From: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=856bf01b
Call-ID: Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.
CSeq: 120 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite 4 release 4.1 stamp 63214
Authorization: Digest username="9001",realm="asterisk",nonce="5efe42da",uri="sip:AAA.AAA.AAA.AAA",response="6d0b3e1105bed8b33944ea2306971454",algorithm=MD5
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to CCC.CCC.CCC.CCC:51762 (no NAT)

<--- Transmitting (NAT) to CCC.CCC.CCC.CCC:51762 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP CCC.CCC.CCC.CCC:51762;branch=z9hG4bK-d8754z-7e46f3a16ca24a01-1---d8754z-;received=CCC.CCC.CCC.CCC;rport=51762
From: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=856bf01b
To: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=as1e00ec67
Call-ID: Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.
CSeq: 120 REGISTER
Server: Asterisk PBX 1.8.7.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4cb4a650"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.' in 32000 ms (Method: REGISTER)

<--- SIP read from UDP:CCC.CCC.CCC.CCC:51762 --->
REGISTER sip:AAA.AAA.AAA.AAA SIP/2.0
Via: SIP/2.0/UDP CCC.CCC.CCC.CCC:51762;branch=z9hG4bK-d8754z-e249d6286dbeda32-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0>
To: "9001"<sip:9001@AAA.AAA.AAA.AAA>
From: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=856bf01b
Call-ID: Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.
CSeq: 121 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite 4 release 4.1 stamp 63214
Authorization: Digest username="9001",realm="asterisk",nonce="4cb4a650",uri="sip:AAA.AAA.AAA.AAA",response="806a63b7d4f1faf75b17289d023a4f37",algorithm=MD5
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to CCC.CCC.CCC.CCC:51762 (NAT)
Reliably Transmitting (NAT) to CCC.CCC.CCC.CCC:51762:
OPTIONS sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0 SIP/2.0
Via: SIP/2.0/UDP AAA.AAA.AAA.AAA:5060;branch=z9hG4bK0d972a5b;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@AAA.AAA.AAA.AAA>;tag=as0834b17a
To: <sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0>
Contact: <sip:asterisk@AAA.AAA.AAA.AAA:5060>
Call-ID: 4326333f26113b1867aaa8707eda3916@AAA.AAA.AAA.AAA:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.8.7.0
Date: Sat, 18 Feb 2012 04:19:42 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---

<--- Transmitting (NAT) to CCC.CCC.CCC.CCC:51762 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP CCC.CCC.CCC.CCC:51762;branch=z9hG4bK-d8754z-e249d6286dbeda32-1---d8754z-;received=CCC.CCC.CCC.CCC;rport=51762
From: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=856bf01b
To: "9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=as1e00ec67
Call-ID: Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.
CSeq: 121 REGISTER
Server: Asterisk PBX 1.8.7.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Expires: 60
Contact: <sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0>;expires=60
Date: Sat, 18 Feb 2012 04:19:42 GMT
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'Mjk1YmNhMWE1NzAxNjE4ZWNiZDRhZWU1NGNiMjlmOGY.' in 32000 ms (Method: REGISTER)

<--- SIP read from UDP:CCC.CCC.CCC.CCC:51762 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP AAA.AAA.AAA.AAA:5060;branch=z9hG4bK0d972a5b;rport=5060
Contact: <sip:192.168.2.2:51762>
To: <sip:9001@CCC.CCC.CCC.CCC:51762;rinstance=8d08f3e1f33a06a0>;tag=e4a046e0
From: "asterisk"<sip:asterisk@AAA.AAA.AAA.AAA>;tag=as0834b17a
Call-ID: 4326333f26113b1867aaa8707eda3916@AAA.AAA.AAA.AAA:5060
CSeq: 102 OPTIONS
Accept: application/sdp
Accept-Language: en
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Supported: replaces
User-Agent: X-Lite 4 release 4.1 stamp 63214
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Really destroying SIP dialog '4326333f26113b1867aaa8707eda3916@AAA.AAA.AAA.AAA:5060' Method: OPTIONS
Server56890*CLI> exit
Executing last minute cleanups
[root@Server56890 asterisk]# nano messages
  GNU nano 1.3.12                                        File: messages


[Feb 18 04:18:43] NOTICE[2902] chan_sip.c:    -- Re-registration for  473555683@sip.callwithus.com
[Feb 18 04:18:43] NOTICE[2902] chan_sip.c: Outbound Registration: Expiry for sip.callwithus.com is 120 sec (Scheduling reregistration in 105 s)
[Feb 18 04:18:47] NOTICE[2902] chan_sip.c: Correct auth, but based on stale nonce received from '"9001"<sip:9001@AAA.AAA.AAA.AAA>;tag=856bf01b'
[Feb 18 04:19:21] NOTICE[23049] res_rtp_asterisk.c: Unknown RTP codec 126 received from 'CCC.CCC.CCC.CCC:63731'
[Feb 18 04:19:21] NOTICE[23049] res_rtp_asterisk.c: Unknown RTP codec 126 received from 'CCC.CCC.CCC.CCC:63731'
[Feb 18 04:19:31] NOTICE[23049] res_rtp_asterisk.c: Unknown RTP codec 126 received from 'CCC.CCC.CCC.CCC:63731'
[Feb 18 04:19:33] WARNING[2902] chan_sip.c: Retransmission timeout reached on transmission NTU1YTY2ZDllNTU0OGJiNWVkNjZlZDlmOTA0OWI5ZDQ. for seqno 2 (Critica$
Packet timed out after 13248ms with no response
[Feb 18 04:19:33] WARNING[2902] chan_sip.c: Hanging up call NTU1YTY2ZDllNTU0OGJiNWVkNjZlZDlmOTA0OWI5ZDQ. - no reply to our critical packet (see https://wiki$

david55 · February 18, 2012, 10:41am

You haven’t logged the packet that is being retransmitted.

10-15s is normally too short for such an error. They tend to be in the 20 to 30 second range.

If it is a re-invite to the ISP, some ISPs have broken handling of re-invites, which the latest versions use for connected line updates, as well as direct media. You will need to find out why it is being sent and then disable that function.

Broken here means that they ignore them, when they should either reject or honour them.

system · February 19, 2012, 8:04am

Thanks david55. You made a very good point.

I did some research on why re-invites were being handled improperly and I stumbled upon a topic on google with someone having a problem with SIP packets with their new ISP and how they got around it.

The problem, as you rightly pointed out, is that some ISPs handle SIP Packets incorrectly. The solution was to change the Asterisk binding port from the default 5060 to another value(5061). Everything works normally now. I still have to do some testing from multiple devices to make sure everything works fine.

Thanks again david55 for replying.

Topic		Replies	Views
Asterisk OUTBOUND SIP REGISTRATIONS timeout Asterisk Support	0	298	November 25, 2011
Sip REGISTER fails from time to time Asterisk Support	1	240	August 9, 2007
Extension not register with tls and srtp Asterisk SIP	4	125	April 20, 2024
SIP registration lost Asterisk Support	1	285	November 13, 2013
Please help me, sip registration timeout Asterisk Support	4	4058	January 15, 2006

Asterisk 1.8.7 call disconnect after 10-15s

Related topics