[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-sip-199) 00 01 02 03 04 05 06 RFC 6228

SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           March 3, 2011
Expires: September 4, 2011


   Session Initiation Protocol (SIP) Response Code for Indication of
                           Terminated Dialog
                     draft-ietf-sipcore-199-06.txt

Abstract

   This specification defines a new Session Initiation Protocol (SIP)
   response code, 199 Early Dialog Terminated, that a SIP forking proxy
   and a User Agent Server (UAS) can use to indicate towards upstream
   SIP entities (including the User Agent Client (UAC)) that an early
   dialog has been terminated, before a final response is sent towards
   the SIP entities.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 4, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Holmberg                Expires September 4, 2011               [Page 1]

Internet-Draft                     199                        March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Applicability and Limitation . . . . . . . . . . . . . . . . .  4
   4.  User Agent Client behavior . . . . . . . . . . . . . . . . . .  5
   5.  User Agent Server behavior . . . . . . . . . . . . . . . . . .  6
   6.  Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Backward compatibility . . . . . . . . . . . . . . . . . . . .  9
   8.  Usage with SDP offer/answer  . . . . . . . . . . . . . . . . . 10
   9.  Message Flow Examples  . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Example with a forking proxy which generates 199 . . . . . 10
     9.2.  Example with a forking proxy which receives 200 OK . . . . 11
     9.3.  Example with two forking proxies, of which one
           generates 199  . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
     11.1. IANA Registration of the 199 response code . . . . . . . . 14
     11.2. IANA Registration of the 199 option-tag  . . . . . . . . . 14
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     14.2. Informational References . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16






















Holmberg                Expires September 4, 2011               [Page 2]

Internet-Draft                     199                        March 2011


1.  Introduction

   As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP)
   early dialog is created when a non-100 provisional response is sent
   to the initial dialog initiation request (e.g.  INVITE, outside an
   existing dialog).  The dialog is considered to be in early state
   until a final response is sent.

   When a proxy receives an initial dialog initiation request, it can
   forward the request towards multiple remote destinations.  When the
   proxy does that, it performs forking [RFC3261].

   When a forking proxy receives a non-100 provisional response, or a
   2xx final response, it forwards the response upstream towards the
   sender of the associated request.  After a forking proxy has
   forwarded a 2xx final response, it normally generates and sends
   CANCEL requests downstream towards all remote destinations where it
   previously forked the request associated with the 2xx final response
   and from which it has yet not received a final response.  The CANCEL
   requests are sent in order to terminate any outstanding early dialogs
   associated with the request.

   Upstream SIP entities might receive multiple 2xx final responses.
   When a SIP entity receives the first 2xx final response, and it does
   not intend to accept any subsequent 2xx final response, it will
   automatically terminate any other outstanding early dialog associated
   with the request.  If the SIP entity receives a subsequent 2xx final
   response, it will normally generate and send an ACK request, followed
   with a BYE request, using the dialog identifier retrieved from the
   2xx final response.

   NOTE: A User Agent Client (UAC) can use the Request-Disposition
   header field [RFC3841] to request that proxies do not generate and
   send CANCEL requests downstream once they have received the first 2xx
   final response.

   When a forking proxy receives a non-2xx final response, it does not
   always immediately forward the response upstream towards the sender
   of the associated request.  Instead, the proxy "stores" the response
   and waits for subsequent final responses from other remote
   destinations where the associated request was forked.  At some point
   the proxy uses a specified mechanism to determine the "best" final
   response code, and forwards a final response using that response code
   upstream towards the sender of the associated request.  When an
   upstream SIP entity receives the non-2xx final response it will
   release resources associated with the session.  The UAC will
   terminate, or retry, the session setup.




Holmberg                Expires September 4, 2011               [Page 3]

Internet-Draft                     199                        March 2011


   Since the forking proxy does not always immediately forward non-2xx
   final responses, upstream SIP entities (including the UAC that
   initiated the request) are not immediately informed that an early
   dialog has been terminated, and will therefore maintain resources
   associated with the early dialog reserved until a final response is
   sent by the proxy, even if the early dialog has already been
   terminated.  A SIP entity could use the resources for other things,
   e.g. to accept subsequent early dialogs that it otherwise would
   reject.

   This specification defines a new SIP response code, 199 Early Dialog
   Terminated.  A forking proxy can send a 199 provisional response to
   inform upstream SIP entities that an early dialog has been
   terminated.  A UAS can send a 199 response code, prior to sending a
   non-2xx final response, for the same purpose.  SIP entities that
   receive the 199 response can use it to trigger the release of
   resources associated with the terminated early dialog.  In addition,
   SIP entities might also use the 199 response to make policy related
   decisions related to early dialogs.  For example, a media gate
   controlling SIP entity might use the 199 response when deciding for
   which early dialogs media will be passed.

   Section 9 contains signalling examples that show when and how a
   forking proxy generates 199 responses in different situations.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  Applicability and Limitation

   The 199 response code is an optimization, and it only optimizes how
   quickly recipients might be informed about terminated early dialogs.
   The achieved optimization is limited.  Since the response is normally
   not sent reliably by an UAS, and can not be sent reliably when
   generated and sent by a proxy, it is possible that some or all of the
   199 responses get lost before they reach the recipients.  In such
   cases, recipients will behave the same as if the 199 response code
   were not used at all.

   One example for which a UAC could use the 199 response, is that when
   it receives a 199 response it releases resources associated with the
   terminated early dialog.  The UAC could also use the 199 response to
   make policy related decisions related to early dialogs.  For example,



Holmberg                Expires September 4, 2011               [Page 4]

Internet-Draft                     199                        March 2011


   if a UAC is playing media associated with an early dialog, and it
   then receives a 199 response indicating the early dialog has been
   terminated, it could start playing media associated with a different
   early dialog.

   Applications designers utilizing the 199 response code MUST ensure
   that the application's user experience is acceptable if all 199
   responses are lost, and not delivered to the recipients.


4.  User Agent Client behavior

   When a UAC sends an initial dialog initiation request, and if it is
   willing to receive 199 responses, it MUST insert a "199" option-tag
   in the Supported header field [RFC3261] of the request.  The option-
   tag indicates that the UAC supports, and is willing to receive, 199
   responses.  A UAC SHOULD NOT insert a "199" option-tag in the Require
   or the Proxy-Require header field [RFC3261] of the request, since in
   many cases it would result in unnecessary session establishment
   failures.

   NOTE: The UAC always needs to insert a "199" option-tag in the
   Supported header field, in order to indicate that it supports, and is
   willing to receive, 199 responses, even if it also inserts the
   option-tag in the Require or Proxy-Require header field.

   It is RECOMMENDED that a UAC does not insert a "100rel" option-tag
   [RFC3262] in the Require header field when it also indicates support
   of 199 responses, unless the UAC also uses some other SIP extension
   or procedure that mandates it to do so.  The reason is that proxies
   are not allowed to generate and send 199 responses when the UAC has
   required provisional responses to be sent reliably.

   When a UAC receives a 199 response, it might release resources
   associated with the terminated early dialog.  A UAC might also use
   the 199 response to make policy related decisions related to early
   dialogs.

   NOTE: The 199 response indicates that the early dialog has been
   terminated, so there is no need for the UAC to send a BYE request in
   order to terminate the early dialog when it receives the 199
   response.

   NOTE: The 199 response does not affect other early dialogs associated
   with the session establishment.  For those the normal SIP rules,
   regarding transaction timeout etc, still apply.

   Once a UAC has received and accepted a 199 response, it MUST NOT send



Holmberg                Expires September 4, 2011               [Page 5]

Internet-Draft                     199                        March 2011


   Any media associated with the early dialog.  In addition, if the UAC
   is able to associate received media with early dialogs, it MUST NOT
   process any received media associated with the early dialog that was
   terminated.

   If multiple usages [RFC5057] are used within an early dialog, and it
   is not clear which dialog usage the 199 response terminates, SIP
   entities that keep dialog state SHALL NOT release resources
   associated with the early dialog when they receive the 199 response.

   If a UAC receives an unreliably sent 199 response on a dialog which
   has not previously been established (this can happen if a 199
   response reaches the client before the 18x response that would
   establish the early dialog) it SHALL discard the 199 responses.  If a
   UAC receives a reliably sent 199 response on a dialog which has not
   previously been created, it MUST acknowledge the 199 response, as
   described in RFC 3262 [RFC3262].

   If a UAC has received a 199 response for all early dialogs, and no
   early dialog associated session establishment remains, it maintains
   the "Proceeding" state [RFC3261] and waits for possible subsequent
   early dialogs to be established, and eventually for a final response
   to be received.


5.  User Agent Server behavior

   If a UAS receives an initial dialog initiation request, with a
   Supported header field that contains a "199" option-tag, it SHOULD
   NOT send a 199 response on an early dialog associated with the
   request, before it sends a non-2xx final response.  Cases where a UAS
   might send a 199 response are if it has been configured to do so due
   to lack of support of the 199 response code by forking proxies or
   other intermediate SIP entities, or it is used in an environment that
   specifies that it shall send a 199 response before sending a non-2xx
   response.

   NOTE: If a UAS has created multiple early dialogs associated with an
   initial dialog initiation request (the UAS is acting similar to a
   forking proxy), it does not always intend to send a final response on
   all of those early dialogs.

   NOTE: If the Require header field of an initial dialog initiation
   request contains a "100rel" option-tag, proxies will not be able to
   generate and send 199 responses.  In such cases the UAS might choose
   to send a 199 response on an early dialog, before it sends a non-2xx
   final response, even if it would not do so in other cases.




Holmberg                Expires September 4, 2011               [Page 6]

Internet-Draft                     199                        March 2011


   If the Supported header field of an initial dialog initiation request
   does not contain a "199" option-tag, the UAC MUST NOT send a 199
   response on any early dialog associated with the request.

   When a UAS generates a 199 response, the response MUST contain a To
   header field tag parameter [RFC3261], in order for other entities to
   identify the early dialog that has been terminated.  The UAS MUST
   also insert a Reason header field [RFC3326] that contains a response
   code which describes the reason why the early dialog was terminated.
   The UAS MUST NOT insert a "199" option-tag in the Supported, Require
   or Proxy-Require header field of the 199 response.

   If a UAS intends to send 199 responses, and if it supports the
   procedures defined in RFC 3840 [RFC3840], it MAY during the
   registration procedure use the sip.extensions feature tag [RFC3840]
   to indicate support of the 199 response code.

   A 199 response SHOULD NOT contain an SDP offer/answer message body,
   unless required by the rules in RFC 3264 [RFC3264].

   According to RFC 3264, if an INVITE request does not contain an SDP
   offer, and the 199 response is the first reliably sent response
   associated with the request, the 199 response is required to contain
   an SDP offer.  In this case the UAS SHOULD send the 199 response
   unreliably, or send the 199 response reliably and include an SDP
   offer with no m- lines in the response.

   Since a 199 response is only used for information purpose, the UAS
   SHOULD send it unreliably, unless the "100rel" option-tag is present
   in the Require header field of the associated request.


6.  Proxy behavior

   When a proxy receives a 199 response to an initial dialog initiation
   request, it MUST process the response as any other non-100
   provisional response.  The proxy will forward the response upstream
   towards the sender of the associated request.  The proxy MAY release
   resources it has reserved associated with the early dialog that is
   terminated.  If a proxy receives a 199 response out of dialog, it
   MUST process it as other non-100 provisional responses received out
   of dialog.

   When a forking proxy receives a non-2xx final response to an initial
   dialog initiation request, that it recognizes as terminating one or
   more early dialogs associated with the request, it MUST generate and
   send a 199 response upstream for each of the terminated early dialogs
   that satisfy each of the following conditions:



Holmberg                Expires September 4, 2011               [Page 7]

Internet-Draft                     199                        March 2011


   - the forking proxy does not intend to forward the final response
   immediately (in accordance with rules for a forking proxy)

   - the UAC has indicated support (by inserting the "199" option-tag in
   a Supported header field) of the 199 response code in the associated
   request

   - the UAC has not required provisional responses to be sent reliably
   (by inserting the "100rel" option-tag in a Require or Proxy-Require
   header field) in the associated request

   - the forking proxy has not already received and forwarded a 199
   response for the early dialog

   - the forking proxy has not already sent a final response for any of
   the early dialogs

   As a consequence, once a final response to an initial dialog
   initiation request has been issued by the proxy, no further 199
   responses associated with the request will be generated or forwarded
   by the proxy.

   When a forking proxy forks an initial dialog initiation request, it
   generates a unique Via header branch parameter value for each forked
   leg.  A proxy can determine whether additional forking has occurred
   downstream of the proxy by storing the top Via branch value from each
   response which creates an early dialog.  If the same top Via branch
   value is received for multiple early dialogs, the proxy knows that
   additional forking has occurred downstream of the proxy.  A non-2xx
   final response received for a specific early dialog also terminates
   all other early dialog for which the same top Via branch value was
   received in the responses which created those early dialogs.

   Based on implementation policy, a forking proxy MAY wait before
   sending the 199 response, e.g. if it expects to receive a 2xx final
   response on another dialog shortly after it received the non-2xx
   final response which triggered the 199 response.

   When a forking proxy generates a 199 response, the response MUST
   contain a To header field tag parameter, that identifies the
   terminated early dialog.  A proxy MUST also insert a Reason header
   field that contains the SIP response code of the response that
   triggered the 199 response.  The SIP response code in the Reason
   header field informs the receiver of the 199 response about the SIP
   response code that was used by the UAS to terminate the early dialog,
   and the receiver might use that information for triggering different
   types of actions and procedures.  The proxy MUST NOT insert a "199"
   option-tag in the Supported, Require or Proxy-Require header field of



Holmberg                Expires September 4, 2011               [Page 8]

Internet-Draft                     199                        March 2011


   the 199 response.

   A forking proxy that supports generating of 199 responses MUST keep
   track of early dialogs, in order to determine whether to generate a
   199 response when the proxy receives a non-2xx final response.  In
   addition, a proxy MUST keep track on which early dialogs it has
   received and forwarded 199 responses, in order to not generate
   additional 199 responses for those early dialogs.

   If a forking proxy receives a reliably sent 199 response for a
   dialog, for which it has previously generated and sent a 199
   response, it MUST forward the 199 response.  If a proxy receives an
   unreliably sent 199 response, for which it has previously generated
   and sent a 199 response, it MAY forward the response, or it MAY
   discard it.

   When a forking proxy generates and sends a 199 response, the response
   SHOULD NOT contain a Contact header field or a Record-Route header
   field [RFC3261].

   If the Require header field of an initial dialog initiation request
   contains a "100rel" option-tag, a proxy MUST NOT generate and send
   199 responses associated with that request.  The reason is that a
   proxy is not allowed to generate and send 199 responses reliably.


7.  Backward compatibility

   Since all SIP entities involved in a session setup do not necessarily
   support the specific meaning of the 199 Early Dialog Terminated
   provisional response, the sender of the response MUST be prepared to
   receive SIP requests and responses associated with the dialog for
   which the 199 response was sent (a proxy can receive SIP messages
   from either direction).  If such request is received by a UA, it MUST
   act in the same way as if it had received the request after sending
   the final non-2xx response to the INVITE request, as specified in RFC
   3261.  A UAC that receives a 199 response for an early dialog MUST
   NOT send any further requests on that dialog, except for requests
   which acknowledge reliable responses.  A proxy MUST forward requests
   according to RFC 3261, even if the proxy has knowledge that the early
   dialog has been terminated.

   A 199 response does not "replace" a final response.  RFC 3261
   specifies when a final response is sent.







Holmberg                Expires September 4, 2011               [Page 9]

Internet-Draft                     199                        March 2011


8.  Usage with SDP offer/answer

   A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264]
   message body, unless required by the rules in RFC 3264.

   If an INVITE request does not contain an SDP offer, and the 199
   response is the first reliably sent response, the 199 response is
   required to contain an SDP offer.  In this case the UAS SHOULD send
   the 199 response unreliable, or include an SDP offer with no m- lines
   in a reliable 199 response.


9.  Message Flow Examples

9.1.  Example with a forking proxy which generates 199

   The figure shows an example, where a proxy (P1) forks an INVITE
   received from UAC.  The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
   which send 18x provisional responses in order to establish early
   dialogs between themselves and the UAC.  UAS_2 and UAS_3 reject the
   INVITE by sending a 4xx error response each.  When P1 receives the
   4xx responses it immediately sends 199 responses towards the UAC, to
   indicate that the early dialogs for which it received the 4xx
   responses have been terminated.  The early dialog leg is shown in
   parenthesis.


























Holmberg                Expires September 4, 2011              [Page 10]

Internet-Draft                     199                        March 2011


    UAC           P1               UAS_2   UAS_3   UAS_4
     |             |                 |       |       |
     |-- INVITE -->|                 |       |       |
     |             |--- INVITE (2) ->|       |       |
     |             |--- INVITE (3) --------->|       |
     |             |--- INVITE (4) ----------------->|
     |             |<-- 18x (2) -----|       |       |
     |<- 18x (2) --|                 |       |       |
     |             |<-- 18x (3) -------------|       |
     |<- 18x (3) --|                 |       |       |
     |             |<-- 18x (4) ---------------------|
     |<- 18x (4) --|                 |       |       |
     |             |<-- 4xx (2) -----|       |       |
     |             |--- ACK (2) ---->|       |       |
     |<- 199 (2) --|                 |       |       |
     |             |<-- 4xx (3) -------------|       |
     |             |--- ACK (3) ------------>|       |
     |<- 199 (3) --|                 |       |       |
     |             |<-- 200 (4) ---------------------|
     |<- 200 (4) --|                 |       |       |
     |-- ACK (4) ->|                 |       |       |
     |             |--- ACK (4) -------------------->|
     |             |                 |       |       |


                        Figure 1: Example call flow

9.2.  Example with a forking proxy which receives 200 OK

   The figure shows an example, where a proxy (P1) forks an INVITE
   request received from UAC.  The forked request reaches UAS_2, UAS_3
   and UAS_4, that all send 18x provisional responses in order to
   establish early dialogs between themselves and the UAC.  Later UAS_4
   accepts the session and sends a 200 OK final response.  When P1
   receives the 200 OK responses it immediately forwards it towards the
   UAC.  P1 does not send 199 responses for the early dialogs from UAS_2
   and UAS_3, since P1 has yet not received any final responses on those
   early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1
   may still receive 200 OK final response from UAS_2 or UAS_3, that P1
   would have to forward towards the UAC.  The early dialog leg is shown
   in parenthesis.










Holmberg                Expires September 4, 2011              [Page 11]

Internet-Draft                     199                        March 2011


    UAC           P1               UAS_2   UAS_3   UAS_4
     |             |                 |       |       |
     |-- INVITE -->|                 |       |       |
     |             |--- INVITE (2) ->|       |       |
     |             |--- INVITE (3) --------->|       |
     |             |--- INVITE (4) ----------------->|
     |             |<-- 18x (2) -----|       |       |
     |<- 18x (2) --|                 |       |       |
     |             |<-- 18x (3) -------------|       |
     |<- 18x (3) --|                 |       |       |
     |             |<-- 18x (4) ---------------------|
     |<- 18x (4) --|                 |       |       |
     |             |<-- 200 (4) ---------------------|
     |<- 200 (4) --|                 |       |       |
     |-- ACK (4) ->|                 |       |       |
     |             |--- ACK (4) -------------------->|
     |             |                 |       |       |


                        Figure 2: Example call flow

9.3.  Example with two forking proxies, of which one generates 199

   The figure shows an example, where a proxy (P1) forks an INVITE
   request received from UAC.  One of the forked requests reaches UAS_2.
   The other requests reach another proxy (P2), that forks the request
   to UAS_3 and UAS_4.  UAS_3 and UAS_4 send 18x provisional responses
   in order to establish early dialogs between themselves and UAC.
   Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx
   error response each.  P2 does not support the 199 response code, and
   forwards a single 4xx response.  P1 supports the 199 response code,
   and when it receives the 4xx response from P2, it also manages to
   associate the early dialogs from both UAS_3 and UAS_4 with the
   response.  Therefore it generates and sends two 199 responses to
   indicate that the early dialogs from UAS_3 and UAS_4 have been
   terminated.  The early dialog leg is shown in parenthesis.















Holmberg                Expires September 4, 2011              [Page 12]

Internet-Draft                     199                        March 2011


    UAC           P1              P2               UAS_2   UAS_3   UAS_4
     |             |               |                 |       |       |
     |-- INVITE -->|               |                 |       |       |
     |             |-- INVITE (2) ------------------>|       |       |
     |             |-- INVITE ---->|                 |       |       |
     |             |               |--- INVITE (3) --------->|       |
     |             |               |--- INVITE (4) ----------------->|
     |             |               |<-- 18x (3) -------------|       |
     |             |<- 18x (3) ----|                 |       |       |
     |<- 18x (3) --|               |                 |       |       |
     |             |               |<-- 18x (4) ---------------------|
     |             |<- 18x (4) ----|                 |       |       |
     |<- 18x (4) --|               |                 |       |       |
     |             |               |<-- 4xx (3) -------------|       |
     |             |               |--- ACK (3) ------------>|       |
     |             |               |<-- 4xx (4) ---------------------|
     |             |               |--- ACK (4) -------------------->|
     |             |<- 4xx (3) ----|                 |       |       |
     |             |-- ACK (3) --->|                 |       |       |
     |<- 199 (3) --|               |                 |       |       |
     |<- 199 (4) --|               |                 |       |       |
     |             |<- 200 (2) ----------------------|       |       |
     |<- 200 (2) --|               |                 |       |       |
     |-- ACK (2) ->|               |                 |       |       |
     |             |-- ACK (2) --------------------->|       |       |
     |             |               |                 |       |       |


                        Figure 3: Example call flow


10.  Security Considerations

   General security issues related to SIP responses are described in RFC
   3261.  Due to the nature of the 199 response, it may be attractive to
   use it for launching attacks in order to terminate specific early
   dialogs (other early dialogs will not be affected).  In addition, if
   a man-in-the-middle generates and sends a 199 response, which
   terminates a specific dialog, towards the UAC, it can take a while
   until the UAS finds out that the UAC, and possible stateful
   intermediates, have terminated the dialog.  SIP security mechanisms
   (e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk
   for such attacks.


11.  IANA Considerations

   This section registers a new SIP response code and a new option-tag,



Holmberg                Expires September 4, 2011              [Page 13]

Internet-Draft                     199                        March 2011


   according to the procedures of RFC 3261.

11.1.  IANA Registration of the 199 response code

   This section registers a new SIP response code, 199.  The required
   information for this registration, as specified in RFC 3261, is:

       RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
           RFC number of this specification]]

       Response Code Number: 199

       Default Reason Phrase: Early Dialog Terminated

11.2.  IANA Registration of the 199 option-tag

   This section registers a new SIP option-tag, 199.  The required
   information for this registration, as specified in RFC 3261, is:

    Name: 199

    Description: This option-tag is for indicating support of the 199
         Early Dialog Terminated provisional response code. When present
         in a Supported header of a request, it indicates that the UAC
         supports the 199 response code. When present in a Require or
         Proxy-Require header field of a request, it indicates that the
         UAS, or proxies, MUST support the 199 response code. It does
         not require the UAS, or proxies, to actually send 199
         responses.


12.  Acknowledgements

   Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet,
   Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan,
   Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo
   Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith
   Drage, Hans Erik van Elburg and Cullen Jennings for their feedback
   and suggestions.


13.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-ietf-sipcore-199-04





Holmberg                Expires September 4, 2011              [Page 14]

Internet-Draft                     199                        March 2011


   o  "Usage with 100rel" section removed based on comments from John
      Elwell (31.01.2011)
   o  Editorial corrections based on comments from Paul Kyzivat
      (31.01.2011)

   Changes from draft-ietf-sipcore-199-03
   o  RFC 3262 update removed
   o  Functional modification: proxy must not send 199 in case of
      Require:100rel
   o  Recommendation that UAC does not require reliable provisional
      responses with 199
   o  Clarification that Require:199 does not mandate the UAS to send a
      199 response
   o  Clarification that a UAC needs to insert the 199 option-tag in a
      Supported header field, even if it also inserts the option-tag in
      a Require or Proxy-Require header field
   o  Editorial corrections

   Changes from draft-ietf-sipcore-199-02
   o  Usage example section rewritten and clarified
   o  Requirement has been removed
   o  SIP has been added to document title
   o  Acronyms expanded in the abstract and throughout the document
   o  Editorial fixes throughout the document
   o  Indication added that document is aimed for standards track
   o  Some references made informative
   o  Additional text added regarding the usage of the Reason header
   o  SBC latching text has been removed
   o  Usage of Require/Proxy-Require header removed
   o  Additional text added regarding sending SDP offer in 199
   o  Note added, which clarifies that 199 does not affect other early
      dialogs
   o  References added to Security Considerations
   o  Clarification of local ringing tone
   o  Clarification that media must not be sent or processed after 199
   o  Text regarding sending media on terminated dialogs added to
      security section
   o  Change: UAS must send 199 reliably in case of Require:100rel
   o  Change: Section 4 of RFC 3262 updated


14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Holmberg                Expires September 4, 2011              [Page 15]

Internet-Draft                     199                        March 2011


   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
              "Indicating User Agent Capabilities in the Session
              Initiation Protocol (SIP)", RFC 3840, August 2004.

14.2.  Informational References

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC5057]  Sparks, R., "Multiple Dialog Usages in the Session
              Initiation Protocol", RFC 5057, November 2007.

   [3GPP.24.182]
              3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting
              Tones (CAT); Protocol specification", 3GPP TS 24.182.

   [3GPP.24.628]
              3GPP, "Common Basic Communication procedures using IP
              Multimedia (IM)Core Network (CN) subsystem; Protocol
              specification", 3GPP TS 24.628.













Holmberg                Expires September 4, 2011              [Page 16]

Internet-Draft                     199                        March 2011


Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com










































Holmberg                Expires September 4, 2011              [Page 17]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/