[asterisk-bugs] [Asterisk 0016748]: Inbound calls are dropped after 15 mins and several Status 400 and 422 messages in SIP trunk against Huawei SoftX3000

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16748 
====================================================================== 
Reported By:                jmacz
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16748
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-01 15:20 CST
Last Modified:              2010-02-02 08:16 CST
====================================================================== 
Summary:                    Inbound calls are dropped after 15 mins and several
Status 400 and 422 messages in SIP trunk against Huawei SoftX3000
Description: 
Inbound calls (haven't test oubound yet) are dropped after 15 mins (aprox
915 segs) in Asterisk 1.6.2.1 and 1.6.2.0 on a SIP trunk against a Huawei
SoftX300 SoftSwitch.

Several "Status: 422 Session Timer too small" and "Status: 400 Bad Request
- 'Malformed/Missing URL'" are shown before the call is dropped.

I'm attaching a CLI SIP debug with the issue.

This doesn't happen in several Asterisk 1.6.0.x installations.
====================================================================== 

---------------------------------------------------------------------- 
 (0117521) lmadsen (administrator) - 2010-02-02 08:16
 https://issues.asterisk.org/view.php?id=16748#c117521 
---------------------------------------------------------------------- 
Sounds like configuring the session-timers so your end-point doesn't get
upset might be a work around. I think there are actually a pair of issues
here:

1) the default session timers are set lower than what your end point
likes. If I'm reading sip.conf.samples right, the default is 1800ms:

;--------------------------- SIP Session-Timers (RFC
4028)------------------------------------
; SIP Session-Timers provide an end-to-end keep-alive mechanism for active
SIP sessions.
; This mechanism can detect and reclaim SIP channels that do not terminate
through normal
; signaling procedures. Session-Timers can be configured globally or at a
user/peer level.
; The operation of Session-Timers is driven by the following configuration
parameters:
;
; * session-timers    - Session-Timers feature operates in the following
three modes:
;                            originate : Request and run session-timers
always
;                            accept    : Run session-timers only when
requested by other UA
;                            refuse    : Do not run session timers in any
case
;                       The default mode of operation is 'accept'.
; * session-expires   - Maximum session refresh interval in seconds.
Defaults to 1800 secs.
; * session-minse     - Minimum session refresh interval in seconds.
Defualts to 90 secs.
; * session-refresher - The session refresher (uac|uas). Defaults to
'uas'.
;
;session-timers=originate
;session-expires=600
;session-minse=90
;session-refresher=uas


And if I'm guessing correctly below, your end point wants a Minimum
Session-Expires of 3600ms:

asterisk1621*CLI> 
<--- SIP read from UDP:192.168.0.3:5060 --->
SIP/2.0 422 Session Timer too small
Via: SIP/2.0/UDP 192.168.150.2:5060;branch=z9hG4bK2377a139;rport
From: <sip:3456789 at 192.168.150.2>;tag=as77dfffb4
To: <sip:18765432 at 192.168.0.3>;tag=42E0B68-8D6
Call-ID: 7FFB32D4-EA311DF-830DA116-E5E7AB98 at 192.168.0.3
Min-SE:  3600                      <------------------
Min-Session-Expires?
CSeq: 102 INVITE
Content-Length: 0



I'm not sure if this is a configuration issue or a bug -- but I'd say if
Asterisk isn't acting on the end point and upping the level to 3600ms, it
probably should, depending on what the RFC says about that.

However, I think the dropping of calls might come from the following after
the 422:


---
Audio is at 192.168.150.2 port 13222
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 192.168.0.3:5060:
INVITE sip:13456789@ SIP/2.0
Via: SIP/2.0/UDP 192.168.150.2:5060;branch=z9hG4bK76920569;rport
...


Looks like the malformed URL comes from there, as there is no IP address
after the sip:13456789@ part (unless of course you've manipulated the
headers here, which it doesn't look like you've done throughout the rest of
the post). This seems to me to be wrong, and is likely the culprit to the
call dropped issue. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-02-02 08:16 lmadsen        Note Added: 0117521                          
======================================================================