Subject: [Sip] Session Timer: UAC populating the refresher parameter

From: Hisham Khartabil <[email-masked]>
Date: Thu, 7 Apr 2005 23:07:39 +0200

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 mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Apr 2005 17:54:29 -0400

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:
> 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.
> 
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

---

From: [email-masked]
Date: Fri, 8 Apr 2005 10:38:35 +1000

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Apr 2005 09:10:09 -0400

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

> 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

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.

> behaviour in section 8.2 queried below does indeed seem to sort itself out

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Apr 2005 11:13:49 -0400

inline.

> when initiating the INVITE. The claim was that the draft does not 

It doesnt forbid lots of things. However, it is not supposed to do that, 
and this is not a good idea.

> refresher parameter that contained 'uas' which will cause all sorts of 

Right. It would have been OK to insert the whole thing had the UAC not 
done the wrong thing.

> (which is what I prefer) or add some text clarifying the scenario and 

Its too late to clarify this, unfortunately, since the spec is about to 
issue as an RFC. However, Please tell those folks that this is not a 
correct implementation.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com