Subject: RE: [Sip] Session Timer Issues and Proposal

From: Adam Roach <[email-masked]>
Date: Tue, 3 Sep 2002 13:03:37 -0500

> From: Tirthankar Saha [mailto:[email-masked]]
> 
> Adam, it's true that the strategy is uniform but what I 
> wanted to say is
> that we have to implement the same thing differently for 
> different methods.
> It'd better having one single message which can refresh 
> different types of
> dialogs/sessions. Consider the case of a dialog-stateful 
> proxy: it has to be
> aware of the separate keep-alive mechanisms of SUBSCRIBE, INVITE etc.
> dialogs. Now suppose a new method is introduced with its own 
> keep-alive
> mechanism, the proxy has to be updated to account for this.

This, too, is an age old debate: does a proxy have any business
tracking dialogs it does not understand? This has been brought
up repeatedly, and consensus has been consistent throughout the
years: no.

If a proxy knows how a method behaves, it makes perfect sense to
track various related state. For new methods with which the proxy
is unfamiliar, a proxy assigns no semantics. It doesn't know whether
unknown requests have the ability to start, extend, modify, or end
a dialog. New methods may necessarily decide to implement their
own rules about dialog handling to suit whatever purpose the method
is being created for. Can we predict the behavior of all such
methods? Of course not -- otherwise, we'd define them all right now
and not worry about making the protocol extensible. But, to paraphrase
one of Dave Oran's maxims: events are always hard to predict,
especially when they involve the future.

While the principle you advocate is admirable, it cannot be
implemented in such a way that will stand the test of time.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Sep 2002 11:57:04 -0400

Adam has made many good points in response to this, and I generally 
agree with what he is saying. Some more comments inline.

Tirthankar Saha wrote:

> Issues:
> 
> 1) Why do we have to refresh the session with a re-INVITE?
> 
> Lots of unnecessary processing for a simple keepalive.
>    - 3 way handshake
>    - sdp re-negotiation & possible re-opening of media channels
> 
> This could have been justified earlier when the refresh-intervals were
> recommended to be 30 mins. but this feature is now being considered to be
> used for keeping the NAT bindings alive. 

Oh? It should not. We removed REGISTER refreshes as a way to keep NAT 
bindings alive from the most recent draft-ietf-sip-nat.

> I think using the re-INVITE to refresh a dialog is seriously flawed; I can't
> think of any good reason for having this procedure.
> We MUST address this issue ASAP.

The current draft in the repository allows for UPDATE, which is 
"lighter" than INVITE. It also allows for the UPDATE to be used without 
SDP, so there is no new offer/answer exchange. I don't think you can ask 
for much ligher than that.

> 
> 
> 2) Unnecessary processing & complications with "refresher" param.
> 
> What do we gain by negotiating who's going to be the referesher?
> On the other hand, extra work is required which can be avoided by having a
> simple rule for deciding the refresher (ref. proposal below). This way we
> can avoid the min-timer checks for DoS attacks and reduce interoperability
> issues arising out
> of certain non-conforming vendor implementations which don't use this param
> at all.

Originally, the UAC was the refresher, period.

However, subsequent discussions on the list indicated that people wanted 
a model whereby session timer could work so long as only one side 
supported the extension. This would facilitate its introduction. That 
means that either UAC or UAS could be the refresher. Once you do that, 
you need an explicit way to determine and indicate who it is. I don't 
know of a simpler way to do this given the constraints that it should 
work so long as one of the two UA support it.

Another design goal was to allow proxies to set the timer. Indeed, the 
primary point of the extension is for proxies to get refreshes on their 
call state, so they can know when to expire it. Just like other 
soft-state methods - such as REGISTER and SUBSCRIBE - the refresh 
intervals need to be negotiated. Otherwise, you get locked into an 
interval that you may find is useless, and you cannot ever change it 
since its burned into the spec. Now, once you add negotiation, the user 
to user nature of the timer introduces the DoS problems that need to be 
addressed.

> 
> 3) Unnecessary confusion with call-hold.
> 
> There's no way to tell whether incoming re-INVITE is for session-refresh or
> session-modification.
> 
>  e.g   A & B in call & A is the refresher. Now, B holds the call and A is
> still the refresher due to a specific case of negotiation
> of refresher param.
> If, A sends the refresh then B can't determine whether A is trying to modify
> the session or refresh the session. B would reject the request (because he's
> holding the call & won't allow A to unhold himself) & A MIGHT terminate the
> call.

This doesn't make sense to me. The origin field in the SDP will indicate 
whether it has changed. Thus, it is easy to determine whether this is a 
refresh or modification. Furthermore, if you use UPDATE, there need not 
even be SDP.

> 
> 4) No uniform strategy for dialog keep-alive : separate procedures for
> INVITE,REGISTER & SUBSCRIBE/NOTIFY dialogs.

I think Adam has addressed this point, so there is no need for me to 
belabor it.

> 
> 
> PROPOSAL
> ========
> 
> Common dialog-keepalive strategy though I've considered only INVITE dialogs.
> Can be extended easily for other dialogs (I feel).
> 
> New feature tag (for use in Supported,Require headers):
>     dtimer
> 
> New Header
>     Dialog-Expires: <time-in-seconds>
> 
>        - Can be included in ANY request and/or its response except BYE or
>          other requests terminating the dialog.
> 
>        - It MUST be included in the dialog-refresh request
>          which can be any valid request in the dialog although
>          the INFO request is recommended.
> 
>        - It is recommended that the UA intiating the dialog
>          SHOULD send this header in the initial INVITE.
> 
>        - If the request doesn't contain this header, the UAS can
>          add it in the response ONLY if the Supported header of
>          request contains the feature-tag "dtimer".
> 
>        - The endpoint (uac/uas) MUST include a supported header in
>          the message containing this header with the feature-tag "dtimer".
> 
>        - Proxies MUST NOT CHANGE this header.
> 
>        - Logic for determining the refresher:
> 
>          if (message contains "Supported: dtimer")
>                         AND
>             ("Dialog-Expires" hdr present in the message)
>          {
> 
>              if (message is REQUEST) {
>                   uac becomes the refresher
>              } else {
>                   uas becomes the refresher
>              }
> 
>          }
>          else
>          {
>              feature disabled
>          }
> 
>          ie. whoever sends this hdr in a transaction first becomes
>          the refresher.

It seems that you are getting simplification from two changes - proxies 
cannot request the timer, and the timer value cannot be negotiated. 
These are two important features of the specification as it stands today.

Again, one of the design goals is for proxies to request session timer, 
since they are the primary consumers of the timer. A UA has other means 
at its disposal to determine that a session has terminated (RTCP 
heartbeats, for example). So, a session timer whereby the proxies cant 
request it, is broken.

Similar point about negotiation of the value.

> 
>        - Logic for (re)starting expiry timer:
>             if (incoming-message contains "Dialog-Expires" header)
>                     AND
>                (message contains Supported header with the
>                 feature-tag "dtimer")
> 
>        - refresher role CANNOT be renegotiated.
> 
>          QUERY: Is this OK? Would renegotiation be needed in any case?
>          If yes, does it justify the extra renegotiation logic reqd.?

IMHO, idempotency of INVITE requires that whatever procedure is done for 
INVITE, also be the one that is implied for re-INVITE.

-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