[asterisk-bugs] [Asterisk 0017005]: [patch] Asterisk sends session-timer with "require" after 15 minutes

Wed Sep 8 16:52:11 CDT 2010

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17005 
====================================================================== 
Reported By:                alexrecarey
Assigned To:                dvossel
====================================================================== 
Project:                    Asterisk
Issue ID:                   17005
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Target Version:             1.6.2.13
Asterisk Version:           SVN 
JIRA:                       SWP-1067 
Regression:                 No 
Reviewboard Link:           https://reviewboard.asterisk.org/r/698/ 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-03-10 21:02 CST
Last Modified:              2010-09-08 16:52 CDT
====================================================================== 
Summary:                    [patch] Asterisk sends session-timer with "require"
after 15 minutes
Description: 
When asterisk is set to defaults in session timer handling, after 15
minutes it will send a re-invite with the "required" tag.

This will cause an asterisk server with session-timers=refuse setting to
respond with a sip 420 and disconnect the call.

According to developer documentation at
https://issues.asterisk.org/file_download.php?file_id=15454&type=bug
asterisk should NEVER send a session timer with the "require" tag even if
set to session-timers=force

This issue is easily reproduced by registering a sip client with one
asterisk, set to session-timers=refuse, and place a call to another
asterisk with default session-timers settings. After exactly 15 minutes the
call will drop.

I have included a SIP Trace of the last 30 seconds of the call.
====================================================================== 

---------------------------------------------------------------------- 
 (0126760) svnbot (reporter) - 2010-09-08 16:52
 https://issues.asterisk.org/view.php?id=17005#c126760 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 285565

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r285565 | dvossel | 2010-09-08 16:52:09 -0500 (Wed, 08 Sep 2010) | 67
lines

Merged revisions 285564 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r285564 | dvossel | 2010-09-08 16:48:37 -0500 (Wed, 08 Sep 2010) | 60
lines

  Merged revisions 285563 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2

  ........
    r285563 | dvossel | 2010-09-08 16:47:29 -0500 (Wed, 08 Sep 2010) | 54
lines

    Fixes interoperability problems with session timer behavior in
Asterisk.

    CHANGES:
    1. Never put "timer" in "Require" header.  This is not to our benefit
    and RFC 4028 section 7.1 even warns against it.  It is possible for
one
    endpoint to perform session-timer refreshes while the other endpoint
does
    not support them.  If in this case the end point performing the
refreshing
    puts "timer" in the Require field during a refresh, the dialog will
    likely get terminated by the other end.

    2. Change the behavior of 'session-timer=accept' in sip.conf (which is
    the default behavior of Asterisk with no session timer configuration
    specified) to only run session-timers as result of an incoming INVITE
    request if the INVITE contains an "Session-Expires" header... Asterisk
is
    currently treating having the "timer" option in the "Supported" header
as
    a request for session timers by the UAC.  I do not agree with this. 
Session
    timers should only be negotiated in "accept" mode when the incoming
INVITE
    supplies a "Session-Expires" header, otherwise RFC 4028 says we should
    treat a request containing no "Session-Expires" header as a session
with
    no expiration.

    Below I have outlined some situations and what Asterisk's behavior is.
    The table reflects the behavior changes implemented by this patch.

    SITUATIONS:
    -Asterisk as UAS
    1. Incoming INVITE: NO  "Session-Expires"
    2. Incoming INVITE: HAS "Session-Expires"

    -Asterisk as UAC
    3. Outgoing INVITE: NO  "Session-Expires". 200 Ok Response HAS
"Session-Expires" header
    4. Outgoing INVITE: NO  "Session-Expires". 200 Ok Response NO 
"Session-Expires" header
    5. Outgoing INVITE: HAS "Session-Expires".

    Active   - Asterisk will have an active refresh timer regardless if
the other endpoint does.
    Inactive - Asterisk does not have an active refresh timer regardless
if the other endpoint does.
    XXXXXXX  - Not possible for mode.
    ______________________________________
    |SITUATIONS | 'session-timer' MODES  |
    |___________|________________________|
    |           | originate  |  accept   |
    |-----------|------------|-----------|
    |1.         |   Active   | Inactive  |
    |2.         |   Active   |  Active   |
    |3.         | XXXXXXXX   | Active    |
    |4.         | XXXXXXXX   | Inactive  |
    |5.         |   Active   | XXXXXXXX  |
    --------------------------------------

    (closes issue https://issues.asterisk.org/view.php?id=17005)
    Reported by: alexrecarey
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=285565 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-08 16:52 svnbot         Checkin                                      
2010-09-08 16:52 svnbot         Note Added: 0126760                          
======================================================================