Summary: | ASTERISK-19942: SIP Session Timers do not honour refresher | ||||
Reporter: | Jon Bonilla (manwe) | Labels: | |||
Date Opened: | 2012-06-02 06:54:43 | Date Closed: | |||
Priority: | Major | Regression? | |||
Status: | Open/New | Components: | 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: |
| ||||
Environment: | SIP communication between Asterisk 1.8 versions and Sems 1.4.X stable releases. Used Linux Debian 6.0 | Attachments: | ( 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. |