draft-ietf-sipping-dialog-package-04.txt   draft-ietf-sipping-dialog-package-05.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft Cisco Systems
Expires: August 13, 2004 H. Schulzrinne Expires: May 5, 2005 H. Schulzrinne
Columbia University Columbia University
R. Mahy, Ed. R. Mahy, Ed.
Cisco Systems, Inc. Airespace
February 13, 2004 Nov 4, 2004
An INVITE Inititiated Dialog Event Package for the Session An INVITE Inititiated Dialog Event Package for the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipping-dialog-package-04.txt draft-ietf-sipping-dialog-package-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2004. This Internet-Draft will expire on May 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document defines a dialog event package for the SIP Events This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in. initiated dialogs that the user is involved in.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Dialog Event Package . . . . . . . . . . . . . . . . . . . 4 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . . . 5
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 4 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 5
3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 4 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 5
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 6 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7
3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . . 8 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . 9
3.7.2 Applying the state machine . . . . . . . . . . . . . . . . 10 3.7.2 Applying the state machine . . . . . . . . . . . . . . 12
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 11 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 13
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 12 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 12 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 14
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 12 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 14
4. Dialog Information Format . . . . . . . . . . . . . . . . 12 4. Dialog Information Format . . . . . . . . . . . . . . . . . . 14
4.1 Structure of Dialog Information . . . . . . . . . . . . . 13 4.1 Structure of Dialog Information . . . . . . . . . . . . . 14
4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . 15
4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . 17
4.1.6 Local and Remote elements . . . . . . . . . . . . . . . . 15 4.1.6 Local and Remote elements . . . . . . . . . . . . . . 17
4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . 17
4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . 17
4.1.6.3 Session Description . . . . . . . . . . . . . . . . . . . 16 4.1.6.3 Session Description . . . . . . . . . . . . . . . 18
4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 16 4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 19
4.3 Constructing Coherent State . . . . . . . . . . . . . . . 17 4.3 Constructing Coherent State . . . . . . . . . . . . . . . 19
5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 21 5. Definition of new media feature parameters . . . . . . . . . . 23
6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 21 5.1 The "sip.byeless" parameter . . . . . . . . . . . . . . . 23
6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 24 5.2 The "sip.rendering" parameter . . . . . . . . . . . . . . 24
6.3 Minimal Dialog Information with Privacy . . . . . . . . . 28 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . 28 6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 29 6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 27
8.1 application/dialog-info+xml MIME Registration . . . . . . 29 6.3 Minimal Dialog Information with Privacy . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1 application/dialog-info+xml MIME Registration . . . . . . 33
8.2 URN Sub-Namespace Registration for 8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 30 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 33
8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 30 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 8.4 Media Feature Parameter Registration . . . . . . . . . . . 34
Normative References . . . . . . . . . . . . . . . . . . . 31 8.4.1 sip.byeless . . . . . . . . . . . . . . . . . . . . . 34
Informative References . . . . . . . . . . . . . . . . . . 32 8.4.2 sip.rendering . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . 34 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 [14], watcher events. Packages have been defined for user presence [16], watcher
information [15], and message waiting indicators [16], amongst information [17], and message waiting indicators [18], amongst
others. Here, we define an event package for INVITE initiated others. Here, we define an event package for INVITE initiated
dialogs. Dialogs refer to the SIP relationship established between dialogs. Dialogs refer to the SIP relationship established between
two SIP peers [2]. Dialogs can be created by many methods, although two SIP peers [2]. Dialogs can be created by many methods, although
RFC 3261 defines only one - the INVITE method. RFC 3265 defines the RFC 3261 defines only one - the INVITE method. RFC 3265 defines the
SUBSCRIBE and NOTIFY methods, which also create dialogs. However, the SUBSCRIBE and NOTIFY methods, which also create dialogs. However,
usage of this package to model transitions in the state of those the usage of this package to model transitions in the state of those
dialogs is out of the scope of this specification. dialogs is out of the scope of this specification.
There are a variety of applications enabled through the knowledge of There are a variety of applications enabled through the knowledge of
INVITE dialog state. Some examples include: INVITE dialog state. Some examples include:
Automatic Callback: In this basic Public Switched Telephone Network Automatic Callback: In this basic Public Switched Telephone Network
(PSTN) application, user A calls user B. User B is busy. User A (PSTN) application, user A calls user B. User B is busy. User A
would like to get a callback when user B hangs up. When B hangs would like to get a callback when user B hangs up. When B hangs
up, user A's phone rings. When A picks it up, they here ringing, up, user A's phone rings. When A picks it up, they here ringing,
and are being connected to B. To implement this with SIP, a and are being connected to B. To implement this with SIP, a
mechanism is required for B to receive a notification when the mechanism is required for B to receive a notification when the
dialogs at A are complete. dialogs at A are complete.
Presence-Enabled Conferencing: In this application, a user A wishes Presence-Enabled Conferencing: In this application, a user A wishes
to set up a conference call with users B and C. Rather than to set up a conference call with users B and C. Rather than
scheduling it, it is to be created automatically when A, B and C scheduling it, it is to be created automatically when A, B and C
are all available. To do this, the server providing the 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 "online",
not idle, and not in a phone call. Determining whether or not A, B not idle, and not in a phone call. Determining whether or not A,
and C are in calls can be done in two ways. In the first, the B and C are in calls can be done in two ways. In the first, the
server acts as a call stateful proxy for users A, B and C, and server acts as a call stateful proxy for users A, B and C, and
therefore knows their call state. This won't always be possible, therefore knows their call state. This won't always be possible,
however, and it introduces scalability, reliability, and however, and it introduces scalability, reliability, and
operational complexities. Rather, the server would subscriber to operational complexities. Rather, the server would subscribe to
the dialog state of those users, and receive notifications as it the dialog state of those users, and receive notifications as it
changes. This enables the application to be provided in a changes. This enables the application to be provided in a
distributed way; the server need not reside in the same domain as distributed way; the server need not reside in the same domain as
the users. the users.
IM Conference Alerts: In this application, a user can get an Instant
IM Conference Alerts: In this application, a user can get an IM sent Message (IM) sent to their phone whenever someone joins a
to their phone whenever someone joins a conference that the phone conference that the phone is involved in. The IM alerts are
is involved in. The IM alerts are generated by an application generated by an application separate from the conference server.
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
[10] feature parameters: "sip.byeless", which indicates that a SIP
User Agent (UA) is not capable of terminating a session itself (for
example as with some announcement or recording services, and in some
call centers)in which the UA is no longer interested in
participating; and "sip.rendering", which positively describes if the
User Agent is rendering any of the media it is receiving.
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 by [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, as defined in [1].
3.2 Event Package Parameters 3.2 Event Package Parameters
This package defines four Event Package parameters. They are call-id, This package defines four Event Package parameters. They are
to-tag, from-tag, and include-session-description. If a subscription call-id, to-tag, from-tag, and include-session-description. If a
to a specific dialog is requested, all of the first three of these subscription to a specific dialog is requested, all of the first
parameters MUST be present. They identify the dialog that is being three of these parameters MUST be present. They identify the dialog
subscribed to. The to-tag is matched against the local tag, the that is being subscribed to. The to-tag is matched against the local
from-tag is matched against the remote tag, and the call-id is tag, the from-tag is matched against the remote tag, and the call-id
matched against the Call-ID. The include-session-description is matched against the Call-ID. The include-session-description
parameter indicates if the subscriber would like to receive the parameter indicates if the subscriber would like to receive the
session descriptions associated with the subscribed dialog or session descriptions associated with the subscribed dialog or
dialogs. dialogs.
It is also possible to subscribe to the set of dialogs created as a It is also possible to subscribe to the set of dialogs created as a
result of a single INVITE sent by a UAC. In that case, the call-id result of a single INVITE sent by a UAC. In that case, the call-id
and to-tag MUST be present. The to-tag is matched against the local and to-tag MUST be present. The to-tag is matched against the local
tag, and the call-id is matched against the Call-ID. tag, and the call-id is matched against the Call-ID.
The ABNF for these parameters is shown below. It refers to many The ABNF for these parameters is shown below. It refers to many
skipping to change at page 5, line 21 skipping to change at page 6, line 26
allowed within a token. 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 for a dialog package MAY contain a body. This body
defines a filter to apply to the subscription. Filter documents are defines a filter to apply to the subscription. Filter documents are
not specified in this document, and at the time of writing, are not specified in this document, and at the time of writing, are
expected to be the subject of future standardization activity. expected to be the subject of future standardization activity.
A SUBSCRIBE for a dialog package MAY be sent without a body. This A SUBSCRIBE for a dialog package MAY be sent without a body. This
implies the default subscription filtering policy. The default policy implies the default subscription filtering policy. The default
is: policy is:
o If the Event header field contained dialog identifiers, o If the Event header field contained dialog identifiers,
notifications are generated every time there is a change in the notifications are 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, o If there were no dialog identifiers in the Event header field,
notifications are generated every time there is any change in the notifications are 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 supressing dialogs, the
entire notification to that subscriber is supressed and the entire notification to that subscriber is supressed and the
skipping to change at page 5, line 42 skipping to change at page 6, line 45
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 supressing dialogs, the
entire notification to that subscriber is supressed and the entire notification to that subscriber is supressed and the
version number in the dialog-info element is not incremented for version number in the dialog-info element is not incremented for
that subscriber. Implicit filtering for one subscriber does not that subscriber. Implicit filtering for one subscriber does not
affect notifications to other subscribers. affect notifications to other subscribers.
o Notifications do not normally contain full state; rather, they o Notifications do not normally contain full state; rather, they
only indicate the state of the dialog whose state has changed. The only indicate the state of the dialog whose state has changed.
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 the NOTIFY that contains no dialog elements. These NOTIFYs contain
complete view of dialog state. the complete view of dialog state.
o The notifications contain the identities of the participants in o The notifications contain the identities of the participants in
the dialog, the target URIs, and the dialog identifiers. Session the dialog, the target URIs, and the dialog identifiers. Session
descriptions are not included normally unless explicitly requested descriptions are not included normally unless explicitly requested
and/or explicitly authorized. and/or explicitly authorized.
3.4 Subscription Duration 3.4 Subscription Duration
Dialog state changes fairly quickly; once established, a typical Dialog state changes fairly quickly; once established, a typical
phone call lasts a few minutes (this is different for other session phone call lasts a few minutes (this is different for other session
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 infrequent. As such, we arbitrarily choose a default
duration of one hour. 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 about just the state of
those dialogs). In that case, when the dialogs terminate, so too does those dialogs). In that case, when the dialogs terminate, so too
the subscription. In these cases, the value of the subscription does the subscription. In these cases, the value of the subscription
duration is largely irrelevant, and SHOULD be longer than the typical duration is largely irrelevant, and SHOULD be longer than the typical
duration of a dialog, about two hours would cover most dialogs. duration of a dialog, about two hours would 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 makes dialogs for a specific user. In these cases, a shorter interval
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 a that describe the state of the subscribed resource. This body is in
format listed in the Accept header field of the SUBSCRIBE, or a a format listed in the Accept header field of the SUBSCRIBE, or a
package-specific default if the Accept header field was omitted from package-specific default if the Accept header field was omitted from
the SUBSCRIBE. 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 subscribers more dialogs associated with the subscribed resource. All
and notifiers MUST support the "application/dialog-info+xml" data subscribers and notifiers MUST support the
format described in Section 4. The subscribe request MAY contain an "application/dialog-info+xml" data format described in Section 4.
Accept header field. If no such header field is present, it has a The subscribe request MAY contain an Accept header field. If no such
default value of "application/dialog-info+xml". If the header field header field is present, it has a default value of
is present, it MUST include "application/dialog-info+xml", and MAY "application/dialog-info+xml". If the header field is present, it
include any other types capable of representing dialog state. MUST include "application/dialog-info+xml", and MAY include any other
types capable of representing dialog state.
Of course, the notifications generated by the server MUST be in one Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header field in the SUBSCRIBE of the formats specified in the Accept header field in the SUBSCRIBE
request. request.
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
skipping to change at page 7, line 17 skipping to change at page 8, line 17
support the digest authentication mechanism as a baseline. support the digest authentication mechanism as a baseline.
Authorization policy is at the discretion of the administrator, as Authorization policy is at the discretion of the administrator, as
always. However, a few recommendations can be made. always. However, a few recommendations can be made.
It is RECOMMENDED that, if the policy of user B is that user A is It is RECOMMENDED that, if the policy of user B is that user A is
allowed to call them, dialog subscriptions from user A be allowed. allowed to call them, dialog subscriptions from user A be allowed.
However, the information provided in the notifications does not However, the information provided in the notifications does not
contain any dialog identification information; merely an indication contain any dialog identification information; merely an indication
of whether the user is in at least one call, or not. Specifically, of whether the user is in at least one call, or not. Specifically,
they should not be able to find out any more information than if they they should not be able to find out any more information than if they
sent an INVITE. (This concept of a "virtual" dialog is discussed more sent an INVITE. (This concept of a "virtual" dialog is discussed
in Section 3.7.2, and an example of such a notification body is shown more in Section 3.7.2, and an example of such a notification body is
below.) shown 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 It is RECOMMENDED that if a user agent registers with the
address-of-record X, that this user agent authorize subscriptions address-of-record X, that this user agent authorize subscriptions
that come from any entity that can authenticate itself as X. Complete that come from any entity that can authenticate itself as X.
information on the dialog state SHOULD be sent in this case. This Complete information on the dialog state SHOULD be sent in this case.
authorization behavior allows a group of devices representing a This authorization behavior allows a group of devices representing a
single user to all become aware of each other's state. This is useful single user to all become aware of each other's state. This is
for applications such as single-line-extension. useful for applications such as single-line-extension.
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 which allows details of calls on a shared address-of-record to be
made private. This is a completely reasonable authorization policy made private. This is a completely reasonable authorization
which could result in notifications which contain only the id policy which could result in notifications which contain only the
attribute of the dialog element and the state element when id attribute of the dialog element and the state element when
shared-line privacy is requested, and notifications with more shared-line privacy is requested, and notifications with more
complete information when shared-line privacy is not requested. complete information when shared-line privacy is not requested.
3.7 Notifier Generation of NOTIFY Requests 3.7 Notifier Generation of NOTIFY Requests
Notifications are generated for the dialog package when an INVITE Notifications are generated for the dialog package when an INVITE
request is sent, when a new dialog comes into existence at a UA, or request is sent, when a new dialog comes into existence at a UA, or
when the state or characteristics of an existing dialog changes. when the state or characteristics of an existing dialog changes.
Therefore, a model of dialog state is needed in order to determine Therefore, a model of dialog state is needed in order to determine
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 for be. The SIP specification has a reasonably well defined lifecycle
dialogs. However, it is not explicitly modelled. This specification for dialogs. However, it is not explicitly modelled. This
provides an explicit model of dialog state through a finite state specification provides an explicit model of dialog state through a
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 is Modelling of dialog state is complicated by two factors. The first
forking, which can cause a single INVITE to generate many dialogs at is forking, which can cause a single INVITE to generate many dialogs
a UAC. The second is the differing views of state at the UAC and UAS. at a UAC. The second is the differing views of state at the UAC and
We have chosen to handle the first issue by extending the dialog FSM UAS. We have chosen to handle the first issue by extending the
to include the states between transmission of the INVITE and the dialog FSM to include the states between transmission of the INVITE
creation of actual dialogs through receipt of 1xx and 2xx responses. and the creation of actual dialogs through receipt of 1xx and 2xx
As a result, this specification supports the notion of dialog state responses. As a result, this specification supports the notion of
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 6 skipping to change at page 11, line 29
to its INVITE transaction, all FSMs spawned from that INVITE to its INVITE transaction, all FSMs spawned from that INVITE
transition to the "terminated" state with the event "cancelled". If transition to the "terminated" state with the event "cancelled". If
the UAC receives a new invitation (with a Replaces [13] header) which the UAC receives a new invitation (with a Replaces [13] header) which
replaces the current Early or Confirmed dialog, all INVITE replaces the current Early or Confirmed dialog, all INVITE
transactions spawned from the replaced invitation transition to the transactions spawned from the replaced invitation transition to the
"terminated" state with the event "replaced". If the INVITE "terminated" state with the event "replaced". If the INVITE
transaction terminates with a non-2xx response for any other reason, transaction terminates with a non-2xx response for any other reason,
all FSMs spawned from that INVITE transition to the terminated state all FSMs spawned from that INVITE transition to the terminated state
with the event "rejected". with the event "rejected".
Once in the confirmed state, the call is active. It can transition to Once in the confirmed state, the call is active. It can transition
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 FSM transitions to the "proceeding" state. If a 1xx is sent with the FSM transitions to the "proceeding" state. If a 1xx is sent with
a tag, the FSM transitions to the "early" state, and if a 2xx is a tag, the FSM transitions to the "early" state, and if a 2xx is
sent, it transitions to the "confirmed" state. If the UAS should sent, it transitions to the "confirmed" state. If the UAS should
skipping to change at page 11, line 39 skipping to change at page 13, line 13
would indicate that they are on a call. 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 (which is
either all of them, if no dialog identifiers were present in the either all of them, if no dialog identifiers were present in the
Event header field, or a specific set of them identified by the Event Event header field, or a specific set of them identified by the Event
header field parameters) be reported, along with complete dialog IDs. header field parameters) be reported, along with complete dialog IDs.
The notifier MAY 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 of
re-INVITEs and UPDATE requests [3] which modify this information MAY re-INVITEs and UPDATE requests [3] which modify this information MAY
trigger notifications. 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 any package specific ways, and in
particular, how it uses the NOTIFY requests to contruct a coherent particular, how it uses the NOTIFY requests to contruct a coherent
view of the state of the subscribed resource. 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 only contain
information about those dialogs whose state has changed. To construct information about those dialogs whose state has changed. To
a coherent view of the total state of all dialogs, a subscriber to construct a coherent view of the total state of all dialogs, a
the dialog package will need to combine NOTIFYs received over time. subscriber to the dialog package will need to combine NOTIFYs
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.
skipping to change at page 12, line 47 skipping to change at page 14, line 24
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. As 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 use XML 1.0 and MUST be encoded using UTF-8. This specification makes
of XML namespaces for identifying dialog information documents and use of XML namespaces for identifying dialog information documents
document fragments. The namespace URI for elements defined by this and document fragments. The namespace URI for elements defined by
specification is a URN [5], using the namespace identifier 'ietf' this specification is a URN [5], using the namespace identifier
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. This A dialog information document starts with a dialog-info element.
element has three mandatory attributes: This element has three mandatory attributes:
version: This attribute allows the recipient of dialog information 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 32 bit integer.
state: This attribute indicates whether the document contains the state: This attribute indicates whether the document contains the
full dialog information, or whether it contains only information full dialog information, or whether it contains only information
on those dialogs which have changed since the previous document on those dialogs which have changed since the previous document
(partial). (partial).
entity: This attribute contains a URI that identifies the user whose entity: This attribute contains a URI that identifies the user whose
dialog information is reported in the remainder of the document. dialog information is reported in the remainder of the document.
This user is referred to as the "observed user". This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog The dialog-info element has a series of zero or more dialog
sub-elements. Each of those represents a specific dialog. sub-elements. Each of those represents a specific dialog.
<?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">
skipping to change at page 13, line 43 skipping to change at page 15, line 16
<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 on a specific dialog or
"half-dialog". It has single mandatory attribute: id. The id "half-dialog". It has single mandatory attribute: id. The id
attribute provides a single string that can be used as an identifier attribute provides a single string that can be used as an identifier
for this dialog or "half-dialog". This is a different identifier than for this dialog or "half-dialog". This is a different identifier
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 with a tag, or a 2xx is received, the dialog is formally
created. The id remains unchanged. However, if an additional 1xx or created. The id remains unchanged. However, if an additional 1xx or
2xx is received, resulting in the creation of another dialog (and 2xx is received, resulting in the creation of another dialog (and
resulting FSM), that dialog is allocated a new id. 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.
skipping to change at page 14, line 49 skipping to change at page 16, line 24
The sub-elements of the dialog element provide additional information The sub-elements of the dialog element provide additional information
about the dialog. Some of these sub-elements provide more detail about the dialog. Some of these sub-elements provide more detail
about the dialog itself, while the local and remote sub-elements about the dialog itself, while the local and remote sub-elements
describe characteristics of the participants involved in the dialog. describe characteristics of the participants involved in the dialog.
The only mandatory sub-element is the state element. The only mandatory sub-element is the state element.
4.1.2 State 4.1.2 State
The state element indicates the state of the dialog. Its value is an The state element indicates the state of the dialog. Its value is an
enumerated type describing one of the states in the FSM above. It has enumerated type describing one of the states in the FSM above. It
an optional event attribute that can be used to indicate the event has an optional event attribute that can be used to indicate the
which caused any transition into the terminated state, and an event which caused any transition into the terminated state, and an
optional code attribute that indicates the response code associated optional code attribute that indicates the response code associated
with any transition caused by a response to the original INVITE. with any transition caused by a response to the original INVITE.
<state event="rejected" code="486">terminated</state> <state event="rejected" code="486">terminated</state>
4.1.3 Duration 4.1.3 Duration
The duration element contains the amount of time, in seconds, since The duration element contains the amount of time, in seconds, since
the FSM was created. the FSM was created.
<duration>145</duration> <duration>145</duration>
4.1.4 Replaces 4.1.4 Replaces
The replaces element is used to correlate a new dialog with one it The replaces element is used to correlate a new dialog with one it
replaced as a result of an invitation with a Replaces header. This replaced as a result of an invitation with a Replaces header. This
element is present in the replacement dialog only (the newer dialog) element is present in the replacement dialog only (the newer dialog)
and contains attributes with the call-id, local-tag, and remote-tag and contains attributes with the call-id, local-tag, and remote-tag
of the replaced dialog. of the replaced dialog.
<replaces call-id="hg287s98s89" local-tag="6762h7" remote-tag="09278hsb"/>
<replaces call-id="hg287s98s89"
local-tag="6762h7" remote-tag="09278hsb"/>
4.1.5 Referred-By 4.1.5 Referred-By
The referred-by element is used to correlate a new dialog with a The referred-by element is used to correlate a new dialog with a
REFER [12] request which triggered it. The element is present in a REFER [12] request which triggered it. The element is present in a
dialog which was triggered by a REFER request which contained a dialog which was triggered by a REFER request which contained a
Referred-By [11] header and contains the (optional) display name Referred-By [11] header and contains the (optional) display name
attribute and the Referred-By URI as its value. attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by> <referred-by display="Bob">sip:bob@example.com</referred-by>
4.1.6 Local and Remote elements 4.1.6 Local and Remote elements
The local and remote elements are sub-elements of the dialog element The local and remote elements are sub-elements of the dialog element
which contain information about the local and remote participants which contain information about the local and remote participants
respectively. They both have a number of optional sub-elements which respectively. They both have a number of optional sub-elements which
indicate the identity conveyed by the participant, the target URI, indicate the identity conveyed by the participant, the target URI,
the feature-tags of the target, and the session-description of the the feature-tags of the target, and the session-description of the
participant. participant.
skipping to change at page 16, line 10 skipping to change at page 17, line 39
Note that multiple identities (for example a sip: URI and a tel: Note that multiple identities (for example a sip: URI and a tel:
URI) could be included if they all correspond to the participant. URI) could be included if they all correspond to the participant.
To avoid repeating identity information in each request, the To avoid repeating identity information in each request, the
subscriber can assume that the identity URIs are the same as in subscriber can assume that the identity URIs are the same as in
previous notifications if no identity elements are present in the previous notifications if no identity elements are present in the
corresponding local or remote element. If any identity elements corresponding local or remote element. If any identity elements
are present in the local or remote part of a notification, the new are present in the local or remote part of a notification, the new
list of identity tags completely supersedes the old list in the list of identity tags completely supersedes the old list in the
corresponding part. corresponding part.
<identity display="Anonymous">sip:anonymous@anonymous.invalid</identity> <identity display="Anonymous">
sip:anonymous@anonymous.invalid</identity>
4.1.6.2 Target 4.1.6.2 Target
The target contains the local or remote target URI as constructed by The target contains the local or remote target URI as constructed by
the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" the user agent for this dialog, as defined in RFC 3261 [2] in a "uri"
attribute. attribute.
It can contain a list of Contact header parameters in param It can contain a list of Contact header parameters in param
sub-elements (such as those defined in [10]. The param element sub-elements (such as those defined in [10]. The param element
contains a required pname attribute and an optional pval attribute contains two required attributes, pname and pval. (Boolean
(some parameters merely exist and have no explicit value). The param parameters are represented by the explicit pval values "true" and
element itself has no contents. To avoid repeating Contact "false" [for example when a feature parameter is explicitly
information in each request, the subscriber can assume that the negated]). 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 an
corresponding part. parameter tags completely supersedes the old target and parameter
list in the corresponding part.
<target uri="sip:alice@pc33.example.com"> <target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/> <param pname="isfocus" pval="true"/>
<param pname="class" pval="personal"/> <param pname="class" pval="personal"/>
</target> </target>
4.1.6.3 Session Description 4.1.6.3 Session Description
The session-description element contains the session description used The session-description element contains the session description used
by the observed user for its end of the dialog. This element should by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless explicitly generally NOT be included in the notifications, unless explicitly
requested by the subscriber. It has a single attribute, type, which requested by the subscriber. It has a single attribute, type, which
indicates the MIME media type of the session description. To avoid indicates the MIME media type of the session description. To avoid
skipping to change at page 17, line 12 skipping to change at page 19, line 18
<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>
<identity display="Alice">sip:alice@example.com</identity> <identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com"> <target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/> <param pname="isfocus" pval="true"/>
<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 for the list of
dialogs. The table contains a row for each dialog. Each row is dialogs. The table contains a row for each dialog. Each row is
indexed by an ID, present in the "id" attribute of the "dialog" indexed by an ID, present in the "id" attribute of the "dialog"
element. The contents of each row contain the state of that dialog as element. The contents of each row contain the state of that dialog
conveyed in the document. The table is also associated with a version as conveyed in the document. The table is also associated with a
number. The version number MUST be initialized with the value of the version number. The version number MUST be initialized with the
"version" attribute from the "dialog-info" element in the first value of the "version" attribute from the "dialog-info" element in
document received. Each time a new document is received, the value of the first document received. Each time a new document is received,
the local version number, and the "version" attribute in the new the value of the local version number, and the "version" attribute in
document, are compared. If the value in the new document is one the new document, are compared. If the value in the new document is
higher than the local version number, the local version number is one higher than the local version number, the local version number is
increased by one, and the document is processed. If the value in the increased by one, and the document is processed. If the value in the
document is more than one higher than the local version number, the document is more than one higher than the local version number, the
local version number is set to the value in the new document, and the local version number is set to the value in the new document, and the
document is processed. If the document did not contain full state, document is processed. If the document did not contain full state,
the subscriber SHOULD generate a refresh request to trigger a full the subscriber SHOULD generate a refresh request to trigger a full
state notification. If the value in the document is less than the state notification. If the value in the document is less than the
local version, the document is discarded without processing. local version, the document is discarded without processing.
The processing of the dialog information document depends on whether The processing of the dialog information document depends on whether
it contains full or partial state. If it contains full state, it contains full or partial state. If it contains full state,
indicated by the value of the "state" attribute in the "dialog-info" indicated by the value of the "state" attribute in the "dialog-info"
element, the contents of the table are flushed. They are repopulated element, the contents of the table are flushed. They are repopulated
from the document. A new row in the table is created for each from the document. A new row in the table is created for each
"dialog" element. If the document contains partial state, as "dialog" element. If the document contains partial state, as
indicated by the value of the "state" attribute in the "dialog-info" indicated by the value of the "state" attribute in the "dialog-info"
element, the document is used to update the table. For each "dialog" element, the document is used to update the table. For each "dialog"
element in the document, the subscriber checks to see whether a row element in the document, the subscriber checks to see whether a row
exists for that dialog. This check is done by comparing the ID in the exists for that dialog. This check is done by comparing the ID in
"id" attribute of the "dialog" element with the ID associated with the "id" attribute of the "dialog" element with the ID associated
the row. If the dialog doesn't exist in the table, a row is added, with the row. If the dialog doesn't exist in the table, a row is
and its state is set to the information from that "dialog" element. added, and its state is set to the information from that "dialog"
If the dialog does exist, its state is updated to be the information element. If the dialog does exist, its state is updated to be the
from that "dialog" element. If a row is updated or created, such that information from that "dialog" element. If a row is updated or
its state is now terminated, that entry MAY be removed from the table created, such that its state is now terminated, that entry MAY be
at any time. removed from the table at any time.
5. 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">
skipping to change at page 20, line 18 skipping to change at page 22, line 23
minOccurs="0" maxOccurs="1"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1"> <xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<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="optional"/> use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:attribute name="uri" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:string" use="required"/>
</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"/>
skipping to change at page 21, line 31 skipping to change at page 23, line 36
<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.1 The "sip.byeless" parameter
The "sip.byeless" media feature parameter is a new boolean parameter,
defined in this document, which provides a positive indication that
the User Agent setting the parameter is unable to terminate sessions
on its own (for example, by sending a BYE request). For example,
continuous announcement services and certain recording services are
unable to determine when it would be desirable to terminate a session
and therefore do not have the ability to terminate sessions at all.
Also, many human call centers are configured so that they never
terminate sessions. (This is to prevent call center agents from
accidentally disconnecting the caller.)
Contact: <sip:recording-service@host.example.net>
;automaton;+sip.byeless
5.2 The "sip.rendering" parameter
The "sip.rendering" media feature parameter is a new string
parameter, defined in this document, which can provide a positive
indication whether the User Agent setting the parameter is currently
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
a dialog created using the INVITE request. (Note that per [10] this
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".
The value "yes" indicates positive knowledge that the User Agent is
rendering at least one of the streams of media that it is receiving.
The value "no" indicates positive knowledge that the User Agent is
rendering none of the media that it is receiving. The value
"unknown" indicates that the User Agent does not know whether the
media associated with the session is being rendered. (which may be
the case if the User Agent is acting as a 3pcc (Third Party Call
Control) [19] controller).
The "sip.rendering" parameter is useful in applications such as
shared appearances, conference status monitoring, or as an input to
user presence.
Contact: <sip:musak-onhold@host.example.net>
;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 like, in part:
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>
skipping to change at page 23, line 41 skipping to change at page 27, line 18
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 is
received for it. This implies that it was successfully cancelled, and received for it. This implies that it was successfully cancelled,
therefore the following notification is sent: 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>
skipping to change at page 24, line 50 skipping to change at page 28, line 25
<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;grid0987"/> <target uri="sip:alice.gruu@srv3.example.com;grid=0987"/>
</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 25, line 45 skipping to change at page 29, line 19
remote-tag="07346y131" direction="initiator"> remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state> <state reason="cancelled">terminated</state>
</dialog> </dialog>
<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 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"/> <param pname="automaton" pval="true"/>
<param pname="+sip.byeless" pval="true"/>
</target> </target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
Alice requests voicemail for Bob's attendant. Alice requests voicemail for Bob's attendant.
(Alice presses "0" in North America / "9" in Europe) (Alice presses "0" in North America / "9" in Europe)
Voicemail completes a transfer with Cathy Voicemail completes a transfer with Cathy
<?xml version="1.0"?> <?xml version="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">
skipping to change at page 26, line 29 skipping to change at page 29, line 51
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.gruu@srv3.example.com;grid1645"/>
<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>
skipping to change at page 27, line 5 skipping to change at page 30, line 29
<?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"/> <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.gruu@srv3.example.com;grid=1645">
<param pname="+activity" pval="noninteractive"/> <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>
skipping to change at page 28, line 45 skipping to change at page 32, line 40
<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 digest policies. All implementations of this package MUST support the
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. encryption mechanisms using S/MIME MAY be used to protect it. User
Agents that implement the dialog package SHOULD also implement SIP
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;
and registers a new XML namespace. a new XML namespace; and two new media feature parameters in the SIP
tree.
8.1 application/dialog-info+xml MIME Registration 8.1 application/dialog-info+xml MIME Registration
MIME media type name: application MIME media type name: application
MIME subtype name: dialog-info+xml MIME subtype name: dialog-info+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8]. specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8]. application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8] and Section 7 Security considerations: See Section 10 of RFC 3023 [8] and Section 7
of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP applications such as call return and used to support SIP applications such as call return and
auto-conference. auto-conference.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .dif or .xml File Extension: .dif or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net> Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
8.2 URN Sub-Namespace Registration for 8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info urn:ietf:params:xml:ns:dialog-info
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[7]. [7].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:dialog-info. urn:ietf:params:xml:ns:dialog-info.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Jonathan Rosenberg <jdrosen@jdrosen.net>. Jonathan Rosenberg <jdrosen@jdrosen.net>.
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"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
skipping to change at page 30, line 28 skipping to change at page 34, line 14
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"
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="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
8.3 Schema Registration 8.3 Schema Registration
skipping to change at page 30, line 41 skipping to change at page 34, line 27
<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="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
8.3 Schema Registration 8.3 Schema Registration
This specification registers a schema, as per the guidelines in in This specification registers a schema, as per the guidelines in in
[7]. [7].
URI: please assign. URI: please assign.
Registrant Contact: IETF, SIPPING Working Group Registrant Contact: IETF, SIPPING Working Group
(sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: The XML can be found as the sole content of Section 4.4.
XML: The XML can be found as the sole content of Section 5. 8.4 Media Feature Parameter Registration
This section registers two new media feature tags, per the procedures
defined in RFC 2506 [14]. The tags are placed into the sip tree,
which is defined in [10].
8.4.1 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
is a boolean flag. When set it indicates that the device is
incapable of terminating a session autonomously.
Values appropriate for use with this feature tag Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms This
feature tag is most useful in a communications application for
describing the capabilities of an application, such as an
announcement service, recording service, conference, or call
center.
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
Media feature tag name sip.rendering
ASN.1 Identifier New assignment by IANA.
Summary of the media feature indicated by this tag This feature tag
contains one of three string values indicating if the device is
rendering any media from the current session ("yes"), none of the
media from the current session ("no"), or if this status is not
known to the device ("unknown").
Values appropriate for use with this feature tag String.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms This
feature tag is most useful in a communications application, for
describing the state of a device (such as a phone or PDA) during a
multimedia session.
Examples of typical use Conferencing, telephone shared-line
emulation, and presence applications.
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 exmaple, a conferencing or other application may
decide to terminate a call prematurely if this media feature tag
is set to "no". 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.
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.
Normative References 10. References
10.1 Normative References
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[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] Bray, T., Paoli, J., Sperberg-McQueen, C. 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
REC 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", RFC
3023, January 2001. 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., "Indicating User Agent Capabilities in the [10] Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User
Session Initiation Protocol (SIP)", Agent Capabilities in the Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003. RFC 3840, August 2004.
[11] Sparks, R., "The SIP Referred-By Mechanism", [11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
draft-ietf-sip-referredby-01 (work in progress), February 2003. 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] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation [13] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
(work in progress), March 2003.
Informative References [14] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
[14] Rosenberg, J., "A Presence Event Package for the Session [15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 2246, January 1999.
in progress), January 2003.
[15] Rosenberg, J., "A Watcher Information Event Template-Package 10.2 Informative References
for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January
2003.
[16] Mahy, R., "A Message Summary and Message Waiting Indication [16] Rosenberg, J., "A Presence Event Package for the Session
Event Package for the Session Initiation Protocol (SIP)", Initiation Protocol (SIP)", RFC 3856, August 2004.
draft-ietf-sipping-mwi-02 (work in progress), March 2003.
[17] Rosenberg, J., "Obtaining and Using Globally Routable User [17] Rosenberg, J., "A Watcher Information Event Template-Package
Agent (UA) URIs (GRUU) in the Session Initiation Protocol for the Session Initiation Protocol (SIP)", RFC 3857, August
(SIP)", draft-ietf-sip-gruu-00 (work in progress), January
2004. 2004.
[18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [18] Mahy, R., "A Message Summary and Message Waiting Indication
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Event Package for the Session Initiation Protocol (SIP)", RFC
progress), February 2003. 3842, August 2004.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[20] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.
[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
dynamicsoft Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027 New York, NY 10027
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs URI: http://www.cs.columbia.edu/~hgs
Rohan Mahy (editor) Rohan Mahy (editor)
Cisco Systems, Inc. Airespace
5617 Scotts Valley Dr 110 Nortech Parkway
Scotts Valley, CA 95066 San Jose, CA 95134
USA USA
EMail: rohan@cisco.com EMail: rohan@ekabal.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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