draft-ietf-sipping-dialogusage-03.txt   draft-ietf-sipping-dialogusage-04.txt 
Network Working Group R. Sparks Network Working Group R. Sparks
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Expires: March 2, 2007 August 29, 2006 Expires: April 25, 2007 October 22, 2006
Multiple Dialog Usages in the Session Initiation Protocol Multiple Dialog Usages in the Session Initiation Protocol
draft-ietf-sipping-dialogusage-03 draft-ietf-sipping-dialogusage-04
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 March 2, 2007. This Internet-Draft will expire on April 25, 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
an existing dialog. These multiple associations, or dialog usages, an existing dialog. These multiple associations, or dialog usages,
require carefully coordinated processing as they have independent require carefully coordinated processing as they have independent
life-cycles, but share common dialog state. life-cycles, but share common dialog state. Processing multiple
dialog usages correctly is not completely understood. What is
understood is difficult to implement.
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4
2.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 5 3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage Creation and Destruction . . . . . . . . . . . . . . . . 8 3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 7
3.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 8 4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 10
3.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 8 4.1. Invite usages . . . . . . . . . . . . . . . . . . . . . . 10
4. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 8 4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 10
4.1. A survey of the effect of failure responses on usages 5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 10
and dialogs . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. A survey of the effect of failure responses on usages
4.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 15 and dialogs . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Matching requests to usages . . . . . . . . . . . . . . . 16 5.2. Transaction timeouts . . . . . . . . . . . . . . . . . . . 16
4.4. Target refresh requests . . . . . . . . . . . . . . . . . 16 5.3. Matching requests to usages . . . . . . . . . . . . . . . 16
4.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17 5.4. Target refresh requests . . . . . . . . . . . . . . . . . 17
4.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 17 5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 18
4.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 17 5.6. Refusing new usages . . . . . . . . . . . . . . . . . . . 18
5. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18 5.7. Replacing usages . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24 11. Informative References . . . . . . . . . . . . . . . . . . . . 25
A.1. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 24 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.2. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 25 A.1. draft-ietf-03->draft-ietf-04 . . . . . . . . . . . . . . . 26
A.3. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 25 A.2. draft-ietf-02->draft-ietf-03 . . . . . . . . . . . . . . . 26
A.4. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 25 A.3. draft-ietf-01->draft-ietf-02 . . . . . . . . . . . . . . . 26
A.5. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 26 A.4. draft-ietf-00->draft-ietf-01 . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.5. draft-sparks-01->draft-ietf-00 . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 A.6. draft-sparks-00->01 . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Overview
This is an informative document. It makes no normative statements of
any kind. This document refines the concept of a dialog usage in the
Session Initiation Protocol (SIP [1]), and discusses what led to its
existence. It explores ambiguity associated with processing multiple
dialog usages that share a dialog. In particular, it surveys the
effect of SIP failure responses on transaction, dialog usage, and
dialog state. This document will help the implementer understand
what is required to process multiple dialog usages correctly, and
will inform future standards-track work clarifying RFC3261 and
related documents. Finally, the document explores single-usage
dialog alternatives (using SIP extensions) to multiple dialog usages.
2. 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 association 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. Such 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.) Similarly, an endpoint in a dialog established with an
INVITE might subscribe to its peer's KPML [11] and later issue a
REFER, resulting in three dialog usages sharing common dialog state.
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, along with other usage-specific state.
dialog each have their own duration. Multiple subscriptions in the same 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.
A dialog can share up to one invite usage and arbitrarily many A dialog can share up to one invite usage and arbitrarily many
subscribe usages. The pseudo-dialog behavior of REGISTER could be subscribe usages.
considered a third usage. Fortunately, no existing implementations
have attempted to mix a registration usage with any other usage.
2. Examples of Multiple Usages Because RFC3261 [1] states that user-agents should reuse Call-ID and
increment CSeq across a series of registration requests (and that to-
tags appear in register responses in some of the examples), some
implementations have treated REGISTER as if it were in a dialog.
However, RFC3261 explicitly calls out that REGISTER does not create a
dialog. A series of REGISTER requests does not create any usage or
dialog. Similarly, PUBLISH [10] does not create any usage or dialog.
2.1. Transfer 3. Examples of Multiple Usages
3.1. Transfer
In Figure 1, Alice transfers a call she received from Bob to Carol. In Figure 1, Alice transfers a call she received from Bob to Carol.
A dialog (and an invite dialog usage) between Alice and Bob came into A dialog (and an invite dialog usage) between Alice and Bob comes
being with the 200 OK labeled F1. A second usage (a subscription to into being with the 200 OK labeled F1. A second usage (a
event refer) springs into being with the NOTIFY labeled F2. This subscription to event refer) comes into being with the NOTIFY labeled
second usage ends when the subscription is terminated by the NOTIFY F2. This second usage ends when the subscription is terminated by
transaction labeled F3. The dialog still has one usage (the invite the NOTIFY transaction labeled F3. The dialog still has one usage
usage), which lasts until the BYE transaction labeled F4. At this (the invite usage), which lasts until the BYE transaction labeled F4.
point, the dialog has no remaining usages, so it ceases to exist. At this point, the dialog has no remaining usages, so it ceases to
exist. Details of each of these messages are shown in Figure 2.
Alice Bob Carol Alice Bob Carol
| INVITE | | | INVITE | |
|<----------------| | |<----------------| |
Dialog 1 Usage 1 | 200 OK (F1) | | Dialog 1 Usage 1 | 200 OK (F1) | |
-start- -start- ----------->|---------------->| | -start- -start- ----------->|---------------->| |
| | | ACK | | | | | ACK | |
| | |<----------------| | | | |<----------------| |
| | | reINVITE/200/ACK| | | | | reINVITE/200/ACK| |
| | | (hold) | | | | | (hold) | |
skipping to change at page 4, line 45 skipping to change at page 5, line 32
| | | |<----------------| ACK | | | | |<----------------| ACK |
| | | | NOTIFY (F3) |----------->| | | | | NOTIFY (F3) |----------->|
| | | |<----------------| | | | | |<----------------| |
| | | | 200 | . | | | | | 200 | . |
| | -end- -->|---------------->| . | | | -end- -->|---------------->| . |
| | | BYE (F4) | Dialog 2 | | | | BYE (F4) | Dialog 2 |
| | |<----------------| proceeds | | | |<----------------| proceeds |
| | | 200 | . | | | | 200 | . |
-end- -end- ------------>|---------------->| . | -end- -end- ------------>|---------------->| . |
Figure 1
Message Details (abridged to show only dialog or usage details) Message Details (abridged to show only dialog or usage details)
F1 F1
SIP/2.0 200 OK SIP/2.0 200 OK
Call-ID: dialog1@bob.example.com Call-ID: dialog1@bob.example.com
CSeq: 100 INVITE CSeq: 100 INVITE
To: <sip:Alice@alice.example.com>;tag=alicetag1 To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1 From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:aliceinstance@alice.example.com> Contact: <sip:aliceinstance@alice.example.com>
F2 F2
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: refer Event: refer
Call-ID: dialog1@bob.example.com Call-ID: dialog1@bob.example.com
CSeq: 101 NOTIFY CSeq: 101 NOTIFY
To: <sip:Alice@alice.example.com>;tag=alicetag1 To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1 From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com> Contact: <sip:bobinstance@bob.example.com>
F3 F3
skipping to change at page 5, line 35 skipping to change at page 6, line 44
F4 F4
BYE sip:aliceinstance@alice.example.com SIP/2.0 BYE sip:aliceinstance@alice.example.com SIP/2.0
Call-ID: dialog1@bob.example.com Call-ID: dialog1@bob.example.com
CSeq: 103 BYE CSeq: 103 BYE
To: <sip:Alice@alice.example.com>;tag=alicetag1 To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1 From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com> Contact: <sip:bobinstance@bob.example.com>
Figure 1 Figure 2
2.2. Reciprocal Subscription 3.2. Reciprocal Subscription
In Figure 2, Alice subscribes to Bob's presence. For simplicity, In Figure 3, Alice subscribes to Bob's presence. For simplicity,
assume Bob and Alice are both serving their presence from their assume Bob and Alice are both serving their presence from their
endpoints instead of a presence server. For space, the figure leaves endpoints instead of a presence server. To focus on the essential
out any rendezvous signaling through which Alice discovers Bob's points, the figure leaves out any rendezvous signaling through which
endpoint. Alice discovers Bob's endpoint.
Bob is interested in Alice's presence too, so he subscribes to Alice Bob is interested in Alice's presence too, so he subscribes to Alice
(in most deployed presence/IM systems, people watch each other). He (in most deployed presence/IM systems, people watch each other). He
decides skip the rendezvous step since he's already in a dialog with decides to skip the rendezvous step since he's already in a dialog
Alice, and sends his SUBSCRIBE inside that dialog (a few early SIMPLE with Alice, and sends his SUBSCRIBE inside that dialog (a few early
clients behaved exactly this way). SIMPLE clients behaved exactly this way).
The dialog and its first usage comes into being at F1, which The dialog and its first usage comes into being at F1, which
establishes Alice's subscription to Bob. Its second usage begins at establishes Alice's subscription to Bob. Its second usage begins at
F2, which establishes Bob's subscription to Alice. These two F2, which establishes Bob's subscription to Alice. These two
subscriptions are independent - they have distinct and different subscriptions are independent - they have distinct and different
expirations, but they share all the dialog state. expirations, but they share all the dialog state.
The first usage ends when Alice decides to unsubscribe at F3. Bob's The first usage ends when Alice decides to unsubscribe at F3. Bob's
subscription to Alice, and thus the dialog, continues to exist. subscription to Alice, and thus the dialog, continues to exist.
Alice's UA must maintain this dialog state even though the Alice's UA must maintain this dialog state even though the
subscription that caused it to exist in the first place is now over. subscription that caused it to exist in the first place is now over.
The second usage ends when Alice decides to terminate Bob's The second usage ends when Alice decides to terminate Bob's
subscription at F4 (she's probably going to reject any attempt on subscription at F4 (she's probably going to reject any attempt on
Bob's part to resubscribe until she's ready to subscribe to Bob Bob's part to resubscribe until she's ready to subscribe to Bob
again). Since this was the last usage, the dialog also terminates. again). Since this was the last usage, the dialog also terminates.
Details of these messages are shown in Figure 4.
Alice Bob Alice Bob
| | | |
| SUBSCRIBE | | SUBSCRIBE |
|------------------->| |------------------->|
Dialog Usage 1 | NOTIFY (F1) | Dialog Usage 1 | NOTIFY (F1) |
-start- -start- --------->|<-------------------| -start- -start- --------->|<-------------------|
| | | 200 SUBSCRIBE | | | | 200 SUBSCRIBE |
| | |<-------------------| | | |<-------------------|
| | | 200 NOTIFY | | | | 200 NOTIFY |
skipping to change at page 6, line 44 skipping to change at page 8, line 28
| | -start- -->|------------------->| | | -start- -->|------------------->|
| | | | 200 SUBSCRIBE | | | | 200 SUBSCRIBE
| | | |------------------->| | | | |------------------->|
| | | | 200 NOTIFY | | | | | 200 NOTIFY |
| | | |<-------------------| | | | |<-------------------|
| | | | : | | | | | : |
| | | | : | | | | | : |
| | | | (un)SUBSCRIBE (F3) | | | | | (un)SUBSCRIBE (F3) |
| | | |------------------->| | | | |------------------->|
| | | | 200 | | | | | 200 |
| -end- ---------->|<-------------------| | | | |<-------------------|
| | | NOTIFY | | | | | NOTIFY |
| | |<-------------------| | | | |<-------------------|
| | | 200 | | | | | 200 |
| | |------------------->| | -end- ----------->|------------------->|
| | | : | | | | : |
| | | : | | | | : |
| | | NOTIFY (F4) | | | | NOTIFY (F4) |
| | | (Terminated) | | | | (Terminated) |
| | |------------------->| | | |------------------->|
| | | 200 | | | | 200 |
-end- -end- -->|<-------------------| -end- -end- -->|<-------------------|
| | | |
Figure 3
Message Details (abridged to show only dialog or usage details) Message Details (abridged to show only dialog or usage details)
F1 F1
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0 NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: presence Event: presence
Subscription-State: active;expires=600 Subscription-State: active;expires=600
Call-ID: alicecallid1@alice.example.com Call-ID: alicecallid1@alice.example.com
From: <sip:Bob@bob.example.com>;tag=bobtag2 From: <sip:Bob@bob.example.com>;tag=bobtag2
To: <sip:Alice@alice.example.com>;tag=alicetag2 To: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 100 NOTIFY CSeq: 100 NOTIFY
Contact: <sip:bobinstance@bob.example.com> Contact: <sip:bobinstance@bob.example.com>
skipping to change at page 8, line 4 skipping to change at page 9, line 44
F4 F4
NOTIFY sip:bobinstance@bob.example.com SIP/2.0 NOTIFY sip:bobinstance@bob.example.com SIP/2.0
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
3. Usage Creation and Destruction Figure 4
4. Usage Creation and Destruction
Dialogs come into existence 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 4.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
and all its usages and all its usages
3.2. Subscribe usages 4.2. Subscribe usages
Created by: 200 class responses to SUBSCRIBE; 200 class responses to Created by: 200 class responses to SUBSCRIBE; 200 class responses to
REFER; NOTIFY requests REFER; NOTIFY requests
Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or
refresh-SUBSCRIBE request timeout; certain failure responses to refresh-SUBSCRIBE request timeout; certain failure responses to
NOTIFY or SUBSCRIBE; anything that destroys a dialog and all its NOTIFY or SUBSCRIBE; expiration without refresh if network issues
usages prevent the terminal NOTIFY from arriving; anything that destroys
a dialog and all its usages
4. Proper Handling of Multiple Usages 5. Proper Handling of Multiple Usages
The examples in Section 2 show straightforward cases where it is The examples in Section 3 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. areas with multiple usages that have been identified to date.
4.1. A survey of the effect of failure responses on usages and dialogs 5.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). Further, unless as a transferee issuing a NOTIFY to event refer). Further, unless
otherwise stated, the conclusions apply to arbitrary multiple-usages. 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.
400 and unrecognized 4xx responses: These responses affect only the For the failure responses with code 400 and greater, there are three
NOTIFY transaction, not the subscription, the dialog it resides in common ways the failure can affect the transaction, usage, and dialog
(beyond affecting the local CSeq), or any other usage of that state.
dialog. In general, the response is a complaint about this Transaction Only The error affects only the transaction, not the
transaction, not the usage or dialog the transaction occurs in. usage or dialog the transaction occurs in (beyond affecting the
local CSeq). Any other usage of the dialog is unaffected. The
error is a complaint about this transaction, not the usage or
dialog the transaction occurs in.
Destroys Usage The error destroys the usage, but not dialog. Any
other usages sharing this dialog are not affected.
The error destroys the dialog and all usages sharing it.
401 Unauthorized ,407 Proxy Authentication Required: This request, Table 1 displays how the various codes affect transaction, usage, or
not the subscription or dialog, is being challenged. The usages dialog state. Response code specific comments (noted with *) or
and dialog are not terminated. exceptions (noted with **) follow the table.
+-----------------------+----------------+------------------+
| Transaction Only | Destroys Usage | Destroys Dialog |
+-----------------------+----------------+------------------+
| 400 (or unknown 4xx) | 405*, 480* | 404*, 410*, 416* |
| 401, 402*, 403, 406 | 481*, 489** | 482*, 483** |
| 407, 408*, 412-415 | 501* | 484*, 485* |
| 417, 420, 421, 422* | | 502*, 604* |
| 423, 428, 429* | | |
| 436-438, 486*, 487 | | |
| 488, 491, 493, 494 | | |
| 500 (or unknown 5xx)* | | |
| 503*, 504*, 505, 513 | | |
| 580 | | |
| 600 (or unknown 6xx)* | | |
| 603*, 606 | | |
+-----------------------+----------------+------------------+
Table 1
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 concerns the transaction, not the usage.
It has no effect on any other usages of the dialog. In our
example scenario, the subscription remains, and is not affected in
any way. The invite usage continues to exist. Similarly, if the
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
come as a result to something that creates subscription. In come as a result to something that creates subscription. In
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
the transaction. Subsequent requests in this same usage may
succeed. Neither the usage nor dialog is terminated, other usages
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 4.2. Section 5.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:
413 Request Entity Too Large:
414 Request-URI Too Long:
415 Unsupported Media Type: These responses concern details of the
message in the transaction. Subsequent requests in this same
usage may succeed. Neither the usage nor dialog is terminated,
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 Unknown Resource-Priority: The effect of this response on usages
and dialogs is analogous 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
objecting 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.
422 Session Interval Too Small: This response 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 does not make a NOTIFY in our example scenario. This response does not make
sense for any mid-usage request. If it is received, an element in sense for any mid-usage request. If it is received, an element in
the path of the request is violating protocol, and the recipient the path of the request is violating protocol, and the recipient
should treat this as it would an unknown 4xx response. If the should treat this as it would an unknown 4xx response. 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
scenario, but if it came in response to a reSUBSCRIBE, the
subscribe usage is not destroyed (or otherwise affected). No
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 only to the REFER request itself. Any REFER, it is objecting only to the REFER request itself. Any
usages sharing this dialog with that REFER request are unaffected. usages sharing this dialog with that REFER request are unaffected.
The dialog is only affected by a change in its local CSeq. The dialog is only 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. Future updates to that
made to show that this response affects only the usage in which specification are expected to clarify that this response affects
the request occurs. No other usages are affected. If the only the usage in which the request occurs. No other usages are
response included a Retry-After header field, further requests in affected. If the response included a Retry-After header field,
that usage should not be sent until the indicated time has past. further requests in that usage should not be sent until the
Requests in other usages may still be sent at any time. indicated time has past. 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 usage state. The dialog peer has lost its copy of the dialog usage state. The dialog
itself should not be destroyed unless this was the last usage. itself should not be destroyed unless this was the last usage.
The effects of a 481 on a dialog and its usages are the most The effects of a 481 on a dialog and its usages are the most
ambiguous of any final response. There are implementations that ambiguous of any final response. There are implementations that
have chosen the meaning recommended here, and others that destroy have chosen the meaning recommended here, and others that destroy
the entire dialog without regard to the number of outstanding the entire dialog without regard to the number of outstanding
usages. Going forward with this clarification will allow those usages. Going forward with this clarification will allow those
deployed implementations that assumed only the usage was destroyed deployed implementations that assumed only the usage was destroyed
skipping to change at page 13, line 5 skipping to change at page 14, line 32
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.
487 Request Terminated: This response speaks to the disposition of a
particular request (transaction). The usage in which that request
occurs is not affected by this response (it may be affected by
another associated request within that usage). No other usages
sharing this dialog are affected.
488 Not Acceptable Here: This response is objecting 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.
489 Bad Event: In our example scenario, [3] declares that the 489 Bad Event: In our example scenario, [3] declares that the
subscription usage in which the NOTIFY is sent is terminated. The subscription usage in which the NOTIFY is sent is terminated. The
invite usage is unaffected and the dialog continues to exist. invite usage is unaffected and the dialog continues to exist.
This response is only valid in the context of SUBSCRIBE and This response is only valid in the context of SUBSCRIBE and
NOTIFY. UAC behavior for receiving this response to other methods NOTIFY. UAC behavior for receiving this response to other methods
is not specified, but treating it as an unknown 4xx is a is not specified, but treating it as an unknown 4xx is a
reasonable practice. reasonable practice.
491 Request Pending: This response addresses in-dialog request glare.
Its affect is scoped to the request. The usage in which the
request occurs is not affected. The dialog is only affected by
the change in its local CSeq. No other usages sharing this dialog
are affected.
493 Undecipherable: 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.
494 Security Agreement Required: This response is objecting 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.
500 and 5xx unrecognized responses: These responses are complaints 500 and 5xx unrecognized responses: These responses are complaints
against the request (transaction), not the usage. If the response against the request (transaction), not the usage. If the response
contains a Retry-After header field value, the server thinks the contains a Retry-After header field value, the server thinks the
condition is temporary and the request can be retried after the condition is temporary and the request can be retried after the
indicated interval. This usage, and any other usages sharing the indicated interval. This usage, and any other usages sharing the
dialog are unaffected. If the response does not contain a Retry- dialog are unaffected. If the response does not contain a Retry-
After header field value, the UA may decide to retry after an After header field value, the UA may decide to retry after an
interval of its choosing or attempt to gracefully terminate the interval of its choosing or attempt to gracefully terminate the
usage. Whether or not to terminate other usages depends on the usage. Whether or not to terminate other usages depends on the
application. If the UA receives a 500 (or unrecognized 5xx) in application. If the UA receives a 500 (or unrecognized 5xx) in
skipping to change at page 14, line 32 skipping to change at page 15, line 32
503 Service Unavailable: As per [2], the logic handling locating SIP 503 Service Unavailable: As per [2], the logic handling locating SIP
servers for transactions may handle 503 requests (effectively servers for transactions may handle 503 requests (effectively
sequentially forking at the endpoint based on DNS results). If sequentially forking at the endpoint based on DNS results). If
this process does not yield a better response, a 503 may be this process does not yield a better response, a 503 may be
returned to the transaction user. Like a 500 response, the error returned to the transaction user. Like a 500 response, the error
is a complaint about this transaction, not the usage. Because is a complaint about this transaction, not the usage. Because
this response occurred in the context of an established usage this response occurred in the context of an established usage
(hence an existing dialog), the route-set has already been formed (hence an existing dialog), the route-set has already been formed
and any opportunity to try alternate servers (as recommended in and any opportunity to try alternate servers (as recommended in
[1] has been exhausted by the RFC3263 logic. The response should [1]) has been exhausted by the RFC3263 logic. The response should
be handled as described for 500 earlier in this memo. be handled as described for 500 earlier in this memo.
504 Server Time-out: It is not obvious under what circumstances this 504 Server Time-out: It is not obvious under what circumstances this
response would be returned to a request in an existing dialog. If response would be returned to a request in an existing dialog. If
it occurs it should have the same affect on the dialog and its it occurs it should have the same affect on the dialog and its
usages as described for unknown 5xx responses. usages as described for unknown 5xx responses.
505 Version Not Supported, 513 Message Too Large: These responses are
objecting 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.
580 Precondition Failure: This response is objecting 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.
600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a 600
response code says something about the recipient user, not the response code says something about the recipient user, not the
request that was made. This end user is stating an unwillingness request that was made. This end user is stating an unwillingness
to communicate. If the response contains a Retry-After header to communicate. If the response contains a Retry-After header
field value, the user is indicating willingness to communicate field value, the user is indicating willingness to communicate
later and the request can be retried after the indicated interval. later and the request can be retried after the indicated interval.
This usage, and any other usages sharing the dialog are This usage, and any other usages sharing the dialog are
unaffected. If the response does not contain a Retry-After header unaffected. If the response does not contain a Retry-After header
field value, the UA may decide to retry after an interval of its field value, the UA may decide to retry after an interval of its
choosing or attempt to gracefully terminate the usage. Whether or choosing or attempt to gracefully terminate the usage. Whether or
skipping to change at page 15, line 28 skipping to change at page 16, line 15
terminated. If this is the last usage sharing the dialog, the terminated. If this is the last usage sharing the dialog, the
dialog is also terminated. dialog is also terminated.
603 Decline: This response declines the action indicated by the 603 Decline: This response declines the action indicated by the
associated request. It can be used, for example, to decline a associated request. It can be used, for example, to decline a
hold or transfer attempt. Receiving this response does NOT hold or transfer attempt. Receiving this response does NOT
terminate the usage it occurs in. Other usages sharing the dialog terminate the usage it occurs in. Other usages sharing the dialog
are unaffected. are unaffected.
604 Does Not Exist Anywhere: Like 404, this response destroys the 604 Does Not Exist Anywhere: Like 404, this response destroys the
dialog and all usages sharing it. The Request-URI that is being dialog and all usages sharing it. The Request-URI in the request
604ed is the remote target set by the Contact provided by the is the remote target set by the Contact provided by the peer.
peer. Getting this response means something has gone Getting this response means something has gone fundamentally wrong
fundamentally wrong with the dialog state. with the dialog state.
606 Not Acceptable: This response is objecting to aspects of the
associated request, not the usage the request appears in. The
usage is unaffected. Any other usages sharing the dialog are
unaffected. The only affect on the dialog is the change in the
local CSeq.
4.2. Transaction timeouts 5.2. Transaction timeouts
[1] states that a UAC should terminate a dialog (by sending a BYE) if [1] states that a UAC should terminate a dialog (by sending a BYE) if
no response is received for a request sent within a dialog. This no response is received for a request sent within a dialog. This
recommendation should have been limited to the invite usage instead recommendation should have been limited to the invite usage instead
of the whole dialog. [3] states that a timeout for a NOTIFY removes a of the whole dialog. [3] states that a timeout for a NOTIFY removes a
subscription, but a SUBSCRIBE that fails with anything other than a subscription, but a SUBSCRIBE that fails with anything other than a
481 does not. Given these statements, it is unclear whether a 481 does not. Given these statements, it is unclear whether a
refresh SUBSCRIBE issued in a dialog shared with an invite usage refresh SUBSCRIBE issued in a dialog shared with an invite usage
destroys either usage or the dialog if it times out. destroys either usage or the dialog if it times out.
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.
4.3. Matching requests to usages 5.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 4.1 and Section 4.2 that destroy entire dialogs will have in Section 5.1 and Section 5.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 way, against the standard recommendation). A failed MESSAGE
occurring inside an existing dialog will have similar effects on the occurring inside an existing dialog will have similar effects on the
dialog and 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.
4.4. Target refresh requests 5.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.
4.5. Refreshing and Terminating Usages There is known ambiguity around the effects of provisional responses
on remote targets that future specification will attempt to clarify.
Furthermore, because the remote target is part of the dialog state,
not any usage state, there is ambiguity in having target refresh
requests in progress simultaneously on multiple usages in the same
dialog. Implementation designers should consider these conditions
with care.
5.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.
4.6. Refusing new usages 5.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 5.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.
5. Avoiding Multiple Usages 6. 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 or features that use SIP dialogs, do
construct multiple usages. If a peer attempts to create a second not require endpoints to construct multiple usages to participate in
usage inside a dialog, refuse it. the application or use the feature. When designing endpoints,
address the existing multiple usage scenarios as best as possible.
Outside those scenarios, if a peer attempts to create a second usage
inside a dialog, refuse it.
Unfortunately, there are existing applications, like transfer, that Unfortunately, there are existing applications, like transfer, that
currently entail multiple usages, so the simple solution of "don't do currently entail multiple usages, so the simple solution of "don't do
it" will require some transitional work. This section looks at the it" will require some transitional work. This section looks at the
pressures that led to these existing multiple usages and suggests pressures that led to these existing multiple usages and suggests
alternatives. alternatives.
When executing a transfer, the transferor and transferee currently When executing a transfer, the transferor and transferee currently
share an invite usage and a subscription usage within the dialog share an invite usage and a subscription usage within the dialog
between them. This is a result of sending the REFER request within between them. This is a result of sending the REFER request within
the dialog established by the invite usage. Implementations were led the dialog established by the invite usage. Implementations were led
to this behavior by two primary pressures: to this behavior by these primary pressures:
1. There was no way to ensure that a REFER on a new dialog would 1. There was no way to ensure that a REFER on a new dialog would
reach the particular endpoint involved in a transfer. Many reach the particular endpoint involved in a transfer. Many
factors, including details of implementations and changes in factors, including details of implementations and changes in
proxy routing between an INVITE and a REFER could cause the REFER proxy routing between an INVITE and a REFER could cause the REFER
to be sent to the wrong place. Sending the REFER down the to be sent to the wrong place. Sending the REFER down the
existing dialog ensured it got to the endpoint we were already existing dialog ensured it got to the same endpoint with which
talking to. the dialog was established.
2. It was unclear how to associate an existing invite usage with a 2. It was unclear how to associate an existing invite usage with a
REFER arriving on a new dialog, where it was completely obvious REFER arriving on a new dialog, where it was completely obvious
what the association was when the REFER came on the invite what the association was when the REFER came on the invite
usage's dialog. usage's dialog.
3. There were concerns with authorizing out-of-dialog REFERs. The 3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases, on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call"). based simply on "I placed or answered this call").
GRUUs [7] have been defined specifically to address problem 1. GRUUs [7] have been defined specifically to address problem 1 by
Problem 2 can be addressed using a GRUU's grid parameter. However, providing a URI that will reach one specific user-agent. The Target-
this approach requires endpoints to create and maintain a GRUU per Dialog header field [9] was created to address problems 2 and 3.
dialog, something the working group is not comfortable recommending. This header field allows a request to indicate the dialog identifiers
of some other dialog, providing association with that other dialog
that can be used in an authorization decision.
The Join [5] and Replaces [6] mechanisms address problem 1 The Join [5] and Replaces [6] mechanisms can also be used to address
differently. Here, a new request is sent outside any dialog with the problem 1. When using this technique, a new request is sent outside
expectation that it will fork to possibly many endpoints, including any dialog with the expectation that it will fork to possibly many
the one we're interested in. This request contains a header field endpoints, including the one we're interested in. This request
listing the dialog identifiers of a dialog in progress. Only the contains a header field listing the dialog identifiers of a dialog in
endpoint holding a dialog matching those identifiers will accept the progress. Only the endpoint holding a dialog matching those
request. The other endpoints the request may have forked to will identifiers will accept the request. The other endpoints the request
respond with an error. This mechanism is reasonably robust, failing may have forked to will respond with an error. This mechanism is
only when the routing logic for out-of-dialog requests changes such reasonably robust, failing only when the routing logic for out-of-
that the new request does not arrive at the endpoint holding the dialog requests changes such that the new request does not arrive at
dialog of interest. the endpoint holding the 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 and Target-Dialog mechanisms. A REFER request sent out-of-
towards a GRUU, and identify an existing dialog as part of the dialog can be sent towards a GRUU, and identify an existing dialog as
context the receiver should use. A new header, Target-Dialog: part of the context the receiver should use. The Target-Dialog
perhaps, would be included in the REFER listing the dialog this REFER header field can be included in the REFER listing the dialog this
is associated with. Figure 3 sketches how this could be used to REFER is associated with. Figure 5 sketches how this could be used
achieve transfer without reusing a dialog. to achieve transfer without reusing a dialog. For simplicity, the
diagram and message details do not show the server at example.com
that will be involved in routing the GRUU. Refer to [7] for those
details.
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 | |
| Call-ID: (call-id one) | | | Call-ID: (call-id one) | |
| Contact: (Bob's-GRUU) | | | Contact: (Bob's-GRUU) | |
|<-------------------------------| | |<-------------------------------| |
| ACK | | | ACK | |
|------------------------------->| | |------------------------------->| |
skipping to change at page 20, line 25 skipping to change at page 21, line 23
|<-------------------------------| | |<-------------------------------| |
| 202 Accepted | | | 202 Accepted | |
|------------------------------->| | |------------------------------->| |
| NOTIFY (Bob's-GRUU) | | | NOTIFY (Bob's-GRUU) | |
| Call-ID: (call-id three) | | | Call-ID: (call-id three) | |
|------------------------------->| | |------------------------------->| |
| 200 OK | | | 200 OK | |
|<-------------------------------| | |<-------------------------------| |
| | | | | |
| F6 INVITE (Carol's-GRUU) | | F6 INVITE (Carol's-GRUU) |
| Call-ID: (call-id-four) | | Call-ID: (call-id four) |
| Contact: (Alice's-GRUU) | | Contact: (Alice's-GRUU) |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| 200 OK | | 200 OK |
| Contact: (Carol's-GRUU) | | Contact: (Carol's-GRUU) |
|<--------------------------------------------------------------| |<--------------------------------------------------------------|
| ACK | | ACK |
|-------------------------------------------------------------->| |-------------------------------------------------------------->|
| | | | | |
| F7 NOTIFY (Bob's-GRUU) | | | F7 NOTIFY (Bob's-GRUU) | |
| Call-ID: (call-id three) | | | Call-ID: (call-id three) | |
skipping to change at page 20, line 48 skipping to change at page 21, line 46
|<-------------------------------| | |<-------------------------------| |
| BYE (Alice's-GRUU) | | | BYE (Alice's-GRUU) | |
| Call-ID: (call-id one) | | | Call-ID: (call-id one) | |
|<-------------------------------| BYE (Carol's-GRUU) | |<-------------------------------| BYE (Carol's-GRUU) |
| | Call-ID: (call-id two) | | | Call-ID: (call-id two) |
| 200 OK |----------------------------->| | 200 OK |----------------------------->|
|------------------------------->| 200 OK | |------------------------------->| 200 OK |
| |<-----------------------------| | |<-----------------------------|
| | | | | |
Figure 3: Transfer without dialog reuse Figure 5: Transfer without dialog reuse
In message F1, Alice invites Bob indicating support for GRUUs (and In message F1, Alice invites Bob indicating support for GRUUs (and
offering a GRUU for herself): offering a GRUU for herself):
Message F1 (abridged, detailing pertinent fields) Message F1 (abridged, detailing pertinent fields)
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Call-ID: 13jfdwer230jsdw@alice.example.com Call-ID: 13jfdwer230jsdw@alice.example.com
Supported: gruu Supported: gruu
Contact: <sip:aanewmr203raswdf@example.com> Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Message F2 lets Alice know that Bob understands GRUUs. If Bob did Message F2 lets Alice know that Bob understands GRUUs. If Bob did
not indicate this support, the original multi-usage approach to not indicate this support, the original multi-usage approach to
transfer would have to be used. transfer would have to be used.
Message F2 (abridged, detailing pertinent fields) Message F2 (abridged, detailing pertinent fields)
SIP/2.0 200 OK SIP/2.0 200 OK
Supported: gruu Supported: gruu
To: <sip:bob@example.com>;tag=totag1 To: <sip:bob@example.com>;tag=totag1
From: <sip:alice@example.com>;tag=fromtag1 From: <sip:alice@example.com>;tag=fromtag1
Contact: <sip:boaiidfjjereis@example.com> Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Bob decides to try to transfer Alice to Carol, so he puts Alice on Bob decides to try to transfer Alice to Carol, so he puts Alice on
hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU
support similar to what happened in F1 and F2. support similar to what happened in F1 and F2.
Message F3 (abridged, detailing pertinent fields) Message F3 (abridged, detailing pertinent fields)
INVITE sip:carol@example.com SIP/2.0 INVITE sip:carol@example.com SIP/2.0
Supported: gruu Supported: gruu
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:boaiidfjjereis@example.com> Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Message F4 (abridged, detailing pertinent fields) Message F4 (abridged, detailing pertinent fields)
SIP/2.0 200 OK SIP/2.0 200 OK
Supported: gruu Supported: gruu
To: <sip:carol@example.com>;tag=totag2 To: <sip:carol@example.com>;tag=totag2
From: <sip:bob@example.com>;tag=fromtag2 From: <sip:bob@example.com>;tag=fromtag2
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:c239fniuweorw9sdfn@example.com> Contact: <sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)>
After consulting Carol, Bob places her on hold and refers Alice to After consulting Carol, Bob places her on hold and refers Alice to
her using message F5. Notice that the Refer-To URI is Carol's GRUU, her using message F5. Notice that the Refer-To URI is Carol's GRUU,
and that this is on a different Call-ID than message F1. (The URI in and that this is on a different Call-ID than message F1. (The URI in
the Refer-To header is line-broken for readability in this draft, it the Refer-To header is line-broken for readability in this draft, it
would not be valid to break the URI this way in a real message) would not be valid to break the URI this way in a real message)
Message F5 (abridged, detailing pertinent fields) Message F5 (abridged, detailing pertinent fields)
REFER sip:aanewmr203raswdf@example.com SIP/2.0 REFER sip:aanewmr203raswdf@example.com SIP/2.0
Call-ID: 39fa99r0329493asdsf3n@bob.example.com Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Refer-To: <sip:c239fniuweorw9sdfn@example.com Refer-To: <sip:carol@example.com;g=urn:uid:(Carol's UA's bits)
?Replaces=23rasdnfoa39i4jnasdf@bob.example.com; ?Replaces=23rasdnfoa39i4jnasdf@bob.example.com;
to-tag=totag2;from-tag=fromtag2> to-tag=totag2;from-tag=fromtag2>
Target-Dialog: 13jfdwer230jsdw@alice.example.com; Target-Dialog: 13jfdwer230jsdw@alice.example.com;
local-tag=fromtag1;remote-tag=totag1 local-tag=fromtag1;remote-tag=totag1
Supported: gruu Supported: gruu
Contact: <sip:boaiidfjjereis@example.com> Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
Alice uses the information in the Target-Dialog header field to Alice uses the information in the Target-Dialog header field to
determine that this REFER is associated with the dialog she already determine that this REFER is associated with the dialog she already
has in place with Bob. Alice is now in a position to use the same has in place with Bob. Alice is now in a position to use the same
admission policy she used for in-dialog REFERs: "Do I have a call admission policy she used for in-dialog REFERs: "Do I have a call
with this person?". She accepts the REFER. sends Bob the obligatory with this person?". She accepts the REFER. sends Bob the obligatory
immediate NOTIFY, and proceeds to INVITE Carol with message F6. immediate NOTIFY, and proceeds to INVITE Carol with message F6.
Message F6 (abridged, detailing pertinent fields) Message F6 (abridged, detailing pertinent fields)
INVITE sip:c239fniuweorw9sdfn@example.com SIP/2.0 sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)
\ /
\ /
| |
v v
INVITE SIP/2.0
Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com
Replaces: 23rasdnfoa39i4jnasdf@bob.example.com; Replaces: 23rasdnfoa39i4jnasdf@bob.example.com;
to-tag=totag2;from-tag=fromtag2 to-tag=totag2;from-tag=fromtag2
Supported: gruu Supported: gruu
Contact: <sip:aanewmr203raswdf@example.com> Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Carol accepts Alice's invitation to replace her dialog (invite usage) Carol accepts Alice's invitation to replace her dialog (invite usage)
with Bob and notifies him that the REFERenced INVITE succeeded with with Bob and notifies him that the REFERenced INVITE succeeded with
F7: F7:
Message F7 (abridged, detailing pertinent fields) Message F7 (abridged, detailing pertinent fields)
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:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
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. Security Considerations 7. Security Considerations
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. The introduces scenarios where the right thing to do is not clear. The
ambiguities described here can result in unexpected disruption of ambiguities described here can result in unexpected disruption of
communication if response codes are chosen carelessly. Furthermore, communication if response codes are chosen carelessly. Furthermore,
these ambiguities could be exploited, particularly by third-parties these ambiguities could be exploited, particularly by third-parties
injecting unauthenticated requests or inappropriate responses. injecting unauthenticated requests or inappropriate responses.
Implementations choosing to create or accept multiple usages within a Implementations choosing to create or accept multiple usages within a
dialog should give extra attention to the security considerations in dialog should give extra attention to the security considerations in
[1], especially those concerning authenticity of requests and [1], especially those concerning authenticity of requests and
skipping to change at page 23, line 30 skipping to change at page 24, line 31
ambiguity. A service that requires multiple usages needs to pay ambiguity. A service that requires multiple usages needs to pay
particular attention to the effect on service and network utilization particular attention to the effect on service and network utilization
when a client fails to destroy a dialog the service believes should when a client fails to destroy a dialog the service believes should
be destroyed. A service that disallows multiple usages should be destroyed. A service that disallows multiple usages should
consider the effect on clients that, for instance, destroy the entire 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 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 service deployed into a network with a large number of misbehaving
clients trying to create multiple usages in an automated fashion, a clients trying to create multiple usages in an automated fashion, a
retry storm similar to an avalanche restart could be induced. retry storm similar to an avalanche restart could be induced.
7. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Conclusion 9. 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.
9. Acknowledgments 10. 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.
10. Informative References 11. 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.
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
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
(UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Agent (UA) URIs (GRUU) in the Session Initiation Protocol
draft-ietf-sip-gruu-10 (work in progress), August 2006. (SIP)", 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.
[9] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[10] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[11] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)",
draft-ietf-sipping-kpml-08 (work in progress), July 2006.
Appendix A. Change Log Appendix A. Change Log
RFC-EDITOR: Please remove this entire Change Log section while RFC-EDITOR: Please remove this entire Change Log section while
formatting this document for publication. formatting this document for publication.
A.1. draft-ietf-02->draft-ietf-03 A.1. draft-ietf-03->draft-ietf-04
o Many minor editorial fixes addressing WGLC comments
o Aligned with changes to GRUU
o Added a short overview
o Added a table summarizing the survey of responses and removed the
description from those responses that were not exceptional.
A.2. draft-ietf-02->draft-ietf-03
o Removed discussion of the retargetting affect of provisional o Removed discussion of the retargetting affect of provisional
responses - that is a general problem that will now be addressed responses - that is a general problem that will now be addressed
in SIP. in SIP.
o Added a Security Considerations section (blush) summarizing points o Added a Security Considerations section (blush) summarizing points
from the document and the list discussion. from the document and the list discussion.
o Added a no-op IANA Considerations section. o Added a no-op IANA Considerations section.
A.2. draft-ietf-01->draft-ietf-02 A.3. draft-ietf-01->draft-ietf-02
o Incorporated editorial-fix contributions from the list o Incorporated editorial-fix contributions from the list
o Noted that REFERs using norefersub (RFC4488) don't create a new o Noted that REFERs using norefersub (RFC4488) don't create a new
subscribe usage subscribe usage
o Changed the affect of 403 to affect only the transaction, not the o Changed the affect of 403 to affect only the transaction, not the
usage. This is motivated by text in 3261 (bottom of page 87 - usage. This is motivated by text in 3261 (bottom of page 87 -
pointed out by Brian Stucker) which states that a UA receiving a pointed out by Brian Stucker) which states that a UA receiving a
non-2xx final response to a re-INVITE must leave the session non-2xx final response to a re-INVITE must leave the session
parameters unchanged as if the re-INVITE had not been issued. parameters unchanged as if the re-INVITE had not been issued.
There are other recommendations in this document that violate that There are other recommendations in this document that violate that
normative must (404,410, etc) but on review, I believe they are normative must (404,410, etc) but on review, I believe they are
correct (except for 403) and that this text in 3261 needs to be correct (except for 403) and that this text in 3261 needs to be
updated to recognize the conditions under which they're sent. updated to recognize the conditions under which they're sent.
o Added text concerning the race condition wherein endpoints failing o Added text concerning the race condition wherein endpoints failing
over rapidly to 3263 destinations may stimulate a merged-request over rapidly to 3263 destinations may stimulate a merged-request
response. response.
o Corrected the 481 inconsistency Paul Kyzivat pointed out (by o Corrected the 481 inconsistency Paul Kyzivat pointed out (by
removing the inconsistent paragraph) removing the inconsistent paragraph)
A.3. draft-ietf-00->draft-ietf-01 A.4. draft-ietf-00->draft-ietf-01
o Changed 481 to only affect the usage the response occurred in, o Changed 481 to only affect the usage the response occurred in,
closing the last open issue. Added some text justifying this closing the last open issue. Added some text justifying this
recommendation. recommendation.
o Added 422 Session Interval Too Small o Added 422 Session Interval Too Small
o Added 417 Unknown Resource-Priority o Added 417 Unknown Resource-Priority
o Added 428 Use Identity Header o Added 428 Use Identity Header
o Added 436 Bad Identity-Info o Added 436 Bad Identity-Info
o Added 437 Unsupported Certificate o Added 437 Unsupported Certificate
o Added 438 Invalid Identity header o Added 438 Invalid Identity header
o Added a section categorizing messages that create and destroy o Added a section categorizing messages that create and destroy
usages usages
o Made sure all descriptions in Section 4 addressed the generic o Made sure all descriptions in Section 5 addressed the generic
multi-usage case. multi-usage case.
o Clarified that the mechanics described in matching messages to o Clarified that the mechanics described in matching messages to
usages applied equally to UACs and UASs. usages applied equally to UACs and UASs.
o More explicitly noted that REFER creates a subscribe-usage o More explicitly noted that REFER creates a subscribe-usage
A.4. draft-sparks-01->draft-ietf-00 A.5. draft-sparks-01->draft-ietf-00
o Draft rename o Draft rename
A.5. draft-sparks-00->01 A.6. draft-sparks-00->01
o Changed 480 to affect only the usage the response occurred in. o Changed 480 to affect only the usage the response occurred in.
o Closed the open issue on 482. Usages and dialogs are destroyed o Closed the open issue on 482. Usages and dialogs are destroyed
even though there is an edge condition in which the response is even though there is an edge condition in which the response is
only stimulated by certain methods (due to method specific routing only stimulated by certain methods (due to method specific routing
rules). rules).
o Closed the open issue on 483. Usages are not terminated since the o Closed the open issue on 483. Usages are not terminated since the
request might succeed if retried with a greater initial Max- request might succeed if retried with a greater initial Max-
Forwards Forwards
o Closed the open issue on 502, accepting -00s suggestion that the o Closed the open issue on 502, accepting -00s suggestion that the
same reasoning used for 482 applies. same reasoning used for 482 applies.
 End of changes. 90 change blocks. 
247 lines changed or deleted 258 lines changed or added

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