[Home]

Summary:ASTERISK-15787: [patch] Asterisk sends session-timer with "require" after 15 minutes
Reporter:Alex Recarey (alexrecarey)Labels:
Date Opened:2010-03-10 21:02:31.000-0600Date Closed:2011-01-31 15:18:34.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

****** ADDITIONAL INFORMATION ******

---
set_destination: Parsing <sip:800902@xxx.xxx.xxx.6> for address/port to send to
set_destination: set destination to xxx.xxx.xxx.6, port 5060
Audio is at yyy.yyy.yyy.24 port 21438
Adding codec 0x100 (g729) to SDP
Adding codec 0x2 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to xxx.xxx.xxx.6:5060:
INVITE sip:800902@xxx.xxx.xxx.6 SIP/2.0
Via: SIP/2.0/UDP yyy.yyy.yyy.24:5060;branch=z9hG4bK0f46aa06;rport
Max-Forwards: 70
From: <sip:1147917335438@yyy.yyy.yyy.24>;tag=as3f7c6e3b
To: "800902" <sip:800902@xxx.xxx.xxx.6>;tag=as7fce532d
Contact: <sip:1147917335438@yyy.yyy.yyy.24>
Call-ID: 602031cf09a4a53f006f5f563549a3bb@xxx.xxx.xxx.6
CSeq: 102 INVITE
User-Agent: Asterisk
Require: timer
Session-Expires: 1800;refresher=uas
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (Session-Timers)
Content-Type: application/sdp
Content-Length: 314

v=0
o=root 1942655890 1942655891 IN IP4 yyy.yyy.yyy.24
s=Asterisk PBX 1.6.1.12
c=IN IP4 yyy.yyy.yyy.24
t=0 0
m=audio 21438 RTP/AVP 18 3 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

---
greywolf*CLI>
<--- SIP read from UDP://xxx.xxx.xxx.6:5060 --->
SIP/2.0 420 Option Disabled
Via: SIP/2.0/UDP yyy.yyy.yyy.24:5060;branch=z9hG4bK0f46aa06;received=yyy.yyy.yyy.24;rport=5060
From: <sip:1147917335438@yyy.yyy.yyy.24>;tag=as3f7c6e3b
To: "800902" <sip:800902@xxx.xxx.xxx.6>;tag=as7fce532d
Call-ID: 602031cf09a4a53f006f5f563549a3bb@xxx.xxx.xxx.6
CSeq: 102 INVITE
Server: VoIPSwitch
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Date: Thu, 11 Mar 2010 02:55:32 GMT
Unsupported: timer
Content-Length: 0


<------------->
--- (12 headers 0 lines) ---
   -- Got SIP response 420 "Option Disabled" back from xxx.xxx.xxx.6
set_destination: Parsing <sip:800902@xxx.xxx.xxx.6> for address/port to send to
set_destination: set destination to xxx.xxx.xxx.6, port 5060
Transmitting (no NAT) to xxx.xxx.xxx.6:5060:
ACK sip:800902@xxx.xxx.xxx.6 SIP/2.0
Via: SIP/2.0/UDP yyy.yyy.yyy.24:5060;branch=z9hG4bK0f46aa06;rport
Max-Forwards: 70
From: <sip:1147917335438@yyy.yyy.yyy.24>;tag=as3f7c6e3b
To: "800902" <sip:800902@xxx.xxx.xxx.6>;tag=as7fce532d
Contact: <sip:1147917335438@yyy.yyy.yyy.24>
Call-ID: 602031cf09a4a53f006f5f563549a3bb@xxx.xxx.xxx.6
CSeq: 102 ACK
User-Agent: Asterisk
Content-Length: 0


---
   -- Hungup 'DAHDI/76-1'
 == Spawn extension (voip10, 1147917335438, 3) exited non-zero on 'SIP/voip10-6-00028ec7'
Comments:By: Leif Madsen (lmadsen) 2010-03-11 09:21:33.000-0600

Thanks for the report! A developer will look at this as time and resources permit.
By: Rick Breidenstein (rbreidenstein) 2010-05-03 13:14:58

I am having this issue as well I believe.  Is the output listed below related to this bug?

Output:

"[May 25 11:11:54] WARNING[25698] chan_sip.c: just did sched_add waitid(5208) for sip_reinvite_retry for dialog 73a02a4f9409ba92 in handle_response_invite

[May 25 11:26:54] WARNING[25698] chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '73a02a4f9409ba92'. Giving up."


By: Frederick (mpi) 2010-06-04 19:01:59

I can confirm the behavior mentioned by rbreidenstein with exactly 15 minutes between events.
It occurs for me on calls over 30 minutes.
As of an update on June 4, I am running Asterisk 1.6.2.8 (Elastix 2.0.0-rc2 with latest updates applied) and no setting for session-timer in sip.conf so it is operating in default "accept" mode.
The events prior to June 4 are on a prior version of asterisk, but I did not record which before the update.
The client is an Aastra 6731i with sip session timer set to 0 as mentioned here: http://www.voip-info.org/wiki/view/Asterisk+and+Aastra+Phones


[Jun  1 11:12:37] VERBOSE[4863] pbx.c:     -- Executing [91NXXNXXXXXX@from-internal:1] Macro("SIP/109-0000000c", "user-callerid,SKIPTTL,") in new stack
[Jun  1 11:42:37] WARNING[3439] chan_sip.c: just did sched_add waitid(14886) for sip_reinvite_retry for dialog 42882908f8fe8ddf in handle_response_invite
[Jun  1 11:57:37] WARNING[3439] chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '42882908f8fe8ddf'. Giving up.

[Jun  3 14:08:51] VERBOSE[24322] pbx.c:     -- Executing [91NXXNXXXXXX@from-internal:1] Macro("SIP/109-00000060", "user-callerid,SKIPTTL,") in new stack
[Jun  3 14:38:51] WARNING[3439] chan_sip.c: just did sched_add waitid(230833) for sip_reinvite_retry for dialog 8625cc9644d54580 in handle_response_invite
[Jun  3 14:53:51] WARNING[3439] chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '8625cc9644d54580'. Giving up.

[Jun  4 15:11:53] VERBOSE[3843] pbx.c:     -- Executing [91NXXNXXXXXX@from-internal:1] Macro("SIP/104-00000024", "user-callerid,SKIPTTL,") in new stack
[Jun  4 15:45:47] WARNING[708] chan_sip.c: just did sched_add waitid(17947) for sip_reinvite_retry for dialog 67d27075a945a1dd in handle_response_invite
[Jun  4 16:00:47] WARNING[708] chan_sip.c: Re-invite to non-existing call leg on other UA. SIP dialog '67d27075a945a1dd'. Giving up.


As a test, I then added:
session-timers=refuse
to sip.conf and restarted asterisk.
I placed a 60 minute call without receiving the WARNING messages so it would appear that in my case, the session-timers=refuse setting seems to have resolved the issue.
I don't know how to do a sip trace so I don't have as much detail to determine if the fault lies with asterisk or the Aastra handset.
By: Leif Madsen (lmadsen) 2010-06-14 13:05:16

http://svn.asterisk.org/svn/asterisk/trunk/doc/HOWTO_collect_debug_information.txt
By: Leif Madsen (lmadsen) 2010-06-14 15:33:58

Break it into multiple files... ?
By: Rick Breidenstein (rbreidenstein) 2010-06-16 19:08:26

I wanted to rule out anything related to this machine so I completed a fresh install of asterisk 1.6.2.8 in a vm and i experience the exact same issue.  The strange thing is i think it may be related to the hard phone we are using (aastra 630i).  When i make a call into conference room from a softphone (zoiper) the call lasts beyond the 45 minute mark.
By: Frederick (mpi) 2010-06-16 19:25:15

My experience was also with Aastra hard phones (6731i, firmware 2.6.0.66). Haven't tested with alternate soft or hard phones yet.
By: Paul Belanger (pabelanger) 2010-06-16 21:49:17

Please upload your sip.conf file.
By: Paul Belanger (pabelanger) 2010-06-16 22:18:33

Warning, this patch is untested.  I plan to give it a try in the morning.  I still need to talk with a developer about it.
By: Rick Breidenstein (rbreidenstein) 2010-06-17 08:52:05

I receive the following error while attempting to apply the patch.

"
patching file channels/chan_sip.c
Hunk #1 FAILED at 9088.
1 out of 1 hunk FAILED -- saving rejects to file channels/chan_sip.c.rej

"
By: Paul Belanger (pabelanger) 2010-06-17 09:08:40

Seems I totally missed the existing work on ReviewBoard (https://reviewboard.asterisk.org/r/698/).
By: Rick Breidenstein (rbreidenstein) 2010-06-17 09:29:09

since the required information was retrieved from the logs posted, can you please remove them for me?
By: Paul Belanger (pabelanger) 2010-06-17 09:51:02

Deleted as requested
By: Digium Subversion (svnbot) 2010-08-25 10:52:52

Repository: asterisk
Revision: 283558

U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r283558 | dvossel | 2010-08-25 10:52:52 -0500 (Wed, 25 Aug 2010) | 10 lines

Asterisk will not advertise session timers are supported when 'session-timers=refuse' is used.

Asterisk now dynamically builds the "Supported" header depending
on what is enabled/disabled in sip.conf.  Session timers used
to always be advertised as being supported even when they were disabled
in the configuration.  This caused problems with some end points.

(issue ASTERISK-15787)


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

http://svn.digium.com/view/asterisk?view=rev&revision=283558
By: Digium Subversion (svnbot) 2010-08-25 10:54:09

Repository: asterisk
Revision: 283559

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c
U   branches/1.8/channels/sip/include/sip.h

------------------------------------------------------------------------
r283559 | dvossel | 2010-08-25 10:54:09 -0500 (Wed, 25 Aug 2010) | 16 lines

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

........
 r283558 | dvossel | 2010-08-25 10:52:54 -0500 (Wed, 25 Aug 2010) | 10 lines
 
 Asterisk will not advertise session timers are supported when 'session-timers=refuse' is used.
 
 Asterisk now dynamically builds the "Supported" header depending
 on what is enabled/disabled in sip.conf.  Session timers used
 to always be advertised as being supported even when they were disabled
 in the configuration.  This caused problems with some end points.
 
 (issue ASTERISK-15787)
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=283559
By: Digium Subversion (svnbot) 2010-08-25 10:56:03

Repository: asterisk
Revision: 283560

_U  trunk/
U   trunk/channels/chan_sip.c
U   trunk/channels/sip/include/sip.h

------------------------------------------------------------------------
r283560 | dvossel | 2010-08-25 10:56:03 -0500 (Wed, 25 Aug 2010) | 23 lines

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

................
 r283559 | dvossel | 2010-08-25 10:54:11 -0500 (Wed, 25 Aug 2010) | 16 lines
 
 Merged revisions 283558 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ........
   r283558 | dvossel | 2010-08-25 10:52:54 -0500 (Wed, 25 Aug 2010) | 10 lines
   
   Asterisk will not advertise session timers are supported when 'session-timers=refuse' is used.
   
   Asterisk now dynamically builds the "Supported" header depending
   on what is enabled/disabled in sip.conf.  Session timers used
   to always be advertised as being supported even when they were disabled
   in the configuration.  This caused problems with some end points.
   
   (issue ASTERISK-15787)
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=283560
By: David Vossel (dvossel) 2010-08-25 11:21:34

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.
By: Digium Subversion (svnbot) 2010-09-08 16:47:31

Repository: asterisk
Revision: 285563

U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r285563 | dvossel | 2010-09-08 16:47:30 -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 ASTERISK-15787)
Reported by: alexrecarey


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

http://svn.digium.com/view/asterisk?view=rev&revision=285563
By: Digium Subversion (svnbot) 2010-09-08 16:48:38

Repository: asterisk
Revision: 285564

_U  branches/1.8/
U   branches/1.8/channels/chan_sip.c

------------------------------------------------------------------------
r285564 | dvossel | 2010-09-08 16:48:38 -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 ASTERISK-15787)
 Reported by: alexrecarey
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=285564
By: Digium Subversion (svnbot) 2010-09-08 16:52:09

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 ASTERISK-15787)
   Reported by: alexrecarey
 ........
................

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

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