draft-ietf-sipping-dialogusage-01.txt   draft-ietf-sipping-dialogusage-02.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: September 3, 2006 March 2, 2006 Expires: December 27, 2006 June 25, 2006
Multiple Dialog Usages in the Session Initiation Protocol Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-01 draft-ietf-sipping-dialogusage-02
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 33
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 September 3, 2006. This Internet-Draft will expire on December 27, 2006.
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 12 skipping to change at page 2, line 12
This memo argues that multiple dialog usages should be avoided. It This memo argues that multiple dialog usages should be avoided. It
discusses alternatives to their use and clarifies essential behavior discusses alternatives to their use and clarifies essential behavior
for elements that cannot currently avoid them. for elements that cannot currently avoid them.
This is an informative document and makes no normative statements of This is an informative document and makes no normative statements of
any kind. any kind.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 3 2. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4
2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5 2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5
3. Usage Creation and Destruction . . . . . . . . . . . . . . . . 8 3. Usage Creation and Destruction . . . . . . . . . . . . . . . . 8
3.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 8 3.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 8
4. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 8 4. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 8
4.1. A survey of the effect of failure responses on usages 4.1. A survey of the effect of failure responses on usages
and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 15 4.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 15
4.3. Matching requests to usages . . . . . . . . . . . . . . . 15 4.3. Matching requests to usages . . . . . . . . . . . . . . . 16
4.4. Target refresh requests . . . . . . . . . . . . . . . . . 16 4.4. Target refresh requests . . . . . . . . . . . . . . . . . 16
4.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17 4.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17
4.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 17 4.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 17
4.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 17 4.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 17
5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 17 5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
8. Informative References . . . . . . . . . . . . . . . . . . . . 23 8. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
A.1. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 24 A.1. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 24
A.2. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 24 A.2. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 24
A.3. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 24 A.3. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.4. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
Several methods in SIP can establish a dialog. When they do so, they Several methods in SIP can establish a dialog. When they do so, they
also establish an association between the endpoints within that also establish an association between the endpoints within that
dialog. This assocation has been known for some time as a "dialog dialog. This assocation has been known for some time as a "dialog
usage" in the developer community. A dialog initiated with an INVITE usage" in the developer community. A dialog initiated with an INVITE
request has an invite usage. A dialog initiated with a SUBSCRIBE request has an invite usage. A dialog initiated with a SUBSCRIBE
request has a subscribe usage. A dialog initiated with a REFER request has a subscribe usage. A dialog initiated with a REFER
request has a subscribe usage. request has a subscribe usage.
Dialogs with multiple usages arise when a usage-creating action Dialogs with multiple usages arise when a usage-creating action
occurs inside an existing dialog. Susch actions include accepting a occurs inside an existing dialog. Susch actions include accepting a
REFER or SUBSCRIBE issued inside a dialog established with an INVITE REFER or SUBSCRIBE issued inside a dialog established with an INVITE
request. Multiple REFERs within a dialog create multiple request. Multiple REFERs within a dialog create multiple
subscriptions, each of which is a new dialog usage sharing common subscriptions, each of which is a new dialog usage sharing common
dialog state. dialog state. (Note that any REFER issued utilizing the
subscription-suppression mechanism specified in [8] creates no new
usage.)
The common state in the dialog shared by any usages is exactly: The common state in the dialog shared by any usages is exactly:
o the Call-ID o the Call-ID
o the local Tag o the local Tag
o the remote Tag o the remote Tag
o the local CSeq o the local CSeq
o the remote CSeq o the remote CSeq
o the Route-set o the Route-set
o the local contact o the local contact
o the remote target o the remote target
o the secure flag
Usages have state that is not shared in the dialog. For example, a Usages have state that is not shared in the dialog. For example, a
subscription has a duration. Multiple subscriptions in the same subscription has a duration. Multiple subscriptions in the same
dialog each have thier own duration. dialog each have thier own duration.
A dialog comes into existence with the creation of the first usage, A dialog comes into existence with the creation of the first usage,
and continues to exist until the last usage is terminated (reference and continues to exist until the last usage is terminated (reference
counting). Unfortunately, many of the usage management aspects of counting). Unfortunately, many of the usage management aspects of
SIP, such as authentication, were originally designed with the SIP, such as authentication, were originally designed with the
implicit assumption that there was one usage per dialog. The implicit assumption that there was one usage per dialog. The
skipping to change at page 9, line 24 skipping to change at page 9, line 25
dialog. In general, the response is a complaint about this dialog. In general, the response is a complaint about this
transaction, not the usage or dialog the transaction occurs in. transaction, not the usage or dialog the transaction occurs in.
401 Unauthorized ,407 Proxy Authentication Required: This request, 401 Unauthorized ,407 Proxy Authentication Required: This request,
not the subscription or dialog, is being challenged. The usages not the subscription or dialog, is being challenged. The usages
and dialog are not terminated. and dialog are not terminated.
402 Payment Required: This is a reserved response code. If 402 Payment Required: This is a reserved response code. If
encountered, it should be treated as an unrecognized 4xx. encountered, it should be treated as an unrecognized 4xx.
403 Forbidden: This response terminates the usage, but has no effect 403 Forbidden: This response concerns the transaction, not the usage.
on any other usages of the dialog. In our example scenario, the It has no effect on any other usages of the dialog. In our
subscription is terminated, but the invite usage continues to example scenario, the subscription remains, and is not affected in
exist. Similarly, if the 403 came in response to a reINVITE, the any way. The invite usage continues to exist. Similarly, if the
invite usage would be terminated, but not the subscription. 403 came in response to a reINVITE, the invite usage would
continue to exist.
404 Not Found: This response destroys the dialog and all usages 404 Not Found: This response destroys the dialog and all usages
sharing it. The Request-URI that is being 404ed is the remote sharing it. The Request-URI that is being 404ed is the remote
target set by the Contact provided by the peer. Getting this target set by the Contact provided by the peer. Getting this
response means something has gone fundamentally wrong with the response means something has gone fundamentally wrong with the
dialog state. dialog state.
405 Method Not Allowed: In our example scenario, this response 405 Method Not Allowed: In our example scenario, this response
destroys the subscription, but not the invite usage or the dialog. destroys the subscription, but not the invite usage or the dialog.
It's an aberrant case for NOTIFYs to receive a 405 since they only It's an aberrant case for NOTIFYs to receive a 405 since they only
skipping to change at page 11, line 12 skipping to change at page 11, line 17
subscribe usage is not destroyed (or otherwise affected). No subscribe usage is not destroyed (or otherwise affected). No
other usages of the dialog are affected. other usages of the dialog are affected.
428 Use Identity Header: This response objects to the request, not 428 Use Identity Header: This response objects to the request, not
the usage. The usage is not affected. The dialog is only the usage. The usage is not affected. The dialog is only
affected by a change in its local CSeq. No other usages of the affected by a change in its local CSeq. No other usages of the
dialog are affected. dialog are affected.
429 Provide Referrer Identity: This response won't be returned to a 429 Provide Referrer Identity: This response won't be returned to a
NOTIFY as in our example scenario, but when it is returned to a NOTIFY as in our example scenario, but when it is returned to a
REFER, it is objecting to the REFER request itself, not any usage REFER, it is objecting only to the REFER request itself. Any
the REFER occurs within. The usage is unaffected. Any other usages sharing this dialog with that REFER request are unaffected.
usages sharing this dialog are unaffected. The dialog is only The dialog is only affected by a change in its local CSeq.
affected by a change in its local CSeq.
436 Bad Identity-Info, 437 Unsupported Certificate, 438 Invalid 436 Bad Identity-Info, 437 Unsupported Certificate, 438 Invalid
Identity Header These responses object to the request, not the usage. Identity Header These responses object to the request, not the usage.
The usage is not affected. The dialog is only affected by a The usage is not affected. The dialog is only affected by a
change in its local CSeq. No other usages of the dialog are change in its local CSeq. No other usages of the dialog are
affected. affected.
480 Temporarily Unavailable: RFC 3261 is unclear on what this 480 Temporarily Unavailable: RFC 3261 is unclear on what this
response means for mid-usage requests. Clarifications will be response means for mid-usage requests. Clarifications will be
made to show that this response affects only the usage in which made to show that this response affects only the usage in which
skipping to change at page 12, line 13 skipping to change at page 12, line 14
multiple usages in a dialog. multiple usages in a dialog.
482 Loop Detected: This response is aberrant mid-dialog. It will 482 Loop Detected: This response is aberrant mid-dialog. It will
only occur if the Record-Route header field was improperly 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. The dialog and any usages sharing it are
destroyed. destroyed.
An edge condition exists during RFC3263 failover at the element
sending a request where the request effectively forks to
multiple destinations from the client. Some implementations
increase risk entering this edge condition by trying the next
potential location as determined by RFC3263 very rapidly if the
first does not immediately respond. In any situation where a
client sends the same request to more than one endpoint, it
must be prepared to receive a response from each branch (and
should choose a "best" response to act on following the same
guidelines as a forking proxy). In this particular race
condition, if multiple branches respond, all but one will most
likely return a 482 Merged Request. The client should select
the remaining non-482 response as the "best" response.
483 Too Many Hops: Similar to 482, receiving this mid-dialog is 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 attempt to
gracefully terminate this usage and all other usages that share gracefully terminate this usage and all other usages that share
its dialog. its dialog.
484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these 484 Address Incomplete, 485 Ambiguous: Similar to 404 and 410, these
skipping to change at page 16, line 18 skipping to change at page 16, line 32
exploring the consequences of that bad behavior). exploring the consequences of that bad behavior).
According to [1], "an OPTIONS request received within a dialog According to [1], "an OPTIONS request received within a dialog
generates a 200 OK response that is identical to one constructed generates a 200 OK response that is identical to one constructed
outside a dialog and does not have any impact on that dialog". Thus outside a dialog and does not have any impact on that dialog". Thus
OPTIONS does not belong to any usage. Only those failures discussed OPTIONS does not belong to any usage. Only those failures discussed
in Section 4.1 and Section 4.2 that destroy entire dialogs will have in Section 4.1 and Section 4.2 that destroy entire dialogs will have
any effect on the usages sharing the dialog with a failed OPTIONS any effect on the usages sharing the dialog with a failed OPTIONS
request. request.
MESSAGE requests are not currently allowed inside a dialog (though MESSAGE requests are discouraged inside a dialog. Implementations
some implementations use it that way, against the standard are restricted from creating a usage for the purpose of carrying a
recommendation). As it is not meant to be part of any given dialog, sequence of MESSAGE requests (though some implementations use it that
it cannot be part of any given usage. A failed MESSAGE request way, against the standard recommendation). A failed MESSAGE occuring
should have similar effects on a dialog and its usages as a failed inside an existing dialog will have similar effects on the dialog and
OPTIONS request. its usages as a failed OPTIONS request.
Mid-dialog requests with unknown methods cannot be matched with a Mid-dialog requests with unknown methods cannot be matched with a
usage. Servers will return a failure response (likely a 501). The usage. Servers will return a failure response (likely a 501). The
effect on the dialog and its usages at either the client or the effect on the dialog and its usages at either the client or the
server should be similar to that of a failed OPTIONS request. server should be similar to that of a failed OPTIONS request.
These guidelines for matching messages to usages (or determining These guidelines for matching messages to usages (or determining
there is no usage) apply equally when acting as a UAS, a UAC, or any there is no usage) apply equally when acting as a UAS, a UAC, or any
third party tracking usage and dialog state by inspecting all third party tracking usage and dialog state by inspecting all
messages between two endpoints. messages between two endpoints.
skipping to change at page 17, line 22 skipping to change at page 17, line 36
dialog, refreshing one of them has no effect on the expiration of the dialog, refreshing one of them has no effect on the expiration of the
others. others.
Normal termination of a usage has no effect on other usages sharing Normal termination of a usage has no effect on other usages sharing
the same dialog. For instance terminating a subscription with a the same dialog. For instance terminating a subscription with a
NOTIFY/Subscription-State: terminated will not terminate an invite NOTIFY/Subscription-State: terminated will not terminate an invite
usage sharing its dialog. Likewise, ending an invite usage with a usage sharing its dialog. Likewise, ending an invite usage with a
BYE does not terminate any active Event: refer subscriptions BYE does not terminate any active Event: refer subscriptions
established on that dialog. established on that dialog.
Abnormal termination can effect all usages on a dialog. Rejecting a
NOTIFY with a 481 (incorrectly recommended in the past as an
inexpensive way to terminate a REFER subscription) destroys the
dialog and all of its usages.
4.6. Refusing new usages 4.6. Refusing new usages
As the survey of the effect of failure responses shows, care must be As the survey of the effect of failure responses shows, care must be
taken when refusing a new usage inside an existing dialog. Choosing taken when refusing a new usage inside an existing dialog. Choosing
the wrong response code will terminate the dialog and all of its the wrong response code will terminate the dialog and all of its
usages. Generally, returning a 603 Decline is the safest way to usages. Generally, returning a 603 Decline is the safest way to
refuse a new usage. refuse a new usage.
4.7. Replacing usages 4.7. Replacing usages
skipping to change at page 23, line 51 skipping to change at page 23, line 51
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[5] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) [5] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004. "Join" Header", RFC 3911, October 2004.
[6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [6] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[7] Rosenberg, J., "Obtaining and Using Globally Routable User Agent [7] Rosenberg, J., "Obtaining and Using Globally Routable User Agent
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
draft-ietf-sip-gruu-06 (work in progress), October 2005. draft-ietf-sip-gruu-08 (work in progress), June 2006.
[8] Levin, O., "Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription", RFC 4488, May 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-00->draft-ietf-01 A.1. draft-ietf-01->draft-ietf-02
o Incorporated editorial-fix contributions from the list
o Noted that REFERs using norefersub (RFC4488) don't create a new
subscribe usage
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 -
pointed out by Brian Stucker) which states that a UA receiving a
non-2xx final response to a re-INVITE MUST leave the session
parameters unchanges as if the re-INVITE had not been issued.
There are other recommendations in this document that violate that
MUST (404,410, etc) but on review, I believe they are correct
(except for 403) and that this text in 3261 needs to be updated to
recognize the conditions under which they're sent.
o Added text concerning the race condition wherein endpoints failing
over rapidly to 3263 destinations may stimulate a merged-request
response.
o Corrected the 481 inconsistency Paul Kyzivat pointed out (by
removing the inconsistent paragraph)
o NOT DONE: As mentioned in Dallas, there was a list discussion
around the effect of provisional responses on the remote and local
target stored in dialog state. This version of the draft hasn't
captured that discussion. More list attention is needed to
conclude the discussion and determine if this is the right draft
to capture that conclusion.
A.2. draft-ietf-00->draft-ietf-01
o Changed 481 to only affect the usage the response occured in, o Changed 481 to only affect the usage the response occured 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 Uknown Resource-Priority o Added 417 Uknown 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 4 addressed the generic o Made sure all descriptions in Section 4 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.2. draft-sparks-01->draft-ietf-00 A.3. draft-sparks-01->draft-ietf-00
o Draft rename o Draft rename
A.3. draft-sparks-00->01 A.4. draft-sparks-00->01
o Changed 480 to affect only the usage the response occured in. o Changed 480 to affect only the usage the response occured 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 stimuted by certain methods (due to method specific routing only stimuted 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.
 End of changes. 18 change blocks. 
36 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/