[asterisk-dev] Require header

[Mark Michelson]

On 11/01/2012 03:02 AM, Olle E. Johansson wrote:
> Mark,
>
> Look in RFC 3261 for a discussion on the Supported: and the Require header for SIP extension handling. Use vulcan logic: If we should not parse the require header - why bother at all with adding it? ;-)
>
> In SIP, a user agent announces extensions support with the supported header. If the response contains a Require header with one or more of the offered extensions named, the response indicates that the extension will be used for this dialog.

Yep, I'm aware of the concept. It was an oversight on our part not to 
include "Require: timer" in 200 OK responses when session timers support 
was first implemented.
>
> Now, session timers have an extra mode. If there is NO require header in the response, the UAC may still run refreshes, since these are just ordinary in-dialog requests and doesn't hurt communication. In this case the UAC is always the refresher, since the other party does not understand the extension.  This has been the state when any UAC has sent Asterisk offers of session timers - nothing activates, they run Session timers and have not trusted Asterisk to do it, since Asterisk never said it would.

Yep, and this is why there's a review up to add "Require: timer" to 200 
OK responses when session timers are in use.
> RFC 4208 is clear about this:
>
> It is
>     possible that the UAC requested the session timer (and thus included
>     a Session-Expires header field in the request) and that there was no
>     Require or Session-Expires header field in the 2xx response.  This
>     will happen when the UAS doesn't support the session timer extension
>     and only the UAC has asked for a session timer (no proxies have
>     requested it).  In this case, if the UAC still wishes to use the
>     session timer (which is purely for its benefit alone), it has to
>     perform them.  To do this, the UAC follows the procedures defined in
>     this specification as if the Session-Expires header field were in the
>     2xx response, and its value was the same as that in the request, but
>     with a refresher parameter of 'uac'.
>
> So if we have a Require-header in the response, we can parse the response headers and potentially let the other side do the refreshes and trust that it happens - since they have expressed an agreement on using the extension.

See, here's where things get interesting. Session timers have the 
requirement that if a UAS supports session timers, they have to put a 
Session-Expires header in the response. There's never a "potentially let 
the other side do refreshes and trust that it happens." The response 
MUST contain a Session-Expires header that explicitly states what the 
refresh interval is and who the refresher for the dialog is.
> If there is no Require header with "timer" in the response, we're all alone and have to decide if we still want to play the session timer game.

Except that we have to interoperate with versions of Asterisk that were 
released before the addition of "Require: timer" to the 200 OK. If we 
get a 200 OK from Asterisk that has no "Require: timer" in it but has a 
Session-Expires header with ";refresher=uas" then we have to assume that 
even though the UAS is not following guidelines properly, they will be 
the one to do the refreshes. I would say that we need to see both a 
"Require: timer" and a Session-Expires header, but then we would behave 
unexpectedly when used with earlier versions of Asterisk.
>
> I hope this clarifies.
>
> ...now I need to update my slides for the SIP Masterclass with the very same explanation. Always good to discuss these matters. :-)

Yep, this is one of those issues where if things were done correctly the 
first time, then we wouldn't have the current mess.

In a "be liberal in what you accept but strict in what you send" sort of 
manner, let me propose what I think will work best:

1) As the UAS, we will send "Require: timer" as RFC 4028 mandates. The 
only time we will not send "Require: timer" is if we as the UAS will be 
doing the refreshes and the UAC had no "Supported: timer" header in the 
INVITE. In this way, we should be compliant with RFC 4028. If, as a UAS, 
Asterisk was not working with certain endpoints previously, it should now.

2) As the UAC, if we find a Session-Expires header in a 200 OK response, 
we will assume there is an implied "Require: timer" header as well. This 
allows for us to interoperate with earlier versions of Asterisk 
properly, and as far as I can tell, it won't hurt our ability to 
interoperate with other user agents either. From a pure "following the 
RFC" perspective, this is wrong, but I don't think this should actually 
cause an issue.

As it happens, this is how it works in the code review I currently have 
up at https://reviewboard.asterisk.org/r/2172/ .

Mark Michelson

>
> /O
>
>
> --
> * Olle E. Johansson - oej at edvina.net
> * Kamailio & SIP Masterclass Miami FL December 2012
> * http://edvina.net/training/
>
>
>
>