[asterisk-dev] [Code Review]: SIP session timers: Add Require: timer to appropriate responses

[Mark Michelson]

> On Oct. 31, 2012, 11:58 a.m., Olle E Johansson wrote:
> > @matt: I did not require anything or refer to any policy. Please calm down.
> > 
> > Now, do we parse incoming Require: headers to our INVITE? That part is also in my code. If the other side does NOT add a Require header we're running stand-alone mode, but can still activate session timers. If the other side adds a Require header, we're in the play.

I just want to make sure I understand this comment before I add a new revision:

"do we parse incoming Require: headers to our INVITE?"

Are you asking if we parse Require headers in responses to our INVITE? If that's the question, then no we do not in current 1.8. Based on my reading of RFC 4028, I don't think it's really necessary for us to read a Require header in a response. Let's go over the various scenarios where Asterisk is the one placing the original INVITE:

* session-timers=originate
  * session-refresher=uac
    When Asterisk sends an INVITE out, it includes a Supported: timer header and a Session-Expires header.
    In this situation, the far end MUST send Require: timer in the 200 OK. We don't look for this header, but we do look for a Session-Expires header to determine the refresh interval. If the far end overrides our refresher preference, then we'll honor their preference.

  * session-refresher=uas
    When Asterisk sends an INVITE out, it includes a Supported: timer header and a Session-Expires header.
    In this situation, the far end SHOULD send Require: timer in the 200 OK. We don't look for this header, but we do look for a Session-Expires header to determine the refresh interval. If the far end overrides our refresher preference, then we'll honor their preference.

* session-timers=accept
  In this mode, Asterisk's behavior is the same no matter what session-refresher is set to.
  When Asterisk sends an INVITE out, it includes a Supported: timer header and a Session-Expires header.
  In this situation, the far end SHOULD send Require: timer in the 200 OK. We don't look for this header, but we do look for a Session-Expires header to determine the refresh interval. We will let the far end decide who the refresher is.

* session-timers=refuse
  In this mode, Asterisk's behavior is the same no matter what session-refresher is set to.
  When Asterisk sends an INVITE out, it does not include a Supported: timer header, nor does it include a Session-Expires header.
  In this situation, RFC 4028 does not explicitly say whether the UAS should or should not include a Require: timer header in the 200 OK. In this situation, Asterisk does not inspect the Require header and it will also ignore the Session-Expires header in the 200 OK response. In theory, this is because Asterisk is refusing to use session timers. In such a case, the UAS would be responsible for all refreshes, and Asterisk simply does not care about session expiry. Whether this is actually compliant, I'm not sure, since it appears that the UAS is the entity that gets to decide in the end whether there is a session timer in use or not.

So let's sum up. In every case where there might be a Require: timer, there will also be a Session-Expires header. If we're looking at the Session-Expires header, then is it really necessary for us to also inspect the Require header? Does the presence of a Require header in addition to a Session-Expires header change how we should behave? I don't think it does, actually. Looking at your branch, you get the Require header value but all you do is print a debug message if it was set to "timer". There's no additional processing done.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2172/#review7345
-----------------------------------------------------------


On Oct. 31, 2012, 11:05 a.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2172/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2012, 11:05 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch makes it so Asterisk adds Require: timer when appropriate when sending INVITE responses.
> 
> If session timers are in use, then there are two situations under which we'll add the header:
> 
> 1) We are sending a 200 OK with a Session-Expires header that has a refresher parameter of "uac"
> 2) We are sending a 200 OK with a Session-Expires header that has a refresher parameter of "uas" and the INVITE to which we are responding had a Supported: timer header in it.
> 
> This patch also introduces another change. Prior to this change, the only way we would add a Session-Expires header in an INVITE response was if the inbound INVITE had a Supported: timer header in it. Now we always add this header if Asterisk using session-timers=originate. This is based on a table in section 9 of RFC 4028. It indicates that if the UAC does not support Session-Timers but the UAS does, then the UAS should send a Session-Expires header with a refresher parameter of "uas".
> 
> 
> This addresses bug ASTERISK-20570.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20570
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 375481 
>   /branches/1.8/channels/sip/include/sip.h 375481 
> 
> Diff: https://reviewboard.asterisk.org/r/2172/diff
> 
> 
> Testing
> -------
> 
> Tried the following three scenarios that should have resulted in Asterisk sending a 200 OK with a Require: timer:
> 
> 1. INVITE with refresher=uac
> 2. INVITE with refresher=uas
> 3. INVITE with no Session-Expires but with Supported: timer
> 
> I also tried the following scenario that should result in a 200 OK with a Session-Expires (refresher=uas) but no Require: timer header:
> 
> INVITE with no Supported: timer header present.
> 
> I plan on turning this into a testsuite test as well.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121031/78d56949/attachment.htm>