[asterisk-dev] Require header

Thu Nov 1 13:22:50 CDT 2012

1 nov 2012 kl. 17:07 skrev Mark Michelson <mmichelson at digium.com>:

> 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.
What you describe is definitely a problem. I missed that. 
It only applies if the other end suggest refresher: uac, but yes, that would be bad.

> 
> 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?
Let's implement a flag where the admin can select to be backwards compatible with previous Asterisk versions. You've convinced me that we need it. Enable it by default in old releases, disable it in trunk.

If old Asterisk communicates with other implementations, the SIP session timer implemenetation has been so bad and has broken down calls, so in all my installations we've been forced to turn it off. I don't know if anyone with two asterisks really use this, since we do have the RTP checks as well and have no silence suppression.

I do really want this to be correct so I can interoperate correctly with other implementations and turn it on again. Since most of the code is written, it can't be a huge task to enable it.

/O

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