draft-ietf-sipping-dialog-package-06.txt   rfc4235.txt 
SIPPING J. Rosenberg Network Working Group J. Rosenberg
Internet-Draft Cisco Systems Request for Comments: 4235 Cisco Systems
Expires: October 11, 2005 H. Schulzrinne Category: Standards Track H. Schulzrinne
Columbia University Columbia University
R. Mahy, Ed. R. Mahy, Ed.
SIP Edge LLC SIP Edge LLC
Apr 12, 2005 November 2005
An INVITE Inititiated Dialog Event Package for the Session An INVITE-Initiated Dialog Event Package for the
Initiation Protocol (SIP) Session Initiation Protocol (SIP)
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 specifies an Internet standards track protocol for the
of section 3 of RFC 3667. By submitting this Internet-Draft, each Internet community, and requests discussion and suggestions for
author represents that any applicable patent or other IPR claims of improvements. Please refer to the current edition of the "Internet
which he or she is aware have been or will be disclosed, and any of Official Protocol Standards" (STD 01) for the standardization state
which he or she become aware will be disclosed, in accordance with and status of this protocol. Distribution of this memo is unlimited.
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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, and receive notifications about the changes in state of INVITE user and to receive notification of the changes in state of INVITE-
initiated dialog usages that the user is involved in. initiated dialog usages in which the subscribed-to user is involved.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5 3. Dialog Event Package ............................................4
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5 3.1. Event Package Name .........................................4
3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5 3.2. Event Package Parameters ...................................4
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.3. SUBSCRIBE Bodies ...........................................5
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7 3.4. Subscription Duration ......................................6
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.5. NOTIFY Bodies ..............................................6
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 3.6. Notifier Processing of SUBSCRIBE Requests ..................7
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 ............................8
3.7.2 Applying the state machine . . . . . . . . . . . . . . 12 3.7.2. Applying the State Machine .........................11
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 3.8. Subscriber Processing of NOTIFY Requests ..................12
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13 3.9. Handling of Forked Requests ...............................12
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14 3.10. Rate of Notifications ....................................13
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14 3.11. State Agents .............................................13
4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14 4. Dialog Information Format ......................................13
4.1 Structure of Dialog Information . . . . . . . . . . . . . 14 4.1. Structure of Dialog Information ...........................13
4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Dialog Element .....................................14
4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. State Element ......................................15
4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Duration Element ...................................15
4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.4. Replaces Element ...................................15
4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . 17 4.1.5. Referred-By Element ................................16
4.1.6 Local and Remote elements . . . . . . . . . . . . . . 17 4.1.6. Local and Remote Elements ..........................16
4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . 17 4.2. Sample Notification Body ..................................17
4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Constructing Coherent State ...............................18
4.1.6.3 Session Description . . . . . . . . . . . . . . . 18 4.4. Schema ....................................................19
4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 19 5. Definition of New Media Feature Parameters .....................22
4.3 Constructing Coherent State . . . . . . . . . . . . . . . 19 5.1. The "sip.byeless" Parameter ...............................22
4.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. The "sip.rendering" parameter .............................23
5. Definition of new media feature parameters . . . . . . . . . . 23 6. Examples .......................................................24
5.1 The "sip.byeless" parameter . . . . . . . . . . . . . . . 23 6.1. Basic Example .............................................24
5.2 The "sip.rendering" parameter . . . . . . . . . . . . . . 24 6.2. Emulating a Shared-Line Phone System ......................26
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3. Minimal Dialog Information with Privacy ...................31
6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations ........................................32
6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27 8. IANA Considerations ............................................32
6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31 8.1. application/dialog-info+xml MIME Registration .............33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8.2. URN Sub-Namespace Registration for
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 urn:ietf:params:xml:ns:dialog-info ........................34
8.1 application/dialog-info+xml MIME Registration . . . . . . 33 8.3. Schema Registration .......................................34
8.2 URN Sub-Namespace Registration for 8.4. Media Feature Parameter Registration ......................34
urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33 8.4.1. sip.byeless ........................................35
8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34 8.4.2. sip.rendering ......................................35
8.4 Media Feature Parameter Registration . . . . . . . . . . . 34 9. Acknowledgements ...............................................36
8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34 10. References ....................................................36
8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References .....................................36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 10.2. Informative References ...................................37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 36
10.2 Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . 39
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 dialog others. This document defines an event package for INVITE-initiated
usages. Dialogs refer to the SIP relationship established between dialog usages. Dialogs refer to the SIP relationship established
two SIP peers [2]. Dialogs can be created by many methods, although between two SIP peers [2]. Dialogs can be created by many methods,
RFC 3261 defines only one - the INVITE method. RFC 3265 defines the although RFC 3261 defines only one: the INVITE method. RFC 3265 [1]
SUBSCRIBE and NOTIFY methods, which also create new dialog usages. defines the SUBSCRIBE and NOTIFY methods, which also create new
However, the usage of this package to model transitions in the state dialog usages. However, using this package to model state for non-
of those dialog usages are out of the scope of this specification. session dialog usages is out of the scope of this specification.
There are a variety of applications enabled through the knowledge of A variety of applications are enabled through knowledge of INVITE
INVITE dialog usage state. Some examples include: dialog usage state. Some examples include:
Automatic Callback: In this basic Public Switched Telephone Network
(PSTN) application, user A calls user B. User B is busy. User A Automatic Callback: In this basic Public Switched Telephone
would like to get a callback when user B hangs up. When B hangs Network (PSTN) application, user A calls user B but User B is
up, user A's phone rings. When A picks it up, they here ringing, busy. User A would like to get a callback when user B hangs
and are being connected to B. To implement this with SIP, a up. When B hangs up, user A's phone rings. When A picks up,
mechanism is required for B to receive a notification when the they hear ringing, while they are being connected to B. To
dialogs at A are complete. implement this with SIP, a mechanism is required for A to
Presence-Enabled Conferencing: In this application, a user A wishes receive a notification when the dialogs at B are complete.
Presence-Enabled Conferencing: In this application, 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 being scheduled, the call is created automatically when A, B
are all available. To do this, the server providing the and C are all available. To do this, the server providing the
application would like to know whether A, B and C are "online", application would like to know whether A, B, and C are
not idle, and not in a phone call. Determining whether or not A, "online", not idle, and not in a phone call. Determining
B and C are in calls can be done in two ways. In the first, the whether or not A, B, and C are in calls can be done in two
server acts as a call stateful proxy for users A, B and C, and ways. In the first, the server acts as a call-stateful proxy
therefore knows their call state. This won't always be possible, for users A, B, and C, and therefore knows their call state.
however, and it introduces scalability, reliability, and This won't always be possible, however, and it introduces
operational complexities. Rather, the server would subscribe to scalability, reliability, and operational complexities. In the
the dialog state of those users, and receive notifications as it second way, the server subscribes to the dialog state of those
changes. This enables the application to be provided in a users and receives notifications as this state changes. This
distributed way; the server need not reside in the same domain as enables the application to be provided in a distributed way;
the users. the server need not reside in the same domain as the users.
IM Conference Alerts: In this application, a user can get an Instant
Message (IM) sent to their phone whenever someone joins a IM Conference Alerts: In this application, a user can receive an
Instant Message (IM) on 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
resides. resides.
In addition, this document also defines two new callee capabilities This document also defines two new callee capability [10] feature
[10] feature parameters: "sip.byeless", which indicates that a SIP parameters:
User Agent (UA) is not capable of terminating a session itself (for
example as with some announcement or recording services, and in some o "sip.byeless", which indicates that a SIP user agent (UA) is not
call centers)in which the UA is no longer interested in capable of terminating a session itself (for example, in some
participating; and "sip.rendering", which positively describes if the announcement or recording services, or in some call centers) in
User Agent is rendering any of the media it is receiving. These which the UA is no longer interested in participating; and
feature parameters are useful in many of the same applications which
motivated the dialog package, such as conferencing, presence, and the o "sip.rendering", which positively describes whether the user
shared-line example described in Section 6.2. agent is rendering any of the media it is receiving. These
feature parameters are useful in many of the same applications
that 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
This section provides the details for defining a SIP Events package, This section provides the details for defining a SIP Events package,
as specified by [1]. as specified in [1].
3.1 Event Package Name 3.1. Event Package Name
The name of this event package is "dialog". This package name is The name of this event package is "dialog". This package name is
carried in the Event and Allow-Events header, as defined in [1]. carried in the Event and Allow-Events header fields, as defined in
[1].
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: call-id, to-tag,
call-id, to-tag, from-tag, and include-session-description. If a from-tag, and include-session-description. If a subscription to a
subscription to a specific dialog is requested, all of the first specific dialog is requested, the first three of these parameters
three of these parameters MUST be present. They identify the dialog MUST be present, to identify the dialog that is being subscribed to.
that is being subscribed to. The to-tag is matched against the local The to-tag is matched against the local tag, the from-tag is matched
tag, the from-tag is matched against the remote tag, and the call-id against the remote tag, and the call-id is matched against the
is matched against the Call-ID. The include-session-description Call-ID. The include-session-description parameter indicates whether
parameter indicates if the subscriber would like to receive the the subscriber would like to receive the session descriptions
session descriptions associated with the subscribed dialog usage or associated with the subscribed dialog usage or usages.
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 (user agent client). In that
and to-tag MUST be present. The to-tag is matched against the local case, the call-id and to-tag MUST be present. The to-tag is matched
tag, and the call-id is matched against the Call-ID. against the local tag and the call-id is matched against the Call-ID.
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 = "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 = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description" with-sessd = "include-session-description"
Any callids which contain embedded double-quotes MUST escape those If any call-ids contain embedded double-quotes, those double-quotes
double-quotes using the backslash-quoting mechanism. Note that the MUST be escaped 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 the callid production and the word
allow for some characters (such as "@", "[", and ":") which are not production, which is used by callid (both from RFC 3261 [1]), allow
allowed within a token. some characters (such as "@", "[", and ":") that are not allowed
within a token.
3.3 SUBSCRIBE Bodies 3.3. SUBSCRIBE Bodies
A SUBSCRIBE for a dialog package MAY contain a body. This body A SUBSCRIBE request for a dialog package MAY contain a body. This
defines a filter to apply to the subscription. Filter documents are body defines a filter to be applied to the subscription. Filter
not specified in this document, and at the time of writing, are documents are not specified in this document, and at the time of
expected to be the subject of future standardization activity. writing, they are expected to be the subject of future
standardization activity.
A SUBSCRIBE for a dialog package MAY be sent without a body. This A SUBSCRIBE request for a dialog package MAY be sent without a body.
implies the default subscription filtering policy. The default This implies the default subscription filtering policy. The default
policy is: policy is:
o If the Event header field contained dialog identifiers,
notifications are generated every time there is a change in the o If the Event header field contained dialog identifiers, a
notification is generated every time there is a change in the
state of any matching dialogs for the user identified in the state of any matching dialogs for the user identified in the
request URI of the SUBSCRIBE. request URI of the SUBSCRIBE.
o If there were no dialog identifiers in the Event header field,
notifications are generated every time there is any change in the o If there were no dialog identifiers in the Event header field, a
notification is generated every time there is any change in the
state of any dialogs for the user identified in the request URI of state of any dialogs for the user identified in the request URI of
the SUBSCRIBE with the following exceptions. If the target the SUBSCRIBE with the following exceptions. If the target
(Contact) URI of a subscriber is equivalent to the remote target (Contact) URI of a subscriber is equivalent to the remote target
URI of a specific dialog, then the dialog element for that dialog URI of a specific dialog, then the dialog element for that dialog
is suppressed for that subscriber. (The subscriber is already a is suppressed for that subscriber. (The subscriber is already a
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 suppressing dialogs, the
entire notification to that subscriber is supressed and the entire notification to that subscriber is suppressed 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(s) 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
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 unless explicitly requested and
and/or explicitly authorized. 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
types, of course). However, the interval between new calls is types, of course). However, the interval between new calls is
typically infrequent. As such, we arbitrarily choose a default typically long. Clients SHOULD specify an explicit duration.
duration of one hour. Clients SHOULD specify an explicit duration.
There are two distinct use cases for dialog state. The first is when There are two distinct use cases for dialog state. The first is when
a subscriber is interested in the state of a specific dialog or a subscriber is interested in the state of a specific dialog or
dialogs (and they are authorized to find out about just the state of dialogs (and they are authorized to find out just the state of those
those dialogs). In that case, when the dialogs terminate, so too dialogs). In that case, when the dialogs terminate, so too does the
does the subscription. In these cases, the value of the subscription subscription. In these cases, the value of the subscription duration
duration is largely irrelevant, and SHOULD be longer than the typical is largely irrelevant; it SHOULD be longer than the typical duration
duration of a dialog, about two hours would cover most dialogs. of a dialog. We recommend a default duration of two hours, which is
likely to cover most dialogs.
In another case, a subscriber is interested in the state of all In another case, a subscriber is interested in the state of all
dialogs for a specific user. In these cases, a shorter interval dialogs for a specific user. In these cases, a shorter interval
makes more sense. The default is one hour for these subscriptions. makes more sense. The default is one hour for these subscriptions.
3.5 NOTIFY Bodies 3.5. NOTIFY Bodies
As described in RFC 3265 [1], the NOTIFY message will contain bodies As described in RFC 3265 [1], the NOTIFY message will contain bodies
that describe the state of the subscribed resource. This body is in that describe the state of the subscribed resource. This body is in
a format listed in the Accept header field of the SUBSCRIBE, or a a format listed in the Accept header field of the SUBSCRIBE, or in a
package-specific default if the Accept header field was omitted from package-specific default format if the Accept header field was
the SUBSCRIBE. omitted from the SUBSCRIBE.
In this event package, the body of the notification contains a dialog In this event package, the body of the notification contains a dialog
information document. This document describes the state of one or information document. This document describes the state of one or
more dialogs associated with the subscribed resource. All more dialogs associated with the subscribed resource. All
subscribers and notifiers MUST support the subscribers and notifiers MUST support the "application/
"application/dialog-info+xml" data format described in Section 4. dialog-info+xml" data format described in Section 4. The subscribe
The subscribe request MAY contain an Accept header field. If no such request MAY contain an Accept header field. If no such header field
header field is present, it has a default value of is present, it has a default value of "application/dialog-info+xml".
"application/dialog-info+xml". If the header field is present, it If the header field is present, it MUST include "application/
MUST include "application/dialog-info+xml", and MAY include any other dialog-info+xml", and it MAY include any other types capable of
types capable of representing dialog state. 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.
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. The
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
of whether the user is in at least one call, or not. Specifically, of whether the user is in at least one call. Specifically, they
they should not be able to find out any more information than if they should not be able to find out any more information than if they sent
sent an INVITE. (This concept of a "virtual" dialog is discussed an INVITE. (This concept of a "virtual" dialog is discussed more in
more in Section 3.7.2, and an example of such a notification body is Section 3.7.2, and an example of such a notification body is shown
shown below.) below).
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version="0" state="full"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8"> <dialog id="as7d900as8">
<state>confirmed</state> <state>confirmed</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
It is RECOMMENDED that if a user agent registers with the A user agent that registers with the address-of-record X SHOULD
address-of-record X, that this user agent authorize subscriptions authorize subscriptions that come from any entity that can
that come from any entity that can authenticate itself as X. authenticate itself as X. Complete information on the dialog state
Complete information on the dialog state SHOULD be sent in this case. SHOULD be sent in this case. This authorization behavior allows a
This authorization behavior allows a group of devices representing a group of devices representing a single user to become aware of each
single user to all become aware of each other's state. This is other's state. This is useful for applications such as
useful for applications such as single-line-extension. single-line-extension, also known as shared lines.
Note that many implementations of "shared-lines" have a feature Note that many implementations of "shared-lines" have a feature
which allows details of calls on a shared address-of-record to be that allows details of calls on a shared address-of-record to be
made private. This is a completely reasonable authorization made private. This is a completely reasonable authorization
policy which could result in notifications which contain only the policy that could result in notifications that contain only the id
id attribute of the dialog element and the state element when 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
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
authorized to see. authorized to see.
3.7.1 The Dialog State Machine 3.7.1. The Dialog State Machine
Modelling of dialog state is complicated by two factors. The first Modelling of dialog state is complicated by two factors. The first
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
UAS. We have chosen to handle the first issue by extending the (user agent client) and UAS (usage agent server). We have chosen to
dialog FSM to include the states between transmission of the INVITE handle the first issue by extending the dialog finite state machine
and the creation of actual dialogs through receipt of 1xx and 2xx (FSM) to include the states between transmission of the INVITE 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.
+----------+ +----------+ +----------+ +----------+
| | 1xx-notag | | | | 1xx-notag | |
| |----------->| | | |----------->| |
| Trying | |Proceeding|-----+ | Trying | |Proceeding|-----+
| |---+ +-----| | | | |---+ +-----| | |
skipping to change at page 10, line 49 skipping to change at page 10, line 5
+------+ +------+
2xx w. new tag 2xx w. new tag
(new FSM instance (new FSM instance
created) created)
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",
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 (the
known (the call identifier and local tag). If a 1xx with a tag is call identifier and local tag) are known. 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
or "confirmed" state respectively. The benefit of this approach is Confirmed state, respectively. The benefit of this approach is that
that there will be a single FSM representing the entire state of the there will be a single FSM representing the entire state of the
invitation and resulting dialog when dealing with the common case of invitation and resulting dialog when dealing in the common case of no
no forking. forking.
If the UAC should send a CANCEL, and then subsequently receive a 487 If the UAC sends a CANCEL and then subsequently receives a 487 to its
to its INVITE transaction, all FSMs spawned from that INVITE INVITE transaction, all FSMs spawned from that INVITE transition to
transition to the "terminated" state with the event "cancelled". If the Terminated state with the event "cancelled". If the UAC receives
the UAC receives a new invitation (with a Replaces [13] header) which a new invitation (with a Replaces [13] header) that replaces the
replaces the current Early or Confirmed dialog, all INVITE current Early or Confirmed dialog, all INVITE transactions spawned
transactions spawned from the replaced invitation transition to the from the replaced invitation transition to the Terminated state with
"terminated" state with the event "replaced". If the INVITE the event "replaced". If the INVITE transaction terminates with a
transaction terminates with a non-2xx response for any other reason, non-2xx response for any other reason, all FSMs spawned from that
all FSMs spawned from that INVITE transition to the terminated state 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 From 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
the FSM transitions to the "proceeding" state. If a 1xx is sent with FSM transitions to the Proceeding state. If a 1xx is sent with a
a tag, the FSM transitions to the "early" state, and if a 2xx is tag, the FSM transitions to the Early state, and if a 2xx is sent, it
sent, it transitions to the "confirmed" state. If the UAS should transitions to the Confirmed state. If the UAS receives a CANCEL
receive a CANCEL request and then generate a 487 response to the request and then generates a 487 response to the INVITE (which can
INVITE (which can occur in the proceeding and early states), the FSM occur in the Proceeding and Early states), the FSM transitions to the
transitions to the terminated state with the event "cancelled". If Terminated state with the event "cancelled". If the UAS generates
the UAS should generate any other non-2xx final response to the any other non-2xx final response to the INVITE request, the FSM
INVITE request, the FSM transitions to the terminated state with the transitions to the Terminated state with the event "rejected". If
event "rejected". If the UAS receives a new invitation (with a the UAS receives a new invitation (with a Replaces [13] header field)
Replaces [13] header) which replaces the current Confirmed dialog, that replaces the current Confirmed dialog, the replaced invitation
the replaced invitation transitions to the "terminated" state with transitions to the Terminated state with the event "replaced". Once
the event "replaced". Once in the "confirmed" state, the other in the Confirmed state, the other transitions to the Terminated state
transitions to the "terminated" state occur for the same reasons they occur for the same reasons they do in the case of UAC.
do in the case of UAC.
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 states 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
the FSM. Whether it does or not is policy dependent. However, some the FSM. Whether it does or not is policy dependent. However, some
general guidelines are provided. general guidelines are provided.
When the subscriber is unauthenticated, or is authenticated, but When the subscriber is unauthenticated, or it is authenticated but
represents a third party with no specific authorization policies, it represents a third party with no specific authorization policies, it
is RECOMMENDED that subscriptions to an individual dialog, or to a is RECOMMENDED that subscriptions to an individual dialog or to a
specific set of dialogs, is forbidden. Only subscriptions to all specific set of dialogs be forbidden. Only subscriptions to all
dialogs (i.e., there are no dialog identifiers in the Event header dialogs (i.e., there are no dialog identifiers in the Event header
field) are permitted. In that case, actual dialog states across all field) are permitted. In that case, actual dialog states across all
dialogs will not be reported. Rather, a single "virtual" dialog FSM dialogs will not be reported. Rather, a single "virtual" dialog FSM
be used, and event transitions on that FSM be reported. will be used, and event transitions on that FSM will be reported.
If there is any dialog at the UA whose state is "confirmed", the If there is any dialog at the UA whose state is Confirmed, the
virtual FSM is in the "confirmed" state. If there are no dialogs at virtual FSM is in the Confirmed state. If there are no dialogs at
the UA in the confirmed state, but there is at least one in the the UA in the Confirmed state but there is at least one in the Early
"early" state, the virtual FSM is in the "early" or "confirmed" state, the virtual FSM is in the Early or Confirmed state. If there
state. If there are no dialogs in the confirmed or early states, but are no dialogs in the Confirmed or Early states but there is at least
there is at least one in the "proceeding" state, the virtual FSM is one in the Proceeding state, the virtual FSM is in the Proceeding,
in the "proceeding", "early" or "confirmed" state. If there are no Early, or Confirmed state. If there are no dialogs in the Confirmed,
dialogs in the confirmed, early, or proceeding states, but there is Early, or Proceeding states but there is at least one in the Trying
at least one in the "trying" state, the virtual FSM is in the state, the virtual FSM is in the Trying, Proceeding, Early or
"trying", "proceeding", "early" or "confirmed" state. The choice Confirmed state. The choice of state to use depends on whether the
about which state to use depends on whether the UA wishes to let UA wishes to let unknown users know that their phone is ringing, as
unknown users know that their phone is ringing, as opposed to in an opposed to being in an active call.
active call.
It is RECOMMENDED that, in the absence of any preference, "confirmed" It is RECOMMENDED that, in the absence of any preference, Confirmed
is used in all cases (as shown in the example in Section 3.6. is used in all cases as shown in the example in Section 3.6.
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 minimal information to be conveyed. A subscriber cannot
cannot know how many calls are in progress, or with whom, just that know how many calls are in progress, or with whom, just that there
there exists a call. This is the same information they would receive exists a call. This is the same information they would receive if
if they simply sent an INVITE to the user instead; a 486 response they simply sent an INVITE to the user instead; a 486 (Busy Here)
would indicate that they are on a call. response would indicate that they are on a call.
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 be
either all of them, if no dialog identifiers were present in the reported, along with complete dialog IDs. This means either all of
Event header field, or a specific set of them identified by the Event the dialogs, if no dialog identifiers were present in the Event
header field parameters) be reported, along with complete dialog IDs. header field, or the specific set of dialogs identified by the Event
header field parameters.
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
Contact URIs, Contact parameters and session descriptions, receipt of Contact URIs, Contact parameters, and session descriptions, receipt
re-INVITEs and UPDATE requests [3] which modify this information MAY of re-INVITEs and UPDATE requests [3] that modify this information
trigger notifications. MAY trigger notifications.
3.8 Subscriber Processing of NOTIFY Requests 3.8. Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in processes NOTIFY requests in package-specific ways. In particular, a
particular, how it uses the NOTIFY requests to contruct a coherent package should specify how it uses the NOTIFY requests to construct a
view of the state of the subscribed resource. coherent view of the state of the subscribed resource.
Typically, the NOTIFY for the dialog package will only contain Typically, the NOTIFY for the dialog package will contain information
information about those dialogs whose state has changed. To about only those dialogs whose state has changed. To construct a
construct a coherent view of the total state of all dialogs, a coherent view of the total state of all dialogs, a subscriber to the
subscriber to the dialog package will need to combine NOTIFYs dialog package will need to combine NOTIFYs received over time.
received over time.
Notifications within this package can convey partial information; Notifications within this package can convey partial information;
that is, they can indicate information about a subset of the state that is, they can indicate information about a subset of the state
associated with the subscription. This means that an explicit associated with the subscription. This means that an explicit
algorithm needs to be defined in order to construct coherent and algorithm needs to be defined in order to construct coherent and
consistent state. The details of this mechanism are specific to the consistent state. The details of this mechanism are specific to the
particular document type. See Section 4.3 for information on particular document type. See Section 4.3 for information on
constructing coherent information from an application/dialog-info+xml constructing coherent information from an application/dialog-info+xml
document. document.
3.9 Handling of Forked Requests 3.9. Handling of Forked Requests
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 to reach multiple UAs.
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.
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 be excessive. It is RECOMMENDED that the server
that the server not generate notifications for a single subscriber at not generate notifications for a single subscriber faster than once
a rate faster than once every 1 second. 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
dialog resides. Therefore, the elements that maintain the dialog are dialog resides. Therefore, the elements that maintain the dialog are
the ones best suited to handle subscriptions to it. However, in some the ones best suited to handle subscriptions to it. However, in some
cases, a network agent may also know the state of the dialogs held by cases, a network agent may also know the state of the dialogs held by
a user. As such, state agents MAY be used with this package. a user. Such state agents MAY be used with this package.
4. Dialog Information Format 4. Dialog Information Format
Dialog information is an XML document [4] that MUST be well-formed Dialog information is an XML document [4] that MUST be well-formed
and SHOULD be valid. Dialog information documents MUST be based on and SHOULD be valid. Dialog information documents MUST be based on
XML 1.0 and MUST be encoded using UTF-8. This specification makes XML 1.0 and MUST be encoded using UTF-8. This specification makes
use of XML namespaces for identifying dialog information documents use of XML namespaces for identifying dialog information documents
and document fragments. The namespace URI for elements defined by and document fragments. The namespace URI for elements defined by
this specification is a URN [5], using the namespace identifier this specification is a URN [5], using the namespace identifier
'ietf' defined by [6] and extended by [7]. This URN is: 'ietf' defined by [6] and extended by [7]. This URN is:
urn:ietf:params:xml:ns:dialog-info urn:ietf:params:xml:ns:dialog-info
A dialog information document begins with the root element tag A dialog information document begins with the root element tag
"dialog-info". "dialog-info".
4.1 Structure of Dialog Information 4.1. Structure of Dialog Information
A dialog information document starts with a dialog-info element. A dialog information document starts with a dialog-info element.
This element has three mandatory attributes: This element has three mandatory attributes:
version: This attribute allows the recipient of dialog information
o version: This attribute allows the recipient of dialog information
documents to properly order them. Versions start at 0, and documents to properly order them. Versions start at 0, and
increment by one for each new document sent to a subscriber. increment by one for each new document sent to a subscriber.
Versions are scoped within a subscription. Versions MUST be Versions are scoped within a subscription. Versions MUST be
representable using a 32 bit integer. representable using a non-negative 32 bit integer.
state: This attribute indicates whether the document contains the
o 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 that have changed since the previous document
(partial). (partial).
entity: This attribute contains a URI that identifies the user whose
dialog information is reported in the remainder of the document.
This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog o entity: This attribute contains a URI that identifies the user
sub-elements. Each of those represents a specific dialog. whose dialog information is reported in the remainder of the
document. This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog sub-
elements. Each of those represents a specific dialog. An example:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" notify-state="full" version="0" notify-state="full"
entity="sip:alice@example.com"> entity="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 about a specific dialog or
"half-dialog". It has single mandatory attribute: id. The id "half-dialog". It has a 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.
For a caller, the id is created when an INVITE request is sent. When For a caller, the id is created when an INVITE request is sent. When
a 1xx with a tag, or a 2xx is received, the dialog is formally a 1xx response with a tag, or a 2xx response is received, the dialog
created. The id remains unchanged. However, if an additional 1xx or is formally created. The id remains unchanged. However, if an
2xx is received, resulting in the creation of another dialog (and additional 1xx or 2xx is received, resulting in the creation of
resulting FSM), that dialog is allocated a new id. another dialog (and resulting FSM), that dialog is allocated a new
id.
For a callee, the id is created when an INVITE outside of an existing For a callee, the id is created when an INVITE outside of an existing
dialog is received. When a 2xx or a 1xx with a tag is sent, creating dialog is received. When a 2xx or a 1xx with a tag is sent, creating
the dialog, the id remains unchanged. the dialog, the id remains unchanged.
The id MUST be unique amongst all dialogs at a UA. The id MUST be unique amongst all current dialogs at a UA.
There are a number of optional attributes which provide There are a number of optional attributes that provide identification
identification information about the dialog: information about the dialog:
call-id: This attribute is a string which represents the call-id
component of the dialog identifier. (Note that single and double o call-id: This attribute is a string that represents the call-id
quotes inside a call-id must be escaped using &quote; for " and component of the dialog identifier. (Note that single and
&apos; for ' .) double quotes inside a call-id must be escaped using &quote;
local-tag: This attribute is a string which represents the local-tag for " and &apos; for ' .)
component of the dialog identifier.
remote-tag: This attribute is a string which represents the o local-tag: This attribute is a string that represents the
local-tag component of the dialog identifier.
o remote-tag: This attribute is a string that 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
o 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"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial" version="0" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator"> local-tag="1928301774" direction="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 Element
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
enumerated type describing one of the states in the FSM above. It an 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 that 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="rejected" code="486">terminated</state>
4.1.3 Duration 4.1.3. Duration Element
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 Element
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 field.
element is present in the replacement dialog only (the newer dialog) This element is present in the replacement dialog only (the newer
and contains attributes with the call-id, local-tag, and remote-tag dialog) and contains attributes with the call-id, local-tag, and
of the replaced dialog. remote-tag of the replaced dialog.
<replaces call-id="hg287s98s89" <replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/> local-tag="6762h7" remote-tag="09278hsb"/>
4.1.5 Referred-By 4.1.5. Referred-By Element
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 that triggered it. The element is present in a
dialog which was triggered by a REFER request which contained a dialog that was triggered by a REFER request that contained a
Referred-By [11] header and contains the (optional) display name Referred-By [11] header field and contains the (optional) display
attribute and the Referred-By URI as its value. name attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by> <referred-by display="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
which contain information about the local and remote participants element that contain information about the local and remote
respectively. They both have a number of optional sub-elements which participants, respectively. They both have a number of optional
indicate the identity conveyed by the participant, the target URI, sub-elements that indicate the identity conveyed by the participant,
the feature-tags of the target, and the session-description of the the target URI, the feature-tags of the target, and the
participant. session-description of the participant.
4.1.6.1 Identity 4.1.6.1. Identity Element
The identity element indicates a local or remote URI, as defined in The "identity" element indicates a local or remote URI, as defined in
[2] as appropriate. It has an optional attribute, display, that [2] as appropriate. It has an optional attribute, display, that
contains the display name from the appropriate URI. contains the display name from the appropriate URI.
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.
skipping to change at page 17, line 42 skipping to change at page 16, line 46
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="Anonymous">
sip:anonymous@anonymous.invalid</identity> sip:anonymous@anonymous.invalid</identity>
4.1.6.2 Target 4.1.6.2. Target Element
The target contains the local or remote target URI as constructed by The "target" contains the local or remote target URI 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-
sub-elements (such as those defined in [10]). The param element elements (such as those defined in [10]). The param element contains
contains two required attributes, pname and pval. Boolean parameters two required attributes, pname and pval. Boolean parameters are
are represented by the explicit pval values "true" and "false" (for represented by the explicit pval values, "true" and "false" (for
example when a feature parameter is explicitly negated). The param example, when a feature parameter is explicitly negated). Parameters
element itself has no contents. To avoid repeating Contact that have no value at all are represented by the explicit pval value
information in each request, the subscriber can assume that the "true". The param element itself has no contents. To avoid
target URI and parameters are the same as in previous notifications repeating Contact information in each request, the subscriber can
if no target element is present in the corresponding local or remote assume that the target URI and parameters are the same as in previous
element. If a target element is present in the local or remote part notifications if no target element is present in the corresponding
of a notification, the new target tag and list of an parameter tags local or remote element. If a target element is present in the local
completely supersedes the old target and parameter list in the or remote part of a notification, the new target tag and list of
corresponding part. parameter tags completely supersedes the old target and parameter
list in the corresponding part. Note that any quoting (including
extra angle-bracket quoting used to quote string values in [10]) or
backslash escaping MUST be removed before being placed in a pval
attribute. Any remaining single quotes, double quotes, and
ampersands MUST be properly XML escaped.
<target uri="sip:alice@pc33.example.com"> <target uri="sip:alice@pc33.example.com">
<param pname="isfocus" pval="true"/> <param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/> <param pname="class" pval="business"/>
<param pname="description" pval="Alice's desk &amp; office"/>
<param pname="sip.rendering" pval="no"/>
</target> </target>
4.1.6.3 Session Description 4.1.6.3. Session Description Element
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 it was
requested by the subscriber. It has a single attribute, type, which explicitly requested by the subscriber. It has a single attribute,
indicates the MIME media type of the session description. To avoid "type", which indicates the MIME media type of the session
repeating session description information in each request, the description. To avoid repeating session description information in
subscriber can assume that the session description is the same as in each request, the subscriber can assume that the session description
previous notifications if no session description element is present is the same as in previous notifications if no session description
in the corresponding local or remote element. element is present in the corresponding local or remote element.
4.2 Sample Notification Body 4.2. Sample Notification Body
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info" xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"> version="1" state="full">
<dialog id="123456"> <dialog id="123456">
<state>confirmed</state> <state>confirmed</state>
<duration>274</duration> <duration>274</duration>
<local> <local>
skipping to change at page 19, line 29 skipping to change at page 18, line 18
<param pname="class" pval="personal"/> <param pname="class" pval="personal"/>
</target> </target>
</local> </local>
<remote> <remote>
<identity display="Bob">sip:bob@example.org</identity> <identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/> <target uri="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 listing the
dialogs. The table contains a row for each dialog. Each row is dialogs, with a row for each dialog. Each row is indexed by an ID
indexed by an ID, present in the "id" attribute of the "dialog" that is present in the "id" attribute of the "dialog" element. Each
element. The contents of each row contain the state of that dialog row contains the state of that dialog, as conveyed in the document.
as conveyed in the document. The table is also associated with a
version number. The version number MUST be initialized with the The table is also associated with a version number. The version
value of the "version" attribute from the "dialog-info" element in number MUST be initialized with the value of the "version" attribute
the first document received. Each time a new document is received, from the "dialog-info" element in the first document received. Each
the value of the local version number, and the "version" attribute in time a new document is received, the value of the local version
the new document, are compared. If the value in the new document is number is compared to the "version" attribute in the new document.
one higher than the local version number, the local version number is If the value in the new document is one higher than the local version
increased by one, and the document is processed. If the value in the number, the local version number is increased by one and the document
document is more than one higher than the local version number, the is processed. If the value in the document is more than one higher
local version number is set to the value in the new document, and the than the local version number, the local version number is set to the
document is processed. If the document did not contain full state, value in the new document and the document is processed. If the
the subscriber SHOULD generate a refresh request to trigger a full document did not contain full state, the subscriber SHOULD generate a
state notification. If the value in the document is less than the refresh request (SUBSCRIBE) to trigger a full state notification. If
local version, the document is discarded without processing. the value in the document is less than the 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,
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 and then 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 compares the ID in the "id"
the "id" attribute of the "dialog" element with the ID associated attribute of the "dialog" element with the ID associated with the
with the row. If the dialog doesn't exist in the table, a row is row. If the dialog does not exist in the table, a row is added and
added, and its state is set to the information from that "dialog" its state is set to the information from that "dialog" element. If
element. If the dialog does exist, its state is updated to be the the dialog does exist, its state is updated to be the information
information from that "dialog" element. If a row is updated or from that "dialog" element. If a row is updated or created, such
created, such that its state is now terminated, that entry MAY be that its state is now terminated, that entry MAY be removed from the
removed from the table at any time. 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="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info" targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info" xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="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="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="dialog-info"> <xs:element name="dialog-info">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:dialog" minOccurs="0" <xs:element ref="tns:dialog" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger" <xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/> use="required"/>
skipping to change at page 21, line 5 skipping to change at page 19, line 44
<xs:attribute name="version" type="xs:nonNegativeInteger" <xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/> use="required"/>
<xs:attribute name="state" use="required"> <xs:attribute name="state" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="full"/> <xs:enumeration value="full"/>
<xs:enumeration value="partial"/> <xs:enumeration value="partial"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="entity" type="xs:anyURI" use="required"/> <xs:attribute name="entity" type="xs:anyURI"
use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="dialog"> <xs:element name="dialog">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/> <xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger" <xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="replaces" minOccurs="0" maxOccurs="1"> <xs:element name="replaces" minOccurs="0" maxOccurs="1">
<xs:complexType> <xs:complexType>
skipping to change at page 21, line 29 skipping to change at page 20, line 25
use="required"/> use="required"/>
<xs:attribute name="remote-tag" type="xs:string" <xs:attribute name="remote-tag" type="xs:string"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="referred-by" type="tns:nameaddr" <xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="route-set" minOccurs="0" maxOccurs="1"> <xs:element name="route-set" minOccurs="0" maxOccurs="1">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="hop" type="xs:string" minOccurs="1" <xs:element name="hop" type="xs:string"
maxOccurs="unbounded"/> minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="local" type="tns:participant" <xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant" <xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
skipping to change at page 22, line 27 skipping to change at page 21, line 24
<xs:element name="param" minOccurs="0" <xs:element name="param" minOccurs="0"
maxOccurs="unbounded"> maxOccurs="unbounded">
<xs:complexType> <xs:complexType>
<xs:attribute name="pname" type="xs:string" <xs:attribute name="pname" type="xs:string"
use="required"/> use="required"/>
<xs:attribute name="pval" type="xs:string" <xs:attribute name="pval" type="xs:string"
use="required"/> use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
<xs:attribute name="uri" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:string"
use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="session-description" type="tns:sessd" <xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger" <xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
skipping to change at page 22, line 49 skipping to change at page 21, line 48
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:anyURI"> <xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string" <xs:attribute name="display-name" type="xs:string"
use="optional"/> use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="sessd"> <xs:complexType name="sessd">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string" use="required"/> <xs:attribute name="type" type="xs:string"
use="required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:element name="state"> <xs:element name="state">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="event" use="optional"> <xs:attribute name="event" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="cancelled"/> <xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/> <xs:enumeration value="rejected"/>
<xs:enumeration value="replaced"/> <xs:enumeration value="replaced"/>
skipping to change at page 23, line 36 skipping to change at page 22, line 37
<xs:maxInclusive value="699"/> <xs:maxInclusive value="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 This section defines two new media feature parameters that are useful
useful as input to user presence, in conferencing applications, and as input to user presence, in conferencing applications, and in
in applications like the shared-line example described in Section applications like the shared-line example described in Section 6.2.
6.2. These feature parameters are especially useful when used in These feature parameters are especially useful in combination with
combination with the dialog package, as they allow an authorized the dialog package, as they allow an authorized third party to become
third party to become aware of these characteristics. 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, that 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,
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
and therefore do not have the ability to terminate sessions at all. session, and therefore they do not have the ability to terminate
Also, many human call centers are configured so that they never sessions at all. Also, many human call centers are configured so
terminate sessions. (This is to prevent call center agents from that they never terminate sessions. (This is to prevent call center
accidentally disconnecting the caller.) agents from accidentally disconnecting the caller). (Note that per
[10], this parameter name must be preceded by a "+" character when
used in a SIP Contact header field.)
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, that 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
a dialog created using the INVITE request. (Note that per [10] this a dialog created using the INVITE request.
parameter name must be preceeded by a "+" character when used in a
SIP Contact header field.)
This parameter has three legal values: "yes", "no", and "unknown". This parameter has three legal values: "yes", "no", and "unknown".
The value "yes" indicates positive knowledge that the User Agent is The value "yes" indicates positive knowledge that the user agent is
rendering at least one of the streams of media that it is receiving. rendering at least one of the streams of media that it is receiving.
The value "no" indicates positive knowledge that the User Agent is The value "no" indicates positive knowledge that the user agent is
rendering none of the media that it is receiving. The value rendering none of the media that it is receiving. The value
"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
the case if the User Agent is acting as a 3pcc (Third Party Call case if the user agent is acting as a 3pcc (Third Party Call Control)
Control) [19] controller). [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="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, in part, like:
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=z9hG4bKnashds8
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=1928301774
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
skipping to change at page 26, line 45 skipping to change at page 26, line 4
local-tag="1928301774" remote-tag="456887766" local-tag="1928301774" remote-tag="456887766"
direction="initiator"> direction="initiator">
<state>early</state> <state>early</state>
</dialog> </dialog>
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag="1928301774" remote-tag="hh76a"
direction="initiator"> direction="initiator">
<state>early</state> <state>early</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
If a 200 OK response is received on the second dialog, the dialog
If a 200 OK is received on the second dialog, it moves to confirmed: moves to confirmed:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" version="3"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag="1928301774" remote-tag="hh76a"
direction="initiator"> direction="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
received for it. This implies that it was successfully cancelled, response has been received for it. This implies that it was
and therefore the following notification is sent: successfully cancelled, and therefore the following notification is
sent:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" version="4"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag="1928301774" remote-tag="hh76a"
direction="initiator"> direction="initiator">
<state event="cancelled">terminated</state> <state event="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="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
skipping to change at page 28, line 25 skipping to change at page 27, line 28
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial" version="2" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator"> local-tag="1928301774" direction="initiator">
<state>trying</state> <state>trying</state>
<local> <local>
<identity display="Alice Smith"> <identity display="Alice Smith">
sip:alice@example.com sip:alice@example.com
</identity> </identity>
<target uri="sip:alice.gruu@srv3.example.com;grid=0987"/> <target uri="sip:alice@pc33.example.com"/>
</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="1.0"?>
skipping to change at page 29, line 25 skipping to change at page 29, line 4
<state code="200">confirmed</state> <state code="200">confirmed</state>
<remote> <remote>
<target uri="sip:bob-is-not-here@vm.example.net"> <target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/> <param pname="actor" pval="msg-taker"/>
<param pname="automaton" pval="true"/> <param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/> <param pname="+sip.byeless" pval="true"/>
</target> </target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice would rather talk to Bob's assistant (Cathy Jones) than to
Alice requests voicemail for Bob's attendant. Bob's voicemail. She indicates this preference by pressing a key
(Alice presses "0" in North America / "9" in Europe) (perhaps "0" in North America or "9" in Europe). Bob's voicemail
Voicemail completes a transfer with Cathy system then acts on this keypress by transferring [20] Alice's call
to Cathy's AOR.
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial" version="5" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710" <dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774" local-tag="1928301774"
remote-tag="8736347" direction="initiator"> remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state> <state reason="replaced">terminated</state>
</dialog> </dialog>
skipping to change at page 29, line 50 skipping to change at page 29, line 30
local-tag="8903j4" local-tag="8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state> <state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710" <replaces call-id="a84b4c76e66710"
local-tag="1928301774" local-tag="1928301774"
remote-tag="8736347"/> remote-tag="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="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="yes"/> <param pname="+sip.rendering" pval="yes"/>
</local> </local>
<remote> <remote>
<identity display="Cathy Jones"> <identity display="Cathy Jones">
sip:cjones@example.net sip:cjones@example.net
</identity> </identity>
<target uri="sip:line3@host3.example.net"> <target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/> <param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/> <param pname="automaton" pval="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="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial" version="6" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4" local-tag="8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag="78cjkus" direction="receiver">
<state>confirmed</state> <state>confirmed</state>
<remote> <remote>
<target uri="sip:confid-34579@host3.example.net"> <target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus" pval="true"/> <param pname="isfocus" pval="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="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial" version="7" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4" local-tag="8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag="78cjkus" direction="receiver">
<state>confirmed</state> <state>confirmed</state>
<local> <local>
<target uri="sip:alice.gruu@srv3.example.com;grid=1645"> <target uri="sip:alice@pc33.example.com"/>
<param pname="+sip.rendering" pval="no"/> <param pname="+sip.rendering" pval="no"/>
</target> </target>
</local> </local>
</dialog> </dialog>
</dialog-info> </dialog-info>
Cathy hangs up Cathy hangs up:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial" version="8" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1" <dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4" local-tag="8903j4"
remote-tag="78cjkus" direction="receiver"> remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state> <state reason="remote-bye">terminated</state>
</dialog> </dialog>
skipping to change at page 31, line 28 skipping to change at page 31, line 28
</dialog-info> </dialog-info>
Alice hangs up: Alice hangs up:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full" version="9" state="full"
entity="sip:alice@example.com"> entity="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.
Onhook: Onhook:
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version="0" state="full"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
</dialog-info> </dialog-info>
Offhook: (implementation/policy choice for Alice to transition to
Offhook: (implementation/policy choice for Alice to transition this "state" when "seized", when Trying, when Proceeding, or when
to this "state" when "seized", when Trying, when Proceeding, Confirmed.)
or when Confirmed.)
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full" version="1" state="full"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="1"> <dialog id="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
this "state" when terminated, or when no longer "seized") "state" when terminated, or when no longer "seized")
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full" version="2" state="full"
entity="sip:alice@example.com"> entity="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;
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. MIME Registration for application/dialog-info+xml Type
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 that 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: .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, 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: The IESG, <iesg@ietf.org> Registrant Contact: The IESG, <iesg@ietf.org>
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="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="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
skipping to change at page 34, line 18 skipping to change at page 34, line 30
"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="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-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="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</a>.</p>
</body> </body>
</html> </html>
END END
8.3 Schema Registration 8.3. Schema Registration
This specification registers a schema, per the guidelines in [7].
URI: urn:ietf:params:xml:schema:dialog-info
This specification registers a schema, as per the guidelines in in
[7].
URI: please assign.
Registrant Contact: The IESG, <iesg@ietf.org> Registrant Contact: The IESG, <iesg@ietf.org>
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. Media Feature Tag sip.byeless
Media feature tag name sip.byeless Media feature tag name sip.byeless
ASN.1 Identifier New assignment by IANA.
Summary of the media feature indicated by this tag This feature tag ASN.1 Identifier 19
Summary of the media feature indicated by this tag: This feature tag
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.
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
replace XXXX with the RFC number of this specification.]]
Security Considerations This media feature tag can be used in ways
which affect application behaviors or may reveal private
information. For example, a conferencing or other application may
decide to terminate a call prematurely if this media feature tag
is set. Therefore, if an attacker can modify the values of this
tag, they may be able to affect the behavior of applications. As
a result of this, applications which utilize this media feature
tag SHOULD provide a means for ensuring its integrity. Similarly,
this feature tag should only be trusted as valid when it comes
from the user or user agent described by the tag. As a result,
protocols for conveying this feature tag SHOULD provide a
mechanism for guaranteeing authenticity.
8.4.2 sip.rendering Related standards or documents: RFC 4235
Media feature tag name sip.rendering Security Considerations: This media feature tag can be used in ways
ASN.1 Identifier New assignment by IANA. that affect application behaviors or may reveal private information.
Summary of the media feature indicated by this tag This feature tag For example, a conferencing or other application may decide to
terminate a call prematurely if this media feature tag is set.
Therefore, if an attacker can modify the values of this tag, they may
be able to affect the behavior of applications. As a result of this,
applications that utilize this media feature tag SHOULD provide a
means for ensuring its integrity. Similarly, this feature tag should
only be trusted as valid when it comes from the user or user agent
described by the tag. As a result, protocols for conveying this
feature tag SHOULD provide a mechanism for guaranteeing authenticity.
8.4.2. Media Feature Tag sip.rendering
Media feature tag name: sip.rendering
ASN.1 Identifier: 20
Summary of the media feature indicated by this tag: This feature tag
contains one of three string values indicating if the device is contains one of three string values indicating if the device is
rendering any media from the current session ("yes"), none of the rendering any media from the current session ("yes"), none of the
media from the current session ("no"), or if this status is not media from the current session ("no"), or if this status is not
known to the device ("unknown"). known to the device ("unknown").
Values appropriate for use with this feature tag String.
Values appropriate for use with this feature tag: String.
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 state of a device (such as a phone or PDA) during a describing the state of a device (such as a phone or PDA) during a
multimedia session. multimedia session.
Examples of typical use Conferencing, telephone shared-line
Examples of typical use: Conferencing, telephone shared-line
emulation, and presence applications. emulation, and presence applications.
Related standards or documents RFC XXXX [[Note to IANA: Please
replace XXXX with the RFC number of this specification.]] Related standards or documents: RFC 4235
Security Considerations This media feature tag can be used in ways
which affect application behaviors or may reveal private Security Considerations: This media feature tag can be used in ways
information. For exmaple, a conferencing or other application may that affect application behaviors or may reveal private
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 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 that utilize this
this media feature tag SHOULD provide a means for ensuring its 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.
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.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[4] Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler, [4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000. FirstEdition REC-xml-20001006, October 2000.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997. [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
3023, January 2001. RFC 3023, January 2001.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[10] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User [10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
Agent Capabilities in the Session Initiation Protocol (SIP)", User Agent Capabilities in the Session Initiation Protocol
RFC 3840, August 2004. (SIP)", RFC 3840, August 2004.
[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.
[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.
[17] Rosenberg, J., "A Watcher Information Event Template-Package [17] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857, August for the Session Initiation Protocol (SIP)", RFC 3857, August
2004. 2004.
[18] Mahy, R., "A Message Summary and Message Waiting Indication [18] Mahy, R., "A Message Summary and Message Waiting Indication
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] Sparks, R., "Session Initiation Protocol Call Control -
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Transfer", Work in Progress, July 2005.
(SIP)", draft-ietf-sip-gruu-03 (work in progress), February
2005.
[21] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in
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
skipping to change at page 39, line 5 skipping to change at page 39, line 5
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)
SIP Edge LLC SIP Edge LLC
EMail: rohan@ekabal.com EMail: rohan@ekabal.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
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. 197 change blocks. 
561 lines changed or deleted 595 lines changed or added

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