draft-ietf-sipping-dialog-package-05.txt   draft-ietf-sipping-dialog-package-06.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: May 5, 2005 H. Schulzrinne Expires: October 11, 2005 H. Schulzrinne
Columbia University Columbia University
R. Mahy, Ed. R. Mahy, Ed.
Airespace SIP Edge LLC
Nov 4, 2004 Apr 12, 2005
An INVITE Inititiated Dialog Event Package for the Session An INVITE Inititiated Dialog Event Package for the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipping-dialog-package-05.txt draft-ietf-sipping-dialog-package-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2005. This Internet-Draft will expire on October 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a dialog event package for the SIP Events This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in. =0C
user, and receive notifications about the changes in state of INVITE
initiated dialog usages that the user is involved in.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5
3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8
3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . 9 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . 9
3.7.2 Applying the state machine . . . . . . . . . . . . . . 12 3.7.2 Applying the state machine . . . . . . . . . . . . . . 12
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14
4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14 4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14
4.1 Structure of Dialog Information . . . . . . . . . . . . . 14 4.1 Structure of Dialog Information . . . . . . . . . . . . . 14
4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 4 skipping to change at page 3, line 4
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24 6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27 6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27
6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31 6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1 application/dialog-info+xml MIME Registration . . . . . . 33 8.1 application/dialog-info+xml MIME Registration . . . . . . 33
8.2 URN Sub-Namespace Registration for 8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33
8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34
=0C
8.4 Media Feature Parameter Registration . . . . . . . . . . . 34 8.4 Media Feature Parameter Registration . . . . . . . . . . . 34
8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34 8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34
8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35 8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
10.2 Informative References . . . . . . . . . . . . . . . . . . . 37 10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . 39
=0C
1. Introduction 1. Introduction
The SIP Events framework [1] defines general mechanisms for The SIP Events framework [1] defines general mechanisms for
subscription to, and notification of, events within SIP networks. It subscription to, and notification of, events within SIP networks. It
introduces the notion of a package, which is a specific introduces the notion of a package, which is a specific
"instantiation" of the events mechanism for a well-defined set of "instantiation" of the events mechanism for a well-defined set of
events. Packages have been defined for user presence [16], watcher events. Packages have been defined for user presence [16], watcher
information [17], and message waiting indicators [18], amongst information [17], and message waiting indicators [18], amongst
others. Here, we define an event package for INVITE initiated others. Here, we define an event package for INVITE initiated dialog
dialogs. Dialogs refer to the SIP relationship established between usages. Dialogs refer to the SIP relationship established between
two SIP peers [2]. Dialogs can be created by many methods, although two SIP peers [2]. Dialogs can be created by many methods, although
RFC 3261 defines only one - the INVITE method. RFC 3265 defines the RFC 3261 defines only one - the INVITE method. RFC 3265 defines the
SUBSCRIBE and NOTIFY methods, which also create dialogs. However, SUBSCRIBE and NOTIFY methods, which also create new dialog usages.
the usage of this package to model transitions in the state of those However, the usage of this package to model transitions in the state
dialogs is out of the scope of this specification. of those dialog usages are out of the scope of this specification.
There are a variety of applications enabled through the knowledge of There are a variety of applications enabled through the knowledge of
INVITE dialog state. Some examples include: INVITE dialog usage state. Some examples include:
Automatic Callback: In this basic Public Switched Telephone Network Automatic Callback: In this basic Public Switched Telephone Network
(PSTN) application, user A calls user B. User B is busy. User A (PSTN) application, user A calls user B. User B is busy. User A
would like to get a callback when user B hangs up. When B hangs would like to get a callback when user B hangs up. When B hangs
up, user A's phone rings. When A picks it up, they here ringing, up, user A's phone rings. When A picks it up, they here ringing,
and are being connected to B. To implement this with SIP, a and are being connected to B. To implement this with SIP, a
mechanism is required for B to receive a notification when the mechanism is required for B to receive a notification when the
dialogs at A are complete. dialogs at A are complete.
Presence-Enabled Conferencing: In this application, a user A wishes Presence-Enabled Conferencing: In this application, a user A wishes
to set up a conference call with users B and C. Rather than to set up a conference call with users B and C. Rather than
scheduling it, it is to be created automatically when A, B and C scheduling it, it is to be created automatically when A, B and C
skipping to change at page 5, line 4 skipping to change at page 5, line 4
distributed way; the server need not reside in the same domain as distributed way; the server need not reside in the same domain as
the users. the users.
IM Conference Alerts: In this application, a user can get an Instant IM Conference Alerts: In this application, a user can get an Instant
Message (IM) sent to their phone whenever someone joins a Message (IM) sent to their phone whenever someone joins a
conference that the phone is involved in. The IM alerts are conference that the phone is involved in. The IM alerts are
generated by an application separate from the conference server. generated by an application separate from the conference server.
In general, the dialog package allows for construction of distributed In general, the dialog package allows for construction of distributed
applications, where the application requires information on dialog applications, where the application requires information on dialog
state, but is not co-resident with the end user on which that state state, but is not co-resident with the end user on which that state
=0C
resides. resides.
In addition, this document also defines two new callee capabilities In addition, this document also defines two new callee capabilities
[10] feature parameters: "sip.byeless", which indicates that a SIP [10] feature parameters: "sip.byeless", which indicates that a SIP
User Agent (UA) is not capable of terminating a session itself (for User Agent (UA) is not capable of terminating a session itself (for
example as with some announcement or recording services, and in some example as with some announcement or recording services, and in some
call centers)in which the UA is no longer interested in call centers)in which the UA is no longer interested in
participating; and "sip.rendering", which positively describes if the participating; and "sip.rendering", which positively describes if the
User Agent is rendering any of the media it is receiving. User Agent is rendering any of the media it is receiving. These
feature parameters are useful in many of the same applications which
motivated the dialog package, such as conferencing, presence, and the
shared-line example described in Section 6.2.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Dialog Event Package 3. Dialog Event Package
skipping to change at page 5, line 41 skipping to change at page 5, line 46
3.2 Event Package Parameters 3.2 Event Package Parameters
This package defines four Event Package parameters. They are This package defines four Event Package parameters. They are
call-id, to-tag, from-tag, and include-session-description. If a call-id, to-tag, from-tag, and include-session-description. If a
subscription to a specific dialog is requested, all of the first subscription to a specific dialog is requested, all of the first
three of these parameters MUST be present. They identify the dialog three of these parameters MUST be present. They identify the dialog
that is being subscribed to. The to-tag is matched against the local that is being subscribed to. The to-tag is matched against the local
tag, the from-tag is matched against the remote tag, and the call-id tag, the from-tag is matched against the remote tag, and the call-id
is matched against the Call-ID. The include-session-description is matched against the Call-ID. The include-session-description
parameter indicates if the subscriber would like to receive the parameter indicates if the subscriber would like to receive the
session descriptions associated with the subscribed dialog or session descriptions associated with the subscribed dialog usage or
dialogs. usages.
It is also possible to subscribe to the set of dialogs created as a It is also possible to subscribe to the set of dialogs created as a
result of a single INVITE sent by a UAC. In that case, the call-id result of a single INVITE sent by a UAC. In that case, the call-id
and to-tag MUST be present. The to-tag is matched against the local and to-tag MUST be present. The to-tag is matched against the local
tag, and the call-id is matched against the Call-ID. tag, and the call-id is matched against the Call-ID.
=0C
The ABNF for these parameters is shown below. It refers to many The ABNF for these parameters is shown below. It refers to many
constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and
token. token.
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE ) call-id =3D "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped! ;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token from-tag =3D "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token to-tag =3D "to-tag" EQUAL token
with-sessd = "include-session-description" with-sessd =3D "include-session-description"
Any callids which contain embedded double-quotes MUST escape those Any callids which contain embedded double-quotes MUST escape those
double-quotes using the backslash-quoting mechanism. Note that the double-quotes using the backslash-quoting mechanism. Note that the
call-id parameter may need to be expressed as a quoted string. This call-id parameter may need to be expressed as a quoted string. This
is because the ABNF for callid and word (which is used by callid) is because the ABNF for callid and word (which is used by callid)
allow for some characters (such as "@", "[", and ":") which are not allow for some characters (such as "@", "[", and ":") which are not
allowed within a token. allowed within a token.
3.3 SUBSCRIBE Bodies 3.3 SUBSCRIBE Bodies
skipping to change at page 6, line 49 skipping to change at page 7, line 4
party in the dialog directly, so these notifications are party in the dialog directly, so these notifications are
superfluous.) If no dialogs remain after supressing dialogs, the superfluous.) If no dialogs remain after supressing dialogs, the
entire notification to that subscriber is supressed and the entire notification to that subscriber is supressed and the
version number in the dialog-info element is not incremented for version number in the dialog-info element is not incremented for
that subscriber. Implicit filtering for one subscriber does not that subscriber. Implicit filtering for one subscriber does not
affect notifications to other subscribers. affect notifications to other subscribers.
o Notifications do not normally contain full state; rather, they o Notifications do not normally contain full state; rather, they
only indicate the state of the dialog whose state has changed. only indicate the state of the dialog whose state has changed.
The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a
NOTIFY that contains no dialog elements. These NOTIFYs contain NOTIFY that contains no dialog elements. These NOTIFYs contain
=0C
the complete view of dialog state. the complete view of dialog state.
o The notifications contain the identities of the participants in o The notifications contain the identities of the participants in
the dialog, the target URIs, and the dialog identifiers. Session the dialog, the target URIs, and the dialog identifiers. Session
descriptions are not included normally unless explicitly requested descriptions are not included normally unless explicitly requested
and/or explicitly authorized. and/or explicitly authorized.
3.4 Subscription Duration 3.4 Subscription Duration
Dialog state changes fairly quickly; once established, a typical Dialog state changes fairly quickly; once established, a typical
phone call lasts a few minutes (this is different for other session phone call lasts a few minutes (this is different for other session
skipping to change at page 7, line 49 skipping to change at page 8, line 5
The subscribe request MAY contain an Accept header field. If no such The subscribe request MAY contain an Accept header field. If no such
header field is present, it has a default value of header field is present, it has a default value of
"application/dialog-info+xml". If the header field is present, it "application/dialog-info+xml". If the header field is present, it
MUST include "application/dialog-info+xml", and MAY include any other MUST include "application/dialog-info+xml", and MAY include any other
types capable of representing dialog state. types capable of representing dialog state.
Of course, the notifications generated by the server MUST be in one Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header field in the SUBSCRIBE of the formats specified in the Accept header field in the SUBSCRIBE
request. request.
=0C
3.6 Notifier Processing of SUBSCRIBE Requests 3.6 Notifier Processing of SUBSCRIBE Requests
The dialog information for a user contains sensitive information. The dialog information for a user contains sensitive information.
Therefore, all subscriptions SHOULD be authenticated and then Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. All implementors of this package MUST authorized before approval. All implementors of this package MUST
support the digest authentication mechanism as a baseline. support the digest authentication mechanism as a baseline.
Authorization policy is at the discretion of the administrator, as Authorization policy is at the discretion of the administrator, as
always. However, a few recommendations can be made. always. However, a few recommendations can be made.
It is RECOMMENDED that, if the policy of user B is that user A is It is RECOMMENDED that, if the policy of user B is that user A is
allowed to call them, dialog subscriptions from user A be allowed. allowed to call them, dialog subscriptions from user A be allowed.
However, the information provided in the notifications does not However, the information provided in the notifications does not
contain any dialog identification information; merely an indication contain any dialog identification information; merely an indication
skipping to change at page 8, line 20 skipping to change at page 8, line 25
It is RECOMMENDED that, if the policy of user B is that user A is It is RECOMMENDED that, if the policy of user B is that user A is
allowed to call them, dialog subscriptions from user A be allowed. allowed to call them, dialog subscriptions from user A be allowed.
However, the information provided in the notifications does not However, the information provided in the notifications does not
contain any dialog identification information; merely an indication contain any dialog identification information; merely an indication
of whether the user is in at least one call, or not. Specifically, of whether the user is in at least one call, or not. Specifically,
they should not be able to find out any more information than if they they should not be able to find out any more information than if they
sent an INVITE. (This concept of a "virtual" dialog is discussed sent an INVITE. (This concept of a "virtual" dialog is discussed
more in Section 3.7.2, and an example of such a notification body is more in Section 3.7.2, and an example of such a notification body is
shown below.) shown below.)
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version=3D"0" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8"> <dialog id=3D"as7d900as8">
<state>confirmed</state> <state>confirmed</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
It is RECOMMENDED that if a user agent registers with the It is RECOMMENDED that if a user agent registers with the
address-of-record X, that this user agent authorize subscriptions address-of-record X, that this user agent authorize subscriptions
that come from any entity that can authenticate itself as X. that come from any entity that can authenticate itself as X.
Complete information on the dialog state SHOULD be sent in this case. Complete information on the dialog state SHOULD be sent in this case.
This authorization behavior allows a group of devices representing a This authorization behavior allows a group of devices representing a
single user to all become aware of each other's state. This is single user to all become aware of each other's state. This is
skipping to change at page 8, line 50 skipping to change at page 9, line 4
id attribute of the dialog element and the state element when id attribute of the dialog element and the state element when
shared-line privacy is requested, and notifications with more shared-line privacy is requested, and notifications with more
complete information when shared-line privacy is not requested. complete information when shared-line privacy is not requested.
3.7 Notifier Generation of NOTIFY Requests 3.7 Notifier Generation of NOTIFY Requests
Notifications are generated for the dialog package when an INVITE Notifications are generated for the dialog package when an INVITE
request is sent, when a new dialog comes into existence at a UA, or request is sent, when a new dialog comes into existence at a UA, or
when the state or characteristics of an existing dialog changes. when the state or characteristics of an existing dialog changes.
Therefore, a model of dialog state is needed in order to determine Therefore, a model of dialog state is needed in order to determine
=0C
precisely when to send notifications, and what their content should precisely when to send notifications, and what their content should
be. The SIP specification has a reasonably well defined lifecycle be. The SIP specification has a reasonably well defined lifecycle
for dialogs. However, it is not explicitly modelled. This for dialogs. However, it is not explicitly modelled. This
specification provides an explicit model of dialog state through a specification provides an explicit model of dialog state through a
finite state machine. finite state machine.
It is RECOMMENDED that NOTIFY requests only contain information on It is RECOMMENDED that NOTIFY requests only contain information on
the dialogs whose state or participation information has changed. the dialogs whose state or participation information has changed.
However, if a notifier receives a SUBSCRIBE request, the triggered However, if a notifier receives a SUBSCRIBE request, the triggered
NOTIFY SHOULD contain the state of all dialogs that the subscriber is NOTIFY SHOULD contain the state of all dialogs that the subscriber is
skipping to change at page 10, line 5 skipping to change at page 10, line 5
is forking, which can cause a single INVITE to generate many dialogs is forking, which can cause a single INVITE to generate many dialogs
at a UAC. The second is the differing views of state at the UAC and at a UAC. The second is the differing views of state at the UAC and
UAS. We have chosen to handle the first issue by extending the UAS. We have chosen to handle the first issue by extending the
dialog FSM to include the states between transmission of the INVITE dialog FSM to include the states between transmission of the INVITE
and the creation of actual dialogs through receipt of 1xx and 2xx and the creation of actual dialogs through receipt of 1xx and 2xx
responses. As a result, this specification supports the notion of responses. As a result, this specification supports the notion of
dialog state for dialogs before they are fully instantiated. dialog state for dialogs before they are fully instantiated.
We have also chosen to use a single FSM for both UAC and UAS. We have also chosen to use a single FSM for both UAC and UAS.
=0C
+----------+ +----------+ +----------+ +----------+
| | 1xx-notag | | | | 1xx-notag | |
| |----------->| | | |----------->| |
| Trying | |Proceeding|-----+ | Trying | |Proceeding|-----+
| |---+ +-----| | | | |---+ +-----| | |
| | | | | | | | | | | | | |
+----------+ | | +----------+ | +----------+ | | +----------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
+<--C-----C--+ |1xx-tag | +<--C-----C--+ |1xx-tag |
skipping to change at page 11, line 4 skipping to change at page 11, line 4
Figure 3 Figure 3
The FSM for dialog state is shown in Figure 3. The FSM is best The FSM for dialog state is shown in Figure 3. The FSM is best
understood by considering the UAC and UAS cases separately. understood by considering the UAC and UAS cases separately.
The FSM is created in the "trying" state when the UAC sends an INVITE The FSM is created in the "trying" state when the UAC sends an INVITE
request. Upon receipt of a 1xx without a tag, the FSM transitions to request. Upon receipt of a 1xx without a tag, the FSM transitions to
the "proceeding" state. Note that there is no actual dialog yet, as the "proceeding" state. Note that there is no actual dialog yet, as
defined by the SIP specification. However, there is a "half-dialog", defined by the SIP specification. However, there is a "half-dialog",
=0C
in the sense that two of the three components of the dialog ID are in the sense that two of the three components of the dialog ID are
known (the call identifier and local tag). If a 1xx with a tag is known (the call identifier and local tag). If a 1xx with a tag is
received, the FSM transitions to the early state. The full dialog received, the FSM transitions to the early state. The full dialog
identifier is now defined. Had a 2xx been received, the FSM would identifier is now defined. Had a 2xx been received, the FSM would
have transitioned to the "confirmed" state. have transitioned to the "confirmed" state.
If, after transitioning to the "early" or "confirmed" states, the UAC If, after transitioning to the "early" or "confirmed" states, the UAC
receives another 1xx or 2xx respectively with a different tag, receives another 1xx or 2xx respectively with a different tag,
another instance of the FSM is created, initialized into the "early" another instance of the FSM is created, initialized into the "early"
or "confirmed" state respectively. The benefit of this approach is or "confirmed" state respectively. The benefit of this approach is
skipping to change at page 11, line 36 skipping to change at page 11, line 38
all FSMs spawned from that INVITE transition to the terminated state all FSMs spawned from that INVITE transition to the terminated state
with the event "rejected". with the event "rejected".
Once in the confirmed state, the call is active. It can transition Once in the confirmed state, the call is active. It can transition
to the terminated state if the UAC sends a BYE or receives a BYE to the terminated state if the UAC sends a BYE or receives a BYE
(corresponding to the "local-bye" and "remote-bye" events as (corresponding to the "local-bye" and "remote-bye" events as
appropriate), if a mid-dialog request generates a 481 or 408 response appropriate), if a mid-dialog request generates a 481 or 408 response
(corresponding to the "error" event), or a mid-dialog request (corresponding to the "error" event), or a mid-dialog request
generates no response (corresponding to the "timeout" event). generates no response (corresponding to the "timeout" event).
From the perspective of the UAS, when an INVITE is received, the FSM =46rom the perspective of the UAS, when an INVITE is received, the =
FSM
is created in the "trying" state. If it sends a 1xx without a tag, is created in the "trying" state. If it sends a 1xx without a tag,
the FSM transitions to the "proceeding" state. If a 1xx is sent with the FSM transitions to the "proceeding" state. If a 1xx is sent with
a tag, the FSM transitions to the "early" state, and if a 2xx is a tag, the FSM transitions to the "early" state, and if a 2xx is
sent, it transitions to the "confirmed" state. If the UAS should sent, it transitions to the "confirmed" state. If the UAS should
receive a CANCEL request and then generate a 487 response to the receive a CANCEL request and then generate a 487 response to the
INVITE (which can occur in the proceeding and early states), the FSM INVITE (which can occur in the proceeding and early states), the FSM
transitions to the terminated state with the event "cancelled". If transitions to the terminated state with the event "cancelled". If
the UAS should generate any other non-2xx final response to the the UAS should generate any other non-2xx final response to the
INVITE request, the FSM transitions to the terminated state with the INVITE request, the FSM transitions to the terminated state with the
event "rejected". If the UAS receives a new invitation (with a event "rejected". If the UAS receives a new invitation (with a
Replaces [13] header) which replaces the current Confirmed dialog, Replaces [13] header) which replaces the current Confirmed dialog,
the replaced invitation transition transitions to the "terminated" the replaced invitation transitions to the "terminated" state with
state with the event "replaced". Once in the "confirmed" state, the the event "replaced". Once in the "confirmed" state, the other
other transitions to the "terminated" state occur for the same transitions to the "terminated" state occur for the same reasons they
reasons they do in the case of UAC. do in the case of UAC.
=0C
There should never be a transition from the "trying" state to the There should never be a transition from the "trying" state to the
"terminated" state with the event "cancelled", since the SIP "terminated" state with the event "cancelled", since the SIP
specification prohibits transmission of CANCEL until a provisional specification prohibits transmission of CANCEL until a provisional
response is received. However, this transition is defined in the response is received. However, this transition is defined in the
FSM just to unify the transitions from trying, proceeding, and FSM just to unify the transitions from trying, proceeding, and
early to the terminated state. early to the terminated state.
3.7.2 Applying the state machine 3.7.2 Applying the state machine
The notifier MAY generate a NOTIFY request on any event transition of The notifier MAY generate a NOTIFY request on any event transition of
skipping to change at page 13, line 5 skipping to change at page 13, line 5
Furthermore, it is RECOMMENDED that the notifications of changes in Furthermore, it is RECOMMENDED that the notifications of changes in
the virtual FSM machine not convey any information except the state the virtual FSM machine not convey any information except the state
of the FSM and its event transitions - no dialog identifiers (which of the FSM and its event transitions - no dialog identifiers (which
are ill-defined in this model in any case). The use of this virtual are ill-defined in this model in any case). The use of this virtual
FSM allows for minimal information to be conveyed. A subscriber FSM allows for minimal information to be conveyed. A subscriber
cannot know how many calls are in progress, or with whom, just that cannot know how many calls are in progress, or with whom, just that
there exists a call. This is the same information they would receive there exists a call. This is the same information they would receive
if they simply sent an INVITE to the user instead; a 486 response if they simply sent an INVITE to the user instead; a 486 response
would indicate that they are on a call. would indicate that they are on a call.
=0C
When the subscriber is authenticated, and has authenticated itself When the subscriber is authenticated, and has authenticated itself
with the same address-of-record that the UA itself uses, if no with the same address-of-record that the UA itself uses, if no
explicit authorization policy is defined, it is RECOMMENDED that all explicit authorization policy is defined, it is RECOMMENDED that all
state transitions on dialogs that have been subscribed to (which is state transitions on dialogs that have been subscribed to (which is
either all of them, if no dialog identifiers were present in the either all of them, if no dialog identifiers were present in the
Event header field, or a specific set of them identified by the Event Event header field, or a specific set of them identified by the Event
header field parameters) be reported, along with complete dialog IDs. header field parameters) be reported, along with complete dialog IDs.
The notifier SHOULD generate a NOTIFY request on any change in the The notifier SHOULD generate a NOTIFY request on any change in the
characteristics associated with the dialog. Since these include characteristics associated with the dialog. Since these include
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Since dialog state is distributed across the UA for a particular Since dialog state is distributed across the UA for a particular
user, it is reasonable and useful for a SUBSCRIBE request for dialog user, it is reasonable and useful for a SUBSCRIBE request for dialog
state to fork, and reach multiple UA. state to fork, and reach multiple UA.
As a result, a forked SUBSCRIBE request for dialog state can install As a result, a forked SUBSCRIBE request for dialog state can install
multiple subscriptions. Subscribers to this package MUST be prepared multiple subscriptions. Subscribers to this package MUST be prepared
to install subscription state for each NOTIFY generated as a result to install subscription state for each NOTIFY generated as a result
of a single SUBSCRIBE. of a single SUBSCRIBE.
=0C
3.10 Rate of Notifications 3.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at that the server not generate notifications for a single subscriber at
a rate faster than once every 1 second. a rate faster than once every 1 second.
3.11 State Agents 3.11 State Agents
Dialog state is ideally maintained in the user agents in which the Dialog state is ideally maintained in the user agents in which the
skipping to change at page 15, line 4 skipping to change at page 15, line 4
representable using a 32 bit integer. representable using a 32 bit integer.
state: This attribute indicates whether the document contains the state: This attribute indicates whether the document contains the
full dialog information, or whether it contains only information full dialog information, or whether it contains only information
on those dialogs which have changed since the previous document on those dialogs which have changed since the previous document
(partial). (partial).
entity: This attribute contains a URI that identifies the user whose entity: This attribute contains a URI that identifies the user whose
dialog information is reported in the remainder of the document. dialog information is reported in the remainder of the document.
This user is referred to as the "observed user". This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog The dialog-info element has a series of zero or more dialog
=0C
sub-elements. Each of those represents a specific dialog. sub-elements. Each of those represents a specific dialog.
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full" version=3D"0" notify-state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
</dialog-info> </dialog-info>
4.1.1 Dialog Element 4.1.1 Dialog Element
The dialog element reports information on a specific dialog or The dialog element reports information on a specific dialog or
"half-dialog". It has single mandatory attribute: id. The id "half-dialog". It has single mandatory attribute: id. The id
attribute provides a single string that can be used as an identifier attribute provides a single string that can be used as an identifier
for this dialog or "half-dialog". This is a different identifier for this dialog or "half-dialog". This is a different identifier
than the dialog ID defined in RFC 3261 [2], but related to it. than the dialog ID defined in RFC 3261 [2], but related to it.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
component of the dialog identifier. component of the dialog identifier.
remote-tag: This attribute is a string which represents the remote-tag: This attribute is a string which represents the
remote-tag component of the dialog identifier. The remote tag remote-tag component of the dialog identifier. The remote tag
attribute won't be present if there is only a "half-dialog", attribute won't be present if there is only a "half-dialog",
resulting from the generation of an INVITE for which no final resulting from the generation of an INVITE for which no final
responses or provisional responses with tags has been received. responses or provisional responses with tags has been received.
direction: This attribute is either initiator or recipient, and direction: This attribute is either initiator or recipient, and
indicates whether the observed user was the initiator of the indicates whether the observed user was the initiator of the
dialog, or the recipient of the INVITE that created it. dialog, or the recipient of the INVITE that created it.
<?xml version="1.0"?> =0C
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <?xml version=3D"1.0"?>
version="0" state="partial" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
entity="sip:alice@example.com"> version=3D"0" state=3D"partial"
<dialog id="as7d900as8" call-id="a84b4c76e66710" entity=3D"sip:alice@example.com">
local-tag="1928301774" direction="initiator"> <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag=3D"1928301774" direction=3D"initiator">
... ...
</dialog> </dialog>
</dialog-info> </dialog-info>
The sub-elements of the dialog element provide additional information The sub-elements of the dialog element provide additional information
about the dialog. Some of these sub-elements provide more detail about the dialog. Some of these sub-elements provide more detail
about the dialog itself, while the local and remote sub-elements about the dialog itself, while the local and remote sub-elements
describe characteristics of the participants involved in the dialog. describe characteristics of the participants involved in the dialog.
The only mandatory sub-element is the state element. The only mandatory sub-element is the state element.
4.1.2 State 4.1.2 State
The state element indicates the state of the dialog. Its value is an The state element indicates the state of the dialog. Its value is an
enumerated type describing one of the states in the FSM above. It enumerated type describing one of the states in the FSM above. It
has an optional event attribute that can be used to indicate the has an optional event attribute that can be used to indicate the
event which caused any transition into the terminated state, and an event which caused any transition into the terminated state, and an
optional code attribute that indicates the response code associated optional code attribute that indicates the response code associated
with any transition caused by a response to the original INVITE. with any transition caused by a response to the original INVITE.
<state event="rejected" code="486">terminated</state> <state event=3D"rejected" code=3D"486">terminated</state>
4.1.3 Duration 4.1.3 Duration
The duration element contains the amount of time, in seconds, since The duration element contains the amount of time, in seconds, since
the FSM was created. the FSM was created.
<duration>145</duration> <duration>145</duration>
4.1.4 Replaces 4.1.4 Replaces
The replaces element is used to correlate a new dialog with one it The replaces element is used to correlate a new dialog with one it
replaced as a result of an invitation with a Replaces header. This replaced as a result of an invitation with a Replaces header. This
element is present in the replacement dialog only (the newer dialog) element is present in the replacement dialog only (the newer dialog)
and contains attributes with the call-id, local-tag, and remote-tag and contains attributes with the call-id, local-tag, and remote-tag
of the replaced dialog. of the replaced dialog.
<replaces call-id="hg287s98s89" <replaces call-id=3D"hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/> local-tag=3D"6762h7" remote-tag=3D"09278hsb"/>
=0C
4.1.5 Referred-By 4.1.5 Referred-By
The referred-by element is used to correlate a new dialog with a The referred-by element is used to correlate a new dialog with a
REFER [12] request which triggered it. The element is present in a REFER [12] request which triggered it. The element is present in a
dialog which was triggered by a REFER request which contained a dialog which was triggered by a REFER request which contained a
Referred-By [11] header and contains the (optional) display name Referred-By [11] header and contains the (optional) display name
attribute and the Referred-By URI as its value. attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by> <referred-by display=3D"Bob">sip:bob@example.com</referred-by>
4.1.6 Local and Remote elements 4.1.6 Local and Remote elements
The local and remote elements are sub-elements of the dialog element The local and remote elements are sub-elements of the dialog element
which contain information about the local and remote participants which contain information about the local and remote participants
respectively. They both have a number of optional sub-elements which respectively. They both have a number of optional sub-elements which
indicate the identity conveyed by the participant, the target URI, indicate the identity conveyed by the participant, the target URI,
the feature-tags of the target, and the session-description of the the feature-tags of the target, and the session-description of the
participant. participant.
skipping to change at page 17, line 39 skipping to change at page 17, line 41
Note that multiple identities (for example a sip: URI and a tel: Note that multiple identities (for example a sip: URI and a tel:
URI) could be included if they all correspond to the participant. URI) could be included if they all correspond to the participant.
To avoid repeating identity information in each request, the To avoid repeating identity information in each request, the
subscriber can assume that the identity URIs are the same as in subscriber can assume that the identity URIs are the same as in
previous notifications if no identity elements are present in the previous notifications if no identity elements are present in the
corresponding local or remote element. If any identity elements corresponding local or remote element. If any identity elements
are present in the local or remote part of a notification, the new are present in the local or remote part of a notification, the new
list of identity tags completely supersedes the old list in the list of identity tags completely supersedes the old list in the
corresponding part. corresponding part.
<identity display="Anonymous"> <identity display=3D"Anonymous">
sip:anonymous@anonymous.invalid</identity> sip:anonymous@anonymous.invalid</identity>
4.1.6.2 Target 4.1.6.2 Target
The target contains the local or remote target URI as constructed by The target contains the local or remote target URI as constructed by
the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" the user agent for this dialog, as defined in RFC 3261 [2] in a "uri"
attribute. attribute.
It can contain a list of Contact header parameters in param It can contain a list of Contact header parameters in param
sub-elements (such as those defined in [10]. The param element sub-elements (such as those defined in [10]). The param element
contains two required attributes, pname and pval. (Boolean contains two required attributes, pname and pval. Boolean parameters
parameters are represented by the explicit pval values "true" and are represented by the explicit pval values "true" and "false" (for
"false" [for example when a feature parameter is explicitly example when a feature parameter is explicitly negated). The param
negated]). The param element itself has no contents. To avoid
repeating Contact information in each request, the subscriber can
assume that the target URI and parameters are the same as in previous
notifications if no target element is present in the corresponding
local or remote element. If a target element is present in the local
or remote part of a notification, the new target tag and list of an
parameter tags completely supersedes the old target and parameter
list in the corresponding part.
<target uri="sip:alice@pc33.example.com"> =0C
<param pname="isfocus" pval="true"/> element itself has no contents. To avoid repeating Contact
<param pname="class" pval="personal"/> information in each request, the subscriber can assume that the
target URI and parameters are the same as in previous notifications
if no target element is present in the corresponding local or remote
element. If a target element is present in the local or remote part
of a notification, the new target tag and list of an parameter tags
completely supersedes the old target and parameter list in the
corresponding part.
<target uri=3D"sip:alice@pc33.example.com">
<param pname=3D"isfocus" pval=3D"true"/>
<param pname=3D"class" pval=3D"personal"/>
</target> </target>
4.1.6.3 Session Description 4.1.6.3 Session Description
The session-description element contains the session description used The session-description element contains the session description used
by the observed user for its end of the dialog. This element should by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless explicitly generally NOT be included in the notifications, unless explicitly
requested by the subscriber. It has a single attribute, type, which requested by the subscriber. It has a single attribute, type, which
indicates the MIME media type of the session description. To avoid indicates the MIME media type of the session description. To avoid
repeating session description information in each request, the repeating session description information in each request, the
subscriber can assume that the session description is the same as in subscriber can assume that the session description is the same as in
previous notifications if no session description element is present previous notifications if no session description element is present
in the corresponding local or remote element. in the corresponding local or remote element.
=0C
4.2 Sample Notification Body 4.2 Sample Notification Body
<?xml version="1.0" encoding="UTF-8"?> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info" xsi:schemaLocation=3D"urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"> version=3D"1" state=3D"full">
<dialog id="123456"> <dialog id=3D"123456">
<state>confirmed</state> <state>confirmed</state>
<duration>274</duration> <duration>274</duration>
<local> <local>
<identity display="Alice">sip:alice@example.com</identity> <identity display=3D"Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com"> <target uri=3D"sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/> <param pname=3D"isfocus" pval=3D"true"/>
<param pname="class" pval="personal"/> <param pname=3D"class" pval=3D"personal"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity display="Bob">sip:bob@example.org</identity> <identity display=3D"Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/> <target uri=3D"sip:bobster@phone21.example.org"/>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
4.3 Constructing Coherent State 4.3 Constructing Coherent State
The dialog information subscriber maintains a table for the list of The dialog information subscriber maintains a table for the list of
dialogs. The table contains a row for each dialog. Each row is dialogs. The table contains a row for each dialog. Each row is
indexed by an ID, present in the "id" attribute of the "dialog" indexed by an ID, present in the "id" attribute of the "dialog"
element. The contents of each row contain the state of that dialog element. The contents of each row contain the state of that dialog
skipping to change at page 20, line 4 skipping to change at page 20, line 4
increased by one, and the document is processed. If the value in the increased by one, and the document is processed. If the value in the
document is more than one higher than the local version number, the document is more than one higher than the local version number, the
local version number is set to the value in the new document, and the local version number is set to the value in the new document, and the
document is processed. If the document did not contain full state, document is processed. If the document did not contain full state,
the subscriber SHOULD generate a refresh request to trigger a full the subscriber SHOULD generate a refresh request to trigger a full
state notification. If the value in the document is less than the state notification. If the value in the document is less than the
local version, the document is discarded without processing. local version, the document is discarded without processing.
The processing of the dialog information document depends on whether The processing of the dialog information document depends on whether
it contains full or partial state. If it contains full state, it contains full or partial state. If it contains full state,
=0C
indicated by the value of the "state" attribute in the "dialog-info" indicated by the value of the "state" attribute in the "dialog-info"
element, the contents of the table are flushed. They are repopulated element, the contents of the table are flushed. They are repopulated
from the document. A new row in the table is created for each from the document. A new row in the table is created for each
"dialog" element. If the document contains partial state, as "dialog" element. If the document contains partial state, as
indicated by the value of the "state" attribute in the "dialog-info" indicated by the value of the "state" attribute in the "dialog-info"
element, the document is used to update the table. For each "dialog" element, the document is used to update the table. For each "dialog"
element in the document, the subscriber checks to see whether a row element in the document, the subscriber checks to see whether a row
exists for that dialog. This check is done by comparing the ID in exists for that dialog. This check is done by comparing the ID in
the "id" attribute of the "dialog" element with the ID associated the "id" attribute of the "dialog" element with the ID associated
with the row. If the dialog doesn't exist in the table, a row is with the row. If the dialog doesn't exist in the table, a row is
added, and its state is set to the information from that "dialog" added, and its state is set to the information from that "dialog"
element. If the dialog does exist, its state is updated to be the element. If the dialog does exist, its state is updated to be the
information from that "dialog" element. If a row is updated or information from that "dialog" element. If a row is updated or
created, such that its state is now terminated, that entry MAY be created, such that its state is now terminated, that entry MAY be
removed from the table at any time. removed from the table at any time.
4.4 Schema 4.4 Schema
The following is the schema for the application/dialog-info+xml type: The following is the schema for the application/dialog-info+xml type:
<?xml version="1.0" encoding="UTF-8"?> <?xml version=3D"1.0" encoding=3D"UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info" targetNamespace=3D"urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info" xmlns:tns=3D"urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified" elementFormDefault=3D"qualified"
attributeFormDefault="unqualified"> attributeFormDefault=3D"unqualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace=3D"http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> schemaLocation=3D"http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="dialog-info"> <xs:element name=3D"dialog-info">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:dialog" minOccurs="0" <xs:element ref=3D"tns:dialog" minOccurs=3D"0"
maxOccurs="unbounded"/> maxOccurs=3D"unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace=3D"##other" processContents=3D"lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs=3D"0" maxOccurs=3D"unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger" <xs:attribute name=3D"version" type=3D"xs:nonNegativeInteger"
use="required"/> use=3D"required"/>
<xs:attribute name="state" use="required"> <xs:attribute name=3D"state" use=3D"required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base=3D"xs:string">
<xs:enumeration value="full"/> <xs:enumeration value=3D"full"/>
<xs:enumeration value="partial"/> <xs:enumeration value=3D"partial"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
=0C
</xs:attribute> </xs:attribute>
<xs:attribute name="entity" type="xs:anyURI" use="required"/> <xs:attribute name=3D"entity" type=3D"xs:anyURI" =
use=3D"required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="dialog"> <xs:element name=3D"dialog">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/> <xs:element ref=3D"tns:state" minOccurs=3D"1" maxOccurs=3D"1"/>=
<xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/> <xs:element name=3D"duration" type=3D"xs:nonNegativeInteger"
<xs:element name="replaces" minOccurs="0" maxOccurs="1"> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:element name=3D"replaces" minOccurs=3D"0" maxOccurs=3D"1">
<xs:complexType> <xs:complexType>
<xs:attribute name="call-id" type="xs:string" <xs:attribute name=3D"call-id" type=3D"xs:string"
use="required"/> use=3D"required"/>
<xs:attribute name="local-tag" type="xs:string" <xs:attribute name=3D"local-tag" type=3D"xs:string"
use="required"/> use=3D"required"/>
<xs:attribute name="remote-tag" type="xs:string" <xs:attribute name=3D"remote-tag" type=3D"xs:string"
use="required"/> use=3D"required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="referred-by" type="tns:nameaddr" <xs:element name=3D"referred-by" type=3D"tns:nameaddr"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1"> <xs:element name=3D"route-set" minOccurs=3D"0" maxOccurs=3D"1">=
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="hop" type="xs:string" minOccurs="1" <xs:element name=3D"hop" type=3D"xs:string" =
maxOccurs="unbounded"/> minOccurs=3D"1"
maxOccurs=3D"unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="local" type="tns:participant" <xs:element name=3D"local" type=3D"tns:participant"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:element name="remote" type="tns:participant" <xs:element name=3D"remote" type=3D"tns:participant"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace=3D"##other" processContents=3D"lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs=3D"0" maxOccurs=3D"unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name=3D"id" type=3D"xs:string" use=3D"required"/>
<xs:attribute name="call-id" type="xs:string" <xs:attribute name=3D"call-id" type=3D"xs:string"
use="optional"/> use=3D"optional"/>
<xs:attribute name="local-tag" type="xs:string" <xs:attribute name=3D"local-tag" type=3D"xs:string"
use="optional"/> use=3D"optional"/>
<xs:attribute name="remote-tag" type="xs:string" <xs:attribute name=3D"remote-tag" type=3D"xs:string"
use="optional"/> use=3D"optional"/>
<xs:attribute name="direction" use="optional"> <xs:attribute name=3D"direction" use=3D"optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base=3D"xs:string">
<xs:enumeration value="initiator"/> <xs:enumeration value=3D"initiator"/>
<xs:enumeration value="recipient"/>
=0C
<xs:enumeration value=3D"recipient"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name="participant"> <xs:complexType name=3D"participant">
<xs:sequence> <xs:sequence>
<xs:element name="identity" type="nameaddr" <xs:element name=3D"identity" type=3D"tns:nameaddr"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1"> <xs:element name=3D"target" minOccurs=3D"0" maxOccurs=3D"1">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="param" minOccurs="0" <xs:element name=3D"param" minOccurs=3D"0"
maxOccurs="unbounded"> maxOccurs=3D"unbounded">
<xs:complexType> <xs:complexType>
<xs:attribute name="pname" type="xs:string" <xs:attribute name=3D"pname" type=3D"xs:string"
use="required"/> use=3D"required"/>
<xs:attribute name="pval" type="xs:string" <xs:attribute name=3D"pval" type=3D"xs:string"
use="required"/> use=3D"required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
<xs:attribute name=3D"uri" type=3D"xs:string" =
use=3D"required"/>
</xs:complexType> </xs:complexType>
<xs:attribute name="uri" type="xs:string" use="required"/>
</xs:element> </xs:element>
<xs:element name="session-description" type="tns:sessd" <xs:element name=3D"session-description" type=3D"tns:sessd"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger" <xs:element name=3D"cseq" type=3D"xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/> minOccurs=3D"0" maxOccurs=3D"1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace=3D"##other" processContents=3D"lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs=3D"0" maxOccurs=3D"unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="nameaddr"> <xs:complexType name=3D"nameaddr">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:anyURI"> <xs:extension base=3D"xs:anyURI">
<xs:attribute name="display-name" type="xs:string" <xs:attribute name=3D"display-name" type=3D"xs:string"
use="optional"/> use=3D"optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="sessd"> <xs:complexType name=3D"sessd">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base=3D"xs:string">
<xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name=3D"type" type=3D"xs:string" =
use=3D"required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
=0C
</xs:complexType> </xs:complexType>
<xs:element name="state"> <xs:element name=3D"state">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base=3D"xs:string">
<xs:attribute name="event" use="optional"> <xs:attribute name=3D"event" use=3D"optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base=3D"xs:string">
<xs:enumeration value="cancelled"/> <xs:enumeration value=3D"cancelled"/>
<xs:enumeration value="rejected"/> <xs:enumeration value=3D"rejected"/>
<xs:enumeration value="replaced"/> <xs:enumeration value=3D"replaced"/>
<xs:enumeration value="local-bye"/> <xs:enumeration value=3D"local-bye"/>
<xs:enumeration value="remote-bye"/> <xs:enumeration value=3D"remote-bye"/>
<xs:enumeration value="error"/> <xs:enumeration value=3D"error"/>
<xs:enumeration value="timeout"/> <xs:enumeration value=3D"timeout"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="code" use="optional"> <xs:attribute name=3D"code" use=3D"optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:positiveInteger"> <xs:restriction base=3D"xs:positiveInteger">
<xs:minInclusive value="100"/> <xs:minInclusive value=3D"100"/>
<xs:maxInclusive value="699"/> <xs:maxInclusive value=3D"699"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
5. Definition of new media feature parameters 5. Definition of new media feature parameters
This section defines two new media feature parameters which are
useful as input to user presence, in conferencing applications, and
in applications like the shared-line example described in Section
6.2. These feature parameters are especially useful when used in
combination with the dialog package, as they allow an authorized
third party to become aware of these characteristics.
5.1 The "sip.byeless" parameter 5.1 The "sip.byeless" parameter
The "sip.byeless" media feature parameter is a new boolean parameter, The "sip.byeless" media feature parameter is a new boolean parameter,
defined in this document, which provides a positive indication that defined in this document, which provides a positive indication that
the User Agent setting the parameter is unable to terminate sessions the User Agent setting the parameter is unable to terminate sessions
on its own (for example, by sending a BYE request). For example, on its own (for example, by sending a BYE request). For example,
=0C
continuous announcement services and certain recording services are continuous announcement services and certain recording services are
unable to determine when it would be desirable to terminate a session unable to determine when it would be desirable to terminate a session
and therefore do not have the ability to terminate sessions at all. and therefore do not have the ability to terminate sessions at all.
Also, many human call centers are configured so that they never Also, many human call centers are configured so that they never
terminate sessions. (This is to prevent call center agents from terminate sessions. (This is to prevent call center agents from
accidentally disconnecting the caller.) accidentally disconnecting the caller.)
Contact: <sip:recording-service@host.example.net> Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless ;automaton;+sip.byeless
5.2 The "sip.rendering" parameter 5.2 The "sip.rendering" parameter
The "sip.rendering" media feature parameter is a new string The "sip.rendering" media feature parameter is a new string
parameter, defined in this document, which can provide a positive parameter, defined in this document, which can provide a positive
indication whether the User Agent setting the parameter is currently indication whether the User Agent setting the parameter is currently
rendering any of the media it is receiving in the context of a rendering any of the media it is receiving in the context of a
specific session. It MUST only be used in a Contact header field in specific session. It MUST only be used in a Contact header field in
skipping to change at page 24, line 33 skipping to change at page 24, line 42
"unknown" indicates that the User Agent does not know whether the "unknown" indicates that the User Agent does not know whether the
media associated with the session is being rendered. (which may be media associated with the session is being rendered. (which may be
the case if the User Agent is acting as a 3pcc (Third Party Call the case if the User Agent is acting as a 3pcc (Third Party Call
Control) [19] controller). Control) [19] controller).
The "sip.rendering" parameter is useful in applications such as The "sip.rendering" parameter is useful in applications such as
shared appearances, conference status monitoring, or as an input to shared appearances, conference status monitoring, or as an input to
user presence. user presence.
Contact: <sip:musak-onhold@host.example.net> Contact: <sip:musak-onhold@host.example.net>
;automaton;+sip.rendering="no" ;automaton;+sip.rendering=3D"no"
6. Examples 6. Examples
6.1 Basic Example 6.1 Basic Example
For example, if a UAC sends an INVITE that looks like, in part: For example, if a UAC sends an INVITE that looks like, in part:
=0C
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pc33.example.com;branch=3Dz9hG4bKnashds8
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=3D1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com> Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 142 Content-Length: 142
[SDP not shown] [SDP not shown]
The XML document in a notification from Alice might look like: The XML document in a notification from Alice might look like:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="0" version=3D"0"
state="full" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" direction="initiator"> local-tag=3D"1928301774" direction=3D"initiator">
<state>trying</state> <state>trying</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
If the following 180 response is received: If the following 180 response is received:
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pc33.example.com;branch=3Dz9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=456887766 To: Bob <sip:bob@example.com>;tag=3D456887766
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=3D1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:bob@host.example.com> Contact: <sip:bob@host.example.com>
The XML document in a notification might look like: The XML document in a notification might look like:
<?xml version="1.0"?> =0C
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <?xml version=3D"1.0"?>
version="1" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
state="full" version=3D"1"
entity="sip:alice@example.com"> state=3D"full"
<dialog id="as7d900as8" call-id="a84b4c76e66710" entity=3D"sip:alice@example.com">
local-tag="1928301774" remote-tag="456887766" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
direction="initiator"> local-tag=3D"1928301774" remote-tag=3D"456887766"
direction=3D"initiator">
<state>early</state> <state>early</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
If it receives a second 180 with a different tag: If it receives a second 180 with a different tag:
SIP/2.0 180 Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pc33.example.com;branch=3Dz9hG4bKnashds8
To: Bob <sip:bob@example.com>;tag=hh76a To: Bob <sip:bob@example.com>;tag=3Dhh76a
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=3D1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:jack@host.example.com> Contact: <sip:jack@host.example.com>
This results in the creation of a second dialog: This results in the creation of a second dialog:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="2" version=3D"2"
state="full" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" remote-tag="456887766" local-tag=3D"1928301774" remote-tag=3D"456887766"
direction="initiator"> direction=3D"initiator">
<state>early</state> <state>early</state>
</dialog> </dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag=3D"1928301774" remote-tag=3D"hh76a"
direction="initiator"> direction=3D"initiator">
<state>early</state> <state>early</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
If a 200 OK is received on the second dialog, it moves to confirmed: If a 200 OK is received on the second dialog, it moves to confirmed:
<?xml version="1.0"?> =0C
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <?xml version=3D"1.0"?>
version="3" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
state="partial" version=3D"3"
entity="sip:alice@example.com"> state=3D"partial"
<dialog id="as7d900as8" call-id="a84b4c76e66710" entity=3D"sip:alice@example.com">
local-tag="1928301774" remote-tag="hh76a" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
direction="initiator"> local-tag=3D"1928301774" remote-tag=3D"hh76a"
direction=3D"initiator">
<state>confirmed</state> <state>confirmed</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
32 seconds later, the other early dialog terminates because no 2xx is 32 seconds later, the other early dialog terminates because no 2xx is
received for it. This implies that it was successfully cancelled, received for it. This implies that it was successfully cancelled,
and therefore the following notification is sent: and therefore the following notification is sent:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="4" version=3D"4"
state="partial" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag=3D"1928301774" remote-tag=3D"hh76a"
direction="initiator"> direction=3D"initiator">
<state event="cancelled">terminated</state> <state event=3D"cancelled">terminated</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
6.2 Emulating a Shared-Line phone system 6.2 Emulating a Shared-Line phone system
The following example shows how a SIP telephone user agent can The following example shows how a SIP telephone user agent can
provide detailed state information and also emulate a shared-line provide detailed state information and also emulate a shared-line
telephone system (the phone "lies" about having a dialog while it is telephone system (the phone "lies" about having a dialog while it is
merely offhook). merely offhook).
Idle: Idle:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version=3D"0" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
</dialog-info> </dialog-info>
Seized: Seized:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial" =0C
entity="sip:alice@example.com"> <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
<dialog id="as7d900as8"> version=3D"1" state=3D"partial"
entity=3D"sip:alice@example.com">
<dialog id=3D"as7d900as8">
<state>trying</state> <state>trying</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
Dialing: Dialing:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial" version=3D"2" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" direction="initiator"> local-tag=3D"1928301774" direction=3D"initiator">
<state>trying</state> <state>trying</state>
<local> <local>
<identity display="Alice Smith"> <identity display=3D"Alice Smith">
sip:alice@example.com sip:alice@example.com
</identity> </identity>
<target uri="sip:alice.gruu@srv3.example.com;grid=0987"/> <target uri=3D"sip:alice.gruu@srv3.example.com;grid=3D0987"/>
</local> </local>
<remote> <remote>
<identity>sip:bob@example.net</identity> <identity>sip:bob@example.net</identity>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Ringing: Ringing:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial" version=3D"3" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
local-tag="1928301774" local-tag=3D"1928301774"
remote-tag="07346y131" direction="initiator"> remote-tag=3D"07346y131" direction=3D"initiator">
<state code="180">early</state> <state code=3D"180">early</state>
<remote> <remote>
<target uri="sip:bobster@host2.example.net"/> <target uri=3D"sip:bobster@host2.example.net"/>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Answered (by voicemail): Answered (by voicemail):
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial" =0C
entity="sip:alice@example.com"> <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
<dialog id="as7d900as8" call-id="a84b4c76e66710" version=3D"4" state=3D"partial"
local-tag="1928301774" entity=3D"sip:alice@example.com">
remote-tag="07346y131" direction="initiator"> <dialog id=3D"as7d900as8" call-id=3D"a84b4c76e66710"
<state reason="cancelled">terminated</state> local-tag=3D"1928301774"
remote-tag=3D"07346y131" direction=3D"initiator">
<state reason=3D"cancelled">terminated</state>
</dialog> </dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710" <dialog id=3D"zxcvbnm3" call-id=3D"a84b4c76e66710"
local-tag="1928301774" local-tag=3D"1928301774"
remote-tag="8736347" direction="initiator"> remote-tag=3D"8736347" direction=3D"initiator">
<state code="200">confirmed</state> <state code=3D"200">confirmed</state>
<remote> <remote>
<target uri="sip:bob-is-not-here@vm.example.net"> <target uri=3D"sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/> <param pname=3D"actor" pval=3D"msg-taker"/>
<param pname="automaton" pval="true"/> <param pname=3D"automaton" pval=3D"true"/>
<param pname="+sip.byeless" pval="true"/> <param pname=3D"+sip.byeless" pval=3D"true"/>
</target> </target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice requests voicemail for Bob's attendant. Alice requests voicemail for Bob's attendant.
(Alice presses "0" in North America / "9" in Europe) (Alice presses "0" in North America / "9" in Europe)
Voicemail completes a transfer with Cathy Voicemail completes a transfer with Cathy
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial" version=3D"5" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710" <dialog id=3D"zxcvbnm3" call-id=3D"a84b4c76e66710"
local-tag="1928301774" local-tag=3D"1928301774"
remote-tag="8736347" direction="initiator"> remote-tag=3D"8736347" direction=3D"initiator">
<state reason="replaced">terminated</state> <state reason=3D"replaced">terminated</state>
</dialog> </dialog>
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id=3D"sfhjsjk12" call-id=3D"o34oii1"
local-tag="8903j4" local-tag=3D"8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag=3D"78cjkus" direction=3D"receiver">
<state reason="replaced">confirmed</state> <state reason=3D"replaced">confirmed</state>
<replaces call-id="a84b4c76e66710" <replaces call-id=3D"a84b4c76e66710"
local-tag="1928301774" local-tag=3D"1928301774"
remote-tag="8736347"/> remote-tag=3D"8736347"/>
<referred-by> <referred-by>
sip:bob-is-not-here@vm.example.net sip:bob-is-not-here@vm.example.net
</referred-by> </referred-by>
<local> <local>
<target uri="sip:alice.gruu@srv3.example.com;grid1645"/> <target uri=3D"sip:alice.gruu@srv3.example.com;grid1645"/>
<param pname="+sip.rendering" pval="yes"/> <param pname=3D"+sip.rendering" pval=3D"yes"/>
=0C
</local> </local>
<remote> <remote>
<identity display="Cathy Jones"> <identity display=3D"Cathy Jones">
sip:cjones@example.net sip:cjones@example.net
</identity> </identity>
<target uri="sip:line3@host3.example.net"> <target uri=3D"sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/> <param pname=3D"actor" pval=3D"attendant"/>
<param pname="automaton" pval="false"/> <param pname=3D"automaton" pval=3D"false"/>
</target> </target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice and Cathy talk, Cathy adds Alice to a local conference. Alice and Cathy talk, Cathy adds Alice to a local conference.
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial" version=3D"6" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id=3D"sfhjsjk12" call-id=3D"o34oii1"
local-tag="8903j4" local-tag=3D"8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag=3D"78cjkus" direction=3D"receiver">
<state>confirmed</state> <state>confirmed</state>
<remote> <remote>
<target uri="sip:confid-34579@host3.example.net"> <target uri=3D"sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/> <param pname=3D"isfocus" pval=3D"true"/>
</target> </target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice puts Cathy on hold Alice puts Cathy on hold
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial" version=3D"7" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id=3D"sfhjsjk12" call-id=3D"o34oii1"
local-tag="8903j4" local-tag=3D"8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag=3D"78cjkus" direction=3D"receiver">
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target uri="sip:alice.gruu@srv3.example.com;grid=1645"> <target uri=3D"sip:alice.gruu@srv3.example.com;grid=3D1645">
<param pname="+sip.rendering" pval="no"/> <param pname=3D"+sip.rendering" pval=3D"no"/>
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
=0C
Cathy hangs up Cathy hangs up
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial" version=3D"8" state=3D"partial"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id=3D"sfhjsjk12" call-id=3D"o34oii1"
local-tag="8903j4" local-tag=3D"8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag=3D"78cjkus" direction=3D"receiver">
<state reason="remote-bye">terminated</state> <state reason=3D"remote-bye">terminated</state>
</dialog> </dialog>
<dialog id="08hjh1345"> <dialog id=3D"08hjh1345">
<state>trying</state> <state>trying</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice hangs up: Alice hangs up:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="9" state="full" version=3D"9" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
</dialog-info> </dialog-info>
6.3 Minimal Dialog Information with Privacy 6.3 Minimal Dialog Information with Privacy
The following example shows the same user agent providing minimal The following example shows the same user agent providing minimal
information to maintain privacy for services like automatic callback. information to maintain privacy for services like automatic callback.
=0C
Onhook: Onhook:
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version=3D"0" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
</dialog-info> </dialog-info>
Offhook: (implementation/policy choice for Alice to transition Offhook: (implementation/policy choice for Alice to transition
to this "state" when "seized", when Trying, when Proceeding, to this "state" when "seized", when Trying, when Proceeding,
or when Confirmed.) or when Confirmed.)
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="1" state="full" version=3D"1" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
<dialog id="1"> <dialog id=3D"1">
<state>confirmed</state> <state>confirmed</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
Onhook: (implementation/policy choice for Alice to transition to Onhook: (implementation/policy choice for Alice to transition to
this "state" when terminated, or when no longer "seized") this "state" when terminated, or when no longer "seized")
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns=3D"urn:ietf:params:xml:ns:dialog-info"
version="2" state="full" version=3D"2" state=3D"full"
entity="sip:alice@example.com"> entity=3D"sip:alice@example.com">
</dialog-info> </dialog-info>
7. Security Considerations 7. Security Considerations
Subscriptions to dialog state can reveal sensitive information. For Subscriptions to dialog state can reveal sensitive information. For
this reason, Section 3.6 discusses authentication and authorization this reason, Section 3.6 discusses authentication and authorization
of subscriptions, and provides guidelines on sensible authorization of subscriptions, and provides guidelines on sensible authorization
policies. All implementations of this package MUST support the policies. All implementations of this package MUST support the
digest authentication mechanism. digest authentication mechanism.
Since the data in notifications is sensitive as well, end-to-end SIP Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME MAY be used to protect it. User encryption mechanisms using S/MIME MAY be used to protect it. User
Agents that implement the dialog package SHOULD also implement SIP Agents that implement the dialog package SHOULD also implement SIP
over TLS [15] and the sips: scheme. over TLS [15] and the sips: scheme.
8. IANA Considerations 8. IANA Considerations
This document registers a new MIME type, application/dialog-info+xml; This document registers a new MIME type, application/dialog-info+xml;
=0C
a new XML namespace; and two new media feature parameters in the SIP a new XML namespace; and two new media feature parameters in the SIP
tree. tree.
8.1 application/dialog-info+xml MIME Registration 8.1 application/dialog-info+xml MIME Registration
MIME media type name: application MIME media type name: application
MIME subtype name: dialog-info+xml MIME subtype name: dialog-info+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8]. specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8]. application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8] and Section 7 Security considerations: See Section 10 of RFC 3023 [8] and Section 7
of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP applications such as call return and used to support SIP applications such as call return and
auto-conference. auto-conference.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .dif or .xml File Extension: .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net> Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
8.2 URN Sub-Namespace Registration for 8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info urn:ietf:params:xml:ns:dialog-info
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[7]. [7].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:dialog-info. urn:ietf:params:xml:ns:dialog-info.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: The IESG, <iesg@ietf.org>
Jonathan Rosenberg <jdrosen@jdrosen.net>.
XML: XML:
=0C
BEGIN BEGIN
<?xml version="1.0"?> <?xml version=3D"1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns=3D"http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv=3D"content-type"
content="text/html;charset=iso-8859-1"/> content=3D"text/html;charset=3Diso-8859-1"/>
<title>Dialog Information Namespace</title> <title>Dialog Information Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Dialog Information</h1> <h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2> <h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href=3D"[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
8.3 Schema Registration 8.3 Schema Registration
This specification registers a schema, as per the guidelines in in This specification registers a schema, as per the guidelines in in
[7]. [7].
URI: please assign. URI: please assign.
Registrant Contact: IETF, SIPPING Working Group Registrant Contact: The IESG, <iesg@ietf.org>
(sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: The XML can be found as the sole content of Section 4.4. XML: The XML can be found as the sole content of Section 4.4.
8.4 Media Feature Parameter Registration 8.4 Media Feature Parameter Registration
This section registers two new media feature tags, per the procedures This section registers two new media feature tags, per the procedures
defined in RFC 2506 [14]. The tags are placed into the sip tree, defined in RFC 2506 [14]. The tags are placed into the sip tree,
which is defined in [10]. which is defined in [10].
8.4.1 sip.byeless 8.4.1 sip.byeless
Media feature tag name sip.byeless Media feature tag name sip.byeless
skipping to change at page 35, line 5 skipping to change at page 35, line 5
is a boolean flag. When set it indicates that the device is is a boolean flag. When set it indicates that the device is
incapable of terminating a session autonomously. incapable of terminating a session autonomously.
Values appropriate for use with this feature tag Boolean. Values appropriate for use with this feature tag Boolean.
The feature tag is intended primarily for use in the following The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms This applications, protocols, services, or negotiation mechanisms This
feature tag is most useful in a communications application for feature tag is most useful in a communications application for
describing the capabilities of an application, such as an describing the capabilities of an application, such as an
announcement service, recording service, conference, or call announcement service, recording service, conference, or call
center. center.
=0C
Examples of typical use Call centers and media services. Examples of typical use Call centers and media services.
Related standards or documents RFC XXXX [[Note to IANA: Please Related standards or documents RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]] replace XXXX with the RFC number of this specification.]]
Security Considerations This media feature tag can be used in ways Security Considerations This media feature tag can be used in ways
which affect application behaviors or may reveal private which affect application behaviors or may reveal private
information. For example, a conferencing or other application may information. For example, a conferencing or other application may
decide to terminate a call prematurely if this media feature tag decide to terminate a call prematurely if this media feature tag
is set. Therefore, if an attacker can modify the values of this is set. Therefore, if an attacker can modify the values of this
tag, they may be able to affect the behavior of applications. As tag, they may be able to affect the behavior of applications. As
a result of this, applications which utilize this media feature a result of this, applications which utilize this media feature
skipping to change at page 36, line 5 skipping to change at page 36, line 5
decide to terminate a call prematurely if this media feature tag decide to terminate a call prematurely if this media feature tag
is set to "no". Therefore, if an attacker can modify the values is set to "no". Therefore, if an attacker can modify the values
of this tag, they may be able to affect the behavior of of this tag, they may be able to affect the behavior of
applications. As a result of this, applications which utilize applications. As a result of this, applications which utilize
this media feature tag SHOULD provide a means for ensuring its this media feature tag SHOULD provide a means for ensuring its
integrity. Similarly, this feature tag should only be trusted as integrity. Similarly, this feature tag should only be trusted as
valid when it comes from the user or user agent described by the valid when it comes from the user or user agent described by the
tag. As a result, protocols for conveying this feature tag SHOULD tag. As a result, protocols for conveying this feature tag SHOULD
provide a mechanism for guaranteeing authenticity. provide a mechanism for guaranteeing authenticity.
=0C
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Sean Olson for his comments. The authors would like to thank Sean Olson for his comments.
10. References 10. References
10.1 Normative References 10.1 Normative References
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
skipping to change at page 37, line 5 skipping to change at page 37, line 5
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By [11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004. Mechanism", RFC 3892, September 2004.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer [12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[13] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation [13] 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.
=0C
[14] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag [14] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999. Registration Procedure", BCP 31, RFC 2506, March 1999.
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
10.2 Informative References 10.2 Informative References
[16] Rosenberg, J., "A Presence Event Package for the Session [16] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004. Initiation Protocol (SIP)", RFC 3856, August 2004.
skipping to change at page 37, line 31 skipping to change at page 37, line 32
Event Package for the Session Initiation Protocol (SIP)", RFC Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004. 3842, August 2004.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [19] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in "Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004. 2004.
[20] Rosenberg, J., "Obtaining and Using Globally Routable User [20] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. (SIP)", draft-ietf-sip-gruu-03 (work in progress), February
2005.
[21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in
progress), October 2004. progress), October 2004.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@cisco.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
=0C
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027 New York, NY 10027
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor) Rohan Mahy (editor)
Airespace SIP Edge LLC
110 Nortech Parkway
San Jose, CA 95134
USA
EMail: rohan@ekabal.com EMail: rohan@ekabal.com
=0C
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 39, line 41 skipping to change at page 39, line 43
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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