draft-ietf-sipping-dialogusage-02.txt   draft-ietf-sipping-dialogusage-03.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: December 27, 2006 June 25, 2006 Expires: March 2, 2007 August 29, 2006
Multiple Dialog Usages in the Session Initiation Protocol Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-02 draft-ietf-sipping-dialogusage-03
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 December 27, 2006. This Internet-Draft will expire on March 2, 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 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 18 5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Informative References . . . . . . . . . . . . . . . . . . . . 23 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
10. Informative References . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
A.1. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 24 A.1. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 24
A.2. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 24 A.2. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 25
A.3. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 25 A.3. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 25
A.4. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 25 A.4. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.5. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
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 association 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. Such 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. (Note that any REFER issued utilizing the dialog state. (Note that any REFER issued utilizing the
subscription-suppression mechanism specified in [8] creates no new subscription-suppression mechanism specified in [8] creates no new
usage.) 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 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 their 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.
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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. Usage Creation and Destruction 3. Usage Creation and Destruction
Dialogs come into existance along with their first usage. Dialogs Dialogs come into existence along with their first usage. Dialogs
terminate when their last usage is destroyed. The messages that terminate when their last usage is destroyed. The messages that
create and destroy usages vary per usage. This section provides a create and destroy usages vary per usage. This section provides a
high-level categorization of those messages. The section does not high-level categorization of those messages. The section does not
attempt to explore the REGISTER pseudo-dialog. attempt to explore the REGISTER pseudo-dialog.
3.1. Invite usages 3.1. Invite usages
Created by: non-100 provisional responses to INVITE; 200 response to Created by: non-100 provisional responses to INVITE; 200 response to
INVITE INVITE
Destroyed by: 200 responses to BYE; certain failure responses to Destroyed by: 200 responses to BYE; certain failure responses to
INVITE, UPDATE, PRACK, or INFO; anything that destroys a dialog INVITE, UPDATE, PRACK, or INFO; anything that destroys a dialog
skipping to change at page 10, line 30 skipping to change at page 10, line 30
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 417 Unknown Resource-Priority: The effect of this response on usages
and dialogs is analgous to that for 420 and 488. The usage is not and dialogs is analogous to that for 420 and 488. The usage is
affected. The dialog is only affected by a change in its local not affected. The dialog is only affected by a change in its
CSeq. No other usages of the dialog are affected. 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 422 Session Interval Too Small: This response will not be returned to
a NOTIFY in our example scenario. This response is non-sensical a NOTIFY in our example scenario. This response does not make
for any mid-usage request. If it is received, an element in the sense for any mid-usage request. If it is received, an element in
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. If the
response came to a request that was attempting to establish a new response came to a request that was attempting to establish a new
usage in an existing dialog, no new usage is created and existing usage in an existing dialog, no new usage is created and existing
usages are unaffected. 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.
skipping to change at page 12, line 42 skipping to change at page 12, line 42
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
responses came to a request whose Request-URI was provided by the responses came to a request whose Request-URI was provided by the
peer in a Contact header field. Something has gone fundamentally peer in a Contact header field. Something has gone fundamentally
wrong, and the dialog and all of its usages are destroyed. wrong, and the dialog and all of its usages are destroyed.
486 Busy Here: This response is non-sensical in our example scenario, 486 Busy Here: This response is nonsensical in our example scenario,
or in any scenario where this response comes inside an established or in any scenario where this response comes inside an established
usage. If it occurs in that context, it should be treated as an usage. If it occurs in that context, it should be treated as an
unknown 4xx response. The usage, and any other usages sharing its unknown 4xx response. The usage, and any other usages sharing its
dialog are unaffected. The dialog is only affected by the change dialog are unaffected. The dialog is only affected by the change
in its local CSeq. If this response is to a request that is in its local CSeq. If this response is to a request that is
attempting to establish a new usage within an existing dialog attempting to establish a new usage within an existing dialog
(such as an INVITE sent within a dialog established by a (such as an INVITE sent within a dialog established by a
subscription), the request fails, no new usage is created, and no subscription), the request fails, no new usage is created, and no
other usages are affected. other usages are affected.
skipping to change at page 16, line 35 skipping to change at page 16, line 35
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 discouraged inside a dialog. Implementations MESSAGE requests are discouraged inside a dialog. Implementations
are restricted from creating a usage for the purpose of carrying a are restricted from creating a usage for the purpose of carrying a
sequence of MESSAGE requests (though some implementations use it that sequence of MESSAGE requests (though some implementations use it that
way, against the standard recommendation). A failed MESSAGE occuring way, against the standard recommendation). A failed MESSAGE
inside an existing dialog will have similar effects on the dialog and occurring inside an existing dialog will have similar effects on the
its usages as a failed OPTIONS request. dialog and 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 19, line 25 skipping to change at page 19, line 25
that the new request does not arrive at the endpoint holding the that the new request does not arrive at the endpoint holding the
dialog of interest. dialog of interest.
The reachability aspects of using a GRUU to address problem 1 can be The reachability aspects of using a GRUU to address problem 1 can be
combined with the association-with-other-dialogs aspects of the Join/ combined with the association-with-other-dialogs aspects of the Join/
Replaces solution. A REFER request sent out-of-dialog can be sent Replaces solution. A REFER request sent out-of-dialog can be sent
towards a GRUU, and identify an existing dialog as part of the towards a GRUU, and identify an existing dialog as part of the
context the receiver should use. A new header, Target-Dialog: context the receiver should use. A new header, Target-Dialog:
perhaps, would be included in the REFER listing the dialog this REFER perhaps, would be included in the REFER listing the dialog this REFER
is associated with. Figure 3 sketches how this could be used to is associated with. Figure 3 sketches how this could be used to
acheive transfer without reusing a dialog. achieve transfer without reusing a dialog.
Alice Bob Carol Alice Bob Carol
| | | | | |
| F1 INVITE (Bob's AOR) | | | F1 INVITE (Bob's AOR) | |
| Call-ID: (call-id-one) | | | Call-ID: (call-id-one) | |
| Contact: (Alice's-GRUU) | | | Contact: (Alice's-GRUU) | |
|------------------------------->| | |------------------------------->| |
| F2 200 OK | | | F2 200 OK | |
| To: <>;tag=totag1 | | | To: <>;tag=totag1 | |
| From: <>;tag=fromtag1 | | | From: <>;tag=fromtag1 | |
skipping to change at page 23, line 5 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.
6. Conclusion 6. Security Considerations
Handling multiple usages within a single dialog is complex and
introduces scenarios where the right thing to do is not clear. The
ambiguities described here can result in unexpected disruption of
communication if response codes are chosen carelessly. Furthermore,
these ambiguities could be exploited, particularly by third-parties
injecting unauthenticated requests or inappropriate responses.
Implementations choosing to create or accept multiple usages within a
dialog should give extra attention to the security considerations in
[1], especially those concerning authenticity of requests and
processing of responses.
Service implementations should carefully consider the effects on
their service of peers making different choices in these areas of
ambiguity. A service that requires multiple usages needs to pay
particular attention to the effect on service and network utilization
when a client fails to destroy a dialog the service believes should
be destroyed. A service that disallows multiple usages should
consider the effect on clients that, for instance, destroy the entire
dialog when only a usage should be torn down. In the worst case of a
service deployed into a network with a large number of misbehaving
clients trying to create multiple usages in an automated fashion, a
retry storm similar to an avalanche restart could be induced.
7. IANA Considerations
This document has no actions for IANA.
8. 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.
7. Acknowledgments 9. 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, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate
project also shared their difficulties and discoveries while project also shared their difficulties and discoveries while
implementing multiple-usage dialog handlers. implementing multiple-usage dialog handlers.
8. Informative References 10. 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 23, line 51 skipping to change at page 24, line 34
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-08 (work in progress), June 2006. draft-ietf-sip-gruu-10 (work in progress), August 2006.
[8] Levin, O., "Suppression of Session Initiation Protocol (SIP) [8] Levin, O., "Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription", RFC 4488, May 2006. 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-01->draft-ietf-02 A.1. draft-ietf-02->draft-ietf-03
o Removed discussion of the retargetting affect of provisional
responses - that is a general problem that will now be addressed
in SIP.
o Added a Security Considerations section (blush) summarizing points
from the document and the list discussion.
o Added a no-op IANA Considerations section.
A.2. 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 unchanges 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
MUST (404,410, etc) but on review, I believe they are correct normative must (404,410, etc) but on review, I believe they are
(except for 403) and that this text in 3261 needs to be updated to correct (except for 403) and that this text in 3261 needs to be
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)
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 A.3. 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 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 Uknown 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 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.3. draft-sparks-01->draft-ietf-00 A.4. draft-sparks-01->draft-ietf-00
o Draft rename o Draft rename
A.4. draft-sparks-00->01 A.5. 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 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 stimuted 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.
o Redid the transfer example to not require a GRUU per usage, but o Redid the transfer example to not require a GRUU per usage, but
instead leverage the target-dialog concepts common to Join and instead leverage the target-dialog concepts common to Join and
Replaces. Replaces.
 End of changes. 28 change blocks. 
53 lines changed or deleted 88 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/