SIP Working Group C. Holmberg
Internet-Draft Ericsson
Expires: April 23, 2009 October 20, 2008
Response Code for Indication of Terminated Dialog
draft-ietf-sip-199-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 April 23, 2009.
Abstract
This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP entity can use to indicate upstream that an
early dialog has been terminated. The response code can be used by a
SIP entity to indicate to the UAC that an early dialog has been
terminated, before a final response is sent to the UAC.
Holmberg Expires April 23, 2009 [Page 1]
Internet-Draft 199 October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Examples of resource types . . . . . . . . . . . . . . . . 5
5. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 6
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Backward compability . . . . . . . . . . . . . . . . . . . . . 7
8. 199 Early Dialog Terminated . . . . . . . . . . . . . . . . . 7
9. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 7
10. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 7
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13.1. IANA Registration of the 199 response code . . . . . . . . 9
13.2. IANA Registration of the 199 Option Tag . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
15. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Holmberg Expires April 23, 2009 [Page 2]
Internet-Draft 199 October 2008
1. Introduction
As defined in SIP (Session Initiation Protocol) specification
[RFC3261], an early SIP dialog is created when a non-100 provisional
response is sent to the dialog initiation request (e.g. INVITE).
The dialog is considered to be in early state until a final response
is sent.
When a proxy receives an initial request (outside an existing dialog,
and without a pre-defined route set), it can forward it towards
multiple remote destinations. When the proxy does that, it performs
forking.
When a forking proxy receives non-100 provisional responses, it
forwards the responses upstream towards the sender of the associated
request. When a forking proxy receives a 2xx final response, it
forwards the response upstream towards the sender of the associated
request. At that point the proxy normally sends a CANCEL request
downstream towards all remote destinations where it previously sent
the request associated with the 2xx final response, and from which it
has yet not received a final response, in order to terminate
associated outstanding early dialogs. It is possible to receive
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, for INVITE initiated dialogs 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
request that proxies do not send CANCEL requests downstream once they
have received the first final 2xx response.
When a forking proxy receives a non-2xx final response, it does not
always immediately forward the response upstream towards the sender
of the associated request. Instead, the forking proxy "stores" it
and waits for further final responses from remote destinations where
the forked request was forwarded. At some point the proxy uses a
specified mechanism to determine the "best" final response code, and
forwards that final response upstream towards the sender of the
associated request. When SIP entities upstream receive the non-2xx
final response they will automatically terminate the session setup
and all associated early dialogs.
Since the forking proxy does not always immediately forward non-2xx
final responses, SIP entities upstream (including the UAC that
initiated the request) do not know that a specific early dialog has
Holmberg Expires April 23, 2009 [Page 3]
Internet-Draft 199 October 2008
been terminated, and the SIP entities keep possible resources
associated with the early dialog until they receive a final response
from the forking proxy.
This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a forking proxy and a UAS can use to indicate
upstream that an early dialog has been terminated. The 199 response
can also be sent by an UAS, prior to sending a non-2xx final
response. SIP entities that receive the 199 provisional response MAY
release resources associated with the specific early dialog.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[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. Client behavior
When a client sends an initial request it MUST insert the 199 option-
tag in the Supported header, which indicates that the client supports
the 199 Early Dialog Terminated response code.
When a client receives a 199 response it MAY release resources and
procedures associated with the early dialog the 199 response is
received on. 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.
If multiple usages [RFC5057] are used within an early dialog, and it
is not clear which dialogusage 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 a 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.
Holmberg Expires April 23, 2009 [Page 4]
Internet-Draft 199 October 2008
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
resources associated to the pre-conditions for that dialog can be
released.
3. In-band security negotiation - when the dialog is terminated,
procedures and resrouces associated with the in-band security
negototiation for that dialog can be released.
4. ICE [ref needed] mechanism - when the dialog is terminated,
procedures and resrouces associated with the ICE related in-band
procedures for that dialog can be released.
5. Limited access resources - in case of forking and multiple stream
it may not be possible to allow early media on all dialogs, so some
dialogs may e.g. be set to "inactive". When a dialog is terminated,
media can be allowed on other dialogs.
If the client is able to associate the 199 response with a specific
media stream, it MAY choose to discard media on that specific media
stream, it MAY release all resources associated with that media
stream and it MAY start to process media streams received on other
early diaogs. When the P-Early-Media header 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 [RFC3261], the secure media stream is bound to
the crypto context setup for the dialog, and can be identified using
the MKI of SRTP.
If the client only has a single early dialog (other early dialogs may
not have been established, or they may have been established and
later terminated) when a 199 response is received for that early
dialog, after the client has terminated the early dialog associated
with the 199 response it will act as before the first early dialog
was established.
Holmberg Expires April 23, 2009 [Page 5]
Internet-Draft 199 October 2008
5. Server behavior
If the received intial request contains an 199 option tag, and the
server has established an early dialog with the initiator of the
request, the server MAY send a 199 response prior to sending a non-
200 final response towards the initiator of the request.
If the server intends to send 199 responses, and if the server
supports the procedures defined in [RFC3840], it MAY during the
registration procedure use the sip.extensions feature tag [RFC3840]
to indicate support of the 199 response code.
OPEN ISSUE: We still need to describe when a UAS sends a 199
response. One potential solution is to define an indicator which a
forking proxy that supports 199 can insert in the request, indicating
that the UAS does not need to send 199.
6. Proxy behavior
When a proxy receives a 199 provisional response, the proxy MUST
process the response as any other non-100 provisional responses. The
proxy MUST forward the response upstream towards the sender of the
associated request. The proxy MAY release resources it has reserved
associated with the early dialog on which the response is received.
When a forking proxy receives a non-2xx final response which
terminates an early dialog and the proxy does not intend to forward
the final response immediately (due to the rules for a forking
proxy), and the UAC has indicated support of the 199 response code,
the proxy MUST generate and send a 199 provisional response upstream
for that early dialog, unless the proxy prior has received and
forwarded a 199 response for that early dialog. The 199 provisional
response MUST contain a To header tag parameter, which identifies the
early dialog that has been terminated.
A proxy which supports generating of 199 response codes MUST keep
track of early dialogs, in order to determine whether to generate a
199 response when the proxy receives a non-2xx final response. In
addition, the proxy MUST keep track on which early dialogs it has
received and forwarded 199 responses, in order to not generate
additional 199 responses for those early dialogs.
NOTE: If the non-2xx final response is received from another forking
proxy upstream, the final response may terminate multiple early
dialogs. If the forking proxy which receives the final response is
able to associate the final response with multiple early dialogs, the
forking proxy can generate 199 responses for all of those early
Holmberg Expires April 23, 2009 [Page 6]
Internet-Draft 199 October 2008
dialogs.
7. Backward compability
Since all SIP entities involved in a session setup do not necessarily
support the specific meaning of the 199 Early Dialog Terminated
provisional response, the sender of the response MUST be prepared to
receive SIP requests and responses associated with the dialog for
which the 199 response was sent (a proxy may receive SIP messages
from either direction). If such request is received by a UA, it MUST
reply to such requests with a 481 final response. A UAC that
receives a 199 response for an early dialog MUST NOT send any further
requests on that dialog, except for requests which acknowledge
reliable responses. A proxy MUST forward requests according to
[RFC3261], even if the proxy has knowledge that the early dialog has
been terminated.
The 199 Early Dialog Terminated response code MUST NOT "replace" a
final response. A final response MUST always be sent, after one or
many 199 responses have been sent.
8. 199 Early Dialog Terminated
The 199 Early Dialog Terminated response code allows a SIP entity to
indicate upstream that a specific dialog has been terminated, before
a final response is sent by the entity. The To header tag value is
used to identify the dialog.
9. Usage with SDP offer/answer
A 199 Early Dialog Terminated provisional response MUST NOT contain a
new SDP offer/answer message body, but the sender of the response MAY
insert a copy of a previously sent offer/answer message body as
otherwise allowed by the offer/answer rules for a provisional
response.
10. Usage with 100rel
When a 199 Early Dialog Terminated provisional response is sent by a
UAS, since the provisional response is only used for information
purpose, the UAS SHOULD send it unreliably even if the 100rel option
tag [RFC3262] is present in the Require header of the associated
request.
Holmberg Expires April 23, 2009 [Page 7]
Internet-Draft 199 October 2008
When a forking proxy triggers a 199 response, the response MUST NOT
be sent reliably.
NOTE: The 199 response MUST NOT be sent reliably if it would be
required to insert a new SDP offer/answer message body in the
response, according to the rules in [RFC3264].
11. Example
The figure shows an example, where a proxy (P1) forks an INVITE
received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
which send 18x provisional responses in order to create early dialogs
between themselves and the UAC. UAS_2 and UAS_3 rejects the INVITE
by sending a 4xx error response. When P1 receives the 4xx responses
it immediately sends 199 Early Dialog Terminated responses,
associated with the dialogs where the 4xx responses were received,
towards the UAC.
UAC P1 UAS_2 UAS_3 UAS_4
--- INVITE ------>
--- INVITE (leg 2) ->
--- INVITE (leg 3) ---------->
--- INVITE (leg 4) ------------------->
<-- 18x (leg 2) -----
<-- 18x (leg 2) --
<-- 18x (leg 3) --------------
<-- 18x (leg 3) --
<-- 18x (leg 4) -----------------------
<-- 18x (leg 4) --
<-- 4xx (leg 2) -----
--- ACK (leg 2) ---->
<-- 199 (leg 2) --
<-- 4xx (leg 3) --------------
--- ACK (leg 3) ------------->
<-- 199 (leg 3) --
<-- 200 (leg 4) -----------------------
<-- 200 (leg 4) --
--- ACK (leg 4) ->
--- ACK (leg 4) ---------------------->
Figure 1: Example call flow
Holmberg Expires April 23, 2009 [Page 8]
Internet-Draft 199 October 2008
12. Security Considerations
TBD
13. IANA Considerations
This section registers a new SIP response code and a new option tag,
according to the procedures of RFC 3261.
13.1. IANA Registration of the 199 response code
This section registers a new SIP response code, 199. The required
information for this registration, as specified in RFC 3261, is:
RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification]]
Response Code Number: 199
Default Reason Phrase: Early Dialog Terminated
13.2. IANA Registration of the 199 Option Tag
This section registers a new SIP option tag, 199. The required
information for this registration, as specified in RFC 3261, is:
Name: 199
Description: This option tag is for indicating support of the 199
Early Dialog Terminated provisional response code. When present
in a Supported header, it indicates that the UA supports the
response code. When present in a Require header in a request,
it indicates that the UAS MUST support the sending of the
response code.
14. Acknowledgements
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet,
Attila Sipos, Robert Sparks, Brett Tate and Ian Elz for their
feedback and suggestions.
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Holmberg Expires April 23, 2009 [Page 9]
Internet-Draft 199 October 2008
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 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,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires April 23, 2009 [Page 10]
Internet-Draft 199 October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Holmberg Expires April 23, 2009 [Page 11]