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

From: feng zhang <[email-masked]>
Date: Fri, 30 Aug 2002 21:55:37 +0800

Hi,

   I think Tirthankar's words about session timer is reasonable, why doesn't any one
give some comments?

Best Regards.
>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
>
>.
_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Fri, 30 Aug 2002 20:31:54 +0300

Hi,

The session-timer has been discussed many times, during a very long time, so I think it
would be a good to have a look at the archieves. I can't remember if all of the issues
have been addressed, but at least some have.

For example, the fact that INVITE is a very "heavy" thing to use for the session-timer
has been brought up (by myself, among others) many times, and my understanding is that
the UPDATE method will be added to the draft as an option for the session-timer. Using
INFO has been discussed many times, and reasons have been given why it is not a very
good solution.

And, there IS a way of knowing if a re-INVITE is for a session modification, or simply
for a session refresh - by checking the SDP.

Regards,

Christer Holmberg
Ericsson Finland