[Sip] Re: draft-ietf-sip-session-timer-10

[Paul Kyzivat <pkyzivat@cisco.com>]

There has been a fair amount of discussion over the last few months, on the sip or sip-implementors lists, trying to clarify the meaning of the session timer draft. I'm a bit concerned that the latest draft still leaves some doubt about the meaning.

Session Refresh Request is defined as follows in draft-ietf-sip-session-timer-10:

        Session Refresh Request: An INVITE or UPDATE request within a
             dialog. If the request generates a 2xx response, the
             session expiration is increased to the current time plus
             the session interval obtained from the response. A session
             refresh request is not to be confused with a target refresh
             request, defined in Section 6 of [1], which is a request
             that can update the remote target of a dialog.

This explicitly tried to distinguish this from a Target Refresh Request. That is defined as follows in rfc 3261 (taken from various places):

      Target Refresh Request: A target refresh request sent within a
         dialog is defined as a request that can modify the remote
         target of the dialog.

      For dialogs that have been established with an INVITE, the only 
      target refresh request defined is re-INVITE

   A UAC SHOULD include a Contact header field in any target refresh
   requests within a dialog, and unless there is a need to change it,
   the URI SHOULD be the same as used in previous requests within the
   dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.
   As discussed in Section 12.2.2, a Contact header field in a target
   refresh request updates the remote target URI.  This allows a UA to
   provide a new contact address, should its address change during the
   duration of the dialog.

This latter suggests that a target refresh request need not actually change the target. So an INVITE within a dialog must always be a target refresh request.

But the definition of Session Refresh Request is also just an INVITE. So despite the attempt to distinguish the two, it seems that *every* INVITE within a dialog is both a Session Refresh Request and a Target Refresh Request.

Draft-ietf-sip-session-timer-10 also says (in different places):

   The default value of the Session-Expires header field, when not
   present, is infinity. This means that absence of the Session-Expires
   header field implies no expiration.

   A UAC MAY include a Session-Expires in an initial session refresh
   request request if it wishes for a session timer to be applied to the
   session. The value of this header field indicates the session
   interval desired by the UAC. In a session refresh request sent within
   a dialog with an active session timer, the header field SHOULD be
   present. When present, it MUST be equal to the maximum of the Min-SE
   header field (recall that its default value when not present is zero)
   and the current session interval.

Putting this all together, I think it effectively says:

Every reINVITE or UPDATE within a dialog refreshes the session timer. If a session timer was already active within the session then the reINVITE or UPDATE SHOULD refresh it to the value previously established. (The maximum of the Min-SE header field and the current session interval.) If a reINVITE or UPDATE does not contain a Session-Expires header, then the session timer is deactivated. (Set to an infinite value.)

Given all the discussion that has gone on before on this subject, I think the language is still pretty confusing. I'm don't see where the term "session refresh request" does much to help clarify what is required. For instance, what is an "initial session refresh request"? I think it is typically the initial INVITE that establishes a dialog. It isn't itself in a dialog, and so doesn't qualify as a session refresh request at all.

I don't know what the best solution is. One possibility would be to reword the text. Another would be to simply include some additional examples to show the other cases.

	Paul
_______________________________________________
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