[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, June 21, 2001 10:20 PM
> To: 'Jonathan Rosenberg'; sip@ietf.org
> 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
jdrosen@dynamicsoft.com                     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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip