draft-ietf-sipcore-199-02.txt   draft-ietf-sipcore-199-03.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: June 12, 2010 December 9, 2009 Updates: 3262 (if approved) December 9, 2010
Intended status: Standards Track
Expires: June 12, 2011
Response Code for Indication of Terminated Dialog Session Initiation Protocol (SIP) Response Code for Indication of
draft-ietf-sipcore-199-02.txt Terminated Dialog
draft-ietf-sipcore-199-03.txt
Abstract Abstract
This specification defines a new SIP response code, 199 Early Dialog This specification defines a new Session Initiation Protocol (SIP)
Terminated, which a SIP forking proxy and a UAS can use to indicate response code, 199 Early Dialog Terminated, that a SIP forking proxy
upstream towards the UAC that an early dialog has been terminated, and a User Agent Server (UAS) can use to indicate towards upstream
before a final response is sent towards the UAC. 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. In addition, this specification updates section 4
of RFC 3262.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on June 12, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability and Limitation . . . . . . . . . . . . . . . . . 4
4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 5
4.1. Examples of resource types . . . . . . . . . . . . . . . . 5 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6
4.2. Examples of policy procedures . . . . . . . . . . . . . . 6 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 8
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9
8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9
9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 9
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative update of RFC 3262 . . . . . . . . . . . . . . . . . 9
10.1. Example with a forking proxy which generates 199 . . . . . 10 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Example with a forking proxy which receives 200 OK . . . . 11 10.2. RFC3262: 4. UAC Behavior . . . . . . . . . . . . . . . . 9
10.3. Example with two forking proxies, of which one 11. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10
generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Example with a forking proxy which generates 199 . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11.2. Example with a forking proxy which receives 200 OK . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11.3. Example with two forking proxies, of which one
12.1. IANA Registration of the 199 response code . . . . . . . . 14 generates 199 . . . . . . . . . . . . . . . . . . . . . . 11
12.2. IANA Registration of the 199 Option Tag . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. IANA Registration of the 199 response code . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.2. IANA Registration of the 199 option-tag . . . . . . . . . 13
14.2. Informational References . . . . . . . . . . . . . . . . . 15 13.3. RFC 3262 Update . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
16.1. Normative References . . . . . . . . . . . . . . . . . . 14
16.2. Informational References . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
As defined in SIP (Session Initiation Protocol) specification As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP)
[RFC3261], an early SIP dialog is created when a non-100 provisional early dialog is created when a non-100 provisional response is sent
response is sent to the dialog initiation request (e.g. INVITE). to the initial dialog initiation request (e.g. INVITE, outside an
The dialog is considered to be in early state until a final response existing dialog). The dialog is considered to be in early state
is sent. until a final response is sent.
When a proxy receives an initial request (outside an existing dialog, When a proxy receives an initial dialog initiation request, it can
and without a pre-defined route set), it can forward it towards forward the request towards multiple remote destinations. When the
multiple remote destinations. When the proxy does that, it performs proxy does that, it performs forking [RFC3261].
forking.
When a forking proxy receives non-100 provisional responses, it When a forking proxy receives a non-100 provisional response, or a
forwards the responses upstream towards the sender of the associated 2xx final response, it forwards the response upstream towards the
request. When a forking proxy receives a 2xx final response, it sender of the associated request. After a forking proxy has
forwards the response upstream towards the sender of the associated forwarded a 2xx final response, it normally generates and sends
request. At that point the proxy normally sends a CANCEL request CANCEL requests downstream towards all remote destinations where it
downstream towards all remote destinations where it previously sent previously forked the request associated with the 2xx final response
the request associated with the 2xx final response, and from which it and from which it has yet not received a final response. The CANCEL
has yet not received a final response, in order to terminate requests are sent in order to terminate any outstanding early dialogs
associated outstanding early dialogs. It is possible to receive associated with the request.
multiple 2xx final responses. When SIP entities upstream receive the
first 2xx final response, and they do not to intend to accept
subsequent 2xx final responses, they will automatically terminate
other associated outstanding early dialogs. If additional 2xx final
responses are received, those SIP entities will normally send a BYE
request using the dialog identifier retrieved from the subsequent 2xx
final response.
NOTE: A UAC can use the Request-Disposition header [RFC3841] to Upstream SIP entities might receive multiple 2xx final responses.
request that proxies do not send CANCEL requests downstream once they When a SIP entity receives the first 2xx final response, and it does
have received the first final 2xx response. 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 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 forking proxy "stores" it of the associated request. Instead, the proxy "stores" the response
and waits for further final responses from remote destinations where and waits for subsequent final responses from other remote
the forked request was forwarded. At some point the proxy uses a destinations where the associated request was forked. At some point
specified mechanism to determine the "best" final response code, and the proxy uses a specified mechanism to determine the "best" final
forwards that final response upstream towards the sender of the response code, and forwards a final response using that response code
associated request. When SIP entities upstream receive the non-2xx upstream towards the sender of the associated request. When an
final response they will release resources associated with the upstream SIP entity receives the non-2xx final response it will
session, and the UAC will terminate, or retry, the session setup. release resources associated with the session. The UAC will
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, SIP entities upstream (including the UAC that final responses, upstream SIP entities (including the UAC that
initiated the request) do not know that a specific early dialog has initiated the request) are not immediately informed that an early
been terminated, and the SIP entities keep possible resources dialog has been terminated, and will therefor maintain resources
associated with the early dialog until they receive a final response associated with the early dialog reserved until a final response is
from the forking proxy. 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 This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a forking proxy and a UAS can use to indicate Terminated. A forking proxy can send a 199 provisional response to
upstream that an early dialog has been terminated. The 199 response inform upstream SIP entities that an early dialog has been
can also be sent by a UAS, prior to sending a non-2xx final response. terminated. A UAS can send a 199 response code, prior to sending a
SIP entities that receive the 199 provisional response can release non-2xx final response, for the same purpose. SIP entities that
resources associated with the specific early dialog. The SIP receive the 199 response can use it to release resources associated
entities can also use the 199 provisional response to make policy with the terminated early dialog. In addition, SIP entities might
related decisions related to early dialogs. also use the 199 provisional response to make policy related
decisions related to early dialogs.
The 199 response code is an optimization, which allows the UAC to be This specification updates RFC 3262 [RFC3841], by mandating a UAC to
informed about terminated early dialogs. However, since the support be prepared to receive unreliably sent provisional responses even if
of the 199 response is optional, a UAC cannot assume that it will it has required provisional responses to be sent reliably.
always receive a 199 provisional response for all terminated early
dialogs.
2. Conventions 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 BCP 14, RFC 2119 document are to be interpreted as described in RFC 2119 [RFC2119].
[RFC2119].
3. Requirements
REQ 1: It must be possible to indicate to the UAC that an early
dialog has been terminated before a final response is sent.
4. User Agent Client behavior
When a UAC sends an initial request, and if it wants to receive 199
responses, it MUST insert the 199 option-tag in the Supported header,
which indicates that the client supports the 199 Early Dialog
Terminated response code. The UAC SHOULD NOT insert the 199 option-
tag in the Require header, unless the particular session usage
requires the UAS to support the response code. Also, the UAC SHOULD
NOT insert the 199 option-tag in the Proxy-Require header, unless the
particular session usage requires every proxy on the path to support
the response code. Using Require or Proxy-Require with the 199
option-tag will in many cases result in unnecessary session
establishment failures.
When a UAC receives a 199 response it MAY release resources and
procedures associated with the early dialog on which the 199 response
is received. Examples of resources and procedures are e.g.
procedures for the establishment of media plane resources (bandwidth,
radio, codecs etc), media security procedures or procedures related
to NAT traversal. In addition, the UAC may use the 199 response for
policy decisions related to early dialogs, e.g. when choosing to
process media associated with a particular early dialog.
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 client receives an unreliable 199 response on a dialog which has
not previously been created (this can happen if a 199 response
reaches the client before a 18x response) the client SHALL discard
the 199 responses. If a client receives a reliable 199 response on a
dialog which has not previously been created the UAC SHOULD
acknowledge the 199 response, as described in [RFC3262].
4.1. Examples of resource types
Examples which benefit from resource-release are:
1. Codec release - when resources for a specific codec has been
reserved only for the stream that is terminated. In that case the
resources associated with that codec can be released.
2. Pre-conditions - when the dialog is terminated, procedures and 3. Applicability and Limitation
resources associated to the pre-conditions for that dialog can be
released.
3. In-band security negotiation - when the dialog is terminated, The 199 response code is an optimization, and it only optimizes how
procedures and resources associated with the in-band security quickly receipients might be informed about terminated early dialogs.
negotiation for that dialog can be released. 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 receipients. In such
cases, recipients will behave the same as if the 199 response code
were not used at all.
4. ICE [I-D.ietf-mmusic-ice] mechanism - when the dialog is One example for which a UA could use the 199 response, is that when
terminated, procedures and resources associated with the ICE related it receives a 199 response it releases resources associated with the
in-band procedures for that dialog can be released. terminated early dialog. It could also use the 199 response to make
policy related decisions related to early dialogs. For example, if a
UAC is playing media associated with an early dialog, and the it
receives a 199 response indicating the early dialog has been
terminated, it could start playing media associated with a different
early dialog.
5. Limited access resources - in case of forking and multiple stream Applications designers utilizing the 199 response code MUST ensure
it may not be possible to allow early media on all dialogs, so media that the application's user experience is acceptable if all 199
sessions associated with some dialogs may e.g. be set to "inactive". responses are lost, and not delivered to the receipients.
When a dialog is terminated, media sessions associated with other
dialogs can be allowed.
6. Secure media selection - when SRTP is used to encrypt the media. 4. User Agent Client behavior
In some cases SIP entities are only able to render media associated When a UAC sends an initial request, and if it is willing to receive
with a single early dialog. If a 199 response is received on a 199 responses, it MUST insert the "199" option-tag in the Supported
dialog, and media associated with that media has been rendered, the header field. The option-tag indicates that the UAC supports 199
SIP entity can start rendering media associated with another early responses. The UAC SHOULD NOT insert the "199" option-tag in the
dialog. Require or the Proxy-Require header fields, since in many cases it
would result in unnecessary session establishment failures.
If the client is able to associate the 199 response with a specific When a UAC receives a 199 response it might release resources
media stream, it MAY choose to discard media on that specific media associated with the terminated early dialog. It might also use the
stream, it MAY release all resources associated with that media 199 response to make policy related decisions related to early
stream and it MAY start to process media streams received on other dialogs.
early dialogs. When the P-Early-Media header [RFC5009] is used, a UA
MAY trigger different actions depending on whether the header has
been used for the terminated dialog. How the association between the
dialog and the associated media stream is done is outside the scope
of this document.
NOTE: When using SRTP [RFC3711], the secure media stream is bound to NOTE: The 199 response indicates that the early dialog has been
the crypto context setup for the dialog, and can be identified using terminated, so there is no need for the UAC to send a BYE request in
the MKI (if used) of SRTP. order to terminate the early dialog when it receives the 199
response.
If the client only has a single early dialog (other early dialogs MAY NOTE: The 199 response does not affect other early dialogs associated
not have been established, or they MAY have been established and with the session establishment. For those the normal SIP rules,
later terminated) and a 199 response is received for that early regarding transaction timeout etc, still apply.
dialog, the client terminates the early dialog. Afterwards, the
client SHOULD act as before the first early dialog was established.
4.2. Examples of policy procedures Once the UAC has received and accepted the 199 provisional response,
it MUST NOT send or process any media associated with the early
dialog that was terminated.
1. UAC early media selection - when media associated with multiple If multiple usages [RFC5057] are used within an early dialog, and it
early dialogs is received, SIP endpoint normally chooses to process is not clear which dialog usage the 199 response terminates, SIP
media associated with a single early dialog (e.g. the recently entities that keep dialog state SHALL NOT release resources
established early dialog). If a 199 response is received on such associated with the early dialog when they receive the 199 response.
early dialog, the SIP endpoint can start processing media associated
with another early dialog. For example, an early dialog may be used
for an announcement message, and when the message is finished a 199
response will be sent on that dialog, in order for the SIP endpoint
to stop processing media associated with that early dialog. This
kind of policy is normal especially in PSTN gateways, where the
calling user cannot control which media is processed.
2. SBC early media selection - when an SBC is used to control which If a SIP entity receives an unreliable 199 response on a dialog which
media is processed and forwarded. In many cases, the SBC only has not previously been established (this can happen if a 199
processes media associated with a single early dialog. Typical for response reaches the client before the 18x response that would
NAT traversal, the SBC often "latches" onto a media stream. If a 199 establish the early dialog) it SHALL discard the 199 responses. If a
response is received, the SBC can choose to start processing media SIP entity receives a reliable 199 response on a dialog which has not
associated with another dialog. If the SBC performs latching, it can previously been created the UAC MUST acknowledge the 199 response, as
trigger a "re-latch" onto a new media stream when the 199 response is described in RFC 3262.
received.
3. UAC ringing tone generation - when a UAC receives a 180 response, If the UAC has received a 199 response for all early dialogs, and no
it may choose to generate a local ringing tone. If early media is early dialog associatd session establisment remains, the UAC
received, the UAC may stop the local ringing tone generation and play maintains the "Procedding" state [RFC3261] and waits for possible
the incoming early media packets. If a 199 response is received on subsequent early dialogs to be established, and eventually for a
the early dialog associated with the early media, and the UAC has final response to be received.
previously received a 180 response for another early dialog, it can
start to generate local ringing tone again. Having knowledge that
the early dialog associated with early media has been terminated, the
UAC can also start generating local ringing tone if a 180 is received
on another early dialog after the early dialog has been terminated.
5. User Agent Server behavior 5. User Agent Server behavior
If the received initial request contains an 199 option tag, the UAS If a UAS receives an initial request that contains an "199" option-
SHOULD NOT send a 199 response on a dialog on which it intends to tag, it SHOULD NOT send a 199 response on an early dialog on which it
send a final response, unless it e.g. has been configured to do so intends to send a final response, unless it e.g. has been configured
due to lack of 199 support by forking proxies or other intermediate to do so due to lack of 199 support by forking proxies or other
SIP entities. intermediate SIP entities.
NOTE: If the UAS has created multiple early dialogs (the UAS is NOTE: If the UAS has created multiple early dialogs (the UAS is
acting similar to a forking proxy), it does not always intend to send acting similar to a forking proxy), it does not always intend to send
a final response for all of those dialogs. a final response for all of those dialogs.
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 tag parameter, which identifies the early dialog that has been header field tag parameter, in order to identify the early dialog
terminated. The UAS MUST also insert a Reason header [RFC3326] which that has been terminated. The UAS MUST also insert a Reason header
contains a response code which describes the reason why the dialog field [RFC3326] that contains a response code which describes the
was terminated. reason why the early dialog was terminated.
If the UAS intends to send 199 responses, and if it supports the If the UAS intends to send 199 responses, and if it supports the
procedures defined in [RFC3840], it MAY during the registration procedures defined in RFC 3840 [RFC3840], it MAY during the
procedure use the sip.extensions feature tag [RFC3840] to indicate registration procedure use the sip.extensions feature tag [RFC3840]
support of the 199 response code. to indicate support of the 199 response code.
A 199 response SHOULD NOT contain an SDP offer/answer message body, A 199 response SHOULD NOT contain an SDP offer/answer message body,
unless required by the rules in [RFC3264]. unless required by the rules in RFC 3264 [RFC3264].
If the INVITE request did not contain an SDP offer, and the 199 According to RFC 3264, if the INVITE request does not contain an SDP
response is the first reliably sent response, the 199 response is offer, and the 199 response is the first reliably sent response, the
required to contain an SDP offer. In this case the UAS SHOULD send 199 response is required to contain an SDP offer. In this case the
the 199 response unreliable, or include an SDP offer with no m- lines UAS SHOULD send the 199 response unreliably, or include an SDP offer
in the reliable 199 response. with no m- lines in the reliable 199 response.
When a 199 response is sent by a UAS, since the provisional response Since the provisional response is only used for information purpose,
is only used for information purpose, the UAS SHOULD send it the UAS SHOULD send it unreliably, unless the "100rel" option-tag
unreliably even if the 100rel option tag [RFC3262] is present in the [RFC3262] is present in the Require header field of the associated
Require header of the associated request. request.
Once the UAS has sent a 199 response, it MUST NOT send or process any
media associated with the terminated early dialog.
6. Proxy behavior 6. Proxy behavior
When a proxy receives a 199 response, it MUST process the response as When a proxy receives a 199 response, it MUST process the response as
any other non-100 provisional responses. The proxy will forward the any other non-100 provisional responses. The proxy will forward the
response upstream towards the sender of the associated request. The response upstream towards the sender of the associated request. The
proxy MAY release resources it has reserved associated with the proxy MAY release resources it has reserved associated with the early
dialog on which the response is received. If a proxy receives a 199 dialog that is terminated. If a proxy receives a 199 response out of
response out of dialog, it processes it as other non-100 provisional dialog, it processes it as other non-100 provisional responses
responses received out of dialog. received out of dialog.
When a forking proxy receives a non-2xx final response that it When a forking proxy receives a non-2xx final response that it
recognizes as terminating one or more early dialogs, it SHOULD recognizes as terminating one or more early dialogs, it MUST generate
generate and send a 199 response upstream for each of the terminated and send a 199 response upstream for each of the terminated early
early dialogs that satisfy each of the following conditions: dialogs 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 (using the 199 option tag) for the - the UAC has indicated support (using the "199" option-tag) for the
199 response code 199 response code
- the forking proxy has not already received and forwarded a 199 - the forking proxy has not already received and forwarded a 199
response for that 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 the INVITE has been issued As a consequence, once a final response to the INVITE has been issued
by the proxy, no further 199 responses associated with the INVITE by the proxy, no further 199 responses associated with the INVITE
request will be generated or forwarded by the proxy. request will be generated or forwarded by the proxy.
When the forking proxy forks the initial request, it generates a When the forking proxy forks the initial request, it generates a
unique Via header branch parameter value for each forked leg. The unique Via header branch parameter value for each forked leg. The
proxy can determine whether additional forking has occurred 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 which 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 occured 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 dialog for which the same top Via branch value was
received in the responses which created those early dialogs. received in the responses which created those early dialogs.
Based on implementation policy, the forking proxy MAY wait before Based on implementation policy, the 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 which 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 tag parameter, which identifies the early dialog contain a To header field tag parameter, that identifies the
that has been terminated. The proxy MUST also insert a Reason header terminated early dialog. The proxy MUST also insert a Reason header
[RFC3326] which contains the response code of the response that field that contains the SIP response code of the response that
triggered the 199 response. 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.
A forking proxy which supports generating of 199 responses MUST keep A forking proxy that supports generating of 199 responses MUST keep
track of early dialogs, in order to determine whether to generate a track of early dialogs, in order to determine whether to generate a
199 response when the proxy receives a non-2xx final response. In 199 response when the proxy receives a non-2xx final response. In
addition, the proxy MUST keep track on which early dialogs it has addition, the proxy MUST keep track on which early dialogs it has
received and forwarded 199 responses, in order to not generate received and forwarded 199 responses, in order to not generate
additional 199 responses for those early dialogs. 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, for which it has previously generated and sent a 199 dialog, for which it has previously generated and sent a 199
response, it MUST forward the 199 response. In case of a unreliably response, it MUST forward the 199 response. If the proxy recieves an
sent 199 response, the proxy MAY forward the 199 response, or it MAY 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. discard it.
When a forking proxy generates a 199 response, the response MUST NOT When a forking proxy generates and sends a 199 response, it MUST NOT
be sent reliably. send the response reliably.
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].
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 request is received by a UA, it MUST
act in the same way as if it had received the request after sending act in the same way as if it had received the request after sending
the final non-2xx response to the INVITE, as specified in [RFC3261]. the final non-2xx response to the INVITE request, as specified in RFC
A UAC that receives a 199 response for an early dialog MUST NOT send 3261. A UAC that receives a 199 response for an early dialog MUST
any further requests on that dialog, except for requests which NOT send any further requests on that dialog, except for requests
acknowledge reliable responses. A proxy MUST forward requests which acknowledge reliable responses. A proxy MUST forward requests
according to [RFC3261], even if the proxy has knowledge that the according to RFC 3261, even if the proxy has knowledge that the early
early dialog has been terminated. dialog has been terminated.
The 199 Early Dialog Terminated response code does not "replace" a A 199 response does not "replace" a final response. RFC 3261
final response. RFC 3261 [RFC3261] specifies when a final response specifies when a final response is sent.
is sent.
8. Usage with SDP offer/answer 8. Usage with SDP offer/answer
A 199 Early Dialog Terminated provisional response SHOULD NOT contain A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264]
an SDP offer/answer message body, unless required by the rules in message body, unless required by the rules in RFC 3264.
[RFC3264].
If the INVITE request did 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 unreliable, or include an SDP offer with no m- lines
in the reliable 199 response. in a reliable 199 response.
9. Usage with 100rel 9. Usage with 100rel
When a 199 Early Dialog Terminated provisional response is sent by a Since the provisional response is only used for information purpose,
UAS, since the provisional response is only used for information the UAS SHOULD send it unreliably, unless the "100rel" option-tag
purpose, the UAS SHOULD send it unreliably even if the 100rel option [RFC3262] is present in the Require header field of the associated
tag [RFC3262] is present in the Require header of the associated
request. request.
When a forking proxy generates a 199 response, the response MUST NOT NOTE: Implementors need to ensure that a 199 response that is sent
be sent reliably. unreliably, even if the associated INVITE request contained a Require
header filed with an "100rel" option-tag, does not trigger errors or
rejection of the 199 response.
10. Examples When a forking proxy generates and sends a 199 response, it MUST NOT
send the response reliably.
10.1. Example with a forking proxy which generates 199 NOTE: If the forking proxy would generate a reliable 199 response, it
would have to terminate the associated PRACK [RFC3262] request.
10. Normative update of RFC 3262
10.1. General
The paragraph in this section is added to section 4 of RFC 3262.
10.2. RFC3262: 4. UAC Behavior
The UAC MUST support reception of all provisional responses, sent
reliably or unreliably; use of the option tag value "100rel" in a
Require header field does not change this requirement.
11. Message Flow Examples
11.1. Example with a forking proxy which generates 199
The figure shows an example, where a proxy (P1) forks an INVITE 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, received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
which send 18x provisional responses in order to create early dialogs which send 18x provisional responses in order to establish early
between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the
sending a 4xx error response each. When P1 receives the 4xx INVITE by sending a 4xx error response each. When P1 receives the
responses it immediately sends 199 responses, associated with the 4xx responses it immediately sends 199 responses towards the UAC, to
dialogs where the 4xx responses were received, towards the UAC. The indicate that the early dialogs for which it received the 4xx
early dialog leg is shown in parenthesis. responses have been terminated. The early dialog leg is shown in
parenthesis.
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) -------------| |
skipping to change at page 11, line 31 skipping to change at page 10, line 45
| |--- 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
10.2. Example with a forking proxy which receives 200 OK 11.2. Example with a forking proxy which receives 200 OK
The figure shows an example, where a proxy (P1) forks an INVITE 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, request received from UAC. The forked request reaches UAS_2, UAS_3
which send 18x provisional responses in order to create early dialogs and UAS_4, that all send 18x provisional responses in order to
between themselves and the UAC. UAS_4 accepts the session by sending establish early dialogs between themselves and the UAC. Later UAS_4
a 200 OK final response. When P1 receives the 200 OK responses it accepts the session and sends a 200 OK final response. When P1
immediately forwards it towards the UAC. P1 does not send 199 receives the 200 OK responses it immediately forwards it towards the
responses for the early dialogs from UAS_2 and UAS_3, since P1 has UAC. P1 does not send 199 responses for the early dialogs from UAS_2
yet not received any final responses on those early dialogs (even if and UAS_3, since P1 has yet not received any final responses on those
P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200 early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1
OK final response from UAS_2 or UAS_3, which P1 would have to forward may still receive 200 OK final response from UAS_2 or UAS_3, that P1
towards the UAC. The early dialog leg is shown in parenthesis. would have to forward towards the UAC. The early dialog leg is shown
in parenthesis.
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) -------------| |
skipping to change at page 12, line 25 skipping to change at page 11, line 32
| |<-- 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
10.3. Example with two forking proxies, of which one generates 199 11.3. Example with two forking proxies, of which one generates 199
The figure shows an example, where a proxy (P1) forks an INVITE The figure shows an example, where a proxy (P1) forks an INVITE
received from UAC. One of the forked INVITEs reaches UAS_2. The request received from UAC. One of the forked requests reaches UAS_2.
other forked INVITE reaches another proxy (P2), which forks the The other requests reach another proxy (P2), that forks the request
INVITE to UAS_3 and UAS_4, which send 18x provisional responses in to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses
order to create early dialogs between themselves and the UAC. UAS_3 in order to establish early dialogs between themselves and UAC.
and UAS_4 reject the INVITE by sending a 4xx error response each. P2 Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx
does not support the 199 response code, and forwards a single 4xx error response each. P2 does not support the 199 response code, and
response. When P1 receives the 4xx responses from P2, it manages to forwards a single 4xx response. P1 supports the 199 response code,
associate the response with the early dialogs from both UAS_3 and and when it receives the 4xx response from P2, it also manages to
UAS_4, so it generates and sends two 199 response to indicate that associate the early dialogs from both both UAS_3 and UAS_4 with the
the early dialogs from UAS_3 and UAS_4 have been terminated. The response. Therefor it generates and sends two 199 responses to
early dialog leg is shown in parenthesis. indiccate that the early dialogs from UAS_3 and UAS_4 have been
terminated. The early dialog leg is shown in parenthesis.
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 34 skipping to change at page 12, line 34
|<- 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
11. Security Considerations 12. Security Considerations
General security issues related to SIP responses are described in General security issues related to SIP responses are described in
[RFC3261]. Due to the nature of the 199 response, it may be [RFC3261]. Due to the nature of the 199 response, it may be
attractive to use it for launching attacks in order to terminate attractive to use it for launching attacks in order to terminate
specific early dialogs (other early dialogs will not be affected). specific early dialogs (other early dialogs will not be affected).
In addition, if a man-in-the-middle sends a 199 response to the UAC, In addition, if a man-in-the-middle sends a 199 response to the UAC,
which terminates a specific dialog, it can take a while until the UAS which terminates a specific dialog, it can take a while until the UAS
finds out that the UAC, and possbile stateful intermediates, have finds out that the UAC, and possbile stateful intermediates, have
terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS)
can be used to minimize, or eliminate, the risk for such attacks. can be used to minimize, or eliminate, the risk for such attacks.
12. IANA Considerations 13. 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, and updates section 4 of RFC
3262.
12.1. IANA Registration of the 199 response code 13.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 of this specification]] RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the
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
12.2. IANA Registration of the 199 Option Tag 13.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 present
in a Supported header, it indicates that the UA supports the in a Supported header, it indicates that the UA supports the
response code. When present in a Require header in a request, response code. When present in a Require header in a request,
it indicates that the UAS MUST support the sending of the it indicates that the UAS MUST support the sending of the
response code. response code.
13. Acknowledgements 13.3. RFC 3262 Update
This document updates section 4 of RFC 3262.
14. 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 and Hans Erik van Elburg for their feedback and suggestions. Drage, Hans Erik van Elburg and Cullen Jennings for their feedback
and suggestions.
14. References 15. Change Log
14.1. Normative References [RFC EDITOR NOTE: Please remove this section when publishing]
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
16. References
16.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 15, line 15 skipping to change at page 14, line 49
(SIP)", RFC 3262, June 2002. (SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[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.
16.2. Informational 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.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
14.2. Informational References
[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.
[RFC5009] Ejza, R., "Private Header (P-Header) Extension to the [3GPP.24.182]
Session Initiation Protocol (SIP) for Authorization of 3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting
Early Media", RFC 5009, September 2007. 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. 80 change blocks. 
337 lines changed or deleted 346 lines changed or added

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