Subject: [Sip] Session Timer Issues and Proposal

From: "Tirthankar Saha" <[email-masked]>
Date: Thu, 29 Aug 2002 15:58:09 +0530

Hello folks,

I feel there are some issues with the Sip Session Timer spec and that it can
be
made simpler and more useful. I'm submitting a rough proposal for improving
the spec and would appreciate your comments.

I haven't followed any previous discussions on this issue on the mailing
list, so I might be missing something. I thought that the shortcomings would
be addressed in a later version of the draft but it hasn't happened. So
before this draft attains RFC status like all the other ones, it's better
that we have another discussion on this topic.

Regards,

Tirthankar

--------------------------------------------------------------

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. This means that the
refresh-intervals are going to be as low as 30secs.

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.

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.

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.

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

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.

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

       - refresh & expiry time calculations are the same as in the
         session-timer draft.

SCENARIOS
=========
NOTE: INVITE dialog is assumed.
Endpoint A : Dialog initiator/Calling party/Initial UAC
Endpoint B : Called party/Initial UAS
Intermediate server S: proxy/B2BUA.

1) Feature supported by BOTH endpoints.

   A includes "Dialog-Expires" header & "dtimer" in "Supported"
   header in the initial INVITE request. B echoes the header in the
   response and includes "dtimer" in the Supported header of
   the response. As a result, A becomes the refresher. It sends the
   refresh in INFO request which includes the "Dialog-Expires" header,
   as a result of which B restarts the timer.

   1.1) Refresh
        A sends INFO request with "Dialog-Expires" header.
        B restarts the expiry timer.

   1.2) B goes down
        A sends refresh and receives no response.
        After timeout A sends BYE.

   1.3) B goes down & comes up again
        A sends refresh and receives 481 response. A sends BYE.

   1.4) A goes down
        B doesn't recv refreshes & sends BYE.

   1.5) A holds the call and includes "Dialog-Expires" in the
        re-INVITE to avoid sending extra message for refreshing the
        dialog. B restarts the expiry timer upon receiving the re-INVITE.

   1.6) On-the-wire: A & B send re-INVITE "simultaneously"
        There would be a race condition if renegotiation was allowed
        and both endpoints included the "Dialog-Expires" header in
        the re-INVITEs. Since renegotiation is not allowed, A would
        continue to be the refresher.

2) Feature supported ONLY by A & S
   B doesn't send "Supported: dtimer" in response but S inserts it and
   A starts the refresh timer.

3) Feature supported ONLY by B & S
   S inserts "Supported: dtimer" in the request and B inserts the
   "Dialog-Expires" header & becomes the refresher. S removes the
   "Dialog-Expires" header when forwarding the response to A.

4) Feature supported ONLY by A
   A doesn't recv "Supported: dtimer" in the response as neither B
   nor S supports the feature and hence disables the feature.

5) Feature supported ONLY by B
   B doesn't recv "Supported: dtimer" in the request as neither A
   nor S supports the feature and hence disables the feature.

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.

_______________________________________________
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