[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] The fate of session timer?
The current draft fulfils all the requests stated below, but there has been a couple of emails on this thread asking for simplifications to the draft. That's why I asked for requirements.
The simplification might start by examining the need for REQs 3-6.
Also for REQ 1, what is the rationale behind a UAC or proxy requesting session timer to be started on the remote end? Each entity only needs to take care of its own stale sessions (something I tried to propose in my earlier email). Should my UAC care that the remote end has stale sessions? It should just care that the remote end doesn't think my session with it is stale. My suggestion for this was using require-header, but, as pointed out by Jonathan, it is not appropriate (something I over looked).
Regards,
Hisham
> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, November 12, 2002 3:24 PM
> To: Khartabil Hisham (NMP/Helsinki)
> 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