[Home]

Summary:ASTERISK-19942: SIP Session Timers do not honour refresher
Reporter:Jon Bonilla (manwe)Labels:
Date Opened:2012-06-02 06:54:43Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/Interoperability
Versions:SVN 1.8.8.2 1.8.10.1 1.8.13.0 13.18.4 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-25469 chan_sip enabled unnegotiated session-timers after reINVITE if session-minse is non-default.
Environment:SIP communication between Asterisk 1.8 versions and Sems 1.4.X stable releases. Used Linux Debian 6.0Attachments:( 0) scenario4_asterisk_log_full.txt
( 1) scenario4_asterisk_sip.conf
( 2) scenario4.pcap
( 3) scenario5_asterisk_log_full.txt
( 4) scenario5_asterisk_sip.conf
( 5) scenario5.pcap
Description:Tested different session-timer settings in sip.conf and asterisk does not honour refresher. It sends INVITE requests when it should not ot does not send any when it should. Depends on the configuration or scenario. Tested several scenarios to report. I'll add scenarios in notes.
Comments:By: Jon Bonilla (manwe) 2012-06-02 06:57:22.769-0500

Scenario 1:

Asterisk 1.8.8 and 1.8.10 tested as Caller
Sems 1.4.3 tested as Callee

Session-timer configuration:
session-timers=accept
session-refresher=uas


* Asterisk sends INVITE with supported: timer
* Sems sends 200 OK with session-expires: 300;refresher=uas
=> Sems sets sems as refresher  

After 150 seconds (300/2)

* Sems sends INVITE with session-expires: 300
* Asterisk sends 200 OK with session-expires: 300;refresher=uas
=> Asterisk sets Asterisk as refresher  

After 300 seconds

* Asterisk has not sent any INVITE within 300 seconds
* Sems sends BYE for 300 second timeout (Asterisk didn't refresh)




By: Jon Bonilla (manwe) 2012-06-02 06:59:34.307-0500

Scenario 2:

Asterisk 1.8.8 as Caller
Sems 1.4.2 as Callee

Session-timer configuration:
session-timers=originate
sesseion-refresher=uac


* Asterisk sends INVITE session-expires: 120
* Sems sends 200 OK session-expires: 120;refresher=uas
=> Sems sets refresher sems

After 60 seconds (120/2)

* Sems sends INVITE session-expires: 120
* Asterisk sends 200 OK session-expires: 120;refresher=uac
=> Asterisk sets refresher sems

After 60 seconds

* Sems sends INVITE session-expires: 120
* Asterisk sends INVITE session-expires: 120;refresher=uac
* Asterisk sends 491 to sems' INVITE
* Sems sends ACK to 491
* Sems sends 200 OK session-expires: 120;refresher=uas
=> Sems sets refresher sems


This last block is repeated every minute

After the first INVITE, Asterisk is not honouring the refresher setting and it's sending REINVITEs


By: Jon Bonilla (manwe) 2012-06-02 07:16:49.170-0500

Scenario 3:

Asterisk 1.8 svn 368358 as Caller 92.42.136.20:6666
Sems 1.4.2 as callee 77.244.249.120:5060

Session Timer configuration:
session-timers=originate
refresher=uas


Asterisk A
Sems B
Originate
refresher uas
120 seconds

I'm pasting a ngrep capture. I removed provisional responses, sdp bodies and all non-relevant headers. Some comments inline:


#
##Asterisk sends INVITE with sst enabled
#
U 2012/06/02 13:21:02.832903 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:4313012023@77.244.249.120:5060 SIP/2.0'
User-Agent: Asterisk PBX'
Date: Sat, 02 Jun 2012 11:21:02 GMT'
Session-Expires: 120'
Min-SE: 90'
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH'
Supported: replaces, timer'


#
## Sems sets sems as refresher
#
U 2012/06/02 13:21:10.257044 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'
Content-Type: application/sdp'


#
## Asterisk immediatly sends another INVITE
#
U 2012/06/02 13:21:10.261971 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120;refresher=uas'
Min-SE: 90'


#
## Sems sets sems as refresher
#
U 2012/06/02 13:21:10.312392 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'

######################################################

#
## Asterisk sends the REINVITE
#
U 2012/06/02 13:22:02.783205 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120;refresher=uas'
Min-SE: 90'


#
## Sems set sems as refresher
#
U 2012/06/02 13:22:02.812606 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'


#######################################################

#
## Again Asterisk sends the REINVITE
#
U 2012/06/02 13:23:02.807523 77.244.249.120:5060 -> 92.42.136.20:6666
INVITE sip:jbonilla@92.42.136.20:6666 SIP/2.0'
Session-Expires: 120'
Min-SE: 90'


#
## Sems set sems as refresher
#
U 2012/06/02 13:23:02.808463 92.42.136.20:6666 -> 77.244.249.120:5060
SIP/2.0 200 OK'
Session-Expires: 120;refresher=uas'


########################################################

#
## Asterisk sends the INVITE without any Session-expires header
# I leave all the headers here
#
U 2012/06/02 13:25:02.808766 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Via: SIP/2.0/UDP 92.42.136.20:6666;branch=z9hG4bK4b2938b1;rport'
Route: <sip:77.244.249.120;r2=on;lr=on;ftag=as6eef26d2;ngcplb=yes>,<sip:127.0.0.1;r2=on;lr=on;ftag=as6eef26d2;ngcplb=yes>,<sip:127.0.0.1:5062;lr=on;ftag=as6eef26d2;did=585.6768f29>,<sip:127.0.0.1:5062;lr=on;ftag=as6eef26d2;mpd=ii;rtpprx=yes;vsf=Q2FDdTxqDjMhCB1YbyhXM19wb3dDY1gY>'
Max-Forwards: 70'
From: "jbonilla" <sip:jbonilla@sipwise.com>;tag=as6eef26d2'
To: <sip:4313012023@77.244.249.120:5060>;tag=210FA359-4FC9F71E000D085E-44C11700'
Contact: <sip:jbonilla@92.42.136.20:6666>'
Call-ID: 4f0a78713e2f1e54092ad79269b821c0@sipwise.com'
CSeq: 105 INVITE'
User-Agent: Asterisk PBX'
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH'
Supported: replaces, timer'
Content-Type: application/sdp'
Content-Length: 278'


#
## Sems sets sems as refresher with it's own timming 900
#
U 2012/06/02 13:25:02.866416 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 900;refresher=uas'


#
## Immediatly asterisk sends BYE
#
U 2012/06/02 13:25:02.867620 92.42.136.20:6666 -> 77.244.249.120:5060
BYE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
User-Agent: Asterisk PBX'
X-Asterisk-HangupCause: Normal Clearing'
X-Asterisk-HangupCauseCode: 16'
Content-Length: 0'


From Asterisk console:

[Jun  2 13:25:02] WARNING[20557]: chan_sip.c:26076 proc_session_timer: Session-Timer expired - 4f0a78713e2f1e54092ad79269b821c0@sipwise.com
 == Spawn extension (default, 9999, 2) exited non-zero on 'SIP/manwetest-00000004





By: Jon Bonilla (manwe) 2012-06-02 07:32:00.715-0500

Scenario 4:

Asterisk 1.8 svn 368358 as Caller 92.42.136.20:6666
Sems 1.4.2 as callee 77.244.249.120:5060

Session Timer configuration:
session-timers=originate
refresher=uac


I'm pasting a ngrep capture. I removed provisional responses, sdp bodies and all non-relevant headers. No comments:

#############################################################

U 2012/06/02 13:40:07.839129 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:4313012023@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120'
Min-SE: 90'



U 2012/06/02 13:40:20.630729 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'



U 2012/06/02 13:40:20.634583 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120;refresher=uas'
Min-SE: 90'


U 2012/06/02 13:40:20.689781 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'



#############################################################

U 2012/06/02 13:41:07.922084 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120;refresher=uas'
Min-SE: 90'


U 2012/06/02 13:41:07.989247 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'



#######################################################################



U 2012/06/02 13:42:07.983411 77.244.249.120:5060 -> 92.42.136.20:6666
INVITE sip:jbonilla@92.42.136.20:6666 SIP/2.0'
Session-Expires: 120'
Min-SE: 90'



U 2012/06/02 13:42:07.984315 92.42.136.20:6666 -> 77.244.249.120:5060
SIP/2.0 200 OK'
Session-Expires: 120;refresher=uac'



########################################################################



U 2012/06/02 13:43:07.984164 92.42.136.20:6666 -> 77.244.249.120:5060
INVITE sip:ngcp-lb@77.244.249.120:5060 SIP/2.0'
Session-Expires: 120;refresher=uac'
Min-SE: 90'



#
U 2012/06/02 13:43:08.038084 77.244.249.120:5060 -> 92.42.136.20:6666
SIP/2.0 200 Ok'
Session-Expires: 120;refresher=uas'


...
...
...


By: Rusty Newton (rnewton) 2012-06-04 19:55:23.994-0500

Jon, can you attach the sip.conf configuration for the Asterisk 1.8.X systems, and include a full pcap of a call demonstrating the issue along with corresponding asterisk full log (with DEBUG and VERBOSE level 5)?

By: Jon Bonilla (manwe) 2012-06-06 04:09:05.663-0500

Attached sip.conf, sip pcap (rtp has no sense here) and asterisk full log for a scenario4 sample call.

By: Jon Bonilla (manwe) 2012-06-06 05:03:06.453-0500

Trying to reproduce scenario1, found another issue. Asterisk sends the REINVITE in the last second (after 120seconds of a sesseion-expires of 120 seconds) and right away a BYE because session-timer expiration.

By the way, I found that some related issues regarding session timer (ie scenario 1) were already reported for branch 1.6


ASTERISK-17409

ASTERISK-16801 (https://issues.asterisk.org/view.php?id=18127)


By: Olle Johansson (oej) 2012-06-28 01:02:59.517-0500

Jon, notice that Asterisk does not send any require-header in the responses. If I'm right, it means that there's no agreement on using session-timer. From the PCAP it seems like SEMS is missing this part as well. Asterisk doesn't parse the require header in the response either.

See section 9 of RFC 4028. The require header in the response means "I'm applying this extension that you offered or required to this response". This is a MUST if a UA requires the other side to send the refreshes and a SHOULD otherwise. Without the require header, you can't expect the other side to perform refreshes and you don't know if the other side really use session-timers. You can guess that if they add the headers in the response they do though.

I currently have no resources to work with this, but discovered this as I am working with another SIP extension and noticed that Asterisk doesn't fully support the use of extensions with Supported/Required headers. Asterisk handles it in requests, but do not parse responses, so it doesn't bother with the other side's opinion about the use of an extension.

By: Jon Bonilla (manwe) 2012-10-17 16:14:49.741-0500

Taken from a comment in another place where I've been talking about this issue and interoperability tests:

it's the Session-Expires header that indicates how
SST are applied, and if the UAS says 'refresher=uas' then the UAS is
supposed to do the refresh.

The bit regarding the Require and why it's a MUST is explicitely
explained:
"""
If the refresher parameter in the Session-Expires header field in the
   2xx response has a value of 'uac', the UAS MUST place a Require
   header field into the response with the value 'timer'.  This is
   because the uac is performing refreshes and the response has to be
   processed for the UAC to know this.
"""

If asterisk doesn't compute the refresher role properly, it should not
add Session-Expires header in the first place (it can still do
refreshes as it likes, regardless of what intervals are negotiated or
not).

By: Malcolm Davenport (mdavenport) 2014-05-29 16:56:41.025-0500

There've been a number of changes to SIP sessions timers in Asterisk since this report.  Have you have a chance to test any newer version of 1.8?

By: Rusty Newton (rnewton) 2014-06-16 09:55:13.707-0500

Can any one confirm if the issue still exists in a recent version?

By: Walter Doekes (wdoekes) 2014-06-16 10:15:42.004-0500

I ran into one today on my patched asterisk 10 (which should have the latest related patches).

The scenario went like this:

t0- asterisk called peer
t0- peer picked up
(no session timers)

t100- peer reinvited (on-hold)
t100- asterisk added session-timers (1800, refresher=uac, even though peer has no Supported:timer)

t200- peer reinvited (off-hold)
t200- asterisk added session-timers (1800, refresher=uac, even though peer has no Supported:timer)

t1968- asterisk dropped the call after 1800-32 seconds

By: Walter Doekes (wdoekes) 2015-10-16 04:03:43.805-0500

I can confirm that the problem that I had, still exists in the recent 11.19. In my case, it turned out that one extra condition has to be met: the session-minse has to be unequal to the DEFAULT_MIN_SE. But I guess it's a separate problem from the original reporter. I'll go file a new one.