SIP Working Group C. Holmberg
Internet-Draft Ericsson
Intended status: Informational February 21, 2008
Expires: August 24, 2008
Response Code for Indication of Terminated Dialog
draft-holmberg-sipping-199-04.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 August 24, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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, normally a forking SIP proxy, to allow the UAC to know
that an early dialog has been terminated before it a final response
is sent to the request.
Holmberg Expires August 24, 2008 [Page 1]
Internet-Draft 199 February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Server behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Backward compability . . . . . . . . . . . . . . . . . . . . . 5
8. 199 Early Dialog Terminated . . . . . . . . . . . . . . . . . . 6
9. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . . 6
10. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . . 6
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
15. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Holmberg Expires August 24, 2008 [Page 2]
Internet-Draft 199 February 2008
1. Introduction
As defined in SIP (Session Initiation Protocol) specification [2], 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 MAY 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. When SIP entities upstream
receive the 2xx final response they will automatically terminate
other associated outstanding early dialogs.
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 UA that
initiated the request) do not know that a specific early dialog has
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 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.
Holmberg Expires August 24, 2008 [Page 3]
Internet-Draft 199 February 2008
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 [1].
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 receives a 199 Early Dialog Terminated provisional
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.
One example is 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.
Another example is when pre-conditions are used. When the dialog is
terminated, procedures and resources associated to the pre-conditions
for that dialog can be released.
Another example is when in-band security negotiation is used. When
the dialog is terminated, procedures and resrouces associated with
the in-band security negototiation for that dialog can be released.
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.
The UAC MAY use additional information (for example the final
response which triggered the 199 response) received in the 199
response when initiating new sessions, if it is possible to avoid the
new session initation request to be rejected.
Holmberg Expires August 24, 2008 [Page 4]
Internet-Draft 199 February 2008
5. Server behavior
When a UAS wants to terminate a dialog it sends a non-2xx SIP final
response, as specified in [2]. In addition, prior to sending the
non-2xx SIP final response, the UAS MAY send a 199 response to
indicate that the dialog is being terminated.
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 one or more early dialogs and the proxy does not intend to
forward the final response immediately (due to the rules for a
forking proxy) it MUST send a 199 provisional response, for each
associated early dialog that it can associate with the final
response, upstream towards the sender of the associated request. The
199 provisional response MUST contain a To header tag parameter,
which identifies the early dialog that has been terminated.
NOTE: Since the forking proxy is not required to maintain state of
all forked legs, it may not be able to send a 199 provisional
response for each early dialog associated with the received non-2xx
final response.
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 associated with the dialog for which the 199
response was sent. If such request is received, and the receiver
maintains state of the dialogs, the receiver 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 a PRACK if the 199 response was sent
reliably, and PRACKs for other reliable provisional responses that
are to be acknowledged.
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 Early Dialog Terminated provisional responses have been
Holmberg Expires August 24, 2008 [Page 5]
Internet-Draft 199 February 2008
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.
OPEN ISSUE: We need to discuss whether the To tag in the 199
identifies the dialog that has been terminated, and/or if some
additional information element (e.g. SIP header) can be used, which
would allow to indicate the termination of multiple dialogs in a
single 199 response.
OPEN ISSUE: We need to discuss whether, in addition to the dialog
identifier, some additional information (e.g. the non-2xx final
response which triggered the 199 response) should be provided in the
199 response.
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.
A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog
Terminated provisional response reliably in a situation where a
reliable provisional response is required to contain an SDP offer/
answer message body, according to [3] and [4].
10. Usage with 100rel
When a 199 Early Dialog Terminated provisional response is sent,
since it is only used for information purpose, the sender is not
required to send it reliably [3] even if the 100rel option tag is
present in the Require header of the associated request.
OPEN ISSUE: We need to discuss whether a proxy should send 199
reliably at all, since the proxy would have to terminate the
associated PRACK, and support the logic associated with 100rel. If
not sent, how would required 100rel affect the usage of 199?
Holmberg Expires August 24, 2008 [Page 6]
Internet-Draft 199 February 2008
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) -----
<-- 199 (leg 2) --
<-- 4xx (leg 3) --------------
<-- 199 (leg 3) --
<-- 200 (leg 4) -----------------------
<-- 200 (leg 4) --
--- ACK (leg 4) ->
--- ACK (leg 4) ---------------------->
Figure 1: Example call flow
12. Security Considerations
TBD
13. IANA Considerations
This section registers a new SIP response code according to the
procedures of RFC 3261. 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
Holmberg Expires August 24, 2008 [Page 7]
Internet-Draft 199 February 2008
14. Acknowledgements
Thanks to Paul Kyzivat, Dale Worley and Gilad Shaham for their input
on the SIPPING mailing list.
15. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Author's Address
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Holmberg Expires August 24, 2008 [Page 8]
Internet-Draft 199 February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Holmberg Expires August 24, 2008 [Page 9]