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: Mon, 18 Jun 2001 02:36:20 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 2:58 PM
> To: SIP (E-mail)
> Subject: [SIP] draft-ietf-sip-session-timer-04: INVITE with 
> Require and
> Support timer and Session-Expires
> 
> 
> 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.

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

If people concur, I'll make the changes along those lines.

-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
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 21 Jun 2001 22:19:51 -0400

Jonathan, 

Thanks for the response.  Comments inline.

> addressed in the Supported header specification, since its 

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.

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

Isn't the "require implies supported" going to limit 
devices that want to require others to support an 
extension without them actually supporting 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.  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"

_______________________________________________
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