[Home]

Summary:ASTERISK-15558: Inbound calls are dropped after 15 mins and several Status 400 and 422 messages in SIP trunk against Huawei SoftX3000
Reporter:Juan Manuel Coronado Z. (jmacz)Labels:
Date Opened:2010-02-01 15:20:31.000-0600Date Closed:2011-07-26 14:36:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20100201-clilog_hangup_softx3000.txt
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.
Comments:By: Leif Madsen (lmadsen) 2010-02-02 08:16:24.000-0600

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:

�[Kasterisk1621*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@192.168.150.2>;tag=as77dfffb4
To: <sip:18765432@192.168.0.3>;tag=42E0B68-8D6
Call-ID: 7FFB32D4-EA311DF-830DA116-E5E7AB98@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.
By: Leif Madsen (lmadsen) 2010-02-02 08:18:02.000-0600

You may be able to get around all of this by simply disabling session-timers, or upping the level correctly. If upping the level doesn't work, then there must be something wrong with the re-INVITE after the session timers are enabled (at least that's what it looks like).

Disabling the session-timers may cause the re-INVITE to not happen?
By: Juan Manuel Coronado Z. (jmacz) 2010-02-02 14:02:19.000-0600

Actually, setting the Session Expire timer to 3600 solved the issue.

The 422 status message is not showing up nor the asterisk is making a re-INVITE any more (so we aren't getting more Malformed/Missing URL messages from the SS). I guess it was more of an issue than a bug.

Thank you and regards.
By: Leif Madsen (lmadsen) 2010-02-03 10:40:13.000-0600

Ah very good! I'm going to have a developer review this regardless as I think there may still be an issue with the malformed URL that could be resolved.
By: Leif Madsen (lmadsen) 2011-07-26 14:36:35.347-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions

If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!