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

From: Adam Roach <[email-masked]>
Date: Fri, 30 Aug 2002 13:18:18 -0500

> I haven't followed any previous discussions on this issue on 
> the mailing
> list, so I might be missing something.

This is somewhat understandable, since the discussion itself
spans back to January of 1999. In fact, I started the conversation
that led to the creation of the session-timer draft; see message
<[email-masked]> from the confctrl
mailing list. I just re-read the ensuing discussion, and think
it sheds a lot of light on why the decisions in this draft were
made the way that they were. I encourage you to do the same, so
as to gain some historical perspective. Most of the points you make
were considered in some form at that time.

(The confctrl archives are available in one 16 Mb blob from
ftp://ftp.isi.edu/confctrl/confctrl.mail) 

> 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

The early suggestions included a new method (PING) and the
re-use of OPTIONS. The idea is that both of these would be
sent by proxies, leading to an explosion of messages when many
proxies were in the chain. OPTIONS had the additional failure
that it could only determine UA liveness, not session state.

I also suggested SUBSCRIBE/NOTIFY to something like session state
(which we actually are developing a package for now!), but it
suffers from the same message explosion problem.

Further, speaking to the topic of using new methods, Dean objected:

"Why do we keep reinventing new specialized methods like PING and INCALL
 and PRESENCE and so on . . . all these functions can be handled by
 simple, reuasable message primitives."

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

I remember that this was discussed on the list, and that the
current mechanism reflects working group consensus at that time,
but I don't rememeber the logic off the top of my head, and
can't find the conversation. Perhaps someone else remembers.
Jonathan? Steve?

We could revisit this mechanism if it proves problematic, but your
objection seems more aesthetic than technical in nature.

> This way we can... reduce interoperability issues arising out
> of certain non-conforming vendor implementations which don't 
> use this param at all.

We can't really design a protocol to compensate for every moron
out there who happens to get his hands on a compiler. Robustness
is one thing; designing an idiot-proof protocol is another. The
former is admirable, while the latter is impossible.

> 3) Unnecessary confusion with call-hold.
> 
> There's no way to tell whether incoming re-INVITE is for 
> session-refresh or
> session-modification.

Yes, there is. You examine the SDP. This is a non-argument.

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

REGISTER doesn't create a dialog. In any case, registrations
are soft state, and need to be refreshed with new REGISTERs.

SUBSCRIBE dialogs naturally time out due to the soft-state nature
of subscriptions. They need to be refreshed with new SUBSCRIBEs.

The only reason we need session-timer for INVITE created sessions
is that INVITEs don't have an inherent notion of timeouts that
force refreshes. Session-timer fixes this by adding such a soft-
state so that INVITE-created sessions need to be refreshed with
(if you've followed the pattern of the previous two paragraphs,
the next two words should be no surprise) new INVITEs.

I'll try to make my point a little more obvious. You are arguing
for a uniform strategy for keeping state fresh.

+------------------+--------------------+
| State created by | State refreshed by |
+------------------+--------------------+
| REGISTER         | REGISTER           |
| SUBSCRIBE        | SUBSCRIBE          |
| INVITE           | INVITE             |
+------------------+--------------------+

In what way is this not uniform?

> 6) No endpt. support
>    Feature is disabled.
>    However, S can "query" the dialog-status by sending an INFO request
>    to all the endpoints in the dialog. It CAN release its resources if
>    any of the INFO requests elicit a 481 response or no answer.
>    This method can also be used by the UAs as an extra safety-check
>    although it is not recommended.

This suggestion has a host of problems that make it untenable.

 a) These queries would need to appear in-dialog; however,
    when S sends an INFO like this to B, he will use up
    CSeq space in that direction. Since A doesn't know about
    this message, the next message he sends has a high
    probability of being perceived as out-of-order and
    consequently rejected by B.

 b) Similarly, when B receives this request, he will perceive it
    as coming from A (because it's on a dialog he has with A). If
    he decides to challenge this request, S will have no way to
    respond.

 c) In a similar vein, if B requires A to sign and/or encrypt
    requests, any request by S will be rejected as forged or
    unreadable.

 d) This doesn't scale. As mentioned earlier, if you have long
    proxy chains with multiple proxies wanting to check liveness,
    you get huge volumes of traffic dedicated to checking
    dialog liveness.

 e) Ignoring the mechanism, allowing any third party -- even
    a proxy involved in the call -- to actively query dialog
    state without a clear way to implement policy has massive
    privacy problems.

Now, that said, session-timer *is* in need of some updating to
align with 3261 and 3264, as well as possibly making provisions
for the UPDATE method. So, by all means, if you'd like to help
in making revisions to accomodate these changes and make other
improvements to the existing draft, I encourage it. You certainly
seem to have the energy and time to dedicate to this effort.

After over three and a half years of work acheiving some level of
consensus on the current mechanism, though, I don't think it is
rational to consider completely scrapping the existing work and
starting from ground zero. We've discovered and fixed a lot of
tricky problems already. If we start from scratch now, we'll
spend a lot of time discovering and fixing these same and similar
problems. I see no reason to begin afresh on this 44-month journey,
only to be back where we are right now in June of 2007.

/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: "Tirthankar Saha" <[email-masked]>
Date: Sat, 31 Aug 2002 14:13:45 +0530

Hi,

Thanks Adam and Christian for the comments.

Christian, you are right, using the UPDATE method without SDP offer as
recommended in the latest session-timer draft does resolve the main issue
i.e. "heavy" processing for simple keep-alive.

Adam, I don't think that the refresher param is a major issue and it's true
that you can't ensure everyone to follow the spec but my point was it's
better not to have extra options which don't provide anything useful. IMRHO
the refresher param leads to unecessary DoS checks and processing. I'm
searching the mailing lists for an answer to why we should continue with
this param at all... in the meantime it'd be nice for SIP gurus to provide
some info...

> for a uniform strategy for keeping state fresh.

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.

Regards,

Tirthankar