draft-ietf-sipcore-199-06.txt   rfc6228.txt 
SIPCORE Working Group C. Holmberg Internet Engineering Task Force (IETF) C. Holmberg
Internet-Draft Ericsson Request for Comments: 6228 Ericsson
Intended status: Standards Track March 3, 2011 Category: Standards Track May 2011
Expires: September 4, 2011 ISSN: 2070-1721
Session Initiation Protocol (SIP) Response Code for Indication of Session Initiation Protocol (SIP) Response Code for
Terminated Dialog Indication of Terminated Dialog
draft-ietf-sipcore-199-06.txt
Abstract Abstract
This specification defines a new Session Initiation Protocol (SIP) This specification defines a new Session Initiation Protocol (SIP)
response code, 199 Early Dialog Terminated, that a SIP forking proxy response code, 199 Early Dialog Terminated, that a SIP forking proxy
and a User Agent Server (UAS) can use to indicate towards upstream and a User Agent Server (UAS) can use to indicate to upstream SIP
SIP entities (including the User Agent Client (UAC)) that an early entities (including the User Agent Client (UAC)) that an early dialog
dialog has been terminated, before a final response is sent towards has been terminated, before a final response is sent towards the SIP
the SIP entities. entities.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 4, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6228.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................4
3. Applicability and Limitation . . . . . . . . . . . . . . . . . 4 3. Applicability and Limitation ....................................4
4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 5 4. User Agent Client Behavior ......................................4
5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6 5. User Agent Server Behavior ......................................6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Proxy Behavior ..................................................7
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9 7. Backward Compatibility ..........................................9
8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 10 8. Usage with SDP Offer/Answer .....................................9
9. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 9. Message Flow Examples ...........................................9
9.1. Example with a forking proxy which generates 199 . . . . . 10 9.1. Example with a Forking Proxy that Generates 199 ............9
9.2. Example with a forking proxy which receives 200 OK . . . . 11 9.2. Example with a Forking Proxy that Receives 200 OK .........10
9.3. Example with two forking proxies, of which one 9.3. Example with Two Forking Proxies, of which One
generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 Generates 199 .............................................11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. Security Considerations .......................................12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations ...........................................13
11.1. IANA Registration of the 199 response code . . . . . . . . 14 11.1. IANA Registration of the 199 Response Code ...............13
11.2. IANA Registration of the 199 option-tag . . . . . . . . . 14 11.2. IANA Registration of the 199 Option-Tag ..................13
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements ..............................................13
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References ....................................................14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References .....................................14
14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.2. Informative References ...................................14
14.2. Informational References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP)
early dialog is created when a non-100 provisional response is sent early dialog is created when a non-100 provisional response is sent
to the initial dialog initiation request (e.g. INVITE, outside an to the initial dialog initiation request (e.g., INVITE, outside an
existing dialog). The dialog is considered to be in early state existing dialog). The dialog is considered to be in early state
until a final response is sent. until a final response is sent.
When a proxy receives an initial dialog initiation request, it can When a proxy receives an initial dialog initiation request, it can
forward the request towards multiple remote destinations. When the forward the request towards multiple remote destinations. When the
proxy does that, it performs forking [RFC3261]. proxy does that, it performs forking [RFC3261].
When a forking proxy receives a non-100 provisional response, or a When a forking proxy receives a non-100 provisional response, or a
2xx final response, it forwards the response upstream towards the 2xx final response, it forwards the response upstream towards the
sender of the associated request. After a forking proxy has sender of the associated request. After a forking proxy has
forwarded a 2xx final response, it normally generates and sends forwarded a 2xx final response, it normally generates and sends
CANCEL requests downstream towards all remote destinations where it CANCEL requests downstream towards all remote destinations where it
previously forked the request associated with the 2xx final response previously forked the request associated with the 2xx final response
and from which it has yet not received a final response. The CANCEL and from which it has still not received a final response. The
requests are sent in order to terminate any outstanding early dialogs CANCEL requests are sent in order to terminate any outstanding early
associated with the request. dialogs associated with the request.
Upstream SIP entities might receive multiple 2xx final responses. Upstream SIP entities might receive multiple 2xx final responses.
When a SIP entity receives the first 2xx final response, and it does When a SIP entity receives the first 2xx final response, and it does
not intend to accept any subsequent 2xx final response, it will not intend to accept any subsequent 2xx final responses, it will
automatically terminate any other outstanding early dialog associated automatically terminate any other outstanding early dialog associated
with the request. If the SIP entity receives a subsequent 2xx final with the request. If the SIP entity receives a subsequent 2xx final
response, it will normally generate and send an ACK request, followed response, it will normally generate and send an ACK request, followed
with a BYE request, using the dialog identifier retrieved from the with a BYE request, using the dialog identifier retrieved from the
2xx final response. 2xx final response.
NOTE: A User Agent Client (UAC) can use the Request-Disposition NOTE: A User Agent Client (UAC) can use the Request-Disposition
header field [RFC3841] to request that proxies do not generate and header field [RFC3841] to request that proxies do not generate and
send CANCEL requests downstream once they have received the first 2xx send CANCEL requests downstream once they have received the first
final response. 2xx final response.
When a forking proxy receives a non-2xx final response, it does not When a forking proxy receives a non-2xx final response, it does not
always immediately forward the response upstream towards the sender always immediately forward the response upstream towards the sender
of the associated request. Instead, the proxy "stores" the response of the associated request. Instead, the proxy "stores" the response
and waits for subsequent final responses from other remote and waits for subsequent final responses from other remote
destinations where the associated request was forked. At some point destinations where the associated request was forked. At some point,
the proxy uses a specified mechanism to determine the "best" final the proxy uses a specified mechanism to determine the "best" final
response code, and forwards a final response using that response code response code, and forwards a final response using that response code
upstream towards the sender of the associated request. When an upstream towards the sender of the associated request. When an
upstream SIP entity receives the non-2xx final response it will upstream SIP entity receives the non-2xx final response, it will
release resources associated with the session. The UAC will release resources associated with the session. The UAC will
terminate, or retry, the session setup. terminate, or retry, the session setup.
Since the forking proxy does not always immediately forward non-2xx Since the forking proxy does not always immediately forward non-2xx
final responses, upstream SIP entities (including the UAC that final responses, upstream SIP entities (including the UAC that
initiated the request) are not immediately informed that an early initiated the request) are not immediately informed that an early
dialog has been terminated, and will therefore maintain resources dialog has been terminated, and will therefore maintain resources
associated with the early dialog reserved until a final response is associated with the early dialog reserved until a final response is
sent by the proxy, even if the early dialog has already been sent by the proxy, even if the early dialog has already been
terminated. A SIP entity could use the resources for other things, terminated. A SIP entity could use the resources for other things,
e.g. to accept subsequent early dialogs that it otherwise would e.g., to accept subsequent early dialogs that it otherwise would
reject. reject.
This specification defines a new SIP response code, 199 Early Dialog This specification defines a new SIP response code, 199 Early Dialog
Terminated. A forking proxy can send a 199 provisional response to Terminated. A forking proxy can send a 199 provisional response to
inform upstream SIP entities that an early dialog has been inform upstream SIP entities that an early dialog has been
terminated. A UAS can send a 199 response code, prior to sending a terminated. A UAS can send a 199 response code, prior to sending a
non-2xx final response, for the same purpose. SIP entities that non-2xx final response, for the same purpose. SIP entities that
receive the 199 response can use it to trigger the release of receive the 199 response can use it to trigger the release of
resources associated with the terminated early dialog. In addition, resources associated with the terminated early dialog. In addition,
SIP entities might also use the 199 response to make policy related SIP entities might also use the 199 response to make policy decisions
decisions related to early dialogs. For example, a media gate related to early dialogs. For example, a media gate controlling a
controlling SIP entity might use the 199 response when deciding for SIP entity might use the 199 response when deciding for which early
which early dialogs media will be passed. dialogs media will be passed.
Section 9 contains signalling examples that show when and how a Section 9 contains signalling examples that show when and how a
forking proxy generates 199 responses in different situations. forking proxy generates 199 responses in different situations.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Applicability and Limitation 3. Applicability and Limitation
The 199 response code is an optimization, and it only optimizes how The 199 response code is an optimization, and it only optimizes how
quickly recipients might be informed about terminated early dialogs. quickly recipients might be informed about terminated early dialogs.
The achieved optimization is limited. Since the response is normally The achieved optimization is limited. Since the response is normally
not sent reliably by an UAS, and can not be sent reliably when not sent reliably by a UAS, and cannot be sent reliably when
generated and sent by a proxy, it is possible that some or all of the 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 199 responses will get lost before they reach the recipients. In
cases, recipients will behave the same as if the 199 response code such cases, recipients will behave the same as if the 199 response
were not used at all. code were not used at all.
One example for which a UAC could use the 199 response, is that when 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 it receives a 199 response, it releases resources associated with the
terminated early dialog. The UAC could also use the 199 response to terminated early dialog. The UAC could also use the 199 response to
make policy related decisions related to early dialogs. For example, make policy decisions related to early dialogs. For example, if a
if a UAC is playing media associated with an early dialog, and it UAC is playing media associated with an early dialog, and it then
then receives a 199 response indicating the early dialog has been receives a 199 response indicating the early dialog has been
terminated, it could start playing media associated with a different terminated, it could start playing media associated with a different
early dialog. early dialog.
Applications designers utilizing the 199 response code MUST ensure Application designers utilizing the 199 response code MUST ensure
that the application's user experience is acceptable if all 199 that the application's user experience is acceptable if all 199
responses are lost, and not delivered to the recipients. responses are lost and not delivered to the recipients.
4. User Agent Client behavior 4. User Agent Client Behavior
When a UAC sends an initial dialog initiation request, and if it is 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 willing to receive 199 responses, it MUST insert a "199" option-tag
in the Supported header field [RFC3261] of the request. The option- in the Supported header field [RFC3261] of the request. The option-
tag indicates that the UAC supports, and is willing to receive, 199 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 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 or the Proxy-Require header field [RFC3261] of the request, since in
many cases it would result in unnecessary session establishment many cases it would result in unnecessary session establishment
failures. failures.
NOTE: The UAC always needs to insert a "199" option-tag in the 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 Supported header field, in order to indicate that it supports, and
willing to receive, 199 responses, even if it also inserts the is willing to receive, 199 responses, even if it also inserts the
option-tag in the Require or Proxy-Require header field. option-tag in the Require or Proxy-Require header field.
It is RECOMMENDED that a UAC does not insert a "100rel" option-tag It is RECOMMENDED that a UAC not insert a "100rel" option-tag
[RFC3262] in the Require header field when it also indicates support [RFC3262] in the Require header field when it also indicates support
of 199 responses, unless the UAC also uses some other SIP extension for 199 responses, unless the UAC also uses some other SIP extension
or procedure that mandates it to do so. The reason is that proxies 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 are not allowed to generate and send 199 responses when the UAC has
required provisional responses to be sent reliably. required provisional responses to be sent reliably.
When a UAC receives a 199 response, it might release resources When a UAC receives a 199 response, it might release resources
associated with the terminated early dialog. A UAC might also use associated with the terminated early dialog. A UAC might also use
the 199 response to make policy related decisions related to early the 199 response to make policy decisions related to early dialogs.
dialogs.
NOTE: The 199 response indicates that the early dialog has been 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 terminated, so there is no need for the UAC to send a BYE request
order to terminate the early dialog when it receives the 199 in order to terminate the early dialog when it receives the 199
response. response.
NOTE: The 199 response does not affect other early dialogs associated NOTE: The 199 response does not affect other early dialogs
with the session establishment. For those the normal SIP rules, associated with the session establishment. For those dialogs, the
regarding transaction timeout etc, still apply. normal SIP rules regarding transaction timeout, etc., still apply.
Once a UAC has received and accepted a 199 response, it MUST NOT send Once a UAC has received and accepted a 199 response, it MUST NOT send
Any media associated with the early dialog. In addition, if the UAC any media associated with the early dialog. In addition, if the UAC
is able to associate received media with early dialogs, it MUST NOT is able to associate received media with early dialogs, it MUST NOT
process any received media associated with the early dialog that was process any received media associated with the early dialog that was
terminated. terminated.
If multiple usages [RFC5057] are used within an early dialog, and it If multiple usages [RFC5057] are used within an early dialog, and it
is not clear which dialog usage the 199 response terminates, SIP is not clear which dialog usage the 199 response terminates, SIP
entities that keep dialog state SHALL NOT release resources entities that keep dialog state SHALL NOT release resources
associated with the early dialog when they receive the 199 response. associated with the early dialog when they receive the 199 response.
If a UAC receives an unreliably sent 199 response on a dialog which If a UAC receives an unreliably sent 199 response on a dialog that
has not previously been established (this can happen if a 199 has not previously been established (this can happen if a 199
response reaches the client before the 18x response that would response reaches the client before the 18x response that would
establish the early dialog) it SHALL discard the 199 responses. If a establish the early dialog) it SHALL discard the 199 response. If a
UAC receives a reliably sent 199 response on a dialog which has not UAC receives a reliably sent 199 response on a dialog that has not
previously been created, it MUST acknowledge the 199 response, as previously been created, it MUST acknowledge the 199 response, as
described in RFC 3262 [RFC3262]. described in RFC 3262 [RFC3262].
If a UAC has received a 199 response for all early dialogs, and no If a UAC has received a 199 response for all early dialogs, and no
early dialog associated session establishment remains, it maintains early dialogs associated with the session establishment remain, it
the "Proceeding" state [RFC3261] and waits for possible subsequent maintains the "Proceeding" state [RFC3261] and waits for possible
early dialogs to be established, and eventually for a final response subsequent early dialogs to be established, and eventually for a
to be received. final response to be received.
5. User Agent Server behavior 5. User Agent Server Behavior
If a UAS receives an initial dialog initiation request, with a If a UAS receives an initial dialog initiation request with a
Supported header field that contains a "199" option-tag, it SHOULD Supported header field that contains a "199" option-tag, it SHOULD
NOT send a 199 response on an early dialog associated with the 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 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 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 to lack of support for the 199 response code by forking proxies or
other intermediate SIP entities, or it is used in an environment that other intermediate SIP entities, or if it is used in an environment
specifies that it shall send a 199 response before sending a non-2xx that specifies that it shall send a 199 response before sending a
response. non-2xx response.
NOTE: If a UAS has created multiple early dialogs associated with an NOTE: If a UAS has created multiple early dialogs associated with
initial dialog initiation request (the UAS is acting similar to a an initial dialog initiation request (the UAS is acting similarly
forking proxy), it does not always intend to send a final response on to a forking proxy), it does not always intend to send a final
all of those early dialogs. response on all of those early dialogs.
NOTE: If the Require header field of an initial dialog initiation NOTE: If the Require header field of an initial dialog initiation
request contains a "100rel" option-tag, proxies will not be able to request contains a "100rel" option-tag, proxies will not be able
generate and send 199 responses. In such cases the UAS might choose to generate and send 199 responses. In such cases, the UAS might
to send a 199 response on an early dialog, before it sends a non-2xx choose to send a 199 response on an early dialog before it sends a
final response, even if it would not do so in other cases. non-2xx final response, even if it would not do so in other cases.
If the Supported header field of an initial dialog initiation request 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 does not contain a "199" option-tag, the UAC MUST NOT send a 199
response on any early dialog associated with the request. response on any early dialog associated with the request.
When a UAS generates a 199 response, the response MUST contain a To When a UAS generates a 199 response, the response MUST contain a To
header field tag parameter [RFC3261], in order for other entities to header field tag parameter [RFC3261], in order for other entities to
identify the early dialog that has been terminated. The UAS MUST identify the early dialog that has been terminated. The UAS MUST
also insert a Reason header field [RFC3326] that contains a response also insert a Reason header field [RFC3326] that contains a response
code which describes the reason why the early dialog was terminated. code describing the reason why the early dialog was terminated. The
The UAS MUST NOT insert a "199" option-tag in the Supported, Require UAS MUST NOT insert a "199" option-tag in the Supported, Require, or
or Proxy-Require header field of the 199 response. Proxy-Require header field of the 199 response.
If a UAS intends to send 199 responses, and if it supports the If a UAS intends to send 199 responses, and if it supports the
procedures defined in RFC 3840 [RFC3840], it MAY during the procedures defined in RFC 3840 [RFC3840], it MAY during the
registration procedure use the sip.extensions feature tag [RFC3840] registration procedure use the sip.extensions feature tag [RFC3840]
to indicate support of the 199 response code. to indicate support for the 199 response code.
A 199 response SHOULD NOT contain an SDP offer/answer message body, A 199 response SHOULD NOT contain a Session Description Protocol
unless required by the rules in RFC 3264 [RFC3264]. (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 According to RFC 3264, if an INVITE request does not contain an SDP
offer, and the 199 response is the first reliably sent response offer, and the 199 response is the a first reliably sent response
associated with the request, the 199 response is required to contain associated with the request, the 199 response is required to contain
an SDP offer. In this case the UAS SHOULD send the 199 response an SDP offer. In this case, the UAS SHOULD send the 199 response
unreliably, or send the 199 response reliably and include an SDP unreliably, or send the 199 response reliably and include an SDP
offer with no m- lines in the response. offer with no "m=" lines in the response.
Since a 199 response is only used for information purpose, the UAS Since a 199 response is only used for information purposes, the UAS
SHOULD send it unreliably, unless the "100rel" option-tag is present SHOULD send it unreliably, unless the "100rel" option-tag is present
in the Require header field of the associated request. in the Require header field of the associated request.
6. Proxy behavior 6. Proxy Behavior
When a proxy receives a 199 response to an initial dialog initiation When a proxy receives a 199 response to an initial dialog initiation
request, it MUST process the response as any other non-100 request, it MUST process the response as any other non-100
provisional response. The proxy will forward the response upstream provisional response. The proxy will forward the response upstream
towards the sender of the associated request. The proxy MAY release towards the sender of the associated request. The proxy MAY release
resources it has reserved associated with the early dialog that is resources it has reserved associated with the early dialog that is
terminated. If a proxy receives a 199 response out of dialog, it terminated. If a proxy receives a 199 response out of dialog, it
MUST process it as other non-100 provisional responses received out MUST process it as other non-100 provisional responses received out
of dialog. of dialog.
When a forking proxy receives a non-2xx final response to an initial When a forking proxy receives a non-2xx final response to an initial
dialog initiation request, that it recognizes as terminating one or dialog initiation request that it recognizes as terminating one or
more early dialogs associated with the request, it MUST generate and more early dialogs associated with the request, it MUST generate and
send a 199 response upstream for each of the terminated early dialogs send a 199 response upstream for each of the terminated early dialogs
that satisfy each of the following conditions: that satisfy each of the following conditions:
- the forking proxy does not intend to forward the final response - The forking proxy does not intend to forward the final response
immediately (in accordance with rules for a forking proxy) immediately (in accordance with rules for a forking proxy).
- the UAC has indicated support (by inserting the "199" option-tag in - The UAC has indicated support (by inserting the "199" option-tag
a Supported header field) of the 199 response code in the associated in a Supported header field) for the 199 response code in the
request associated request.
- the UAC has not required provisional responses to be sent reliably - The UAC has not required provisional responses to be sent reliably
(by inserting the "100rel" option-tag in a Require or Proxy-Require (i.e., has not inserted the "100rel" option-tag in a Require or
header field) in the associated request Proxy-Require header field) in the associated request.
- the forking proxy has not already received and forwarded a 199 - The forking proxy has not already received and forwarded a 199
response for the early dialog response for the early dialog.
- the forking proxy has not already sent a final response for any of - The forking proxy has not already sent a final response for any of
the early dialogs the early dialogs.
As a consequence, once a final response to an initial dialog As a consequence, once a final response to an initial dialog
initiation request has been issued by the proxy, no further 199 initiation request has been issued by the proxy, no further 199
responses associated with the request will be generated or forwarded responses associated with the request will be generated or forwarded
by the proxy. by the proxy.
When a forking proxy forks an initial dialog initiation request, it When a forking proxy forks an initial dialog initiation request, it
generates a unique Via header branch parameter value for each forked generates a unique Via header branch parameter value for each forked
leg. A proxy can determine whether additional forking has occurred leg. A proxy can determine whether additional forking has occurred
downstream of the proxy by storing the top Via branch value from each 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 response that creates an early dialog. If the same top Via branch
value is received for multiple early dialogs, the proxy knows that value is received for multiple early dialogs, the proxy knows that
additional forking has occurred downstream of the proxy. A non-2xx additional forking has occurred downstream of the proxy. A non-2xx
final response received for a specific early dialog also terminates final response received for a specific early dialog also terminates
all other early dialog for which the same top Via branch value was all other early dialogs for which the same top Via branch value was
received in the responses which created those early dialogs. received in the responses that created those early dialogs.
Based on implementation policy, a forking proxy MAY wait before Based on implementation policy, a forking proxy MAY wait before
sending the 199 response, e.g. if it expects to receive a 2xx final 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 response on another dialog shortly after it received the non-2xx
final response which triggered the 199 response. final response that triggered the 199 response.
When a forking proxy generates a 199 response, the response MUST When a forking proxy generates a 199 response, the response MUST
contain a To header field tag parameter, that identifies the contain a To header field tag parameter that identifies the
terminated early dialog. A proxy MUST also insert a Reason header terminated early dialog. A proxy MUST also insert a Reason header
field that contains the SIP response code of the response that field that contains the SIP response code of the response that
triggered the 199 response. The SIP response code in the Reason triggered the 199 response. The SIP response code in the Reason
header field informs the receiver of the 199 response about the SIP 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, response code that was used by the UAS to terminate the early dialog,
and the receiver might use that information for triggering different and the receiver might use that information for triggering different
types of actions and procedures. The proxy MUST NOT insert a "199" types of actions and procedures. The proxy MUST NOT insert a "199"
option-tag in the Supported, Require or Proxy-Require header field of option-tag in the Supported, Require, or Proxy-Require header field
the 199 response. of the 199 response.
A forking proxy that supports generating of 199 responses MUST keep A forking proxy that supports the generation of 199 responses MUST
track of early dialogs, in order to determine whether to generate a keep track of early dialogs, in order to determine whether to
199 response when the proxy receives a non-2xx final response. In generate a 199 response when the proxy receives a non-2xx final
addition, a proxy MUST keep track on which early dialogs it has response. In addition, a proxy MUST keep track on which early
received and forwarded 199 responses, in order to not generate dialogs it has received and forwarded 199 responses, in order to not
additional 199 responses for those early dialogs. generate additional 199 responses for those early dialogs.
If a forking proxy receives a reliably sent 199 response for a If a forking proxy receives a reliably sent 199 response for a dialog
dialog, for which it has previously generated and sent a 199 for which it has previously generated and sent a 199 response, it
response, it MUST forward the 199 response. If a proxy receives an MUST forward the 199 response. If a proxy receives an unreliably
unreliably sent 199 response, for which it has previously generated sent 199 response for which it has previously generated and sent a
and sent a 199 response, it MAY forward the response, or it MAY 199 response, it MAY forward the response, or it MAY discard it.
discard it.
When a forking proxy generates and sends a 199 response, the response When a forking proxy generates and sends a 199 response, the response
SHOULD NOT contain a Contact header field or a Record-Route header SHOULD NOT contain a Contact header field or a Record-Route header
field [RFC3261]. field [RFC3261].
If the Require header field of an initial dialog initiation request If the Require header field of an initial dialog initiation request
contains a "100rel" option-tag, a proxy MUST NOT generate and send contains a "100rel" option-tag, a proxy MUST NOT generate and send
199 responses associated with that request. The reason is that a 199 responses associated with that request. The reason is that a
proxy is not allowed to generate and send 199 responses reliably. proxy is not allowed to generate and send 199 responses reliably.
7. Backward compatibility 7. Backward Compatibility
Since all SIP entities involved in a session setup do not necessarily Since all SIP entities involved in a session setup do not necessarily
support the specific meaning of the 199 Early Dialog Terminated support the specific meaning of the 199 Early Dialog Terminated
provisional response, the sender of the response MUST be prepared to provisional response, the sender of the response MUST be prepared to
receive SIP requests and responses associated with the dialog for receive SIP requests and responses associated with the dialog for
which the 199 response was sent (a proxy can receive SIP messages 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 from either direction). If such a request is received by a UA, it
act in the same way as if it had received the request after sending MUST act in the same way as if it had received the request after
the final non-2xx response to the INVITE request, as specified in RFC sending the final non-2xx response to the INVITE request, as
3261. A UAC that receives a 199 response for an early dialog MUST specified in RFC 3261. A UAC that receives a 199 response for an
NOT send any further requests on that dialog, except for requests early dialog MUST NOT send any further requests on that dialog,
which acknowledge reliable responses. A proxy MUST forward requests except for requests that acknowledge reliable responses. A proxy
according to RFC 3261, even if the proxy has knowledge that the early MUST forward requests according to RFC 3261, even if the proxy has
dialog has been terminated. knowledge that the early dialog has been terminated.
A 199 response does not "replace" a final response. RFC 3261 A 199 response does not "replace" a final response. RFC 3261
specifies when a final response is sent. specifies when a final response is sent.
8. Usage with SDP offer/answer 8. Usage with SDP Offer/Answer
A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264]
message body, unless required by the rules in RFC 3264. message body, unless required by the rules in RFC 3264.
If an INVITE request does not contain an SDP offer, and the 199 If an INVITE request does not contain an SDP offer, and the 199
response is the first reliably sent response, the 199 response is response is the first reliably sent response, the 199 response is
required to contain an SDP offer. In this case the UAS SHOULD send 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 the 199 response unreliably, or include an SDP offer with no "m="
in a reliable 199 response. lines in a reliable 199 response.
9. Message Flow Examples 9. Message Flow Examples
9.1. Example with a forking proxy which generates 199 9.1. Example with a Forking Proxy that Generates 199
The figure shows an example, where a proxy (P1) forks an INVITE Figure 1 shows an example where a proxy (P1) forks an INVITE received
received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, from a UAC. The forked INVITE reaches UAS_2, UAS_3, and UAS_4, which
which send 18x provisional responses in order to establish early send 18x provisional responses in order to establish early dialogs
dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the between themselves and the UAC. UAS_2 and UAS_3 each reject the
INVITE by sending a 4xx error response each. When P1 receives the INVITE by sending a 4xx error response. When P1 receives the 4xx
4xx responses it immediately sends 199 responses towards the UAC, to responses, it immediately sends 199 responses towards the UAC, to
indicate that the early dialogs for which it received the 4xx indicate that the early dialogs for which it received the 4xx
responses have been terminated. The early dialog leg is shown in responses have been terminated. The early dialog leg is shown in
parenthesis. parentheses.
UAC P1 UAS_2 UAS_3 UAS_4 UAC P1 UAS_2 UAS_3 UAS_4
| | | | | | | | | |
|-- INVITE -->| | | | |-- INVITE -->| | | |
| |--- INVITE (2) ->| | | | |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| | | |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->| | |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | | | |<-- 18x (2) -----| | |
|<- 18x (2) --| | | | |<- 18x (2) --| | | |
| |<-- 18x (3) -------------| | | |<-- 18x (3) -------------| |
|<- 18x (3) --| | | | |<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------| | |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | | |<- 18x (4) --| | | |
| |<-- 4xx (2) -----| | | | |<-- 4xx (2) -----| | |
| |--- ACK (2) ---->| | | | |--- ACK (2) ---->| | |
|<- 199 (2) --| | | | |<- 199 (2) --| | | |
| |<-- 4xx (3) -------------| | | |<-- 4xx (3) -------------| |
| |--- ACK (3) ------------>| | | |--- ACK (3) ------------>| |
|<- 199 (3) --| | | | |<- 199 (3) --| | | |
| |<-- 200 (4) ---------------------| | |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | | |<- 200 (4) --| | | |
|-- ACK (4) ->| | | | |-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->| | |--- ACK (4) -------------------->|
| | | | | | | | | |
Figure 1: Example call flow Figure 1: Example Call Flow
9.2. Example with a forking proxy which receives 200 OK 9.2. Example with a Forking Proxy that Receives 200 OK
The figure shows an example, where a proxy (P1) forks an INVITE Figure 2 shows an example where a proxy (P1) forks an INVITE request
request received from UAC. The forked request reaches UAS_2, UAS_3 received from a UAC. The forked request reaches UAS_2, UAS_3, and
and UAS_4, that all send 18x provisional responses in order to UAS_4, all of which send 18x provisional responses in order to
establish early dialogs between themselves and the UAC. Later UAS_4 establish early dialogs between themselves and the UAC. Later, UAS_4
accepts the session and sends a 200 OK final response. When P1 accepts the session and sends a 200 OK final response. When P1
receives the 200 OK responses it immediately forwards it towards the receives the 200 OK response, it immediately forwards it towards the
UAC. P1 does not send 199 responses for the early dialogs from UAS_2 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 and UAS_3, since P1 has still not received any final responses on
early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1 those early dialogs (even if P1 sends CANCEL requests to UAS_2 and
may still receive 200 OK final response from UAS_2 or UAS_3, that P1 UAS_3, P1 may still receive a 200 OK final response from UAS_2 or
would have to forward towards the UAC. The early dialog leg is shown UAS_3, which P1 would have to forward towards the UAC. The early
in parenthesis. dialog leg is shown in parentheses.
UAC P1 UAS_2 UAS_3 UAS_4 UAC P1 UAS_2 UAS_3 UAS_4
| | | | | | | | | |
|-- INVITE -->| | | | |-- INVITE -->| | | |
| |--- INVITE (2) ->| | | | |--- INVITE (2) ->| | |
| |--- INVITE (3) --------->| | | |--- INVITE (3) --------->| |
| |--- INVITE (4) ----------------->| | |--- INVITE (4) ----------------->|
| |<-- 18x (2) -----| | | | |<-- 18x (2) -----| | |
|<- 18x (2) --| | | | |<- 18x (2) --| | | |
| |<-- 18x (3) -------------| | | |<-- 18x (3) -------------| |
|<- 18x (3) --| | | | |<- 18x (3) --| | | |
| |<-- 18x (4) ---------------------| | |<-- 18x (4) ---------------------|
|<- 18x (4) --| | | | |<- 18x (4) --| | | |
| |<-- 200 (4) ---------------------| | |<-- 200 (4) ---------------------|
|<- 200 (4) --| | | | |<- 200 (4) --| | | |
|-- ACK (4) ->| | | | |-- ACK (4) ->| | | |
| |--- ACK (4) -------------------->| | |--- ACK (4) -------------------->|
| | | | | | | | | |
Figure 2: Example call flow Figure 2: Example Call Flow
9.3. Example with two forking proxies, of which one generates 199 9.3. Example with Two Forking Proxies, of which One Generates 199
The figure shows an example, where a proxy (P1) forks an INVITE Figure 3 shows an example where a proxy (P1) forks an INVITE request
request received from UAC. One of the forked requests reaches UAS_2. received from a UAC. One of the forked requests reaches UAS_2. The
The other requests reach another proxy (P2), that forks the request other requests reach another proxy (P2), which forks the request to
to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses in
in order to establish early dialogs between themselves and UAC. order to establish early dialogs between themselves and the UAC.
Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx Later, UAS_3 and UAS_4 each reject the INVITE request by sending a
error response each. P2 does not support the 199 response code, and 4xx error response. P2 does not support the 199 response code and
forwards a single 4xx response. P1 supports the 199 response code, forwards a single 4xx response. P1 supports the 199 response code,
and when it receives the 4xx response from P2, it also manages to 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 associate the early dialogs from both UAS_3 and UAS_4 with the
response. Therefore it generates and sends two 199 responses to response. Therefore, P1 generates and sends two 199 responses to
indicate that the early dialogs from UAS_3 and UAS_4 have been indicate that the early dialogs from UAS_3 and UAS_4 have been
terminated. The early dialog leg is shown in parenthesis. terminated. The early dialog leg is shown in parentheses.
UAC P1 P2 UAS_2 UAS_3 UAS_4 UAC P1 P2 UAS_2 UAS_3 UAS_4
| | | | | | | | | | | |
|-- INVITE -->| | | | | |-- INVITE -->| | | | |
| |-- INVITE (2) ------------------>| | | | |-- INVITE (2) ------------------>| | |
| |-- INVITE ---->| | | | | |-- INVITE ---->| | | |
| | |--- INVITE (3) --------->| | | | |--- INVITE (3) --------->| |
| | |--- INVITE (4) ----------------->| | | |--- INVITE (4) ----------------->|
| | |<-- 18x (3) -------------| | | | |<-- 18x (3) -------------| |
| |<- 18x (3) ----| | | | | |<- 18x (3) ----| | | |
skipping to change at page 13, line 32 skipping to change at page 12, line 32
| |<- 4xx (3) ----| | | | | |<- 4xx (3) ----| | | |
| |-- ACK (3) --->| | | | | |-- ACK (3) --->| | | |
|<- 199 (3) --| | | | | |<- 199 (3) --| | | | |
|<- 199 (4) --| | | | | |<- 199 (4) --| | | | |
| |<- 200 (2) ----------------------| | | | |<- 200 (2) ----------------------| | |
|<- 200 (2) --| | | | | |<- 200 (2) --| | | | |
|-- ACK (2) ->| | | | | |-- ACK (2) ->| | | | |
| |-- ACK (2) --------------------->| | | | |-- ACK (2) --------------------->| | |
| | | | | | | | | | | |
Figure 3: Example call flow Figure 3: Example Call Flow
10. Security Considerations 10. Security Considerations
General security issues related to SIP responses are described in RFC General security issues related to SIP responses are described in
3261. Due to the nature of the 199 response, it may be attractive to RFC 3261. Due to the nature of the 199 response, it may be
use it for launching attacks in order to terminate specific early attractive to use it for launching attacks in order to terminate
dialogs (other early dialogs will not be affected). In addition, if specific early dialogs (other early dialogs will not be affected).
a man-in-the-middle generates and sends a 199 response, which In addition, if a man-in-the-middle generates and sends towards the
terminates a specific dialog, towards the UAC, it can take a while UAC a 199 response that terminates a specific dialog, it can take a
until the UAS finds out that the UAC, and possible stateful while until the UAS finds out that the UAC, and possible stateful
intermediates, have terminated the dialog. SIP security mechanisms intermediates, have terminated the dialog. SIP security mechanisms
(e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk (e.g., hop-to-hop Transport Layer Security (TLS)) can be used to
for such attacks. minimize, or eliminate, the risk of such attacks.
11. IANA Considerations 11. IANA Considerations
This section registers a new SIP response code and a new option-tag, This section registers a new SIP response code and a new option-tag,
according to the procedures of RFC 3261. according to the procedures of RFC 3261.
11.1. IANA Registration of the 199 response code 11.1. IANA Registration of the 199 Response Code
This section registers a new SIP response code, 199. The required This section registers a new SIP response code, 199. The required
information for this registration, as specified in RFC 3261, is: information for this registration, as specified in RFC 3261, is:
RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC Number: RFC 6228
RFC number of this specification]]
Response Code Number: 199 Response Code Number: 199
Default Reason Phrase: Early Dialog Terminated Default Reason Phrase: Early Dialog Terminated
11.2. IANA Registration of the 199 option-tag 11.2. IANA Registration of the 199 Option-Tag
This section registers a new SIP option-tag, 199. The required This section registers a new SIP option-tag, 199. The required
information for this registration, as specified in RFC 3261, is: information for this registration, as specified in RFC 3261, is:
Name: 199 Name: 199
Description: This option-tag is for indicating support of the 199 Description: This option-tag is for indicating support of the 199
Early Dialog Terminated provisional response code. When present Early Dialog Terminated provisional response code. When
in a Supported header of a request, it indicates that the UAC present in a Supported header of a request, it indicates that
supports the 199 response code. When present in a Require or the UAC supports the 199 response code. When present in a
Proxy-Require header field of a request, it indicates that the Require or Proxy-Require header field of a request, it
UAS, or proxies, MUST support the 199 response code. It does indicates that the UAS, or proxies, MUST support the 199
not require the UAS, or proxies, to actually send 199 response code. It does not require the UAS, or proxies, to
responses. actually send 199 responses.
12. Acknowledgements 12. Acknowledgements
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet,
Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan,
Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo
Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith
Drage, Hans Erik van Elburg and Cullen Jennings for their feedback Drage, Hans Erik van Elburg, and Cullen Jennings for their feedback
and suggestions. and suggestions.
13. Change Log 13. References
[RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-199-04
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 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
skipping to change at page 16, line 26 skipping to change at page 14, line 33
June 2002. June 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002. RFC 3326, December 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
14.2. Informational References 13.2. Informative References
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007. 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.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com EMail: christer.holmberg@ericsson.com
 End of changes. 96 change blocks. 
325 lines changed or deleted 263 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/