[asterisk-dev] Require header

[Olle E. Johansson]

1 nov 2012 kl. 15:46 skrev Mark Michelson <mmichelson at digium.com>:

> 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/ .

What would happen if you actually parse the Require header? If there's no such header, we'll still run session timers but ALWAYS run it on our side. If they do too, fine. That will be compatible with earlier Asterisk implementations too, and be compliant with the RFCs. Communication will work as expected, if one end falls from the network, the call will go down.

If there's a require header, we can trust them to run refreshes if they say they want to. Fine, we save a few transactions.

Please do it right this time instead of continuing with a poor implementation. We've had too many years of that.

/O