[Home]

Summary:ASTERISK-19139: SIP regression in 1.8 branch
Reporter:Dmitry Svyatogorov (punk)Labels:
Date Opened:2011-12-30 03:43:11.000-0600Date Closed:2012-03-23 11:12:30
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:1.8.7.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Asterisk 1.8.x (tested since 1.8.0.2 till 1.8.7.1) in conjunction with Audiocodes MP-124 gateways (tested with 5.80, 6.00 firmwares). Asterisk instalations are on Centos 5 (from packages.asterisk.org), Debian 5,6 (compilled from sources).Attachments:( 0) fulldebug.bz2
Description:  Asterisk 1.8 fails to re-register SIP peer after some packet-loses occures on dirty-lines. With 1.6.2.x (tested since 1.6.2.9 till 1.6.2.20) all works fine with the same Audiocodes devices.
 On sip debug, I view something like that:
=============================================================================
<--- SIP read from UDP:192.168.255.5:5060 --->
REGISTER sip:192.168.255.250 SIP/2.0
Via: SIP/2.0/UDP 192.168.255.5;branch=z9hG4bKac104372512
Max-Forwards: 70
From: <sip:406@192.168.255.5>;tag=1c104350658
To: <sip:406@192.168.255.5>
Call-ID: 109409774128122011123753@192.168.255.5
CSeq: 8554 REGISTER
Authorization: Digest username="406",realm="asterisk",nonce="39e53a62",uri="sip:192.168.255.250",algorithm=MD5,response="42bca04c8e92819aaef62c3c8d432542"
Contact: <sip:406@192.168.255.5:5060>;expires=120
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Expires: 120
User-Agent: Audiocodes-Sip-Gateway-MP-124 FXS/v.6.00A.034.003
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to 192.168.255.5:5060 (NAT)
[Dec 30 12:36:39] NOTICE[5521]: chan_sip.c:13968 check_auth: Correct auth, but based on stale nonce received from '<sip:406@192.168.255.5>;tag=1c104350658'

<--- Transmitting (NAT) to 192.168.255.5:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.255.5;branch=z9hG4bKac104372512;received=192.168.255.5;rport=5060
From: <sip:406@192.168.255.5>;tag=1c104350658
To: <sip:406@192.168.255.5>;tag=as43901364
Call-ID: 109409774128122011123753@192.168.255.5
CSeq: 8554 REGISTER
Server: Miran PBX 1.2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="29177b59", stale=true
Content-Length: 0
=============================================================================
... and such peer stays unregistered forewer until I reboot Audiocodes (or I cat "sip reload" + "Register" on Audiocodes, but it collapses again in no long time). I have suspicion about "stale nonce" behavior in 1.8 branch, as SIP settings are the same between 1.6.x and 1.8.x instalations. And no matter what nat settings I use (yes by default in our instalations).

 Below sip.conf settings are placed. (egrep -v '(^;)|(^$)|(^\s+)' sip.conf)
[general]
context=sip
allowguest=no
allowoverlap=no                 ; Disable overlap dialing support. (Default is yes)
allowtransfer=yes
udpbindaddr=0.0.0.0             ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
tcpenable=no                    ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0             ; IP address for TCP server to bind to (0.0.0.0 binds to all interfaces)
srvlookup=no
maxexpiry=3600
minexpiry=60
defaultexpiry=180
language=ru
progressinband=yes
useragent=Miran PBX 1.2
promiscredir = no
dtmfmode=auto
videosupport=yes
alwaysauthreject = yes
rtptimeout=180
rtpholdtimeout=600
sipdebug = no
recordhistory=yes
dumphistory=yes
allowsubscribe = yes
subscribecontext = BLF
notifyringing = yes
notifyhold = no
notifycid = no
callcounter = yes
nat=yes
directmedia=no
sdpsession=Miran PBX 1.2
rtcachefriends=yes
ignoreregexpire=yes
allowexternaldomains=yes
autodomain=no

 (All peers are real-time from pgsql.)
Comments:By: Paul Belanger (pabelanger) 2011-12-30 09:26:56.069-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Dmitry Svyatogorov (punk) 2012-01-11 06:22:26.663-0600

I've been constructed the debuging scheme, now I'm waiting the bug to reoccur to post the log. It can take up to one month due to low activity at the beginning of the year.
By: Dmitry Svyatogorov (punk) 2012-01-13 04:22:20.403-0600

 Yep, bug is here! sip:404@192.168.255.5 from AudioCodes loosed it's authorisation. It seems that a key is here:
"[Jan 13 13:30:06] DEBUG[5521] chan_sip.c: Ignoring SIP message because of retransmit"
By: Dmitry Svyatogorov (punk) 2012-01-17 05:25:21.192-0600

Hmm, I have to push "Feedback" here to kick an action?
Sorry, I'm not friendly with JIRA.
By: Matt Jordan (mjordan) 2012-01-17 11:19:52.209-0600

Just to clarify, the call sequence is:

Device: REGISTER (cseq 347)
Asterisk: 401 Unauthorized (347 response)
Device: REGISTER (cseq 348)
Asterisk: 200 OK (348 response)
Device: REGISTER (cseq 348)
Asterisk: 401 Unauthorized (348 response)

It appears as if the registering device never received our 200 OK, and re-transmitted the REGISTER with the valid authorization credentials.  Rather the re-transmit our 200 OK, we transmitted a 401 unauthorized.

Thanks for providing the DEBUG information!
By: Joshua C. Colp (jcolp) 2012-02-22 10:34:35.055-0600

Can you please set the following in the 1.8 sip.conf file to confirm some ideas for me:

pedantic=no

Unfortunately I have had a very hard time trying to reproduce this even under controlled circumstances and am wondering if that is the root of the problem.
By: Dmitry Svyatogorov (punk) 2012-02-24 00:38:59.066-0600

 Ok, I've set "pedantic=no" && sip reload. It will take a time to make some desicion, because at this moment all unstable channels are downgraded to use 1.6.2x as a workaround.
By: Matt Jordan (mjordan) 2012-03-23 11:12:25.490-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines


By: Eugene M. Zheganin (drookie) 2012-05-22 04:10:01.274-0500

Actually, it helps. Thus, thank you.
I had exactly the same issue with audiocodes on a lossy WAN link and registration loss across time.
I was fighting this with mp-124 restarts, but with 'pedantic=no' it's now able to restore the registration without any restarts.

thanks a lot.