draft-ietf-sipping-dialogusage-04.txt   draft-ietf-sipping-dialogusage-05.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: April 25, 2007 October 22, 2006 Intended status: Informational November 9, 2006
Expires: May 13, 2007
Multiple Dialog Usages in the Session Initiation Protocol Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-04 draft-ietf-sipping-dialogusage-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 April 25, 2007. This Internet-Draft will expire on May 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Several methods in the Session Initiation Protocol can create an Several methods in the Session Initiation Protocol can create an
association between endpoints known as a dialog. Some of these association between endpoints known as a dialog. Some of these
methods can also create a different, but related, association within methods can also create a different, but related, association within
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4 3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4
3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 7 3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 7
4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 10 4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 10
4.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 10 4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 10
5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 10 5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 10
5.1. A survey of the effect of failure responses on usages 5.1. A survey of the effect of failure responses on usages
and dialogs . . . . . . . . . . . . . . . . . . . . . . . 10 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 16 5.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 16
5.3. Matching requests to usages . . . . . . . . . . . . . . . 16 5.3. Matching requests to usages . . . . . . . . . . . . . . . 17
5.4. Target refresh requests . . . . . . . . . . . . . . . . . 17 5.4. Target refresh requests . . . . . . . . . . . . . . . . . 17
5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 18 5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 18
5.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 18 5.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 18
5.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 18 5.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 18
6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18 6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. Informative References . . . . . . . . . . . . . . . . . . . . 25 11. Informative References . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. draft-ietf-03->draft-ietf-04 . . . . . . . . . . . . . . . 26 A.1. draft-ietf-04->draft-ietf-05 . . . . . . . . . . . . . . . 26
A.2. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 26 A.2. draft-ietf-03->draft-ietf-04 . . . . . . . . . . . . . . . 26
A.3. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 26 A.3. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 26
A.4. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 26 A.4. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 26
A.5. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 27 A.5. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 27
A.6. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 27 A.6. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 27
A.7. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Overview 1. Overview
This is an informative document. It makes no normative statements of This is an informative document. It makes no normative statements of
any kind. This document refines the concept of a dialog usage in the any kind. This document refines the concept of a dialog usage in the
Session Initiation Protocol (SIP [1]), and discusses what led to its Session Initiation Protocol (SIP [1]), and discusses what led to its
existence. It explores ambiguity associated with processing multiple existence. It explores ambiguity associated with processing multiple
dialog usages that share a dialog. In particular, it surveys the dialog usages that share a dialog. In particular, it surveys the
skipping to change at page 11, line 14 skipping to change at page 11, line 14
3xx responses: Redirection mid-dialog is not well understood in SIP, 3xx responses: Redirection mid-dialog is not well understood in SIP,
but whatever effect it has impacts the entire dialog and all of but whatever effect it has impacts the entire dialog and all of
its usages equally. In our example scenario, both the its usages equally. In our example scenario, both the
subscription and the invite usage would be redirected by this subscription and the invite usage would be redirected by this
single response. single response.
For the failure responses with code 400 and greater, there are three For the failure responses with code 400 and greater, there are three
common ways the failure can affect the transaction, usage, and dialog common ways the failure can affect the transaction, usage, and dialog
state. state.
Transaction Only The error affects only the transaction, not the Transaction Only The error affects only the transaction, not the
usage or dialog the transaction occurs in (beyond affecting the usage or dialog the transaction occurs in (beyond affecting the
local CSeq). Any other usage of the dialog is unaffected. The local CSeq). Any other usage of the dialog is unaffected. The
error is a complaint about this transaction, not the usage or error is a complaint about this transaction, not the usage or
dialog the transaction occurs in. dialog the transaction occurs in.
Destroys Usage The error destroys the usage, but not dialog. Any Destroys Usage The error destroys the usage, but not dialog. Any
other usages sharing this dialog are not affected. other usages sharing this dialog are not affected.
The error destroys the dialog and all usages sharing it.
Table 1 displays how the various codes affect transaction, usage, or Destroys Dialog The error destroys the dialog and all usages sharing
dialog state. Response code specific comments (noted with *) or it.
exceptions (noted with **) follow the table.
+-----------------------+----------------+------------------+ Table 1 and Table 2 display how the various codes affect transaction,
usage, or dialog state. Response code specific comments or
exceptions follow the table.
+----------------------+----------------+-----------------+
| Transaction Only | Destroys Usage | Destroys Dialog | | Transaction Only | Destroys Usage | Destroys Dialog |
+-----------------------+----------------+------------------+ +----------------------+----------------+-----------------+
| 400 (or unknown 4xx) | 405*, 480* | 404*, 410*, 416* | | 400 (or unknown 4xx) | 405, 480 | 404, 410, 416 |
| 401, 402*, 403, 406 | 481*, 489** | 482*, 483** | | 401, 402, 403, 406 | 481, 489 | 482, 483 |
| 407, 408*, 412-415 | 501* | 484*, 485* | | 407, 408, 412-415 | 501 | 484, 485 |
| 417, 420, 421, 422* | | 502*, 604* | | 417, 420, 421, 422 | | 502, 604 |
| 423, 428, 429* | | | | 423, 428, 429 | | |
| 436-438, 486*, 487 | | | | 436-438, 486, 487 | | |
| 488, 491, 493, 494 | | | | 488, 491, 493, 494 | | |
| 500 (or unknown 5xx)* | | | | 500 (or unknown 5xx) | | |
| 503*, 504*, 505, 513 | | | | 503, 504, 505 | | |
| 580 | | | | 513, 580 | | |
| 600 (or unknown 6xx)* | | | | 600 (or unknown 6xx) | | |
| 603*, 606 | | | | 603, 606 | | |
+-----------------------+----------------+------------------+ +----------------------+----------------+-----------------+
Table 1 Table 1
+---------+---------------------------------+-------------+-------+
| Code | Reason | Impact | Notes |
+---------+---------------------------------+-------------+-------+
| 400/4xx | Bad Request | Transaction | |
| 401 | Unauthorized | Transaction | |
| 402 | Payment Required | Transaction | (1) |
| 403 | Forbidden | Transaction | |
| 404 | Not Found | Dialog | (2) |
| 405 | Method Not Allowed | Usage | (3) |
| 406 | Not Acceptable | Transaction | |
| 407 | Proxy Authentication Required | Transaction | |
| 408 | Request Timeout | Transaction | (4) |
| 410 | Gone | Dialog | (2) |
| 412 | Conditional Request Failed | Transaction | |
| 413 | Request Entity Too Large | Transaction | |
| 414 | Request-URI Too Long | Transaction | |
| 415 | Unsupported Media Type | Transaction | |
| 416 | Unsupported URI Scheme | Dialog | (2) |
| 417 | Unknown Resource-Priority | Transaction | |
| 420 | Bad Extension | Transaction | |
| 421 | Extension Required | Transaction | |
| 422 | Session Interval Too Brief | Transaction | (5) |
| 423 | Interval Too Brief | Transaction | |
| 428 | Use Identity Header | Transaction | |
| 429 | Provide Referrer Identity | Transaction | (6) |
| 436 | Bad Identity-Info | Transaction | |
| 437 | Unsupported Certificate | Transaction | |
| 438 | Invalid Identity Header | Transaction | |
| 480 | Temporarily Unavailable | Usage | (7) |
| 481 | Call/Transaction Does Not Exist | Usage | (8) |
| 482 | Loop Detected | Dialog | (9) |
| 483 | Too Many Hops | Dialog | (10) |
| 484 | Address Incomplete | Dialog | (2) |
| 485 | Ambiguous | Dialog | (2) |
| 486 | Busy Here | Transaction | (11) |
| 487 | Request Terminated | Transaction | |
| 488 | Not Acceptable Here | Transaction | |
| 489 | Bad Event | Usage | (12) |
| 491 | Request Pending | Transaction | |
| 493 | Undecipherable | Transaction | |
| 494 | Security Agreement Required | Transaction | |
| 500/5xx | Server Internal Error | Transaction | (13) |
| 501 | Not Implemented | Usage | (2) |
| 502 | Bad Gateway | Dialog | (14) |
| 503 | Service Unavailable | Transaction | (15) |
| 504 | Server Time-Out | Transaction | (16) |
| 505 | Version Not Supported | Transaction | |
| 513 | Message Too Large | Transaction | |
| 580 | Precondition Failure | Transaction | |
| 600/6xx | Busy Everywhere | Transaction | (17) |
| 603 | Decline | Transaction | |
| 604 | Does Not Exist Anywhere | Dialog | (2) |
| 606 | Not Acceptable | Transaction | |
+---------+---------------------------------+-------------+-------+
402 Payment Required: This is a reserved response code. If Table 2
encountered, it should be treated as an unrecognized 4xx.
404 Not Found: This response destroys the dialog and all usages
sharing it. The Request-URI that is being 404ed is the remote
target set by the Contact provided by the peer. Getting this
response means something has gone fundamentally wrong with the
dialog state.
405 Method Not Allowed: In our example scenario, this response (1) 402 Payment Required: This is a reserved response code. If
destroys the subscription, but not the invite usage or the dialog. encountered, it should be treated as an unrecognized 4xx.
It's an aberrant case for NOTIFYs to receive a 405 since they only
come as a result to something that creates subscription. In
general, a 405 within a given usage affects only that usage, but
does not affect other usages of the dialog.
408 Request Timeout: Receiving a 408 will have the same effect on (2) 404 Not Found:
usages and dialogs as a real transaction timeout as described in 410 Gone:
Section 5.2. 416 Unsupported URI Scheme:
484 Address Incomplete:
485 Ambiguous:
604 Does Not Exist Anywhere:
The Request-URI that is being rejected is the remote target set by
the Contact provided by the peer. Getting this response means
something has gone fundamentally wrong with the dialog state.
410 Gone: This response destroys the dialog and all usages sharing (3) 405 Method Not Allowed:
it. The Request-URI that is being rejected is the remote target 501 Not Implemented:
set by the Contact provided by the peer. Similar to 404, getting Either of these responses would be aberrant in our example
this response means something has gone fundamentally wrong with scenario since support for the NOTIFY method is required by the
the dialog state, its slightly less aberrant in that the other usage. In this case, the UA knows the condition is unrecoverable
endpoint recognizes that this was once a valid URI that it isn't and should stop sending NOTIFYs on the usage. Any refresh
willing to respond to anymore. subscriptions should be rejected. In general, these errors will
affect at most the usage. If the request was not integral to the
usage (it used an unknown method, or was an INFO inside an INVITE
usage for example), only the transaction is affected.
416 Unsupported URI Scheme: Similar to 404 and 410, this response (4) 408 Request Timeout: Receiving a 408 will have the same effect
came to a request whose Request-URI was provided by the peer in a on usages and dialogs as a real transaction timeout as described
Contact header field. Something has gone fundamentally wrong, and in Section 5.2.
the dialog and all of its usages are destroyed.
422 Session Interval Too Small: This response will not be returned to (5) 422 Session Interval Too Small: This response does not make
a NOTIFY in our example scenario. This response does not make
sense for any mid-usage request. If it is received, an element in sense for any mid-usage request. If it is received, an element in
the path of the request is violating protocol, and the recipient the path of the request is violating protocol, and the recipient
should treat this as it would an unknown 4xx response. If the should treat this as it would an unknown 4xx response.
response came to a request that was attempting to establish a new
usage in an existing dialog, no new usage is created and existing
usages are unaffected.
429 Provide Referrer Identity: This response won't be returned to a (6) 429 Provide Referrer Identity: This response won't be returned
NOTIFY as in our example scenario, but when it is returned to a to a NOTIFY as in our example scenario, but when it is returned to
REFER, it is objecting only to the REFER request itself. Any a REFER, it is objecting only to the REFER request itself.
usages sharing this dialog with that REFER request are unaffected.
The dialog is only affected by a change in its local CSeq.
480 Temporarily Unavailable: RFC 3261 is unclear on what this (7) 480 Temporarily Unavailable: RFC 3261 is unclear on what this
response means for mid-usage requests. Future updates to that response means for mid-usage requests. Future updates to that
specification are expected to clarify that this response affects specification are expected to clarify that this response affects
only the usage in which the request occurs. No other usages are only the usage in which the request occurs. No other usages are
affected. If the response included a Retry-After header field, affected. If the response included a Retry-After header field,
further requests in that usage should not be sent until the further requests in that usage should not be sent until the
indicated time has past. Requests in other usages may still be indicated time has past. Requests in other usages may still be
sent at any time. sent at any time.
481 Call/Transaction Does Not Exist: This response indicates that the (8) 481 Call/Transaction Does Not Exist: This response indicates
peer has lost its copy of the dialog usage state. The dialog that the peer has lost its copy of the dialog usage state. The
itself should not be destroyed unless this was the last usage. dialog itself should not be destroyed unless this was the last
usage.
The effects of a 481 on a dialog and its usages are the most The effects of a 481 on a dialog and its usages are the most
ambiguous of any final response. There are implementations that ambiguous of any final response. There are implementations that
have chosen the meaning recommended here, and others that destroy have chosen the meaning recommended here, and others that destroy
the entire dialog without regard to the number of outstanding the entire dialog without regard to the number of outstanding
usages. Going forward with this clarification will allow those usages. Going forward with this clarification will allow those
deployed implementations that assumed only the usage was destroyed deployed implementations that assumed only the usage was destroyed
to work with a wider number of implementations. Those that made to work with a wider number of implementations. Those that made
the other choice will continue to function as they do now, the other choice will continue to function as they do now,
suffering at most the same extra messages needed for a peer to suffering at most the same extra messages needed for a peer to
discover that that other usages have gone away that they currently discover that that other usages have gone away that they currently
do. However, the necessary clarification to RFC 3261 needs to do. However, the necessary clarification to RFC 3261 needs to
make it very clear that the ability to terminate usages make it very clear that the ability to terminate usages
independently from the overall dialog using a 481 is not independently from the overall dialog using a 481 is not
justification for designing new applications that count on justification for designing new applications that count on
multiple usages in a dialog. multiple usages in a dialog.
482 Loop Detected: This response is aberrant mid-dialog. It will (9) 482 Loop Detected: This response is aberrant mid-dialog. It
only occur if the Record-Route header field was improperly will only occur if the Record-Route header field was improperly
constructed by the proxies involved in setting up the dialog's constructed by the proxies involved in setting up the dialog's
initial usage, or if a mid-dialog request forks and merges (which initial usage, or if a mid-dialog request forks and merges (which
should never happen). Future requests using this dialog state should never happen). Future requests using this dialog state
will also fail. The dialog and any usages sharing it are will also fail.
destroyed.
An edge condition exists during RFC3263 failover at the element An edge condition exists during RFC3263 failover at the element
sending a request where the request effectively forks to sending a request where the request effectively forks to
multiple destinations from the client. Some implementations multiple destinations from the client. Some implementations
increase risk entering this edge condition by trying the next increase risk entering this edge condition by trying the next
potential location as determined by RFC3263 very rapidly if the potential location as determined by RFC3263 very rapidly if the
first does not immediately respond. In any situation where a first does not immediately respond. In any situation where a
client sends the same request to more than one endpoint, it client sends the same request to more than one endpoint, it
must be prepared to receive a response from each branch (and must be prepared to receive a response from each branch (and
should choose a "best" response to act on following the same should choose a "best" response to act on following the same
guidelines as a forking proxy). In this particular race guidelines as a forking proxy). In this particular race
condition, if multiple branches respond, all but one will most condition, if multiple branches respond, all but one will most
likely return a 482 Merged Request. The client should select likely return a 482 Merged Request. The client should select
the remaining non-482 response as the "best" response. the remaining non-482 response as the "best" response.
483 Too Many Hops: Similar to 482, receiving this mid-dialog is (10) 483 Too Many Hops: Similar to 482, receiving this mid-dialog is
aberrant. Unlike 482, recovery may be possible by increasing Max- aberrant. Unlike 482, recovery may be possible by increasing Max-
Forwards (assuming that the requester did something strange like Forwards (assuming that the requester did something strange like
using a smaller value for Max-Forwards in mid-dialog requests than using a smaller value for Max-Forwards in mid-dialog requests than
it used for an initial request). If the request isn't tried with it used for an initial request). If the request isn't tried with
an increased Max-Forwards, then the agent should attempt to an increased Max-Forwards, then the agent should follow the
gracefully terminate this usage and all other usages that share Destroy Dialog actions.
its dialog.
484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these
responses came to a request whose Request-URI was provided by the
peer in a Contact header field. Something has gone fundamentally
wrong, and the dialog and all of its usages are destroyed.
486 Busy Here: This response is nonsensical in our example scenario, (11) 486 Busy Here: This response is nonsensical in our example
or in any scenario where this response comes inside an established scenario, or in any scenario where this response comes inside an
usage. If it occurs in that context, it should be treated as an established usage. If it occurs in that context, it should be
unknown 4xx response. The usage, and any other usages sharing its treated as an unknown 4xx response.
dialog are unaffected. The dialog is only affected by the change
in its local CSeq. If this response is to a request that is
attempting to establish a new usage within an existing dialog
(such as an INVITE sent within a dialog established by a
subscription), the request fails, no new usage is created, and no
other usages are affected.
489 Bad Event: In our example scenario, [3] declares that the (12) 489 Bad Event: In our example scenario, [3] declares that the
subscription usage in which the NOTIFY is sent is terminated. The subscription usage in which the NOTIFY is sent is terminated.
invite usage is unaffected and the dialog continues to exist.
This response is only valid in the context of SUBSCRIBE and This response is only valid in the context of SUBSCRIBE and
NOTIFY. UAC behavior for receiving this response to other methods NOTIFY. UAC behavior for receiving this response to other methods
is not specified, but treating it as an unknown 4xx is a is not specified, but treating it as an unknown 4xx is a
reasonable practice. reasonable practice.
500 and 5xx unrecognized responses: These responses are complaints (13) 500 and 5xx unrecognized responses: If the response contains a
against the request (transaction), not the usage. If the response Retry-After header field value, the server thinks the condition is
contains a Retry-After header field value, the server thinks the temporary and the request can be retried after the indicated
condition is temporary and the request can be retried after the interval. If the response does not contain a Retry-After header
indicated interval. This usage, and any other usages sharing the field value, the UA may decide to retry after an interval of its
dialog are unaffected. If the response does not contain a Retry- choosing or attempt to gracefully terminate the usage. Whether or
After header field value, the UA may decide to retry after an not to terminate other usages depends on the application. If the
interval of its choosing or attempt to gracefully terminate the UA receives a 500 (or unrecognized 5xx) in response to an attempt
usage. Whether or not to terminate other usages depends on the to gracefully terminate this usage, it can treat this usage as
application. If the UA receives a 500 (or unrecognized 5xx) in terminated. If this is the last usage sharing the dialog, the
response to an attempt to gracefully terminate this usage, it can dialog is also terminated.
treat this usage as terminated. If this is the last usage sharing
the dialog, the dialog is also terminated.
501 Not Implemented: This would be a degenerate response in our
example scenario since the NOTIFY is being sent as part of an
established subscribe usage. In this case, the UA knows the
condition is unrecoverable and should stop attempting to send
NOTIFYs on this usage. (It may or may not destroy the usage. If
it remembers the bad behavior, it can reject any refresh
subscription). In general, this response may or may not affect
the usage (a 501 to an unknown method or an INFO will not end an
invite usage). It will never affect other usages sharing this
usage's dialog.
502 Bad Gateway: This response is aberrant mid-dialog. It will only (14) 502 Bad Gateway: This response is aberrant mid-dialog. It will
occur if the Record-Route header field was improperly constructed only occur if the Record-Route header field was improperly
by the proxies involved in setting up the dialog's initial usage. constructed by the proxies involved in setting up the dialog's
Future requests using this dialog state will also fail. The initial usage. Future requests using this dialog state will also
dialog and any usages sharing it are destroyed. fail.
503 Service Unavailable: As per [2], the logic handling locating SIP (15) 503 Service Unavailable: As per [2], the logic handling
servers for transactions may handle 503 requests (effectively locating SIP servers for transactions may handle 503 requests
sequentially forking at the endpoint based on DNS results). If (effectively sequentially forking at the endpoint based on DNS
this process does not yield a better response, a 503 may be results). If this process does not yield a better response, a 503
returned to the transaction user. Like a 500 response, the error may be returned to the transaction user. Like a 500 response, the
is a complaint about this transaction, not the usage. Because error is a complaint about this transaction, not the usage.
this response occurred in the context of an established usage Because this response occurred in the context of an established
(hence an existing dialog), the route-set has already been formed usage (hence an existing dialog), the route-set has already been
and any opportunity to try alternate servers (as recommended in formed and any opportunity to try alternate servers (as
[1]) has been exhausted by the RFC3263 logic. The response should recommended in [1]) has been exhausted by the RFC3263 logic.
be handled as described for 500 earlier in this memo.
504 Server Time-out: It is not obvious under what circumstances this (16) 504 Server Time-out: It is not obvious under what circumstances
response would be returned to a request in an existing dialog. If this response would be returned to a request in an existing
it occurs it should have the same affect on the dialog and its dialog.
usages as described for unknown 5xx responses.
600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 (17) 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a
response code says something about the recipient user, not the 600 response code says something about the recipient user, not the
request that was made. This end user is stating an unwillingness request that was made. This end user is stating an unwillingness
to communicate. If the response contains a Retry-After header to communicate. If the response contains a Retry-After header
field value, the user is indicating willingness to communicate field value, the user is indicating willingness to communicate
later and the request can be retried after the indicated interval. later and the request can be retried after the indicated interval.
This usage, and any other usages sharing the dialog are This usage, and any other usages sharing the dialog are
unaffected. If the response does not contain a Retry-After header unaffected. If the response does not contain a Retry-After header
field value, the UA may decide to retry after an interval of its field value, the UA may decide to retry after an interval of its
choosing or attempt to gracefully terminate the usage. Whether or choosing or attempt to gracefully terminate the usage. Whether or
not to terminate other usages depends on the application. If the not to terminate other usages depends on the application. If the
UA receives a 600 (or unrecognized 6xx) in response to an attempt UA receives a 600 (or unrecognized 6xx) in response to an attempt
to gracefully terminate this usage, it can treat this usage as to gracefully terminate this usage, it can treat this usage as
terminated. If this is the last usage sharing the dialog, the terminated. If this is the last usage sharing the dialog, the
dialog is also terminated. dialog is also terminated.
603 Decline: This response declines the action indicated by the
associated request. It can be used, for example, to decline a
hold or transfer attempt. Receiving this response does NOT
terminate the usage it occurs in. Other usages sharing the dialog
are unaffected.
604 Does Not Exist Anywhere: Like 404, this response destroys the
dialog and all usages sharing it. The Request-URI in the request
is the remote target set by the Contact provided by the peer.
Getting this response means something has gone fundamentally wrong
with the dialog state.
5.2. Transaction timeouts 5.2. Transaction timeouts
[1] states that a UAC should terminate a dialog (by sending a BYE) if [1] states that a UAC should terminate a dialog (by sending a BYE) if
no response is received for a request sent within a dialog. This no response is received for a request sent within a dialog. This
recommendation should have been limited to the invite usage instead recommendation should have been limited to the invite usage instead
of the whole dialog. [3] states that a timeout for a NOTIFY removes a of the whole dialog. [3] states that a timeout for a NOTIFY removes a
subscription, but a SUBSCRIBE that fails with anything other than a subscription, but a SUBSCRIBE that fails with anything other than a
481 does not. Given these statements, it is unclear whether a 481 does not. Given these statements, it is unclear whether a
refresh SUBSCRIBE issued in a dialog shared with an invite usage refresh SUBSCRIBE issued in a dialog shared with an invite usage
destroys either usage or the dialog if it times out. destroys either usage or the dialog if it times out.
skipping to change at page 22, line 12 skipping to change at page 22, line 20
In message F1, Alice invites Bob indicating support for GRUUs (and In message F1, Alice invites Bob indicating support for GRUUs (and
offering a GRUU for herself): offering a GRUU for herself):
Message F1 (abridged, detailing pertinent fields) Message F1 (abridged, detailing pertinent fields)
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Call-ID: 13jfdwer230jsdw@alice.example.com Call-ID: 13jfdwer230jsdw@alice.example.com
Supported: gruu Supported: gruu
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)> Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Message F2 lets Alice know that Bob understands GRUUs. If Bob did Message F2 carries Bob's GRUU to Alice.
not indicate this support, the original multi-usage approach to
transfer would have to be used.
Message F2 (abridged, detailing pertinent fields) Message F2 (abridged, detailing pertinent fields)
SIP/2.0 200 OK SIP/2.0 200 OK
Supported: gruu Supported: gruu
To: <sip:bob@example.com>;tag=totag1 To: <sip:bob@example.com>;tag=totag1
From: <sip:alice@example.com>;tag=fromtag1 From: <sip:alice@example.com>;tag=fromtag1
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)> Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Bob decides to try to transfer Alice to Carol, so he puts Alice on Bob decides to try to transfer Alice to Carol, so he puts Alice on
skipping to change at page 26, line 10 skipping to change at page 26, line 22
[11] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP) [11] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", Event Package for Key Press Stimulus (KPML)",
draft-ietf-sipping-kpml-08 (work in progress), July 2006. draft-ietf-sipping-kpml-08 (work in progress), July 2006.
Appendix A. Change Log Appendix A. Change Log
RFC-EDITOR: Please remove this entire Change Log section while RFC-EDITOR: Please remove this entire Change Log section while
formatting this document for publication. formatting this document for publication.
A.1. draft-ietf-03->draft-ietf-04 A.1. draft-ietf-04->draft-ietf-05
o Fixed the flaw with the GRUU message description text that Paul
caught.
o Integrated Paul's table and further simplified the comment/
exception text.
A.2. draft-ietf-03->draft-ietf-04
o Many minor editorial fixes addressing WGLC comments o Many minor editorial fixes addressing WGLC comments
o Aligned with changes to GRUU o Aligned with changes to GRUU
o Added a short overview o Added a short overview
o Added a table summarizing the survey of responses and removed the o Added a table summarizing the survey of responses and removed the
description from those responses that were not exceptional. description from those responses that were not exceptional.
A.2. draft-ietf-02->draft-ietf-03 A.3. draft-ietf-02->draft-ietf-03
o Removed discussion of the retargetting affect of provisional o Removed discussion of the retargetting affect of provisional
responses - that is a general problem that will now be addressed responses - that is a general problem that will now be addressed
in SIP. in SIP.
o Added a Security Considerations section (blush) summarizing points o Added a Security Considerations section (blush) summarizing points
from the document and the list discussion. from the document and the list discussion.
o Added a no-op IANA Considerations section. o Added a no-op IANA Considerations section.
A.3. draft-ietf-01->draft-ietf-02 A.4. draft-ietf-01->draft-ietf-02
o Incorporated editorial-fix contributions from the list o Incorporated editorial-fix contributions from the list
o Noted that REFERs using norefersub (RFC4488) don't create a new o Noted that REFERs using norefersub (RFC4488) don't create a new
subscribe usage subscribe usage
o Changed the affect of 403 to affect only the transaction, not the o Changed the affect of 403 to affect only the transaction, not the
usage. This is motivated by text in 3261 (bottom of page 87 - usage. This is motivated by text in 3261 (bottom of page 87 -
pointed out by Brian Stucker) which states that a UA receiving a pointed out by Brian Stucker) which states that a UA receiving a
non-2xx final response to a re-INVITE must leave the session non-2xx final response to a re-INVITE must leave the session
parameters unchanged as if the re-INVITE had not been issued. parameters unchanged as if the re-INVITE had not been issued.
There are other recommendations in this document that violate that There are other recommendations in this document that violate that
normative must (404,410, etc) but on review, I believe they are normative must (404,410, etc) but on review, I believe they are
correct (except for 403) and that this text in 3261 needs to be correct (except for 403) and that this text in 3261 needs to be
updated to recognize the conditions under which they're sent. updated to recognize the conditions under which they're sent.
o Added text concerning the race condition wherein endpoints failing o Added text concerning the race condition wherein endpoints failing
over rapidly to 3263 destinations may stimulate a merged-request over rapidly to 3263 destinations may stimulate a merged-request
response. response.
o Corrected the 481 inconsistency Paul Kyzivat pointed out (by o Corrected the 481 inconsistency Paul Kyzivat pointed out (by
removing the inconsistent paragraph) removing the inconsistent paragraph)
A.4. draft-ietf-00->draft-ietf-01 A.5. draft-ietf-00->draft-ietf-01
o Changed 481 to only affect the usage the response occurred in, o Changed 481 to only affect the usage the response occurred in,
closing the last open issue. Added some text justifying this closing the last open issue. Added some text justifying this
recommendation. recommendation.
o Added 422 Session Interval Too Small o Added 422 Session Interval Too Small
o Added 417 Unknown Resource-Priority o Added 417 Unknown Resource-Priority
o Added 428 Use Identity Header o Added 428 Use Identity Header
o Added 436 Bad Identity-Info o Added 436 Bad Identity-Info
o Added 437 Unsupported Certificate o Added 437 Unsupported Certificate
o Added 438 Invalid Identity header o Added 438 Invalid Identity header
o Added a section categorizing messages that create and destroy o Added a section categorizing messages that create and destroy
usages usages
o Made sure all descriptions in Section 5 addressed the generic o Made sure all descriptions in Section 5 addressed the generic
multi-usage case. multi-usage case.
skipping to change at page 27, line 19 skipping to change at page 27, line 40
o Added 437 Unsupported Certificate o Added 437 Unsupported Certificate
o Added 438 Invalid Identity header o Added 438 Invalid Identity header
o Added a section categorizing messages that create and destroy o Added a section categorizing messages that create and destroy
usages usages
o Made sure all descriptions in Section 5 addressed the generic o Made sure all descriptions in Section 5 addressed the generic
multi-usage case. multi-usage case.
o Clarified that the mechanics described in matching messages to o Clarified that the mechanics described in matching messages to
usages applied equally to UACs and UASs. usages applied equally to UACs and UASs.
o More explicitly noted that REFER creates a subscribe-usage o More explicitly noted that REFER creates a subscribe-usage
A.5. draft-sparks-01->draft-ietf-00 A.6. draft-sparks-01->draft-ietf-00
o Draft rename o Draft rename
A.6. draft-sparks-00->01 A.7. draft-sparks-00->01
o Changed 480 to affect only the usage the response occurred in. o Changed 480 to affect only the usage the response occurred in.
o Closed the open issue on 482. Usages and dialogs are destroyed o Closed the open issue on 482. Usages and dialogs are destroyed
even though there is an edge condition in which the response is even though there is an edge condition in which the response is
only stimulated by certain methods (due to method specific routing only stimulated by certain methods (due to method specific routing
rules). rules).
o Closed the open issue on 483. Usages are not terminated since the o Closed the open issue on 483. Usages are not terminated since the
request might succeed if retried with a greater initial Max- request might succeed if retried with a greater initial Max-
Forwards Forwards
o Closed the open issue on 502, accepting -00s suggestion that the o Closed the open issue on 502, accepting -00s suggestion that the
same reasoning used for 482 applies. same reasoning used for 482 applies.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
instead leverage the target-dialog concepts common to Join and instead leverage the target-dialog concepts common to Join and
Replaces. Replaces.
Author's Address Author's Address
Robert J. Sparks Robert J. Sparks
Estacado Systems Estacado Systems
Email: RjS@estacado.net Email: RjS@estacado.net
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 47 change blocks. 
183 lines changed or deleted 198 lines changed or added

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