Paul, Let me start by saying that I agree that the simplest implementation (preferred) would be to leave the refresher parameter not specificied in the request, it is what is recommended in the draft. But I do not think specifying the refresher in the request is stupid and to me it seems clearly allowed in the draft.
I'm not saying that setting the refresher parameter in the request is stupid in general. I am saying that setting the the *uac* setting the refresher parameter to *uas* is contrary to the spirit, if not the letter, of the spec, so doing *that* is stupid.
Leaving the refresher unspecified in the request is deemed 'negotiation' but the UAS can set the refresher in the response to either UAC or UAS,
The UAS has the information to know that the UAC is capable of carrying out the task - it has been presented with an option and the ability to choose.
The same situation does not hold for the UAC - it has no way of knowing if the UAS will be capable of carrying out the task. If it were legal for the UAC to do this (specify UAS as refresher), then in cases where the UAS is incapable of this the negotiation would fail, even though the UAC is presumably capable (though not desiring) of doing so.
By doing this, if it is considered legal, the UAC is saying "I understand session timer, I would like session timer to be used, but I am unwilling to be responsible for doing it and would rather not have it than take responsibility for doing it."
so it is set by local policy at the UAS yeah ?, which is not really a negotiation it is just letting the other guy choose.
No, it is more complex than that. The interesting case is when only one end is capable of doing it, but somebody in the middle wants it. In that case, the guy in the middle gets to choose.
Both UAC and UAS that support session timer are to be capable of performing the session refreshes so I don't really see the harm. The behaviour in section 8.2 queried below does indeed seem to sort itself out for the given scenario.
Something people keep forgetting (or don't realize) is that session timer is of no particular benefit to UAs - it is there for the benefit of proxies that record-route and need a way of knowing that the dialog has not died.
In the absence of a proxy that cares, UAs are free to test liveness of the dialog any time they want, by sending a request in the dialog. So there is no good reason for a UA to propose use of session timer on its own.
Cases of importance are: - proxy wants, uac & uas support => uas choses who does - proxy wants, uac support, uas doesn't => proxy nominates uac - proxy wants, uac doesn't support, uas does => proxy nominates uas - proxy wants, neither uac nor uas support => doesn't happen
The case being discussed here adds another case: - uac wants uas to do, proxy wants, uas doesn't do => doesn't happen
Paul
Regards - Wayne.
I think the implementation is just being stupid.
The whole point is to negotiate who does refreshes, so you discover someone who can if there is anybody who can. Declaring that the other guy should do it violates that. So I think this is clearly not within the intent of the spec, even if the wording could be better.
Paul
Hisham Khartabil wrote:
This came up at sipit 16.
draft-ietf-sip-session-timer-15.txt says in section 7.1:
"The UAC MAY include the refresher parameter with value 'uac' if it wishes to perform the refreshes. However, it is RECOMMENDED that the parameter be omitted, so that it can be selected by the negotiation mechanisms described below."
I came across an implantation that sets the refresher parameter to 'uas'
when initiating the INVITE. The claim was that the draft does not explicitly forbid that.
The problem with that is: what if the UAS does not support session timer. The spec says in section 8.2 (proxy processing responses)
"If, however, the proxy remembers that the UAC did support session timer, additional processing is needed.
Because there is no Session-Expires or Require header field in the response, the proxy knows it is the first session-timer-aware proxy to receive the response. This proxy MUST insert a Session-Expires header field into the response with the value it remembered from the forwarded request."
Some proxies may interpret that to mean the whole value, including the refresher parameter that contained 'uas' which will cause all sorts of funny things to happen.
Now, the draft does go on to say
" It (the proxy) MUST set the value of the 'refresher' parameter to 'uac'."
so the problem my fix itself, but i think we need to clarify this: either say that the UAC MUST NOT set the refresh parameter to 'uas' (which is what I prefer) or add some text clarifying the scenario and behaviour for proxies.
Regards, Hisham
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
********************************************************************** Any personal or sensitive information contained in this email and attachments must be handled in accordance with the Victorian Information Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988 (Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute, copy or use the information contained in this email or attachments. Any confidentiality or privilege is not waived or lost because this email has been sent to you in error. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. **********************************************************************
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
