draft-ietf-sipcore-199-04.txt   draft-ietf-sipcore-199-05.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track January 30, 2011 Intended status: Standards Track February 1, 2011
Expires: August 3, 2011 Expires: August 5, 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-04.txt draft-ietf-sipcore-199-05.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. the SIP entities.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 August 3, 2011. This Internet-Draft will expire on August 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . 9 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9
8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9
9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 9. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10
10. Message Flow Examples . . . . . . . . . . . . . . . . . . . . 10 9.1. Example with a forking proxy which generates 199 . . . . . 10
10.1. Example with a forking proxy which generates 199 . . . . 10 9.2. Example with a forking proxy which receives 200 OK . . . . 11
10.2. Example with a forking proxy which receives 200 OK . . . 11 9.3. Example with two forking proxies, of which one
10.3. Example with two forking proxies, of which one generates 199 . . . . . . . . . . . . . . . . . . . . . . 11
generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11.1. IANA Registration of the 199 response code . . . . . . . . 13
12.1. IANA Registration of the 199 response code . . . . . . . 14 11.2. IANA Registration of the 199 option-tag . . . . . . . . . 13
12.2. IANA Registration of the 199 option-tag . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 15 14.2. Informational References . . . . . . . . . . . . . . . . . 15
15.2. Informational References . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP) As defined in RFC 3261 [RFC3261], a Session Initiation Protocol (SIP)
early dialog is created when a non-100 provisional response is sent early dialog is created when a non-100 provisional response is sent
to the initial dialog initiation request (e.g. INVITE, outside an to the initial dialog initiation request (e.g. INVITE, outside an
existing dialog). The dialog is considered to be in early state existing dialog). The dialog is considered to be in early state
until a final response is sent. until a final response is sent.
When a proxy receives an initial dialog initiation request, it can When a proxy receives an initial dialog initiation request, it can
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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 a UAC has received and accepted a 199 response, it MUST NOT send Once a UAC has received and accepted a 199 response, it MUST NOT send
or process any media associated with the early dialog that was Any media associated with the early dialog. In addition, if the UAC
is able to associate received media with early dialogs, it MUST NOT
process any received media associated with the early dialog that was
terminated. terminated.
If multiple usages [RFC5057] are used within an early dialog, and it If multiple usages [RFC5057] are used within an early dialog, and it
is not clear which dialog usage the 199 response terminates, SIP is not clear which dialog usage the 199 response terminates, SIP
entities that keep dialog state SHALL NOT release resources entities that keep dialog state SHALL NOT release resources
associated with the early dialog when they receive the 199 response. associated with the early dialog when they receive the 199 response.
If a UAC receives an unreliably sent 199 response on a dialog which If a UAC receives an unreliably sent 199 response on a dialog 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
skipping to change at page 6, line 26 skipping to change at page 6, line 29
early dialog associated session establishment remains, it maintains early dialog associated session establishment remains, it maintains
the "Proceeding" state [RFC3261] and waits for possible subsequent the "Proceeding" state [RFC3261] and waits for possible subsequent
early dialogs to be established, and eventually for a final response early dialogs to be established, and eventually for a final response
to be received. to be received.
5. User Agent Server behavior 5. User Agent Server behavior
If a UAS receives an initial dialog initiation request, with a If a UAS receives an initial dialog initiation request, with a
Supported header field that contains a "199" option-tag, it SHOULD Supported header field that contains a "199" option-tag, it SHOULD
NOT send a 199 response on an early dialog associated with the NOT send a 199 response on an early dialog associated with the
request, on which it intends to send a final response, unless it e.g. request, before it sends a non-2xx final response, unless it e.g. has
has been configured to do so due to lack of support of the 199 been configured to do so due to lack of support of the 199 response
response code by forking proxies or other intermediate SIP entities, code by forking proxies or other intermediate SIP entities, or it is
or it is used in an environment that specifies that it shall send a used in an environment that specifies that it shall send a 199
199 response. response before sending a non-2xx response.
NOTE: If a UAS has created multiple early dialogs associated with an NOTE: If a UAS has created multiple early dialogs associated with an
initial dialog initiation request (the UAS is acting similar to a initial dialog initiation request (the UAS is acting similar to a
forking proxy), it does not always intend to send a final response on forking proxy), it does not always intend to send a final response on
all of those early dialogs. all of those early dialogs.
NOTE: If the Require header field of an initial dialog initiation NOTE: If the Require header field of an initial dialog initiation
request contains a "100rel" option-tag, proxies will not be able to request contains a "100rel" option-tag, proxies will not be able to
generate and send 199 responses. In such cases the UAS might choose 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 to send a 199 response on an early dialog, before it sends a non-2xx
a final response, even if it would not do it in other cases. final response, even if it would not do so in other cases.
If the Supported header field of an initial dialog initiation request If the Supported header field of an initial dialog initiation request
does not contain an "199" option-tag, the UAC MUST NOT send a 199 does not contain an "199" option-tag, the UAC MUST NOT send a 199
response on any early dialog associated with the request. response on any early dialog associated with the request.
When a UAS generates a 199 response, the response MUST contain a To When a UAS generates a 199 response, the response MUST contain a To
header field tag parameter [RFC3261], in order for other entities to header field tag parameter [RFC3261], in order for other entities to
identify the early dialog that has been terminated. The UAS MUST identify the early dialog that has been terminated. The UAS MUST
also insert a Reason header field [RFC3326] that contains a response also insert a Reason header field [RFC3326] that contains a response
code which describes the reason why the early dialog was terminated. code which describes the reason why the early dialog was terminated.
skipping to change at page 9, line 22 skipping to change at page 9, line 23
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, the response When a forking proxy generates and sends a 199 response, the response
SHOULD NOT contain a Contact header field or a Record-Route header SHOULD NOT contain a Contact header field or a Record-Route header
field [RFC3261]. field [RFC3261].
If the Require header field of an initial dialog initiation request If the Require header field of an initial dialog initiation request
contains an "100rel" option-tag, a proxy MUST NOT generate and send contains an "100rel" option-tag, a proxy MUST NOT generate and send
send 199 responses associated with that request. The reason is that 199 responses associated with that request. The reason is that a
a proxy is not allowed to generate and send 199 responses reliably. proxy is not allowed to generate and send 199 responses reliably.
7. Backward compatibility 7. Backward compatibility
Since all SIP entities involved in a session setup do not necessarily Since all SIP entities involved in a session setup do not necessarily
support the specific meaning of the 199 Early Dialog Terminated support the specific meaning of the 199 Early Dialog Terminated
provisional response, the sender of the response MUST be prepared to provisional response, the sender of the response MUST be prepared to
receive SIP requests and responses associated with the dialog for receive SIP requests and responses associated with the dialog for
which the 199 response was sent (a proxy can receive SIP messages which the 199 response was sent (a proxy can receive SIP messages
from either direction). If such request is received by a UA, it MUST from either direction). If such 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
skipping to change at page 10, line 9 skipping to change at page 10, line 11
A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264] A 199 response SHOULD NOT contain an SDP offer/answer [RFC3264]
message body, unless required by the rules in RFC 3264. message body, unless required by the rules in RFC 3264.
If an INVITE request does not contain an SDP offer, and the 199 If an INVITE request does not contain an SDP offer, and the 199
response is the first reliably sent response, the 199 response is response is the first reliably sent response, the 199 response is
required to contain an SDP offer. In this case the UAS SHOULD send required to contain an SDP offer. In this case the UAS SHOULD send
the 199 response unreliable, or include an SDP offer with no m- lines the 199 response 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. Message Flow Examples
Since the 199 response is only used for information purpose, a UAS
SHOULD send it unreliably, unless the Require header field of the
associated request contains an "100rel" option-tag.
When a forking proxy generates and sends a 199 response, it MUST NOT
send the response reliably. A forking proxy MUST NOT send a 199
response if the Require header field of the associated request
contains an "100rel" option-tag.
NOTE: If a forking proxy would generate and send a 199 response
reliably, it would have to terminate the associated PRACK request
[RFC3262].
10. Message Flow Examples
10.1. Example with a forking proxy which generates 199 9.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 11, line 31 skipping to change at page 11, line 5
| |--- 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 9.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 12, line 25 skipping to change at page 11, line 40
| |<-- 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 9.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
skipping to change at page 13, line 34 skipping to change at page 12, line 37
|<- 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 10. Security Considerations
General security issues related to SIP responses are described in RFC General security issues related to SIP responses are described in RFC
3261. Due to the nature of the 199 response, it may be attractive to 3261. Due to the nature of the 199 response, it may be attractive to
use it for launching attacks in order to terminate specific early use it for launching attacks in order to terminate specific early
dialogs (other early dialogs will not be affected). In addition, if dialogs (other early dialogs will not be affected). In addition, if
a man-in-the-middle generates and sends a 199 response, which a man-in-the-middle generates and sends a 199 response, which
terminates a specific dialog, towards the UAC, it can take a while terminates a specific dialog, towards the UAC, it can take a while
until the UAS finds out that the UAC, and possible stateful until the UAS finds out that the UAC, and possible stateful
intermediates, have terminated the dialog. SIP security mechanisms intermediates, have terminated the dialog. SIP security mechanisms
(e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk (e.g. hop-to-hop TLS) can be used to minimize, or eliminate, the risk
for such attacks. for such attacks.
12. IANA Considerations 11. IANA Considerations
This section registers a new SIP response code and a new option-tag, This section registers a new SIP response code and a new option-tag,
according to the procedures of RFC 3261. according to the procedures of RFC 3261.
12.1. IANA Registration of the 199 response code 11.1. IANA Registration of the 199 response code
This section registers a new SIP response code, 199. The required This section registers a new SIP response code, 199. The required
information for this registration, as specified in RFC 3261, is: information for this registration, as specified in RFC 3261, is:
RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC Number: RFC 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
12.2. IANA Registration of the 199 option-tag 11.2. IANA Registration of the 199 option-tag
This section registers a new SIP option-tag, 199. The required This section registers a new SIP option-tag, 199. The required
information for this registration, as specified in RFC 3261, is: information for this registration, as specified in RFC 3261, is:
Name: 199 Name: 199
Description: This option-tag is for indicating support of the 199 Description: This option-tag is for indicating support of the 199
Early Dialog Terminated provisional response code. When present Early Dialog Terminated provisional response code. When present
in a Supported header of a request, it indicates that the UAC in a Supported header of a request, it indicates that the UAC
supports the 199 response code. When present in a Require or supports the 199 response code. When present in a Require or
Proxy-Require header field of a request, it indicates that the Proxy-Require header field of a request, it indicates that the
UAS, or proxies, MUST support the 199 response code. It does UAS, or proxies, MUST support the 199 response code. It does
not require the UAS, or proxies, to actually send 199 not require the UAS, or proxies, to actually send 199
responses. responses.
13. Acknowledgements 12. Acknowledgements
Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet,
Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan, Attila Sipos, Robert Sparks, Brett Tate, Ian Elz, Hadriel Kaplan,
Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, Gonzalo
Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith
Drage, Hans Erik van Elburg and Cullen Jennings for their feedback Drage, Hans Erik van Elburg and Cullen Jennings for their feedback
and suggestions. and suggestions.
14. Change Log 13. 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-04
o "Usage with 100rel" section removed based on comments from John
Elwell (31.01.2011)
o Editorial corrections based on comments from Paul Kyzivat
(31.01.2011)
Changes from draft-ietf-sipcore-199-03 Changes from draft-ietf-sipcore-199-03
o RFC 3262 update removed o RFC 3262 update removed
o Functional modification: proxy must not send 199 in case of o Functional modification: proxy must not send 199 in case of
Require:100rel Require:100rel
o Recommendation that UAC does not require reliable provisional o Recommendation that UAC does not require reliable provisional
responses with 199 responses with 199
o Clarification that Require:199 does not mandate the UAS to send a o Clarification that Require:199 does not mandate the UAS to send a
199 response 199 response
o Clarification that a UAC needs to insert the 199 option-tag in a o Clarification that a UAC needs to insert the 199 option-tag in a
skipping to change at page 15, line 38 skipping to change at page 14, line 45
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
15. References 14. References
15.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
skipping to change at page 16, line 19 skipping to change at page 15, line 26
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.
15.2. Informational References 14.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. 22 change blocks. 
58 lines changed or deleted 49 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/