draft-ietf-sipcore-199-03.txt   draft-ietf-sipcore-199-04.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 3262 (if approved) December 9, 2010 Intended status: Standards Track January 30, 2011
Intended status: Standards Track Expires: August 3, 2011
Expires: June 12, 2011
Session Initiation Protocol (SIP) Response Code for Indication of Session Initiation Protocol (SIP) Response Code for Indication of
Terminated Dialog Terminated Dialog
draft-ietf-sipcore-199-03.txt draft-ietf-sipcore-199-04.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 towards upstream
SIP entities (including the User Agent Client (UAC)) that an early SIP entities (including the User Agent Client (UAC)) that an early
dialog has been terminated, before a final response is sent towards dialog has been terminated, before a final response is sent towards
the SIP entities. In addition, this specification updates section 4 the SIP entities.
of RFC 3262.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on June 12, 2011. This Internet-Draft will expire on August 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 5
5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 8 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9
8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9
9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 9 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10
10. Normative update of RFC 3262 . . . . . . . . . . . . . . . . . 9 10. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Example with a forking proxy which generates 199 . . . . 10
10.2. RFC3262: 4. UAC Behavior . . . . . . . . . . . . . . . . 9 10.2. Example with a forking proxy which receives 200 OK . . . 11
11. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 10.3. Example with two forking proxies, of which one
11.1. Example with a forking proxy which generates 199 . . . . 10 generates 199 . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Example with a forking proxy which receives 200 OK . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11.3. Example with two forking proxies, of which one 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
generates 199 . . . . . . . . . . . . . . . . . . . . . . 11 12.1. IANA Registration of the 199 response code . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12.2. IANA Registration of the 199 option-tag . . . . . . . . . 14
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. IANA Registration of the 199 response code . . . . . . . 13 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.2. IANA Registration of the 199 option-tag . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.3. RFC 3262 Update . . . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . 15
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 15.2. Informational References . . . . . . . . . . . . . . . . 16
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
16.1. Normative References . . . . . . . . . . . . . . . . . . 14
16.2. Informational References . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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 therefor 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 release resources associated receive the 199 response can use it to trigger the release of
with the terminated early dialog. In addition, SIP entities might resources associated with the terminated early dialog. In addition,
also use the 199 provisional response to make policy related SIP entities might also use the 199 response to make policy related
decisions related to early dialogs. decisions related to early dialogs.
This specification updates RFC 3262 [RFC3841], by mandating a UAC to
be prepared to receive unreliably sent provisional responses even if
it has required provisional responses to be sent reliably.
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 receipients 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 an UAS, and can not 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 receipients. In such 199 responses get lost before they reach the recipients. In such
cases, recipients will behave the same as if the 199 response code cases, recipients will behave the same as if the 199 response code
were not used at all. were not used at all.
One example for which a UA 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. It could also use the 199 response to make terminated early dialog. The UAC could also use the 199 response to
policy related decisions related to early dialogs. For example, if a make policy related decisions related to early dialogs. For example,
UAC is playing media associated with an early dialog, and the it if a UAC is playing media associated with an early dialog, and the it
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 Applications 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 receipients. 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 request, and if it is willing to receive When a UAC sends an initial dialog initiation request, and if it is
199 responses, it MUST insert the "199" option-tag in the Supported willing to receive 199 responses, it MUST insert an "199" option-tag
header field. The option-tag indicates that the UAC supports 199 in the Supported header field [RFC3261] of the request. The option-
responses. The UAC SHOULD NOT insert the "199" option-tag in the tag indicates that the UAC supports, and is willing to receive, 199
Require or the Proxy-Require header fields, since in many cases it responses. A UAC SHOULD NOT insert an "199" option-tag in the
would result in unnecessary session establishment failures. Require or the Proxy-Require header field [RFC3261] of the request,
since in many cases it would result in unnecessary session
establishment failures.
When a UAC receives a 199 response it might release resources NOTE: The UAC always needs to insert an "199" option-tag in the
associated with the terminated early dialog. It might also use the Supported header field, in order to indicate that it supports, and is
199 response to make policy related decisions related to early willing to receive, 199 responses, even if it also inserts the
option-tag in the Require or Proxy-Require header field.
It is RECOMMENDED that a UAC does not insert an "100rel" option-tag
[RFC3262] in the Require header field when it also indicates support
of 199 responses, unless the UAC also uses some other SIP extension
or procedure that mandates it to do so. The reason is that proxies
are not allowed to generate and send 199 responses when the UAC has
required provisional responses to be sent reliably.
When a UAC receives a 199 response, it might release resources
associated with the terminated early dialog. A UAC might also use
the 199 response to make policy related decisions related to early
dialogs. 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 in
order to terminate the early dialog when it receives the 199 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 associated
with the session establishment. For those the normal SIP rules, with the session establishment. For those the normal SIP rules,
regarding transaction timeout etc, still apply. regarding transaction timeout etc, still apply.
Once the UAC has received and accepted the 199 provisional response, Once a UAC has received and accepted a 199 response, it MUST NOT send
it MUST NOT send or process any media associated with the early or process any media associated with the early dialog that was
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 SIP entity receives an unreliable 199 response on a dialog which If a UAC receives an unreliably sent 199 response on a dialog which
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 responses. If a
SIP entity receives a reliable 199 response on a dialog which has not UAC receives a reliably sent 199 response on a dialog which has not
previously been created the UAC MUST acknowledge the 199 response, as previously been created, it MUST acknowledge the 199 response, as
described in RFC 3262. described in RFC 3262 [RFC3262].
If the 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 associatd session establisment remains, the UAC early dialog associated session establishment remains, it maintains
maintains the "Procedding" state [RFC3261] and waits for possible the "Proceeding" state [RFC3261] and waits for possible subsequent
subsequent early dialogs to be established, and eventually for a early dialogs to be established, and eventually for a final response
final response to be received. to be received.
5. User Agent Server behavior 5. User Agent Server behavior
If a UAS receives an initial request that contains an "199" option- If a UAS receives an initial dialog initiation request, with a
tag, it SHOULD NOT send a 199 response on an early dialog on which it Supported header field that contains a "199" option-tag, it SHOULD
intends to send a final response, unless it e.g. has been configured NOT send a 199 response on an early dialog associated with the
to do so due to lack of 199 support by forking proxies or other request, on which it intends to send a final response, unless it e.g.
intermediate SIP entities. has been configured to do so due to lack of support of the 199
response code by forking proxies or other intermediate SIP entities,
or it is used in an environment that specifies that it shall send a
199 response.
NOTE: If the UAS has created multiple early dialogs (the UAS is NOTE: If a UAS has created multiple early dialogs associated with an
acting similar to a forking proxy), it does not always intend to send initial dialog initiation request (the UAS is acting similar to a
a final response for all of those dialogs. forking proxy), it does not always intend to send a final response on
all of those early dialogs.
NOTE: If the Require header field of an initial dialog initiation
request contains a "100rel" option-tag, proxies will not be able to
generate and send 199 responses. In such cases the UAS might choose
to send a 199 response on an early dialog on which it intends to send
a final response, even if it would not do it in other cases.
If the Supported header field of an initial dialog initiation request
does not contain an "199" option-tag, the UAC MUST NOT send a 199
response on any early dialog associated with the request.
When a UAS generates a 199 response, the response MUST contain a To When a UAS generates a 199 response, the response MUST contain a To
header field tag parameter, in order to identify the early dialog header field tag parameter [RFC3261], in order for other entities to
that has been terminated. The UAS MUST also insert a Reason header identify the early dialog that has been terminated. The UAS MUST
field [RFC3326] that contains a response code which describes the also insert a Reason header field [RFC3326] that contains a response
reason why the early dialog was terminated. code which describes the reason why the early dialog was terminated.
The UAS MUST NOT insert a "199" option-tag in the Supported, Require
or Proxy-Require header field of the 199 response.
If the 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 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 RFC 3264 [RFC3264]. unless required by the rules in RFC 3264 [RFC3264].
According to RFC 3264, if the 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, the offer, and the 199 response is the first reliably sent response
199 response is required to contain an SDP offer. In this case the associated with the request, the 199 response is required to contain
UAS SHOULD send the 199 response unreliably, or include an SDP offer an SDP offer. In this case the UAS SHOULD send the 199 response
with no m- lines in the reliable 199 response. unreliably, or send the 199 response reliably and include an SDP
offer with no m- lines in the response.
Since the provisional response is only used for information purpose, Since a 199 response is only used for information purpose, the UAS
the UAS SHOULD send it unreliably, unless the "100rel" option-tag SHOULD send it unreliably, unless the "100rel" option-tag is present
[RFC3262] is present in the Require header field of the associated in the Require header field of the associated request.
request.
Once the UAS has sent a 199 response, it MUST NOT send or process any Once a UAS has sent a 199 response, it MUST NOT send or process any
media associated with the terminated early dialog. 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 to an initial dialog initiation
any other non-100 provisional responses. The proxy will forward the request, it MUST process the response as any other non-100
response upstream towards the sender of the associated request. The provisional response. The proxy will forward the response upstream
proxy MAY release resources it has reserved associated with the early towards the sender of the associated request. The proxy MAY release
dialog that is terminated. If a proxy receives a 199 response out of resources it has reserved associated with the early dialog that is
dialog, it processes it as other non-100 provisional responses terminated. If a proxy receives a 199 response out of dialog, it
received out of dialog. MUST process it as other non-100 provisional responses 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 to an initial
recognizes as terminating one or more early dialogs, it MUST generate dialog initiation request, that it recognizes as terminating one or
and send a 199 response upstream for each of the terminated early more early dialogs associated with the request, it MUST generate and
dialogs that satisfy each of the following conditions: send a 199 response upstream for each of the terminated early 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 (by inserting the "199" option-tag in
199 response code a Supported header field) of the 199 response code in the associated
request
- the UAC has not required provisional responses to be sent reliably
(by inserting the "100rel" option-tag in a Require or Proxy-Require
header field) in the associated request
- the forking proxy has not already received and forwarded a 199 - 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 the INVITE has been issued As a consequence, once a final response to an initial dialog
by the proxy, no further 199 responses associated with the INVITE initiation request has been issued by the proxy, no further 199
request will be generated or forwarded by the proxy. responses associated with the request will be generated or forwarded
by the proxy.
When the forking proxy forks the initial request, it generates a When a forking proxy forks an initial dialog initiation request, it
unique Via header branch parameter value for each forked leg. The generates a unique Via header branch parameter value for each forked
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 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 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 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, 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 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 field tag parameter, that identifies the contain a To header field tag parameter, that identifies the
terminated early dialog. The 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. types of actions and procedures. The proxy MUST NOT insert a "199"
option-tag in the Supported, Require or Proxy-Require header field of
the 199 response.
A forking proxy that 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, a 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. If the proxy recieves an response, it MUST forward the 199 response. If a proxy receives an
unreliably sent 199 response, for which it has previously generated unreliably sent 199 response, for which it has previously generated
and sent a 199 response,it MAY forward the response, or it MAY and sent a 199 response, it MAY forward the response, or it MAY
discard it. discard it.
When a forking proxy generates and sends a 199 response, it MUST NOT
send the response reliably.
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
contains an "100rel" option-tag, a proxy MUST NOT generate and send
send 199 responses associated with that request. The reason is that
a proxy is not allowed to generate and send 199 responses reliably.
7. Backward compatibility 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 request, as specified in RFC the final non-2xx response to the INVITE request, as specified in RFC
skipping to change at page 9, line 19 skipping to change at page 10, line 11
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 unreliable, or include an SDP offer with no m- lines
in a reliable 199 response. in a reliable 199 response.
9. Usage with 100rel 9. Usage with 100rel
Since the provisional response is only used for information purpose, Since the 199 response is only used for information purpose, a UAS
the UAS SHOULD send it unreliably, unless the "100rel" option-tag SHOULD send it unreliably, unless the Require header field of the
[RFC3262] is present in the Require header field of the associated associated request contains an "100rel" option-tag.
request.
NOTE: Implementors need to ensure that a 199 response that is sent
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.
When a forking proxy generates and sends a 199 response, it MUST NOT When a forking proxy generates and sends a 199 response, it MUST NOT
send the response reliably. send the response reliably. A forking proxy MUST NOT send a 199
response if the Require header field of the associated request
NOTE: If the forking proxy would generate a reliable 199 response, it contains an "100rel" option-tag.
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 NOTE: If a forking proxy would generate and send a 199 response
reliably or unreliably; use of the option tag value "100rel" in a reliably, it would have to terminate the associated PRACK request
Require header field does not change this requirement. [RFC3262].
11. Message Flow Examples 10. Message Flow Examples
11.1. Example with a forking proxy which generates 199 10.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 establish early which send 18x provisional responses in order to establish early
dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the
INVITE by sending a 4xx error response each. When P1 receives the INVITE by sending a 4xx error response each. When P1 receives the
4xx responses it immediately sends 199 responses towards the UAC, to 4xx 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. parenthesis.
skipping to change at page 10, line 45 skipping to change at page 11, line 31
| |--- 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
11.2. Example with a forking proxy which receives 200 OK 10.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
request received from UAC. The forked request reaches UAS_2, UAS_3 request received from UAC. The forked request reaches UAS_2, UAS_3
and UAS_4, that all send 18x provisional responses in order to and UAS_4, that all 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 responses 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 yet not received any final responses on those
early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1 early dialogs (even if P1 sends CANCEL requests to UAS_2 and UAS_3 P1
skipping to change at page 11, line 32 skipping to change at page 12, line 25
| |<-- 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
11.3. Example with two forking proxies, of which one generates 199 10.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
request received from UAC. One of the forked requests reaches UAS_2. request received from UAC. One of the forked requests reaches UAS_2.
The other requests reach another proxy (P2), that forks the request The other requests reach another proxy (P2), that forks the request
to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses
in order to establish early dialogs between themselves and UAC. in order to establish early dialogs between themselves and UAC.
Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx Later UAS_3 and UAS_4 reject the INVITE request by sending a 4xx
error response each. P2 does not support the 199 response code, and error response each. 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 both UAS_3 and UAS_4 with the associate the early dialogs from both UAS_3 and UAS_4 with the
response. Therefor it generates and sends two 199 responses to response. Therefore it generates and sends two 199 responses to
indiccate 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 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) -------------| |
skipping to change at page 12, line 34 skipping to change at page 13, 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
12. Security Considerations 11. Security Considerations
General security issues related to SIP responses are described in General security issues related to SIP responses are described in RFC
[RFC3261]. Due to the nature of the 199 response, it may be 3261. Due to the nature of the 199 response, it may be attractive to
attractive to use it for launching attacks in order to terminate use it for launching attacks in order to terminate specific early
specific early dialogs (other early dialogs will not be affected). dialogs (other early dialogs will not be affected). In addition, if
In addition, if a man-in-the-middle sends a 199 response to the UAC, a man-in-the-middle generates and sends a 199 response, which
which terminates a specific dialog, it can take a while until the UAS terminates a specific dialog, towards the UAC, it can take a while
finds out that the UAC, and possbile stateful intermediates, have until the UAS finds out that the UAC, and possible stateful
terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) intermediates, have terminated the dialog. SIP security mechanisms
can be used to minimize, or eliminate, the risk for such attacks. (e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk
for such attacks.
13. IANA Considerations 12. 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, and updates section 4 of RFC according to the procedures of RFC 3261.
3262.
13.1. IANA Registration of the 199 response code 12.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 XXXX [[NOTE TO IANA: Please replace XXXX with the
RFC number of this specification]] 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
13.2. IANA Registration of the 199 option-tag 12.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 of a request, it indicates that the UAC
response code. When present in a Require header in a request, supports the 199 response code. When present in a Require or
it indicates that the UAS MUST support the sending of the Proxy-Require header field of a request, it indicates that the
response code. UAS, or proxies, MUST support the 199 response code. It does
not require the UAS, or proxies, to actually send 199
13.3. RFC 3262 Update responses.
This document updates section 4 of RFC 3262.
14. Acknowledgements 13. 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.
15. Change Log 14. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
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 Changes from draft-ietf-sipcore-199-02
o Usage example section rewritten and clarified o Usage example section rewritten and clarified
o Requirement has been removed o Requirement has been removed
o SIP has been added to document title o SIP has been added to document title
o Acronyms expanded in the abstract and throughout the document o Acronyms expanded in the abstract and throughout the document
o Editorial fixes throughout the document o Editorial fixes throughout the document
o Indication added that document is aimed for standards track o Indication added that document is aimed for standards track
o Some references made informative o Some references made informative
o Additional text added regarding the usage of the Reason header o Additional text added regarding the usage of the Reason header
o SBC latching text has been removed o SBC latching text has been removed
skipping to change at page 14, line 25 skipping to change at page 15, line 38
o Note added, which clarifies that 199 does not affect other early o Note added, which clarifies that 199 does not affect other early
dialogs dialogs
o References added to Security Considerations o References added to Security Considerations
o Clarification of local ringing tone o Clarification of local ringing tone
o Clarification that media must not be sent or processed after 199 o Clarification that media must not be sent or processed after 199
o Text regarding sending media on terminated dialogs added to o Text regarding sending media on terminated dialogs added to
security section security section
o Change: UAS must send 199 reliably in case of Require:100rel o Change: UAS must send 199 reliably in case of Require:100rel
o Change: Section 4 of RFC 3262 updated o Change: Section 4 of RFC 3262 updated
16. References 15. References
16.1. Normative References 15.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 6 skipping to change at page 16, line 19
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.
16.2. Informational References 15.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.
[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.24.182]
3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting 3GPP, "IP Multimedia Subsystem (IMS) Customized Alerting
 End of changes. 62 change blocks. 
175 lines changed or deleted 203 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/