draft-ietf-sipping-dialogusage-00.txt   draft-ietf-sipping-dialogusage-01.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: May 26, 2006 November 22, 2005 Expires: September 3, 2006 March 2, 2006
Multiple Dialog Usages in the Session Initiation Protocol Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-00 draft-ietf-sipping-dialogusage-01
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 May 26, 2006. This Internet-Draft will expire on September 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 new association within an existing dialog. methods can also create a different, but related, association within
These multiple associations, or dialog usages, require carefully an existing dialog. These multiple associations, or dialog usages,
coordinated processing as they have independent life-cycles, but require carefully coordinated processing as they have independent
share common dialog state. life-cycles, but share common dialog state.
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 . . . . . . . . . . . . . . . . . 3
2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5 2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5
3. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 7 3. Usage Creation and Destruction . . . . . . . . . . . . . . . . 8
3.1. A survey of the effect of failure responses on usages 3.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 8
4. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 8
4.1. A survey of the effect of failure responses on usages
and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 14 4.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 15
3.3. Matching requests to usages . . . . . . . . . . . . . . . 14 4.3. Matching requests to usages . . . . . . . . . . . . . . . 15
3.4. Target refresh requests . . . . . . . . . . . . . . . . . 15 4.4. Target refresh requests . . . . . . . . . . . . . . . . . 16
3.5. Refreshing and Terminating Usages . . . . . . . . . . . . 15 4.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17
3.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 15 4.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 17
3.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 16 4.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 17
4. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 16 5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 17
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. Informative References . . . . . . . . . . . . . . . . . . . . 22 8. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
A.1. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 22 A.1. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 24
A.2. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 22 A.2. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 A.3. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
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. request has a subscribe usage.
Dialogs with multiple usages arise from actions like a REFER or Dialogs with multiple usages arise when a usage-creating action
SUBSCRIBE issued inside a dialog established with an INVITE request. occurs inside an existing dialog. Susch actions include accepting a
Multiple REFERs within a dialog create multiple subscriptions, each REFER or SUBSCRIBE issued inside a dialog established with an INVITE
of which is a new dialog usage sharing common dialog state. This request. Multiple REFERs within a dialog create multiple
state includes: subscriptions, each of which is a new dialog usage sharing common
dialog state.
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
Usages have state that is not shared in the dialog. For example, a
subscription has a duration. Multiple subscriptions in the same
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
resulting mechanisms have mixed effects, some influencing the usage, resulting mechanisms have mixed effects, some influencing the usage,
and some influencing the entire dialog. and some influencing the entire dialog.
The current specifications define two usages, invite and subscribe. The current specifications define two usages, invite and subscribe.
A dialog can share up to one invite usage and arbitrarily many A dialog can share up to one invite usage and arbitrarily many
skipping to change at page 7, line 44 skipping to change at page 8, line 5
Event: presence Event: presence
Subscription-State: terminated;reason=deactivated Subscription-State: terminated;reason=deactivated
Call-ID: alicecallid1@alice.example.com Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2 To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2 From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 502 NOTIFY CSeq: 502 NOTIFY
Contact: <sip:aliceinstance@alice.example.com> Contact: <sip:aliceinstance@alice.example.com>
Figure 2 Figure 2
3. Proper Handling of Multiple Usages 3. Usage Creation and Destruction
Dialogs come into existance along with their first usage. Dialogs
terminate when their last usage is destroyed. The messages that
create and destroy usages vary per usage. This section provides a
high-level categorization of those messages. The section does not
attempt to explore the REGISTER pseudo-dialog.
3.1. Invite usages
Created by: non-100 provisional responses to INVITE; 200 response to
INVITE
Destroyed by: 200 responses to BYE; certain failure responses to
INVITE, UPDATE, PRACK, or INFO; anything that destroys a dialog
and all its usages
3.2. Subscribe usages
Created by: 200 class responses to SUBSCRIBE; 200 class responses to
REFER; NOTIFY requests
Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or
refresh-SUBSCRIBE request timeout; certain failure responses to
NOTIFY or SUBSCRIBE; anything that destroys a dialog and all its
usages
4. Proper Handling of Multiple Usages
The examples in Section 2 show straightforward cases where it is The examples in Section 2 show straightforward cases where it is
fairly obvious when the dialog begins and ends. Unfortunately, there fairly obvious when the dialog begins and ends. Unfortunately, there
are many scenarios where such clarity is not present. For instance, are many scenarios where such clarity is not present. For instance,
in Figure 1, what would it mean if the response to the NOTIFY (F2) in Figure 1, what would it mean if the response to the NOTIFY (F2)
were a 481? Does that simply terminate the refer subscription, or were a 481? Does that simply terminate the refer subscription, or
does it destroy the entire dialog? This section explores the problem does it destroy the entire dialog? This section explores the problem
spots with multiple usages that have been identified to date. spots with multiple usages that have been identified to date.
3.1. A survey of the effect of failure responses on usages and dialogs 4.1. A survey of the effect of failure responses on usages and dialogs
For this survey, consider a subscribe usage inside a dialog For this survey, consider a subscribe usage inside a dialog
established with an invite usage. Unless stated otherwise, we'll established with an invite usage. Unless stated otherwise, we'll
discuss the effect on each usage and the dialog when a client issuing discuss the effect on each usage and the dialog when a client issuing
a NOTIFY inside the subscribe usage receives a failure response (such a NOTIFY inside the subscribe usage receives a failure response (such
as a transferee issuing a NOTIFY to event refer). as a transferee issuing a NOTIFY to event refer). Further, unless
otherwise stated, the conclusions apply to arbitrary multiple-usages.
This survey is written from the perspective of a client receiving the This survey is written from the perspective of a client receiving the
error response. The effect on dialogs and usages at the server error response. The effect on dialogs and usages at the server
issuing the response is the same. issuing the response is the same.
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.
skipping to change at page 8, line 40 skipping to change at page 9, line 24
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 subscription, but has no 403 Forbidden: This response terminates the usage, but has no effect
effect on any other usages of the dialog. In our example on any other usages of the dialog. In our example scenario, the
scenario, the invite usage continues to exist. Similarly, if the subscription is terminated, but the invite usage continues to
403 came in response to a reINVITE, the invite usage would be exist. Similarly, if the 403 came in response to a reINVITE, the
terminated, but not the subscription. invite usage would be terminated, but not the subscription.
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 9, line 19 skipping to change at page 9, line 50
general, a 405 within a given usage affects only that usage, but general, a 405 within a given usage affects only that usage, but
does not affect other usages of the dialog. does not affect other usages of the dialog.
406 Not Acceptable: These responses concern details of the message in 406 Not Acceptable: These responses concern details of the message in
the transaction. Subsequent requests in this same usage may the transaction. Subsequent requests in this same usage may
succeed. Neither the usage nor dialog is terminated, other usages succeed. Neither the usage nor dialog is terminated, other usages
sharing this dialog are unaffected. sharing this dialog are unaffected.
408 Request Timeout: Receiving a 408 will have the same effect on 408 Request Timeout: Receiving a 408 will have the same effect on
usages and dialogs as a real transaction timeout as described in usages and dialogs as a real transaction timeout as described in
Section 3.2. Section 4.2.
410 Gone: This response destroys the dialog and all usages sharing 410 Gone: This response destroys the dialog and all usages sharing
it. The Request-URI that is being rejected is the remote target it. The Request-URI that is being rejected is the remote target
set by the Contact provided by the peer. Similar to 404, getting set by the Contact provided by the peer. Similar to 404, getting
this response means something has gone fundamentally wrong with this response means something has gone fundamentally wrong with
the dialog state, its slightly less aberrant in that the other the dialog state, its slightly less aberrant in that the other
endpoint recognizes that this was once a valid URI that it isn't endpoint recognizes that this was once a valid URI that it isn't
willing to respond to anymore. willing to respond to anymore.
412 Conditional Request Failed: 412 Conditional Request Failed:
skipping to change at page 9, line 42 skipping to change at page 10, line 26
415 Unsupported Media Type: These responses concern details of the 415 Unsupported Media Type: These responses concern details of the
message in the transaction. Subsequent requests in this same message in the transaction. Subsequent requests in this same
usage may succeed. Neither the usage nor dialog is terminated, usage may succeed. Neither the usage nor dialog is terminated,
other usages sharing this dialog are unaffected. other usages sharing this dialog are unaffected.
416 Unsupported URI Scheme: Similar to 404 and 410, this response 416 Unsupported URI Scheme: Similar to 404 and 410, this response
came to a request whose Request-URI was provided by the peer in a came to a request whose Request-URI was provided by the peer in a
Contact header field. Something has gone fundamentally wrong, and Contact header field. Something has gone fundamentally wrong, and
the dialog and all of its usages are destroyed. the dialog and all of its usages are destroyed.
417 Uknown Resource-Priority: The effect of this response on usages
and dialogs is analgous to that for 420 and 488. The usage is not
affected. The dialog is only affected by a change in its local
CSeq. No other usages of the dialog are affected.
420 Bad Extension, 421 Extension Required: These responses are 420 Bad Extension, 421 Extension Required: These responses are
objecting to the request, not the usage. The usage is not objecting to the request, not the usage. The usage is not
affected. The dialog is only affected by a change in its local affected. The dialog is only affected by a change in its local
CSeq. No other usages of the dialog are affected. CSeq. No other usages of the dialog are affected.
422 Session Interval Too Small: This repsonse will not be returned to
a NOTIFY in our example scenario. This response is non-sensical
for any mid-usage request. If it is received, an element in the
path of the request is violating protocol, and the recipient
should treat this as it would an unknown 4xx response. If the
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.
423 Interval Too Brief: This response won't happen in our example 423 Interval Too Brief: This response won't happen in our example
scenario, but if it came in response to a reSUBSCRIBE, the scenario, but if it came in response to a reSUBSCRIBE, the
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
the usage. The usage is not affected. The dialog is only
affected by a change in its local CSeq. No other usages of the
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 to the REFER request itself, not any usage
the REFER occurs within. The usage is unaffected. Any other the REFER occurs within. The usage is unaffected. Any other
usages sharing this dialog are unaffected. The dialog is only usages sharing this dialog are unaffected. 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
Identity Header These responses object to the request, not the usage.
The usage is not affected. The dialog is only affected by a
change in its local CSeq. No other usages of the dialog are
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
the request occurs. No other usages are affected. If the the request occurs. No other usages are affected. If the
response included a Retry-After header field, further requests in response included a Retry-After header field, further requests in
that usage should not be sent until the indicated time has past. that usage should not be sent until the indicated time has past.
Requests in other usages may still be sent at any time. Requests in other usages may still be sent at any time.
481 Call/Transaction Does Not Exist: This response indicates that the 481 Call/Transaction Does Not Exist: This response indicates that the
peer has lost its copy of the dialog state. The dialog and any peer has lost its copy of the dialog usage state. The dialog
usages sharing it are destroyed. itself should not be destroyed unless this was the last usage.
OPEN ISSUE: There has been some list discussion indicating a need The effects of a 481 on a dialog and its usages are the most
for a response code that only terminates the usage, but not the ambiguous of any final response. There are implementations that
dialog (Motivation: being able to destroy a subscription by have chosen the meaning recommended here, and others that destroy
refusing a NOTIFY without destroying the dialog that that the entire dialog without regard to the number of outstanding
subscription exists in, particularly when the susbcription exists usages. Going forward with this clarification will allow those
because of an in-dialog REFER). deployed implementations that assumed only the usage was destroyed
to work with a wider number of implementations. Those that made
the other choice will continue to function as they do now,
suffering at most the same extra messages needed for a peer to
discover that that other usages have gone away that they currently
do. However, the necessary clarification to RFC 3261 needs to
make it very clear that the ability to terminate usages
independently from the overall dialog using a 481 is not
justification for designing new applications that count on
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.
483 Too Many Hops: Similar to 482, receiving this mid-dialog is 483 Too Many Hops: Similar to 482, receiving this mid-dialog is
skipping to change at page 14, line 5 skipping to change at page 15, line 25
604ed is the remote target set by the Contact provided by the 604ed is the remote target set by the Contact provided by the
peer. Getting this response means something has gone peer. Getting this response means something has gone
fundamentally wrong with the dialog state. fundamentally wrong with the dialog state.
606 Not Acceptable: This response is objecting to aspects of the 606 Not Acceptable: This response is objecting to aspects of the
associated request, not the usage the request appears in. The associated request, not the usage the request appears in. The
usage is unaffected. Any other usages sharing the dialog are usage is unaffected. Any other usages sharing the dialog are
unaffected. The only affect on the dialog is the change in the unaffected. The only affect on the dialog is the change in the
local CSeq. local CSeq.
3.2. Transaction timeouts 4.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.
Generally, a transaction timeout should affect only the usage in Generally, a transaction timeout should affect only the usage in
which the transaction occurred. Other uses sharing the dialog should which the transaction occurred. Other uses sharing the dialog should
not be affected. In the worst case of timeout due to total transport not be affected. In the worst case of timeout due to total transport
failure, it may require multiple failed messages to remove all usages failure, it may require multiple failed messages to remove all usages
from a dialog (at least one per usage). from a dialog (at least one per usage).
There are some mid-dialog messages that never belong to any usage. There are some mid-dialog messages that never belong to any usage.
If they timeout, they will have no effect on the dialog or its If they timeout, they will have no effect on the dialog or its
usages. usages.
3.3. Matching requests to usages 4.3. Matching requests to usages
For many mid-dialog requests, identifying the usage they belong to is For many mid-dialog requests, identifying the usage they belong to is
obvious. A dialog can have at most one invite usage, so any INVITE, obvious. A dialog can have at most one invite usage, so any INVITE,
UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The
usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER
requests belong to can be determined from the Event header field of requests belong to can be determined from the Event header field of
the request. REGISTER requests within a (pseudo)-dialog belong to the request. REGISTER requests within a (pseudo)-dialog belong to
the registration usage. (As mentioned before, implementations aren't the registration usage. (As mentioned before, implementations aren't
mixing registration usages with other usages, so this document isn't mixing registration usages with other usages, so this document isn't
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 3.1 and Section 3.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 not currently allowed inside a dialog (though
some implementations use it that way, against the standard some implementations use it that way, against the standard
recommendation). As it is not meant to be part of any given dialog, recommendation). As it is not meant to be part of any given dialog,
it cannot be part of any given usage. A failed MESSAGE request it cannot be part of any given usage. A failed MESSAGE request
should have similar effects on a dialog and its usages as a failed should have similar effects on a dialog and its usages as a failed
OPTIONS request. 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.
3.4. Target refresh requests These guidelines for matching messages to usages (or determining
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
messages between two endpoints.
4.4. Target refresh requests
Target refresh requests update the remote target of a dialog when Target refresh requests update the remote target of a dialog when
they are successfully processed. The currently defined target they are successfully processed. The currently defined target
refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified refresh requests are INVITE, UPDATE, SUBSCRIBE and NOTIFY (clarified
in a bug against RFC3565) and REFER (clarified in a bug against in a bug against RFC3565) and REFER (clarified in a bug against
RFC3515 [4]). RFC3515 [4]).
The remote target is part of the dialog state. When a target refresh The remote target is part of the dialog state. When a target refresh
request affects it, it affects it for ALL usages sharing that dialog. request affects it, it affects it for ALL usages sharing that dialog.
If a subscription and invite usage are sharing a dialog, sending a If a subscription and invite usage are sharing a dialog, sending a
refresh SUBSCRIBE with a different contact will cause reINVITEs from refresh SUBSCRIBE with a different contact will cause reINVITEs from
the peer to go to that different contact. the peer to go to that different contact.
A UAS will only update the remote target if it sends a 200 class A UAS will only update the remote target if it sends a 200 class
response to a target refresh request. A UAC will only update the response to a target refresh request. A UAC will only update the
remote target if it receives a 200 class response to a target refresh remote target if it receives a 200 class response to a target refresh
request. Again, any update to a dialog's remote target affects all request. Again, any update to a dialog's remote target affects all
usages of that dialog. usages of that dialog.
3.5. Refreshing and Terminating Usages 4.5. Refreshing and Terminating Usages
Subscription and registration usages expire over time and must be Subscription and registration usages expire over time and must be
refreshed (with a refresh SUBSCRIBE for example). This expiration is refreshed (with a refresh SUBSCRIBE for example). This expiration is
usage state, not dialog state. If several subscriptions share a usage state, not dialog state. If several subscriptions share a
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 Abnormal termination can effect all usages on a dialog. Rejecting a
NOTIFY with a 481 (incorrectly recommended in the past as an NOTIFY with a 481 (incorrectly recommended in the past as an
inexpensive way to terminate a REFER subscription) destroys the inexpensive way to terminate a REFER subscription) destroys the
dialog and all of its usages. dialog and all of its usages.
3.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.
3.7. Replacing usages 4.7. Replacing usages
[6] defines a mechanism through which one usage can replace another. [6] defines a mechanism through which one usage can replace another.
It can be used, for example, to associate the two dialogs a transfer It can be used, for example, to associate the two dialogs a transfer
target is involved in during an attended transfer. It is written target is involved in during an attended transfer. It is written
using the term "dialog", but its intent was to only affect the invite using the term "dialog", but its intent was to only affect the invite
usage of the dialog it targets. Any other usages inside that dialog usage of the dialog it targets. Any other usages inside that dialog
are unaffected. For some applications, the other usages may no are unaffected. For some applications, the other usages may no
longer make sense, and the application may terminate them as well. longer make sense, and the application may terminate them as well.
However, the interactions between Replaces and multiple dialog usages However, the interactions between Replaces and multiple dialog usages
have not been well explored. More discussion of this topic is have not been well explored. More discussion of this topic is
needed. Implementers should avoid this scenario completely. needed. Implementers should avoid this scenario completely.
4. Avoiding Multiple Usages 5. Avoiding Multiple Usages
Processing multiple usages correctly is not completely understood. Processing multiple usages correctly is not completely understood.
What is understood is difficult to implement and is very likely to What is understood is difficult to implement and is very likely to
lead to interoperability problems. The best way to avoid the trouble lead to interoperability problems. The best way to avoid the trouble
that comes with such complexity is to avoid it altogether. that comes with such complexity is to avoid it altogether.
When designing new applications that use SIP dialogs, do not When designing new applications that use SIP dialogs, do not
construct multiple usages. If a peer attempts to create a second construct multiple usages. If a peer attempts to create a second
usage inside a dialog, refuse it. usage inside a dialog, refuse it.
Unfortunately, there are existing applications, like transfer, that Unfortunately, there are existing applications, like transfer, that
skipping to change at page 21, line 30 skipping to change at page 23, line 5
NOTIFY sip:boaiidfjjereis@example.com SIP/2.0 NOTIFY sip:boaiidfjjereis@example.com SIP/2.0
Subscription-State: terminated;reason=noresource Subscription-State: terminated;reason=noresource
Call-ID: 39fa99r0329493asdsf3n@bob.example.com Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Contact: <sip:aanewmr203raswdf@example.com> Contact: <sip:aanewmr203raswdf@example.com>
Content-Type: message/sipfrag Content-Type: message/sipfrag
SIP/2.0 200 OK SIP/2.0 200 OK
Bob then ends his invite usages with both Alice and Carol using BYEs. Bob then ends his invite usages with both Alice and Carol using BYEs.
5. Conclusion 6. Conclusion
Handling multiple usages within a single dialog is complex and Handling multiple usages within a single dialog is complex and
introduces scenarios where the right thing to do is not clear. introduces scenarios where the right thing to do is not clear.
Implementations should avoid entering into multiple usages whenever Implementations should avoid entering into multiple usages whenever
possible. New applications should be designed to never introduce possible. New applications should be designed to never introduce
multiple usages. multiple usages.
There are some accepted SIP practices, including transfer, that There are some accepted SIP practices, including transfer, that
currently require multiple usages. Recent work, most notably GRUU, currently require multiple usages. Recent work, most notably GRUU,
makes those practices unnecessary. The standardization of those makes those practices unnecessary. The standardization of those
practices and the implementations should be revised as soon as practices and the implementations should be revised as soon as
possible to use only single-usage dialogs. possible to use only single-usage dialogs.
6. Acknowledgments 7. Acknowledgments
The ideas in this draft have been refined over several IETF meetings The ideas in this draft have been refined over several IETF meetings
with many participants. Significant contribution was provided by with many participants. Significant contribution was provided by
Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan
Rosenberg and Rohan Mahy. Members of the reSIProcate project Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate
(http://www.sipfoundry.org/reSIProcate) also shared their project also shared their difficulties and discoveries while
difficulties and discoveries while implementing multiple-usage dialog implementing multiple-usage dialog handlers.
handlers.
7. Informative References 8. Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
skipping to change at page 22, line 32 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-05 (work in progress), September 2005. draft-ietf-sip-gruu-06 (work in progress), October 2005.
Appendix A. Change Log Appendix A. Change Log
A.1. draft-sparks-01->draft-ietf-00 RFC-EDITOR: Please remove this entire Change Log section while
formatting this document for publication.
A.1. draft-ietf-00->draft-ietf-01
o Changed 481 to only affect the usage the response occured in,
closing the last open issue. Added some text justifying this
recommendation.
o Added 422 Session Interval Too Small
o Added 417 Uknown Resource-Priority
o Added 428 Use Identity Header
o Added 436 Bad Identity-Info
o Added 437 Unsupported Certificate
o Added 438 Invalid Identity header
o Added a section categorizing messages that create and destroy
usages
o Made sure all descriptions in Section 4 addressed the generic
multi-usage case.
o Clarified that the mechanics described in matching messages to
usages applied equally to UACs and UASs.
o More explicitly noted that REFER creates a subscribe-usage
A.2. draft-sparks-01->draft-ietf-00
o Draft rename o Draft rename
A.2. draft-sparks-00->01 A.3. 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.
skipping to change at page 25, line 41 skipping to change at page 26, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 37 change blocks. 
68 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/