draft-ietf-sipping-dialog-package-02.txt   draft-ietf-sipping-dialog-package-03.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: December 29, 2003 H. Schulzrinne Expires: April 24, 2004 H. Schulzrinne
Columbia University Columbia University
June 30, 2003 R. Mahy, Ed.
Cisco Systems, Inc.
October 25, 2003
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-02 draft-ietf-sipping-dialog-package-03.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 35
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 http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2003. This Internet-Draft will expire on April 24, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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 . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
3. Dialog Event Package . . . . . . . . . . . . . . . . . . . 6 3. Dialog Event Package . . . . . . . . . . . . . . . . . . 4
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 6 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . 4
3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 6 3.2 Event Package Parameters . . . . . . . . . . . . . . . . 4
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 5
3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 7 3.4 Subscription Duration . . . . . . . . . . . . . . . . . 6
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 6
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . 6
3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . 7
3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . . 9 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . 8
3.7.2 Applying the state machine . . . . . . . . . . . . . . . . 11 3.7.2 Applying the state machine . . . . . . . . . . . . . . . 10
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . 12
3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 13 3.9 Handling of Forked Requests . . . . . . . . . . . . . . 12
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 13 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 12
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 13 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . 13
4. Dialog Information Format . . . . . . . . . . . . . . . . 14 4. Dialog Information Format . . . . . . . . . . . . . . . 13
4.1 Structure of Dialog Information . . . . . . . . . . . . . 14 4.1 Structure of Dialog Information . . . . . . . . . . . . 13
4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . 14
4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3 Local URI . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4 Remote URI . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.5 Local Session Description . . . . . . . . . . . . . . . . 16 4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . . 16
4.1.6 Remote Session Description . . . . . . . . . . . . . . . . 16 4.1.6 Route-Set . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.7 Remote Target . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.1 Local and Remote elements . . . . . . . . . . . . . . . 16
4.1.8 Local CSeq . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.1.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.9 Remote CSeq . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.1.2 Target . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.10 Duration . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.1.3 Session Description . . . . . . . . . . . . . . . . . . 17
4.2 Constructing Coherent State . . . . . . . . . . . . . . . 17 4.1.6.1.4 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Constructing Coherent State . . . . . . . . . . . . . . 17
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . 23 4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . 25
6.1 application/dialog-info+xml MIME Registration . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . 25
6.1 application/dialog-info+xml MIME Registration . . . . . 25
6.2 URN Sub-Namespace Registration for 6.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 25 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . 26
6.3 Schema Registration . . . . . . . . . . . . . . . . . . . 25 6.3 Schema Registration . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 27
Normative References . . . . . . . . . . . . . . . . . . . 27 Normative References . . . . . . . . . . . . . . . . . . 27
Informative References . . . . . . . . . . . . . . . . . . 28 Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . 29 Intellectual Property and Copyright Statements . . . . . 30
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 [10], watcher events. Packages have been defined for user presence [14], watcher
information [11], and message waiting indicators [12], amongst information [15], and message waiting indicators [16], 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, the
usage of this package to model transitions in the state of those 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:
skipping to change at page 6, line 17 skipping to change at page 4, line 29
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 three Event Package parameters. They are This package defines four Event Package parameters. They are call-id,
call-id, to-tag and from-tag. If a subscription to a specific dialog to-tag, from-tag, and include-session-description. If a subscription
is requested, all three of these parameters MUST be present. They to a specific dialog is requested, all of the first three of these
identify the dialog that is being subscribed to. The to-tag is parameters MUST be present. They identify the dialog that is being
matched against the local tag, the from-tag is matched against the subscribed to. The to-tag is matched against the local tag, the
remote tag, and the call-id is matched against the Call-ID. from-tag is matched against the remote tag, and the call-id is
matched against the Call-ID. The include-session-description
parameter indicates if the subscriber would like to receive the
session descriptions associated with the subscribed dialog or
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 BNF for these parameters is: The ABNF for these parameters is shown below. It refers to many
constructions from the ABNF of RFC3261, such as word, callid, EQUAL,
DQUOTE, and token.
call-id = "call-id" EQUAL SWS DQUOTE callid DQUOTE call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;;callid, EQUAL, SWS, DQUOTE from RFC3261 ;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description"
Note that the call-id parameter is a quoted string. This is because Any callids which contain embedded double-quotes MUST escape those
the BNF for word (which is used by callid) allows for characters not double-quotes using the backslash-quoting mechanism. Note that the
allowed within token. call-id parameter may need to be expressed as a quoted string. This
is because the ABNF for callid and word (which is used by callid)
allow for some characters (such as "@", "[", and ":") which are not
allowed within a token.
3.3 SUBSCRIBE Bodies 3.3 SUBSCRIBE Bodies
A SUBSCRIBE for a dialog package MAY contain a body. This body A SUBSCRIBE 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 policy
is: 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. the SUBSCRIBE with the following exceptions. If the target
(Contact) URI of a subscriber is equivalent to the remote target
URI of a specific dialog, then the dialog element for that dialog
is suppressed for that subscriber. (The subscriber is already a
party in the dialog directly, so these notifications are
superfluous.) If no dialogs remain after supressing dialogs, the
entire notification to that subscriber is supressed and the
version number in the dialog-info element is not incremented for
that subscriber. Implicit filtering for one subscriber does not
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. The
exception is a NOTIFY sent in response to a SUBSCRIBE. These exception is a NOTIFY sent in response to a SUBSCRIBE. These
NOTIFYs contain the complete view of dialog state. NOTIFYs contain 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, and the dialog identifiers. Additional information, the dialog, and the dialog identifiers. Additional information,
such as the route set, remote target URI, CSeq numbers, SDP such as the route set, CSeq numbers, SDP information, and so on,
information, and so on, are not included normally unless are not included normally unless explicitly requested and/or
explicitly requested and/or explicitly authorized. explicitly authorized.
3.4 Subscription Duration 3.4 Subscription Duration
Dialog state changes fairly quickly; once established, a typical Dialog state changes fairly quickly; once established, a typical
phone call lasts a few minutes (this is different for other session phone call lasts a few minutes (this is different for other session
types, of course). However, the interval between new calls is types, of course). However, the interval between new calls is
typically infrequent. As such, we arbitrarily choose a default typically 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
skipping to change at page 8, line 32 skipping to change at page 7, line 15
Therefore, all subscriptions SHOULD be authenticated and then Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. All implementors of this package MUST authorized before approval. All implementors of this package MUST
support the digest authentication mechanism as a baseline. support the digest authentication mechanism as a baseline.
Authorization policy is at the discretion of the administrator, as Authorization policy is at the discretion of the administrator, as
always. However, a few recommendations can be made. always. However, a few recommendations can be made.
It is RECOMMENDED that, if the policy of user B is that user A is It is RECOMMENDED that, if the policy of user B is that user A is
allowed to call them, dialog subscriptions from user A be allowed. allowed to call them, dialog subscriptions from user A be allowed.
However, the information provided in the notifications does not However, the information provided in the notifications does not
contain any dialog identification information; merely an indication contain any dialog identification information; merely an indication
of whether the user is in one or more calls, 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. sent an INVITE. (This concept of a "virtual" dialog is discussed more
in Section 3.7.2, and an example of such a notification body is shown
below.)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>confirmed</state>
</dialog>
</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. Complete
information on the dialog state SHOULD be sent in this case. This information on the dialog state SHOULD be sent in this case. This
authorization behavior allows a group of devices representing a 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 useful
for applications such as single-line-extension. for applications such as single-line-extension.
Note that many implementations of "shared-lines" have a feature
which allows details of calls on a shared address-of-record to be
made private. This is a completely reasonable authorization policy
which could result in notifications which contain only the id
attribute of the dialog element and the state element when
shared-line privacy is requested, and notifications with more
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 for
dialogs. However, it is not explicitly modelled. This specification dialogs. However, it is not explicitly modelled. This specification
provides an explicit model of dialog state through a finite state provides an explicit model of dialog state through a finite state
machine. 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 has changed. However, if a notifier receives the dialogs whose state or participation information has changed.
a SUBSCRIBE request, the triggered NOTIFY SHOULD contain the state of However, if a notifier receives a SUBSCRIBE request, the triggered
all dialogs that the subscriber is authorized to see. NOTIFY SHOULD contain the state of all dialogs that the subscriber is
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 is
forking, which can cause a single INVITE to generate many dialogs at forking, which can cause a single INVITE to generate many dialogs at
a UAC. The second is the differing views of state at the UAC and UAS. a UAC. The second is the differing views of state at the UAC and UAS.
We have chosen to handle the first issue by extending the dialog FSM We have chosen to handle the first issue by extending the dialog FSM
to include the states between transmission of the INVITE and the to include the states between transmission of the INVITE and the
creation of actual dialogs through receipt of 1xx and 2xx responses. creation of actual dialogs through receipt of 1xx and 2xx responses.
As a result, this specification supports the notion of dialog state As a result, this specification supports the notion of dialog state
skipping to change at page 9, line 41 skipping to change at page 8, line 44
+----------+ | | +----------+ | +----------+ | | +----------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
+<--C-----C--+ |1xx-tag | +<--C-----C--+ |1xx-tag |
| | | | | | | | | |
cancelled| | | V | cancelled| | | V |
rejected| | |1xx-tag +----------+ | rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx | | +------->| | |2xx
| | | | | | | | | |
+<--C--------------| Early |-----C----+1xx-tag +<--C--------------| Early |-----C----+1xx-tag
| | | | | | w. new tag | | replaced | | | | w. new tag
| | | |<----C----+ (new | | | |<----C----+ (new
| | +----------+ | FSM | | +----------+ | FSM
| | 2xx | | instance | | 2xx | | instance
| +----------------+ | | created) | +----------------+ | | created)
| | |2xx | | | |2xx |
| | | | | | | |
V V V | V V V |
+----------+ +----------+ | +----------+ +----------+ |
| | | | | | | | | |
| | | | | | | | | |
|Terminated|<-----------| Confirmed|<----+ |Terminated|<-----------| Confirmed|<----+
| | hungup | |
| | error | | | | error | |
+----------+ timeout +----------+ | | timeout | |
| ^ +----------+ replaced +----------+
| | local-bye | ^
remote-bye | |
| | | |
+------+ +------+
2xx w. new tag 2xx w. new tag
(new FSM instance (new FSM instance
created) created)
Figure 2 Figure 3
The FSM for dialog state is shown in Figure 2. The FSM is best The FSM for dialog state is shown in Figure 3. The FSM is best
understood by considering the UAC and UAS cases separately. understood by considering the UAC and UAS cases separately.
The FSM is created in the "trying" state when the UAC sends an INVITE The FSM is created in the "trying" state when the UAC sends an INVITE
request. Upon receipt of a 1xx without a tag (the "1xx-notag" event), request. Upon receipt of a 1xx without a tag, the FSM transitions to
the FSM transitions to the "proceeding" state. Note that there is no the "proceeding" state. Note that there is no actual dialog yet, as
actual dialog yet, as defined by the SIP specification. However, defined by the SIP specification. However, there is a "half-dialog",
there is a "half-dialog", in the sense that two of the three in the sense that two of the three components of the dialog ID are
components of the dialog ID are known (the call identifier and local known (the call identifier and local tag). If a 1xx with a tag is
tag). If a 1xx with a tag is received, the FSM transitions to the received, the FSM transitions to the early state. The full dialog
early state. The full dialog identifier is now defined. Had a 2xx identifier is now defined. Had a 2xx been received, the FSM would
been received, the FSM would have transitioned to the "confirmed" have transitioned to the "confirmed" state.
state.
If, after transitioning to the "early" or ``confirmed'' states, the If, after transitioning to the "early" or "confirmed" states, the UAC
UAC receives another 1xx or 2xx respectively with a different tag, receives another 1xx or 2xx respectively with a different tag,
another instance of the FSM is created, initialized into the "early" another instance of the FSM is created, initialized into the "early"
or "confirmed" state respectively. The benefit of this approach is or "confirmed" state respectively. The benefit of this approach is
that there will be a single FSM representing the entire state of the that there will be a single FSM representing the entire state of the
invitation and resulting dialog when dealing with the common case of invitation and resulting dialog when dealing with the common case of
no forking. no forking.
If the UAC should send a CANCEL, and then subsequently receive a 487 If the UAC should send a CANCEL, and then subsequently receive a 487
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 INVITE transaction terminates with a non-2xx response for any the UAC receives a new invitation (with a Replaces [13] header) which
other reason, all FSMs spawned from that INVITE transition to the replaces the current Early or Confirmed dialog, all INVITE
terminated state with the event "rejected". transactions spawned from the replaced invitation transition to the
"terminated" state with the event "replaced". If the INVITE
transaction terminates with a non-2xx response for any other reason,
all FSMs spawned from that INVITE transition to the terminated state
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 to
the terminated state if the UAC sends a BYE or receives a BYE the terminated state if the UAC sends a BYE or receives a BYE
(corresponding to the "hungup" event), if a mid-dialog request (corresponding to the "local-bye" and "remote-bye" events as
generates a 481 or 408 response (corresponding to the "error" event), appropriate), if a mid-dialog request generates a 481 or 408 response
or a mid-dialog request generates no response (corresponding to the (corresponding to the "error" event), or a mid-dialog request
"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
receive a CANCEL request and then generate a 487 response to the receive a CANCEL request and then generate a 487 response to the
INVITE (which can occur in the proceeding and early states), the FSM INVITE (which can occur in the proceeding and early states), the FSM
transitions to the terminated state with the event "cancelled". If transitions to the terminated state with the event "cancelled". If
the UAS should generate any other non-2xx final response to the the UAS should generate any other non-2xx final response to the
INVITE request, the FSM transitions to the terminated state with the INVITE request, the FSM transitions to the terminated state with the
event "rejected". Once in the ``confirmed'' state, the transitions to event "rejected". If the UAS receives a new invitation (with a
the "terminated" state occur for the same reasons they do in the case Replaces [13] header) which replaces the current Confirmed dialog,
of UAC. the replaced invitation transition transitions to the "terminated"
state with the event "replaced". Once in the "confirmed" state, the
other transitions to the "terminated" state occur for the same
reasons they do in the case of UAC.
There should never be a transition from the "trying" state to the There should never be a transition from the "trying" state to the
"terminated" state with the event ``cancelled'', since the SIP "terminated" state with the event "cancelled", since the SIP
specification prohibits transmission of CANCEL until a provisional specification prohibits transmission of CANCEL until a provisional
response is received. However, this transition is defined in the response is received. However, this transition is defined in the
FSM just to unify the transitions from trying, proceeding, and FSM just to unify the transitions from trying, proceeding, and
early to the terminated state. early to the terminated state.
OPEN ISSUE: Since there is only one possible event to cause
transitions to the Proceeding (1xx-notag), Early (1xx-tag), and
Confirmed (2xx) states, the only events which provide any
additional information are the events for transitions to
Terminated (error, timeout, cancelled, local-bye, remote-bye and
replaced). Of these, timeout may not be relevant, since it is
often indistinguishable from "rejected" (for example, a 408) or
"error". Likewise it is unclear if there is any value in
distinguishing "local-bye" from "cancelled"; perhaps we should use
a single event, such as "local-hangup" instead.
3.7.2 Applying the state machine 3.7.2 Applying the state machine
The notifier MAY generate a NOTIFY request on any event transition of The notifier MAY generate a NOTIFY request on any event transition of
the FSM. Whether it does or not is policy dependent. However, some the FSM. Whether it does or not is policy dependent. However, some
general guidelines are provided. general guidelines are provided.
When the subscriber is unauthenticated, or is authenticated, but When the subscriber is unauthenticated, or is authenticated, but
represents a third party with no specific authorization policies, it represents a third party with no specific authorization policies, it
is RECOMMENDED that subscriptions to an individual dialog, or to a is RECOMMENDED that subscriptions to an individual dialog, or to a
specific set of dialogs, is forbidden. Only subscriptions to all specific set of dialogs, is forbidden. Only subscriptions to all
dialogs (i.e., there are no dialog identifiers in the Event header dialogs (i.e., there are no dialog identifiers in the Event header
field) are permitted. In that case, actual dialog states across all field) are permitted. In that case, actual dialog states across all
dialogs not be reported. Rather, a single "virtual" dialog FSM be dialogs will not be reported. Rather, a single "virtual" dialog FSM
used, and event transitions on that FSM be reported. If there is any be used, and event transitions on that FSM be reported.
dialog at the UA whose state is "confirmed", the virtual FSM is in
the "confirmed" state. If there are no dialogs at the UA in the If there is any dialog at the UA whose state is "confirmed", the
confirmed state, but there is at least one in the "early" state, the virtual FSM is in the "confirmed" state. If there are no dialogs at
virtual FSM is in the "early" or "confirmed" state. If there are no the UA in the confirmed state, but there is at least one in the
dialogs in the confirmed or early states, but there is at least one "early" state, the virtual FSM is in the "early" or "confirmed"
in the "proceeding" state, the virtual FSM is in the "proceeding", state. If there are no dialogs in the confirmed or early states, but
"early" or "confirmed" state. If there are no dialogs in the there is at least one in the "proceeding" state, the virtual FSM is
confirmed, early, or proceeding states, but there is at least one in in the "proceeding", "early" or "confirmed" state. If there are no
the "trying" state, the virtual FSM is in the "trying", "proceeding", dialogs in the confirmed, early, or proceeding states, but there is
"early" or "confirmed" state. The choice about which state to use at least one in the "trying" state, the virtual FSM is in the
depends on whether the UA wishes to let unknown users that their "trying", "proceeding", "early" or "confirmed" state. The choice
phone is ringing, as opposed to in an active call. It is RECOMMENDED about which state to use depends on whether the UA wishes to let
that, in the absence of any preference, "confirmed" is used in all unknown users that their phone is ringing, as opposed to in an active
cases. Furthermore, it is RECOMMENDED that the notifications of call.
changes in the virtual FSM machine not convey any information except
the state of the FSM and its event transitions - no dialog It is RECOMMENDED that, in the absence of any preference, "confirmed"
identifiers (which are ill-defined in this model in any case). The is used in all cases (as shown in the example in Section 3.6.
use of this virtual FSM allows for minimal information to be Furthermore, it is RECOMMENDED that the notifications of changes in
conveyed. A subscriber cannot know how many calls are in progress, or the virtual FSM machine not convey any information except the state
with whom, just that there exists a call. This is the same of the FSM and its event transitions - no dialog identifiers (which
information they would receive if they simply sent an INVITE to the are ill-defined in this model in any case). The use of this virtual
user instead; a 486 response would indicate that they are on a call. FSM allows for minimal information to be conveyed. A subscriber
cannot know how many calls are in progress, or with whom, just that
there exists a call. This is the same information they would receive
if they simply sent an INVITE to the user instead; a 486 response
would indicate that they are on a call.
When the subscriber is authenticated, and has authenticated itself When the subscriber is authenticated, and has authenticated itself
with the same address-of-record that the UA itself uses, if no with the same address-of-record that the UA itself uses, if no
explicit authorization policy is defined, it is RECOMMENDED that all explicit authorization policy is defined, it is RECOMMENDED that all
state transitions on dialogs that have been subscribed to (which is state transitions on dialogs that have been subscribed to (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 MAY generate a NOTIFY request on any change in the
characteristics associated with the dialog. Since these include CSeq characteristics associated with the dialog. Since these include CSeq
numbers and SDP, receipt of re-INVITEs and UPDATE requests [3] which numbers and SDP, receipt of re-INVITEs and UPDATE requests [3] which
modify this information MAY trigger notifications. modify this information MAY trigger notifications.
OPEN ISSUE: Is there a good reason to include CSeqs at all? Can
anyone come up with a use case? This seems to contradict the
"Rate of Notifications" section, and I can come up with some good
examples where this would be VERY BAD. For example, say Alice
sends an invitation to Bob, and then, on the same dialog,
subscribes to his dialog package, requesting CSeq information.
Every notification updates the CSeq which in turn generates
another notification, causing an infinite flood of messages.
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 construct
a coherent view of the total state of all dialogs, a subscriber to a coherent view of the total state of all dialogs, a subscriber to
skipping to change at page 13, line 23 skipping to change at page 13, line 8
to install subscription state for each NOTIFY generated as a result to install subscription state for each NOTIFY generated as a result
of a single SUBSCRIBE. of a single SUBSCRIBE.
3.10 Rate of Notifications 3.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds. a rate faster than once every 5 seconds.
Editors Note: This seems too slow to me. I think 1 second is
probably reasonable.
3.11 State Agents 3.11 State Agents
Dialog state is ideally maintained in the user agents in which the Dialog state is ideally maintained in the user agents in which the
dialog resides. Therefore, the elements that maintain the dialog are dialog resides. Therefore, the elements that maintain the dialog are
the ones best suited to handle subscriptions to it. However, in some the ones best suited to handle subscriptions to it. However, in some
cases, a network agent may also know the state of the dialogs held by cases, a network agent may also know the state of the dialogs held by
a user. As such, state agents MAY be used with this package. a user. As such, state agents MAY be used with this package.
4. Dialog Information Format 4. Dialog Information Format
skipping to change at page 14, line 40 skipping to change at page 14, line 9
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 dialog sub-elements. Each of The dialog-info element has a series of zero or more dialog
those represents a specific dialog. sub-elements. Each of those represents a specific dialog.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</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 a single mandatory attribute, id. The id "half-dialog". It has a single mandatory attribute, id. The id
attribute provides a single string that can be used as an identifier attribute provides a single string that can be used as an identifier
for this dialog or "half-dialog". This is a different identifier than for this dialog or "half-dialog". This is a different identifier than
the dialog ID defined in RFC 3261 [2], but related to it. 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
skipping to change at page 15, line 18 skipping to change at page 14, line 41
For a callee, the id is created when an INVITE outside of an existing For a callee, the id is created when an INVITE outside of an existing
dialog is received. When a 2xx or a 1xx with a tag is sent, creating dialog is received. When a 2xx or a 1xx with a tag is sent, creating
the dialog, the id remains unchanged. the dialog, the id remains unchanged.
The id MUST be unique amongst all dialogs at a UA. The id MUST be unique amongst all dialogs at a UA.
There are a number of optional attributes which provide There are a number of optional attributes which provide
identification information about the dialog: identification information about the dialog:
call-id: This attribute is a string which represents the call-id call-id: This attribute is a string which represents the call-id
component of the dialog identifier. component of the dialog identifier. (Note that single and double
quotes inside a call-id must be escaped using &quote; for " and
&apos; for ' .)
OPEN ISSUE: Is it legal to include escaped quotes in XML
attributes?
local-tag: This attribute is a string which represents the local-tag local-tag: This attribute is a string which represents the local-tag
component of the dialog identifier. component of the dialog identifier.
remote-tag: This attribute is a string which represents the remote-tag: This attribute is a string which represents the
remote-tag component of the dialog identifier. The remote tag remote-tag component of the dialog identifier. The remote tag
attribute won't be present if there is only a "half-dialog", attribute won't be present if there is only a "half-dialog",
resulting from the generation of an INVITE for which no final resulting from the generation of an INVITE for which no final
responses or provisional responses with tags has been received. responses or provisional responses with tags has been received.
direction: This attribute is either initiator or recipient, and direction: This attribute is either initiator or recipient, and
indicates whether the observed user was the initiator of the indicates whether the observed user was the initiator of the
dialog, or the recipient of the INVITE that created it. dialog, or the recipient of the INVITE that created it.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
...
</dialog>
</dialog-info>
The sub-elements of the dialog element provide additional information The sub-elements of the dialog element provide additional information
about the dialog. The only mandatory one is state. about the dialog. Some of these sub-elements provide more detail
about the dialog itself, while the local and remote sub-elements
describe characteristics of the participants involved in the dialog.
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 has
an optional event attribute that can be used to indicate the event an optional event attribute that can be used to indicate the event
which caused the transition into the current state, and an optional which caused any transition into the terminated state, and an
code attribute that indicates the response code associated with the optional code attribute that indicates the response code associated
transition, assuming the event was caused by a response. with any transition caused by a response to the original INVITE.
<state event="rejected" code="486">terminated</state>
4.1.3 Local URI 4.1.3 Duration
The local-uri element indicates the local URI, as defined in [2]. It The duration element contains the amount of time, in seconds, since
has an optional attribute, display-name, that contains the display the FSM was created.
name from the local URI. <duration>145</duration>
4.1.4 Remote URI 4.1.4 Replaces
The remote-uri element indicates the remote URI, as defined in [2]. The replaces element is used to correlate a new dialog with one it
It has an optional attribute, display-name, that contains the display replaced as a result of an invitation with a Replaces header. This
name from the remote URI. element is present in the replacement dialog only (the newer dialog)
and contains attributes with the call-id, local-tag, and remote-tag
of the replaced dialog.
<replaces call-id="hg287s98s89" local-tag="6762h7" remote-tag="09278hsb"/>
4.1.5 Local Session Description 4.1.5 Referred-By
The local-session-description element contains the session The referred-by element is used to correlate a new dialog with a
description used by the observed user for its end of the dialog. This REFER [12] request which triggered it. The element is present in a
element should generally NOT be included in the notifications, unless dialog which was triggered by a REFER request which contained a
explicitly requested by the subscriber. It has a single attribute, Referred-By [11] header and contains the (optional) display name
type, which indicates the MIME media type of the session description. attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by>
4.1.6 Remote Session Description 4.1.6 Route-Set
The remote-session-description element contains the session The route-set element conveys an ordered list of hop elements which
description used by the peer of the observed user for its end of the represents the complete route set of the dialog (not including the
dialog. This element should generally NOT be included in the local and remote target URIs) from the perspective of the notifier.
notifications, unless explicitly requested by the subscriber. It has
a single attribute, type, which indicates the MIME media type of the
session description.
4.1.7 Remote Target OPEN ISSUE: Does any one want/need this?
The remote-target contains the remote-target URI as constructed by <route-set>
the user agent for this dialog, as defined in RFC 3261 [2]. This <hop>sip:proxy1.example.net;lr</hop>
element should generally not be included in notifications, unless <hop>sip:proxy2.example.com;lr</hop>
explicitly requested by the subscriber. </route-set>
4.1.8 Local CSeq 4.1.6.1 Local and Remote elements
The local-cseq element contains the most recent value of the CSeq The local and remote elements are sub-elements of the dialog element
header used by the UA in an outgoing request on the dialog. This which contain information about the local and remote participants
element should generally NOT be included in the notifications, unless respectively. They both have a number of optional sub-elements which
explicitly requested by the subscriber. If no CSeq has yet been indicate the identity conveyed by the participant, the target URI,
defined, the value of the element is -1. the feature-tags of the target, and the session-description of the
participant.
4.1.9 Remote CSeq 4.1.6.1.1 Identity
The remote-cseq element contains the most recent value of the CSeq The identity element indicates a local or remote URI, as defined in
header seen by the UA in an incoming request on the dialog. This [2] as appropriate. It has an optional attribute, display-name, that
element should generally NOT be included in the notifications, unless contains the display name from the appropriate URI.
Note that multiple identities (for example a sip: URI and a tel:
URI) could be included if they all correspond to the participant.
<identity display="Anonymous">sip:anonymous@anonymous.invalid</identity>
4.1.6.1.2 Target
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"
attribute.
It can contain a list of Contact header parameters in param
sub-elements (such as those defined in [10]. The param element
contains a required pname attribute and an optional pval attribute
(some parameters merely exist and have no explicit value). The param
element itself has no contents.
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/>
<param pname="class" pval="personal"/>
</target>
4.1.6.1.3 Session Description
The session-description element contains the session description used
by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless explicitly
requested by the subscriber. It has a single attribute, type, which
indicates the MIME media type of the session description.
4.1.6.1.4 CSeq
The cseq element contains the most recent value of the CSeq header
used by the UA in an outgoing request on the dialog. This element
should generally NOT be included in the notifications, unless
explicitly requested by the subscriber. If no CSeq has yet been explicitly requested by the subscriber. If no CSeq has yet been
defined, the value of the element is -1. defined, the value of the element is -1.
4.1.10 Duration OPEN ISSUE: Is this really useful?
The duration element contains the amount of time, in seconds, since
the FSM was created.
4.2 Constructing Coherent State 4.2 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 as
conveyed in the document. The table is also associated with a version conveyed in the document. The table is also associated with a version
number. The version number MUST be initialized with the value of the number. The version number MUST be initialized with the value of the
"version" attribute from the "dialog-info" element in the first "version" attribute from the "dialog-info" element in the first
skipping to change at page 18, line 16 skipping to change at page 18, line 47
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info" xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:element name="dialog-info"> <xs:element name="dialog-info">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:dialog" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="tns:dialog" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="version" type="xs:nonNegativeInteger" <xs:attribute name="version" type="xs:nonNegativeInteger"
use="required"/> use="required"/>
<xs:attribute name="state" use="required"> <xs:attribute name="state" use="required">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="full"/> <xs:enumeration value="full"/>
<xs:enumeration value="partial"/> <xs:enumeration value="partial"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="entity" type="xs:anyURI" use="required"/> <xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="dialog"> <xs:element name="dialog">
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element ref="tns:state"/> <xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
<xs:element name="duration" type="xs:nonNegativeInteger" <xs:element name="duration" type="xs:nonNegativeInteger"
minOccurs="0"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="local-uri" type="tns:nameaddr" <xs:element name="replaces" minOccurs="0" maxOccurs="1">
minOccurs="0"/> <xs:complexType>
<xs:element name="remote-uri" type="tns:nameaddr" <xs:attribute name="call-id" type="xs:string"
minOccurs="0"/> use="required"/>
<xs:element name="local-session-description" type="tns:sessd" <xs:attribute name="local-tag" type="xs:string"
minOccurs="0"/> use="required"/>
<xs:element name="remote-session-description" type="tns:sessd" <xs:attribute name="remote-tag" type="xs:string"
minOccurs="0"/> use="required"/>
<xs:element name="remote-target" type="tns:nameaddr" </xs:complexType>
minOccurs="0"/> </xs:element>
<xs:element name="local-cseq" type="xs:nonNegativeInteger" <xs:element name="referred-by" type="tns:nameaddr"
minOccurs="0"/> minOccurs="0" maxOccurs="1"/>
<xs:element name="remote-cseq" type="xs:nonNegativeInteger" <xs:element name="route-set" minOccurs="0" maxOccurs="1">
minOccurs="0"/> <xs:complexType>
<xs:sequence>
<xs:element name="hop" type="xs:string" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="local" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:element name="remote" type="tns:participant"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" <xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:string" use="required"/>
<xs:attribute name="call-id" type="xs:string" use="optional"/> <xs:attribute name="call-id" type="xs:string"
<xs:attribute name="local-tag" type="xs:string" use="optional"/> use="optional"/>
<xs:attribute name="remote-tag" type="xs:string" use="optional"/> <xs:attribute name="local-tag" type="xs:string"
use="optional"/>
<xs:attribute name="remote-tag" type="xs:string"
use="optional"/>
<xs:attribute name="direction" use="optional"> <xs:attribute name="direction" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="initiator"/> <xs:enumeration value="initiator"/>
<xs:enumeration value="recipient"/> <xs:enumeration value="recipient"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="identity" type="nameaddr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="target" minOccurs="0" maxOccurs="1">
<xs:complexType>
<xs:sequence>
<xs:element name="param" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="optional"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:attribute name="uri" type="xs:string" use="required"/>
</xs:element>
<xs:element name="session-description" type="tns:sessd"
minOccurs="0" maxOccurs="1"/>
<xs:element name="cseq" type="xs:nonNegativeInteger"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="nameaddr"> <xs:complexType name="nameaddr">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:anyURI"> <xs:extension base="xs:anyURI">
<xs:attribute name="display-name" type="xs:string"/> <xs:attribute name="display-name" type="xs:string"
use="optional"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="sessd"> <xs:complexType name="sessd">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string"/> <xs:attribute name="type" type="xs:string" use="required"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:element name="state"> <xs:element name="state">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="xs:string"> <xs:extension base="xs:string">
<xs:attribute name="event" use="optional"> <xs:attribute name="event" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="1xx-notag"/>
<xs:enumeration value="1xx-tag"/>
<xs:enumeration value="2xx"/>
<xs:enumeration value="cancelled"/> <xs:enumeration value="cancelled"/>
<xs:enumeration value="rejected"/> <xs:enumeration value="rejected"/>
<xs:enumeration value="hungup"/> <xs:enumeration value="replaced"/>
<xs:enumeration value="local-bye"/>
<xs:enumeration value="remote-bye"/>
<xs:enumeration value="error"/> <xs:enumeration value="error"/>
<xs:enumeration value="timeout"/> <xs:enumeration value="timeout"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="code" use="optional"> <xs:attribute name="code" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:positiveInteger"> <xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="100"/> <xs:minInclusive value="100"/>
<xs:maxInclusive value="699"/> <xs:maxInclusive value="699"/>
skipping to change at page 23, line 5 skipping to change at page 24, line 23
version="4" version="4"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag="1928301774" remote-tag="hh76a"
direction="initiator"> direction="initiator">
<state event="cancelled">terminated</state> <state event="cancelled">terminated</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
EDITORS NOTE: should provide another example with a richer
notification
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
5. Security Considerations 5. 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 digest
authentication mechanism. 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.
skipping to change at page 26, line 7 skipping to change at page 27, line 14
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.3. XML: The XML can be found as the sole content of Section 4.3.
7. Acknowledgements 7. Acknowledgements
The author would like to thank Sean Olson for his comments. The authors would like to thank Sean Olson for his comments.
Normative References 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] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC-xml-20001006, October 2000. REC 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", [7] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-04 (work in progress), July
2003. 2002.
[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
Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003.
[11] Sparks, R., "The SIP Referred-By Mechanism",
draft-ietf-sip-referredby-01 (work in progress), February 2003.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[13] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation
Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-03
(work in progress), March 2003.
Informative References Informative References
[10] Rosenberg, J., "A Presence Event Package for the Session [14] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003. in progress), January 2003.
[11] Rosenberg, J., "A Watcher Information Event Template-Package [15] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January draft-ietf-simple-winfo-package-05 (work in progress), January
2003. 2003.
[12] Mahy, R., "A Message Summary and Message Waiting Indication [16] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-mwi-02 (work in progress), March 2003. draft-ietf-sipping-mwi-02 (work in progress), March 2003.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
skipping to change at page 29, line 4 skipping to change at page 29, line 4
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)
Cisco Systems, Inc.
5617 Scotts Valley Dr
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.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 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; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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