[Sip] Require header in responses (was- The fate of session timer?)

["Arunachalam Venkatraman" <arunvenk@cisco.com>]

Jonathan
I believe your statement below about the rule for adding a Require header
into a response should be documented in section 20.32 of the RFC3261.
Regards
Venkat

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, November 12, 2002 7:24 AM
To: hisham.khartabil@nokia.com
Cc: chandan.rajah@wipro.com; sip@ietf.org
Subject: Re: [Sip] The fate of session timer?


hisham.khartabil@nokia.com wrote:
 > As I see it, what we are specifying here is a keepalive mechanism for
 > sessions. The value of the keepalive can have a default.
 >
 > UACs don't have to send any new header in an initial INVITE, but
 > proxies and UASs requiring session keepalive can inform the UAC of
 > such requirement by including a (proxy-)Require-header in the
 > response?? The default values can be used.

No. Require/Proxy-REquire in a response is only allowed if the request
contained a Supported header in the INVITE.

 >
 > In this way, each entity can take of cleaning up its own stale
 > sessions. No need for UAC to tell every other entity when it plans on
 > ending the session, it can just send a BYE.
 >
 > Btw, do we have requirements for this, or should we write one?

This specification predates our requirements for requirements. So, no,
there are none. I don't think we need to do a formal requirements
process here. However, I think it is useful to have an email discussion
of the basic requirements that underlie the current draft, to see which
ones we can rule out, as it seems people seem amenable to considering a
simplification:

REQ 1: There shall be a way for a proxy or UA to request that a session
timer be executed for a dialog.

REQ 2: There shall be a way for the session timer to take place so long
as EITHER the UAC or UAS supports it.

REQ 3: There shall be a way for each element - proxy,UAC, UAS, to
specify their desired value for the session timer.

REQ 4: There shall be a way for each element to specify their minimum
allowed value for the session tiemr.

REQ 5: The final session timer shall be:

          MAX(MIN(desired timers),MAX(min timers))

REQ 6: It shall be possible to renegotiate the use of session timer, and
its value, at any time during a dialog.

REQ 7: Session timer shall be immune to DoS attacks introduced by a
rogue UAC, UAS, or proxy.

REQ 8: It shall be possible for the UAC in the initial INVITE to suggest
itself for performing the refreshes.


I think that captures most of it. Some of these requirements, like 6,
fall out of general SIP properties, and we would be hard pressed to
eliminate them.

Its also possible to get simplification through redesign while still
meeting the requirements. For example, it occurs to me that we could
potentially send the refreshes directly from the client to the
"interested" proxies. This is more overhead for the client if there is
more than one interested proxy, but means that proxies which don't care
about session timer don't suffer from additional message volume, which
is a drawback of the current solution.

By doing that, all of the negotiation becomes two-way, between a UA and
a proxy, rather than N-way, and is thus much simplified.

Such a solution would require a proxy requesting session timer to have a
  globally routable URI.


Yet another solution is to define a specific "heartbeat" media stream
type, which periodically genreates a keepalive. In that sense, its
similar to RTCP, but not RTP specific. AN intermediary can get itself
onto this heartbeat stream by being a b2bua that mucks with SDP, or
using a mechanism like the session policy which I have formerly proposed:
http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

There may be other general solutions to this too.


-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  https://www1.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

_______________________________________________
Sip mailing list  https://www1.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