draft-ietf-sipcore-199-01.txt   draft-ietf-sipcore-199-02.txt 
SIPCORE Working Group C. Holmberg SIPCORE Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: June 5, 2010 December 2, 2009 Expires: June 12, 2010 December 9, 2009
Response Code for Indication of Terminated Dialog Response Code for Indication of Terminated Dialog
draft-ietf-sipcore-199-01.txt draft-ietf-sipcore-199-02.txt
Abstract Abstract
This specification defines a new SIP response code, 199 Early Dialog This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP forking proxy and a UAS can use to indicate Terminated, which a SIP forking proxy and a UAS can use to indicate
upstream towards the UAC that an early dialog has been terminated, upstream towards the UAC that an early dialog has been terminated,
before a final response is sent towards the UAC. before a final response is sent towards the UAC.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 5, 2010. This Internet-Draft will expire on June 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4 4. User Agent Client behavior . . . . . . . . . . . . . . . . . . 4
4.1. Examples of resource types . . . . . . . . . . . . . . . . 5 4.1. Examples of resource types . . . . . . . . . . . . . . . . 5
4.2. Examples of policy procedures . . . . . . . . . . . . . . 6 4.2. Examples of policy procedures . . . . . . . . . . . . . . 6
5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7 5. User Agent Server behavior . . . . . . . . . . . . . . . . . . 7
6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9 7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 9
8. 199 Early Dialog Terminated . . . . . . . . . . . . . . . . . 9 8. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 9
9. Usage with SDP offer/answer . . . . . . . . . . . . . . . . . 10 9. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10
10. Usage with 100rel . . . . . . . . . . . . . . . . . . . . . . 10 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Example with a forking proxy which generates 199 . . . . . 10
11.1. Example with a forking proxy which generates 199 . . . . . 10 10.2. Example with a forking proxy which receives 200 OK . . . . 11
11.2. Example with a forking proxy which receives 200 OK . . . . 11 10.3. Example with two forking proxies, of which one
11.3. Example with two forking proxies, of which one
generates 199 . . . . . . . . . . . . . . . . . . . . . . 12 generates 199 . . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13.1. IANA Registration of the 199 response code . . . . . . . . 14 12.1. IANA Registration of the 199 response code . . . . . . . . 14
13.2. IANA Registration of the 199 Option Tag . . . . . . . . . 14 12.2. IANA Registration of the 199 Option Tag . . . . . . . . . 14
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14
15.2. Informational References . . . . . . . . . . . . . . . . . 15 14.2. Informational References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
As defined in SIP (Session Initiation Protocol) specification As defined in SIP (Session Initiation Protocol) specification
[RFC3261], an early SIP dialog is created when a non-100 provisional [RFC3261], an early SIP dialog is created when a non-100 provisional
response is sent to the dialog initiation request (e.g. INVITE). response is sent to the dialog initiation request (e.g. INVITE).
The dialog is considered to be in early state until a final response The dialog is considered to be in early state until a final response
is sent. is sent.
skipping to change at page 3, line 48 skipping to change at page 3, line 48
When a forking proxy receives a non-2xx final response, it does not When a forking proxy receives a non-2xx final response, it does not
always immediately forward the response upstream towards the sender always immediately forward the response upstream towards the sender
of the associated request. Instead, the forking proxy "stores" it of the associated request. Instead, the forking proxy "stores" it
and waits for further final responses from remote destinations where and waits for further final responses from remote destinations where
the forked request was forwarded. At some point the proxy uses a the forked request was forwarded. At some point the proxy uses a
specified mechanism to determine the "best" final response code, and specified mechanism to determine the "best" final response code, and
forwards that final response upstream towards the sender of the forwards that final response upstream towards the sender of the
associated request. When SIP entities upstream receive the non-2xx associated request. When SIP entities upstream receive the non-2xx
final response they will release resources associated with the final response they will release resources associated with the
session, and the UAC will terminate the session setup. session, and the UAC will terminate, or retry, the session setup.
Since the forking proxy does not always immediately forward non-2xx Since the forking proxy does not always immediately forward non-2xx
final responses, SIP entities upstream (including the UAC that final responses, SIP entities upstream (including the UAC that
initiated the request) do not know that a specific early dialog has initiated the request) do not know that a specific early dialog has
been terminated, and the SIP entities keep possible resources been terminated, and the SIP entities keep possible resources
associated with the early dialog until they receive a final response associated with the early dialog until they receive a final response
from the forking proxy. from the forking proxy.
This specification defines a new SIP response code, 199 Early Dialog This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a forking proxy and a UAS can use to indicate Terminated, which a forking proxy and a UAS can use to indicate
upstream that an early dialog has been terminated. The 199 response upstream that an early dialog has been terminated. The 199 response
can also be sent by a UAS, prior to sending a non-2xx final response. can also be sent by a UAS, prior to sending a non-2xx final response.
SIP entities that receive the 199 provisional response MAY release SIP entities that receive the 199 provisional response can release
resources associated with the specific early dialog. The SIP resources associated with the specific early dialog. The SIP
entities MAY also use the 199 provisional response to make policy entities can also use the 199 provisional response to make policy
related decisions related to early dialogs. related decisions related to early dialogs.
The 199 response code is an optimization, which allows the UAC to be The 199 response code is an optimization, which allows the UAC to be
informed about terminated early dialogs. However, since the support informed about terminated early dialogs. However, since the support
of the 199 response is optional, a UAC cannot assume that it will of the 199 response is optional, a UAC cannot assume that it will
always receive a 199 provisional response for all terminated early always receive a 199 provisional response for all terminated early
dialogs. dialogs.
2. Conventions 2. Conventions
skipping to change at page 5, line 16 skipping to change at page 5, line 16
procedures associated with the early dialog on which the 199 response procedures associated with the early dialog on which the 199 response
is received. Examples of resources and procedures are e.g. is received. Examples of resources and procedures are e.g.
procedures for the establishment of media plane resources (bandwidth, procedures for the establishment of media plane resources (bandwidth,
radio, codecs etc), media security procedures or procedures related radio, codecs etc), media security procedures or procedures related
to NAT traversal. In addition, the UAC may use the 199 response for to NAT traversal. In addition, the UAC may use the 199 response for
policy decisions related to early dialogs, e.g. when choosing to policy decisions related to early dialogs, e.g. when choosing to
process media associated with a particular early dialog. process media associated with a particular early dialog.
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 client receives an unreliable 199 response on a dialog which has If a client receives an unreliable 199 response on a dialog which has
not previously been created (this can happen if a 199 response not previously been created (this can happen if a 199 response
reaches the client before a 18x response) the client SHALL discard reaches the client before a 18x response) the client SHALL discard
the 199 responses. If a client receives a reliable 199 response on a the 199 responses. If a client receives a reliable 199 response on a
dialog which has not previously been created the UAC SHOULD dialog which has not previously been created the UAC SHOULD
acknowledge the 199 response, as described in [RFC3262]. acknowledge the 199 response, as described in [RFC3262].
4.1. Examples of resource types 4.1. Examples of resource types
skipping to change at page 7, line 42 skipping to change at page 7, line 42
was terminated. was terminated.
If the UAS intends to send 199 responses, and if it supports the If the UAS intends to send 199 responses, and if it supports the
procedures defined in [RFC3840], it MAY during the registration procedures defined in [RFC3840], it MAY during the registration
procedure use the sip.extensions feature tag [RFC3840] to indicate procedure use the sip.extensions feature tag [RFC3840] to indicate
support of the 199 response code. support of the 199 response code.
A 199 response SHOULD NOT contain an SDP offer/answer message body, A 199 response SHOULD NOT contain an SDP offer/answer message body,
unless required by the rules in [RFC3264]. unless required by the rules in [RFC3264].
NOTE: If the INVITE request did not contain an SDP offer, and the 199 If the INVITE request did 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. 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
in the reliable 199 response.
When a 199 response is sent by a UAS, since the provisional response When a 199 response is sent by a UAS, since the provisional response
is only used for information purpose, the UAS SHOULD send it is only used for information purpose, the UAS SHOULD send it
unreliably even if the 100rel option tag [RFC3262] is present in the unreliably even if the 100rel option tag [RFC3262] is present in the
Require header of the associated request. Require header of the associated request.
6. Proxy behavior 6. Proxy behavior
When a proxy receives a 199 response on an early dialog, it MUST When a proxy receives a 199 response, it MUST process the response as
process the response as any other non-100 provisional responses. The any other non-100 provisional responses. The proxy will forward the
proxy will forward the response upstream towards the sender of the response upstream towards the sender of the associated request. The
associated request. The proxy MAY release resources it has reserved proxy MAY release resources it has reserved associated with the
associated with the early dialog on which the response is received. dialog on which the response is received. If a proxy receives a 199
If a proxy receives a 199 response out of dialog, it processes it as response out of dialog, it processes it as other non-100 provisional
other non-100 provisional responses received out of dialog. 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 that it
recognizes as terminating one or more early dialogs, it SHOULD recognizes as terminating one or more early dialogs, it SHOULD
generate and send a 199 response upstream for each of the terminated generate and send a 199 response upstream for each of the terminated
early dialogs that satisfy each of the following conditions: 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 (using the 199 option tag) for the
199 response code 199 response code
- the forking proxy has not already received and forwarded a 199 - the forking proxy has not already received and forwarded a 199
response for that early dialog response for that 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
by the proxy, no further 199 responses associated with the INVITE
request will be generated or forwarded by the proxy.
When the forking proxy forks the initial request, it generates a When the forking proxy forks the initial request, it generates a
unique Via header branch parameter value for each forked leg. The unique Via header branch parameter value for each forked leg. The
proxy can determine whether additional forking has occurred proxy can determine whether additional forking has occurred
downstream of the proxy by storing the top Via branch value from each downstream of the proxy by storing the top Via branch value from each
response which creates an early dialog. If the same top Via branch response which creates an early dialog. If the same top Via branch
value is received for multiple early dialogs, the proxy knows that value is received for multiple early dialogs, the proxy knows that
additional forking has occured downstream of the proxy. A non-2xx additional forking has occured downstream of the proxy. A non-2xx
final response received for a specific early dialog also terminates final response received for a specific early dialog also terminates
all other early dialog for which the same top Via branch value was all other early dialog for which the same top Via branch value was
received in the responses which created those early dialogs. received in the responses which created those early dialogs.
Based on implementation policy, the forking proxy MAY wait before Based on implementation policy, the forking proxy MAY wait before
sending the 199 response, e.g. if it expects to receive a 2xx final sending the 199 response, e.g. if it expects to receive a 2xx final
response on another dialog shortly after it received the non-2xx response on another dialog shortly after it received the non-2xx
final response which triggered the 199 response. final response which triggered the 199 response.
When a forking proxy generates a 199 response, the response MUST When a forking proxy generates a 199 response, the response MUST
contain a To header tag parameter, which identifies the early dialog contain a To header tag parameter, which identifies the early dialog
that has been terminated. The proxy MUST also insert a Reason header that has been terminated. The proxy MUST also insert a Reason header
[RFC3326] which contains the response code of the response that [RFC3326] which contains the response code of the response that
triggered the 199 response. If the proxy has stored the Contact and triggered the 199 response.
Record-Route header fields received in the responses that created
early dialogs, it SHALL insert those header fields in the 199
responses.
A forking proxy which supports generating of 199 responses MUST keep A forking proxy which supports generating of 199 responses MUST keep
track of early dialogs, in order to determine whether to generate a track of early dialogs, in order to determine whether to generate a
199 response when the proxy receives a non-2xx final response. In 199 response when the proxy receives a non-2xx final response. In
addition, the proxy MUST keep track on which early dialogs it has addition, the proxy MUST keep track on which early dialogs it has
received and forwarded 199 responses, in order to not generate received and forwarded 199 responses, in order to not generate
additional 199 responses for those early dialogs. additional 199 responses for those early dialogs.
If a forking proxy receives a reliably sent 199 response for a If a forking proxy receives a reliably sent 199 response for a
dialog, for which it has previously generated and sent a 199 dialog, for which it has previously generated and sent a 199
skipping to change at page 9, line 44 skipping to change at page 9, line 45
A UAC that receives a 199 response for an early dialog MUST NOT send A UAC that receives a 199 response for an early dialog MUST NOT send
any further requests on that dialog, except for requests which any further requests on that dialog, except for requests which
acknowledge reliable responses. A proxy MUST forward requests acknowledge reliable responses. A proxy MUST forward requests
according to [RFC3261], even if the proxy has knowledge that the according to [RFC3261], even if the proxy has knowledge that the
early dialog has been terminated. early dialog has been terminated.
The 199 Early Dialog Terminated response code does not "replace" a The 199 Early Dialog Terminated response code does not "replace" a
final response. RFC 3261 [RFC3261] specifies when a final response final response. RFC 3261 [RFC3261] specifies when a final response
is sent. is sent.
8. 199 Early Dialog Terminated 8. Usage with SDP offer/answer
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 SHOULD NOT contain A 199 Early Dialog Terminated provisional response SHOULD NOT contain
an SDP offer/answer message body, unless required by the rules in an SDP offer/answer message body, unless required by the rules in
[RFC3264]. [RFC3264].
NOTE: If the INVITE request did not contain an SDP offer, and the 199 If the INVITE request did 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. 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
in the reliable 199 response.
10. Usage with 100rel 9. Usage with 100rel
When a 199 Early Dialog Terminated provisional response is sent by a When a 199 Early Dialog Terminated provisional response is sent by a
UAS, since the provisional response is only used for information UAS, since the provisional response is only used for information
purpose, the UAS SHOULD send it unreliably even if the 100rel option purpose, the UAS SHOULD send it unreliably even if the 100rel option
tag [RFC3262] is present in the Require header of the associated tag [RFC3262] is present in the Require header of the associated
request. request.
When a forking proxy generates a 199 response, the response MUST NOT When a forking proxy generates a 199 response, the response MUST NOT
be sent reliably. be sent reliably.
11. Examples 10. 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 create early dialogs which send 18x provisional responses in order to create early dialogs
between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by
sending a 4xx error response each. When P1 receives the 4xx sending a 4xx error response each. When P1 receives the 4xx
responses it immediately sends 199 responses, associated with the responses it immediately sends 199 responses, associated with the
dialogs where the 4xx responses were received, towards the UAC. The dialogs where the 4xx responses were received, towards the UAC. The
early dialog leg is shown in parenthesis. early dialog leg is shown in parenthesis.
skipping to change at page 11, line 31 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
received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4, received from UAC. The forked INVITE reaches UAS_2, UAS_3 and UAS_4,
which send 18x provisional responses in order to create early dialogs which send 18x provisional responses in order to create early dialogs
between themselves and the UAC. UAS_4 accepts the session by sending between themselves and the UAC. UAS_4 accepts the session by sending
a 200 OK final response. When P1 receives the 200 OK responses it a 200 OK final response. When P1 receives the 200 OK responses it
immediately forwards it towards the UAC. P1 does not send 199 immediately forwards it towards the UAC. P1 does not send 199
responses for the early dialogs from UAS_2 and UAS_3, since P1 has responses for the early dialogs from UAS_2 and UAS_3, since P1 has
yet not received any final responses on those early dialogs (even if yet not received any final responses on those early dialogs (even if
P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200 P1 sends CANCEL request to UAS_2 and UAS_3 P1 may still receive 200
skipping to change at page 12, line 25 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
received from UAC. One of the forked INVITEs reaches UAS_2. The received from UAC. One of the forked INVITEs reaches UAS_2. The
other forked INVITE reaches another proxy (P2), which forks the other forked INVITE reaches another proxy (P2), which forks the
INVITE to UAS_3 and UAS_4, which send 18x provisional responses in INVITE to UAS_3 and UAS_4, which send 18x provisional responses in
order to create early dialogs between themselves and the UAC. UAS_3 order to create early dialogs between themselves and the UAC. UAS_3
and UAS_4 reject the INVITE by sending a 4xx error response each. P2 and UAS_4 reject the INVITE by sending a 4xx error response each. P2
does not support the 199 response code, and forwards a single 4xx does not support the 199 response code, and forwards a single 4xx
response. When P1 receives the 4xx responses from P2, it manages to response. When P1 receives the 4xx responses from P2, it manages to
associate the response with the early dialogs from both UAS_3 and associate the response with the early dialogs from both UAS_3 and
skipping to change at page 13, 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
[RFC3261]. Due to the nature of the 199 response, it may be [RFC3261]. Due to the nature of the 199 response, it may be
attractive to use it for launching attacks in order to terminate attractive to use it for launching attacks in order to terminate
specific early dialogs (other early dialogs will not be affected). specific early dialogs (other early dialogs will not be affected).
In addition, if a man-in-the-middle sends a 199 response to the UAC, In addition, if a man-in-the-middle sends a 199 response to the UAC,
which terminates a specific dialog, it can take a while until the UAS which terminates a specific dialog, it can take a while until the UAS
finds out that the UAC, and possbile stateful intermediates, have finds out that the UAC, and possbile stateful intermediates, have
terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS) terminated the dialog. SIP security mechanisms (e.g. hop-to-hop TLS)
can be used to minimize, or eliminate, the risk for such attacks. can be used to minimize, or eliminate, the risk for such attacks.
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. according to the procedures of RFC 3261.
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 of this specification]] RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC number of this specification]]
Response Code Number: 199 Response Code Number: 199
Default Reason Phrase: Early Dialog Terminated Default Reason Phrase: Early Dialog Terminated
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, it indicates that the UA supports the
response code. When present in a Require header in a request, response code. When present in a Require header in a request,
it indicates that the UAS MUST support the sending of the it indicates that the UAS MUST support the sending of the
response code. response code.
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 and Hans Erik van Elburg for their feedback and suggestions. Drage and Hans Erik van Elburg for their feedback and suggestions.
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 15, line 27 skipping to change at page 15, line 27
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session "Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004. Initiation Protocol (SIP)", RFC 3840, August 2004.
[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.
[RFC5009] Ejza, R., "Private Header (P-Header) Extension to the
Session Initiation Protocol (SIP) for Authorization of
Early Media", RFC 5009, September 2007.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
15.2. Informational References 14.2. Informational References
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007. Initiation Protocol", RFC 5057, November 2007.
[RFC5009] Ejza, R., "Private Header (P-Header) Extension to the
Session Initiation Protocol (SIP) for Authorization of
Early Media", RFC 5009, September 2007.
Author's Address Author's Address
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 32 change blocks. 
62 lines changed or deleted 59 lines changed or added

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