[asterisk-dev] Require header

[Mark Michelson]

On 11/01/2012 09:59 AM, Olle E. Johansson wrote:
> 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.

We're not continuing with a poor implementation. We're fixing the 
problem on the UAS side. My concern is with interoperability at this 
point when Asterisk is the UAC. It's not a matter of saving a few 
transactions, it's a matter of avoiding confusion between the endpoints.

Consider the following scenario. Asterisk A is a version of Asterisk 
running patched as you suggest, and Asterisk B is a version of Asterisk 
such as 1.8.0 that does not include "Require: timer" in its 200 OK.

Asterisk A sends an INVITE with "Supported:timer" and "Session-Expires: 
3600".

Asterisk B inspects this INVITE and sees the "Supported: timer" and 
Session-Expires headers. This value is greater than Asterisk B's locally 
configured maximum of 900 seconds. So Asterisk B sends a 200 OK with no 
"Require: timer" header but with a "Session-Expires: 900;refresher=uac".

Now Asterisk A gets this 200 OK. Since there is no "Require: timer" 
header present, Asterisk A does not look at the Session-Expires header 
that Asterisk B sent back. (At least this is how I've interpreted your 
suggestion. If this is incorrect, please let me know).

At this point, Asterisk A thinks that the session is 3600 seconds and 
will refresh after 1800 seconds. Asterisk B thinks that the session is 
900 seconds and will end the call if it does not receive a refresh 
within 900 seconds.

The result is unexpected no matter which side of the call you're on. 
Asterisk A will find it odd that Asterisk B is suddenly ending the 
session after 900 seconds and Asterisk B will find it odd that it didn't 
get any session refreshes in the interval that it expected. Even though 
Asterisk B is technically in the wrong for not sending "Require: timer" 
in its 200 OK, Asterisk A could reasonably assume Asterisk B's intent 
based on the presence of the Session-Expires header in the 200 OK.

Now consider that you're an Asterisk administrator and you administer 
Asterisk A. You upgrade your box to the latest 1.8, and it contains the 
patch as you suggested. Asterisk B is some SIP provider or some other 
remote endpoint that you communicate with regularly. Prior to the 
upgrade, everything worked fine with regards to session timers, but now 
things appear broken. In the eyes of a user, the fact that we're being 
more strict with what we receive is a bug, a regression in behavior. We 
will get bug reports because things are "broken" now.

Can you see why I might want to continue with a "poor" implementation if 
it means that users get the behavior they expect?

Mark Michelson

>
> /O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev