Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE with Require an d Support timer and Session-Expires

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 02:16:27 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 10:20 PM
> To: 'Jonathan Rosenberg'; [email-masked]
> Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE 
> with Require
> and Support timer and Session-Expires
> 
> 
> Jonathan, 
> 
> Thanks for the response.  Comments inline.
> 
> > > What should happen if a UAC sends an INVITE 
> > > with Session-Expires and both Supported timer 
> > > and Require timer?
> > 
> > The Require implies Supported, so the behavior would be 
> > identical to the
> > case where just Require were present. This is probably an issue best
> > addressed in the Supported header specification, since its 
> > more general than
> > session timer.
> 
> The "Require implies Supported" needs to be 
> reflected in the timer draft since Table 3 
> is otherwise misleading if UAC includes 
> Require timer with session-expires without 
> Supported timer.

Good point.

> 
> If a UAC both requires and supports an option-tag, 
> should it include it in both headers?  

Its redundant. If it requires it, wouldn't that be because it supports it?

> 
> Isn't the "require implies supported" going to limit 
> devices that want to require others to support an 
> extension without them actually supporting it?

I can't think of a case where such a thing would make sense. Do you have a
specific example?

> 
> > > 
> > > What should happen if the UAS responds to such 
> > > a request and includes the same the three 
> > > headers and values?  Are both now effectively 
> > > responsible for sending refreshes?  Or is the 
> > > UAS forbidden from sending such a response?
> > 
> > These are good questions. A lot of it depends on what we mean 
> > when Require
> > is placed in the request. In principal, its quite useless. 
> > Require normally
> > means "don't process the request unless you understand the 
> > extension". But,
> > session timer works just fine even if the UAS doesn't support 
> > the extension.
> > So, based on this definition, inserting it has zero meaning. 
> > However, one
> > might think that Require in the INVITE means, "UAS, you 
> should do the
> > refreshes". 
> > 
> > I'm inclined to be consistent with normal Require usage. In 
> > this case, the
> > presence of Require in the INVITE has no impact on processing 
> > at the UAS if
> > it supports the extension. UAC will do the refreshes. If the 
> > UAC wants the
> > UAS to do them, the UAC can insert the Session-Timer 
> header, but not a
> > Supported header. This will result in the UAS doing them if 
> > it supports it,
> > otherwise there won't be session timers. 
> 
> Sounds fine.
> 
> It has some restrictions since the Supported 
> and Require headers are still being used to indicate 
> who is refreshing instead of what is supported 
> and required. 

Hmm, this is a good point. I am definitely overloading Supported and Require
to convey this information. I would be amenable to being more explicit about
it through a Session-Expires parameter, as you suggest. THis might simplify
the draft quite a bit, but there are folks who have implementations already
that might not like it (then again, it might be compatible anyway).

Anyone?

> However without an extra parameter 
> in Session-Expires to indicate who is refreshing, 
> I can't think of a better solution.
> 
> Actually the same parameter could be used to allow 
> for smaller Session-Expires values which are not to 
> be refreshed.
> 
> Session-Expires  =  
>   ("Session-Expires" | "x") ":" 
>               ( SIP-date | delta-seconds ) [refresher]
> 
> refresher = ";" "refresher" "=" "uas"|"uac"|"none"
> 

What would be the usage of none? I don't see the value in that...??

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.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: "Brett Tate" <[email-masked]>
Date: Tue, 26 Jun 2001 13:17:05 -0400

> Its redundant. If it requires it, wouldn't that be because it 

It depends on if the requires option-tag was 
added by a proxy or a UA.  For instance, the proxy
currently can add timer to Require header in 2xx
responses as a means to indicate who is supposed 
to be sending refreshes.  However if require 
implies supported, this would also mean that the 
UAC can assume that timer is supported by 
the UAS which isn't true.

> I can't think of a case where such a thing would make sense. 

Actually the timer draft is a good example as 
reflected in the example of a proxy adding 
require timer.  The receiver would incorrectly 
think that the UA supported something that it 
didn't.

I currently can't recall any receiver only 
extensions since they all require extension 
support by sender.  The timer draft had the 
potential until the INVITE's require timer 
only meant that the receiver supports the 
draft and not necessarily that the extension 
would be used on the call-leg and refreshed 
by receiver.

> What would be the usage of none? I don't see the value in that...??

The "none" would indicate neither party will be 
extending the session; thus please allow the 
small session-expires value.