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