Summary:	ASTERISK-16801: Session timer refresher role swap on reinvite requested, but not not honoured
Reporter:	Alex Balashov (abalashov)	Labels:
Date Opened:	2010-10-12 21:21:00	Date Closed:	2011-07-27 13:22:52
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	In Asterisk >= 1.6.2.12 (and, as far as I can tell, earlier releases that have SST support as well), Asterisk appears to request a refresher role swap relative to the original refresher roles established in the initial INVITE that set up the session/dialog, but does not actually perform the refreshes.   The call path (INVITE) in my testing scenario is:   (Asterisk) --> (B2BUA) In the 200 OK that establishes the dialog (the response to the initial INVITE), Asterisk receives the SST headers:    Supported: timer    Session-Expires: 120;refresher=uas This establishes the UAS (the B2BUA) as the refresher for this session.  The refresh interval on the B2BUA is set to 60 seconds, and the timeout to 120 seconds.  This means that Asterisk expects the B2BUA to send the reinvites (or UPDATEs) for session timer maintenance. Consistently with this fact, 60 seconds later the B2BUA sends a reinvite to Asterisk with the following headers:   Supported: timer   Session-Expires: 120   Min-SE: 90 Curiously, Asterisk responds to this reinvite with a 200 OK that designates itself as the refresher:   Supported: replaces, timer   Session-Expires: 120;refresher=uas Because Asterisk is the UAS relative to the direction of this reinvite (it is sent by the B2BUA, which is the UAC, to Asterisk, which is the UAS), the B2BUA concludes that Asterisk will now be performing the refresh reinvites. Asterisk does not, however, actually send any reinvites, so at 120 seconds, the B2BUA sends a BYE ending the call.   That very behaviour is the substance on which this bug report is predicated. ****** ADDITIONAL INFORMATION ****** For reference, the B2BUA in question is IPTel's SIP Express Media Server v1.3.0. The SIP Session Timer mechanism is specified in RFC 4028. According to section 7.4 of RFC 4028, the designation of 'uac' and 'uas' refresher roles is relative to the current INVITE transaction, and not to the initial INVITE transaction that opened the session.   David Vossel has reviewed this bug report and concurs with my finding, and suggests that the session timer-related code in chan_sip is not aware of the possibility of a reversal of the initial refresher roles mid-call by way of the aforementioned process.   I believe that there are two options here for resolution: 1) Make Asterisk not send ;refresher=uas in such a scenario, and any other logically congruent scenarios, and/or make it send ;refresher=uac.  This is provided that the other end supports timers, of course, otherwise it is not possible for Asterisk to be the refresher anyhow. 2) Allow Asterisk to send ;refresher=uas in such a scenario, and then honour the obligations of being the new refresher by sending periodic reinvites/updates as the standard specifies.
Comments:	By: David Vossel (dvossel) 2010-10-13 15:10:05 I've looked into this issue and I believe I understand what is causing this, but at the moment I do not have the time resources to address this. In the mean time, as a potential workaround try setting the session-refresher=uac option in sip.conf.  I believe this role reversal will only occur for Asterisk with the refresher is negotiated to be the UAS. By: Alex Balashov (abalashov) 2010-10-13 15:52:55 What happens if we just do session-timers=refuse? By: David Vossel (dvossel) 2010-10-13 16:57:54 We will ignore session timers entirely.  I believe at that point the other endpoint can do session timers for their own benefit as long as they don't tell Asterisk that timer support is required. By: Alex Balashov (abalashov) 2010-10-13 16:58:50 session-refresher=uac had no effect;  it results in identical behaviour to the packet capture I sent you. We are testing the refuse option now. By: Russell Bryant (russell) 2011-07-27 13:22:47.147-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!