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

[Asterisk Bug Tracker]

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:                     acknowledged
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:              
====================================================================== 
Date Submitted:             2010-03-10 21:02 CST
Last Modified:              2010-08-25 11:21 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0126323) dvossel (administrator) - 2010-08-25 11:21
 https://issues.asterisk.org/view.php?id=17005#c126323 
---------------------------------------------------------------------- 
I have committed a patch that I believe will address at least part of what
is going on here.

Here is what I fixed. Asterisk always advertised that it supported session
timers even when 'session-timer=refuse' was set in sip.conf.  This can
cause calls to drop later if the endpoint generates a re-invite with
session timers in the "Require" header because Asterisk really doesn't
support them even though it said it did earlier.  As a result Asterisk will
look at the Require header of the re-invite and determine it can not
proceed.  This is the problem the reporter was having when using Asterisk
back to back with one instance containing the 'session-timer=refuse'
option.

Now, there appears to be some sort of interoperability issue going on with
Astra phones and Asterisk as well in this issue.  Since the information
pertaining to this issue has been removed for some reason I am unable to
determine what that might be, but I have a guess.  My guess is that
something very similar to what was occurring with Asterisk back to back is
occurring with the Aastra endpoints as well.

Asterisk is sending a sending a re-invite as a keepalive mechanism because
it has determined session-timers are active.  Session timers are negotiated
during the initial INVITE transaction so I can't see what is going on here
from the debug output provided in the description. Based upon how Aastra
responds to the re-invite with a "420 Option Disabled"  I'm betting this is
a problem with the Aastra endpoint advertising timers are supported just
like Asterisk was when internally they are disabled.

If someone can post both the call setup and call termination part of the
dropped call I may be able to determine if anything more can be done here. 
Otherwise I will close this if no additional feedback is provided. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-25 11:21 dvossel        Note Added: 0126323                          
======================================================================