[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