Internet Engineering Task Force SIPPING WG
Internet Draft J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia U.
draft-rosenberg-sip-call-package-01.txt
March 1, 2002
Expires: September 2002
SIP Event Packages for Call Leg and Conference State
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document defines two new event packages for the SIP Events
architecture, along with two new data formats used in notifications
for those packages. The first is a call-leg package, and the second
is a conference package. The call-leg package allows users to
subscribe to another user, an receive notifications about the changes
in state of call legs that the user is involved in. The conference
package allows users to subscribe to a URL that is associated with a
conference. Notifications are sent about changes in the membership of
this conference, changes in active speaker, and media mixing
information. These general purpose packages can enable many new SIP
services, including single line extension, automatic callback,
unattended consultation-hold transfer, call park and pickup, and IM-
J. Rosenberg et. al. [Page 1]
Internet Draft call-pkg March 1, 2002
a-call.
J. Rosenberg et. al. [Page 2]
Internet Draft call-pkg March 1, 2002
Table of Contents
1 Introduction ........................................ 5
2 Dialog Event Package ................................ 6
2.1 Event Package Name .................................. 6
2.2 Event Package Parameters ............................ 6
2.3 SUBSCRIBE Bodies .................................... 6
2.4 Subscription Duration ............................... 6
2.5 NOTIFY Bodies ....................................... 7
2.6 Notifier Processing of SUBSCRIBE Requests ........... 7
2.7 Notifier Generation of NOTIFY Requests .............. 8
2.8 Subscriber Processing of NOTIFY Requests ............ 9
2.9 Handling of Forked Requests ......................... 9
2.10 Rate of Notifications ............................... 9
2.11 State Agents ........................................ 9
3 Dialog Data Format .................................. 9
3.1 Structure of Dialog Information ..................... 10
3.2 Dialog Sub-Elements ................................. 11
3.2.1 Status .............................................. 12
3.2.2 Local SDP ........................................... 12
3.2.3 Remote SDP .......................................... 12
3.2.4 Route Set ........................................... 13
3.2.5 Remote Target ....................................... 13
3.2.6 Local CSeq .......................................... 13
3.2.7 Remote CSeq ......................................... 14
4 Conference Event Package ............................ 14
4.1 Event Package Name .................................. 15
4.2 Event Package Parameters ............................ 15
4.3 SUBSCRIBE Bodies .................................... 15
4.4 Subscription Duration ............................... 15
4.5 NOTIFY Bodies ....................................... 15
4.6 Notifier Processing of SUBSCRIBE Requests ........... 16
4.7 Notifier Generation of NOTIFY Requests .............. 16
4.8 Subscriber Processing of NOTIFY Requests ............ 16
4.9 Handling of Forked Requests ......................... 17
4.10 Rate of Notifications ............................... 17
4.11 State Agents ........................................ 17
5 Conference Data Format .............................. 17
5.1 Structute of the Format ............................. 17
5.2 User Sub-Elements ................................... 18
5.3 Example ............................................. 19
6 Relationship to User Presence ....................... 20
7 Open Issues and To-Dos .............................. 20
J. Rosenberg et. al. [Page 3]
Internet Draft call-pkg March 1, 2002
8 Security Considerations ............................. 20
9 IANA Considerations ................................. 20
10 Acknowledgements .................................... 21
11 Changes since -00 ................................... 21
12 Authors Addresses ................................... 21
13 Normative References ................................ 21
14 Informative References .............................. 22
J. Rosenberg et. al. [Page 4]
Internet Draft call-pkg March 1, 2002
1 Introduction
The SIP Events framework [1] defines general mechanisms for
subscription to, and notification of, events within SIP networks. It
introduces the notion of a package, which is a specific
"instantiation" of the events mechanism for a well-defined set of
events. Packages have been defined for user presence [3], watcher
information [4], and message waiting indicators [5], amongst others.
Here, we define two new packages - one for dialogs, and the other for
conferences.
The need for these packages is driven based on the fact that many
applications are driven off of knowledge about the progress of
dialogs and conferences. In the case of dialogs, we see many
potential applications that require knowledge of dialog state:
Automatic Callback: In this basic 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 up, user A's phone
rings. When A picks it up, they here ringing, and are being
connected to B. In VoIP, this requires A to receive a
notification when the dialogs at A are complete.
Presence-Enabled Conferencing: In this application, a user A
wishes 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 are all available. To do
this, the server providing the 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 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
therefore knows their call state. This won't always be
possible, however, and it introduces scalability,
reliability, and operational complexities. Rather, the
server would subscriber to the dialog state of those users,
and receive notifications as it changes. This enables the
application to be provided in a distributed way; the server
need not reside in the same domain as the users.
IM Conference Alerts: In this application, a user can get an IM
sent to their phone whenever someone joins a conference
that the phone is involved in. The IM alerts are generated
by an application separate from the conference server.
In general, defining dialog and conference state packages allows for
construction of distributed applications, where the application
requires information on dialog and conference state, but is not co-
J. Rosenberg et. al. [Page 5]
Internet Draft call-pkg March 1, 2002
resident with the end user or conference server. We think this is a
very important piece of the SIP services model.
2 Dialog Event Package
This section provides the details for defining a SIP Events package,
as specified by [1].
2.1 Event Package Name
The name of this event package is "dialog". This package name is
carried in the Event and Allow-Events header, as defined in [1].
2.2 Event Package Parameters
This package does not define any event package parameters.
2.3 SUBSCRIBE Bodies
A SUBSCRIBE for a dialog package MAY contain a body. This body
defines a filter to apply to the subscription.
A SUBSCRIBE for a dialog package MAY be sent without a body. This
implies the default subscription filtering policy. The default policy
is:
o Notifications are generated every time there is any change in
the state of any dialogs for the user identified in the
request URI of the SUBSCRIBE.
o Notifications do not normally contain full state; rather, they
only indicate the state of the dialog whose state has changed.
The exception is a NOTIFY sent in response to a SUBSCRIBE.
These NOTIFYs contain the complete view of dialog state.
o The notifications contain the identities of the participants
in the dialog, and the dialog identifiers. Additional
information, such as the route set, remote target URI, CSeq
numbers, SDP information, and so on, are not included normally
unless explicitly requested and/or explicitly authorized.
2.4 Subscription Duration
Dialog state changes fairly quickly; once established, a typical
phone call lasts a few minutes (this is different for other session
types, of course). However, the interval between new calls is
typically infrequent.
J. Rosenberg et. al. [Page 6]
Internet Draft call-pkg March 1, 2002
We do note that there are two distinct use cases for dialog state.
The first is when a subscriber is interested in the state of a
specific dialog (and they are authorized to find out about just the
state of that dialog). In that case, when the dialog terminates, so
too does the subscription. In these cases, the refresh interval can
be very long, since there exists an easy alternative way to destroy
subscription state. As a result, the default duration of these
subscriptions is one day. The subscriber MAY request other durations.
In another case, a subscriber is interested in the state of all call
legs for a specific user. In these cases, a shorter interval makes
more sense. The default is one hour for these subscriptions.
OPEN ISSUE: We should probably have a single default
subscription duration.
2.5 NOTIFY Bodies
The body of the notification contains a dialog information document.
The format of this document is described in Section 3. Its MIME type
is "application/dialog-info+xml". All subscribers MUST support this
format, and MUST list its type in any Accept header in the SUBSCRIBE.
When no Accept header is present in the SUBSCRIBE, its default value
is "application/dialog-info+xml".
Other dialog information formats might be defined in the future. In
that case, the subscriptions MAY indicate support for other formats.
However, they MUST always support and list "application/dialog-
info+xml" as an allowed format.
Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header in the SUBSCRIBE
request.
2.6 Notifier Processing of SUBSCRIBE Requests
The dialog information for a user contains very sensitive
information. Therefore, all subscriptions SHOULD be authenticated and
then authorized before approval. Authorization policy is at the
discretion of the administrator, as always. However, a few
recommendations can be made.
It is RECOMMENDED that if the policy of a user is that A is allowed
to call them, dialog subscriptions from user A be allowed. However,
the information provided in the notifications does not contain any
dialog identification information; merely an indication of whether
the user in in one or more calls, or not. Specifically, they should
J. Rosenberg et. al. [Page 7]
Internet Draft call-pkg March 1, 2002
not be able to find out any more information than if they sent an
INVITE.
It is RECOMMENDED that if a user agent registers with the address-
of-record X, that this user agent authorize subscriptions that come
from any entity that can authenticate itself as X. Complete
information on the dialog state SHOULD be sent in this case. This
authorization behavior allows a group of devices representing a
single user to all become aware of each other's state. This is useful
for applications such as single-line-extension.
2.7 Notifier Generation of NOTIFY Requests
Notifications are generated for the dialog package when a new dialog
comes into existence at a UA, or when the state of an existing dialog
changes.
For the purposes of this package, we define the states of a dialog
through numeric codes. These codes are equivalent to the most recent
SIP status codes sent in response to the INVITE which created the
call leg. The status code "0" is reserved for the case where no
response has yet been received or sent.
When a UAC initially creates an INVITE to establish a call, this
causes a change to state "0". When it receives the first non-100
provisional response, the state changes to the value of that status
code. Any further provisional responses cause the UA to change state
to the value of that status code. When a final response is received,
the state changes to the value of that response. If the response was
a non-200, the dialog is considered terminated, and no further state
changes are possible. Multiple 2xx responses received create
additional dialogs, each with the state of that specific 2xx.
When a UAS initially receives an INVITE to establish a call, this
causes a change to the state of the provisional response which was
sent. Any subequent provisional responses cause a change in state to
the value of that response. A final response causes a transition in
state to that response code. There is no change in state when the ACK
arrives. However, if no ACK is received, and the UAS destroys the
call, the state changes to a value of -1.
When the call is terminated as a result of a BYE, the state changes
to -1.
OPEN ISSUE: This is kind of ugly. We could alternately
define a more formal state machine.
J. Rosenberg et. al. [Page 8]
Internet Draft call-pkg March 1, 2002
2.8 Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to contruct a coherent
view of the state of the subscribed resource.
Typically, the NOTIFY for the dialog package will only contain
information about those dialogs whose state has changed. To construct
a coherent view of the total state of all dialogs, a subscriber to
the dialog package will need to combine NOTIFYs received over time.
The subscriber maintains is complete dialog list in a table, indexed
by the id. This ID is different from the formal dialog ID as defined
in [2], which is the concatenation of the local tag, remote tag, and
Call-Id. This ID is conveyed in the id attribute of the dialog
element of the "application/dialog-info+xml" type. If the dialog
information in a NOTIFY has a dialog listed with an ID not in the
table, an entry is added to that table. The version number from the
dialog element is also extracted, and placed in the table. If the
dialog information in a NOTIFY has a dialog listed with an ID in the
table, and the version in the NOTIFY is greater than the version
stored in the table, the dialog information in the table for that
dialog is updated, including the version number. If a dialog is
updated such that its status is now "-1", that entry MAY be removed
from the table at any time.
2.9 Handling of Forked Requests
A forked SUBSCRIBE request for dialog state can install multiple
subscriptions. Subscribers to this package MUST be prepared to
install subscription state for each NOTIFY generated as a result of a
single SUBSCRIBE.
2.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds.
2.11 State Agents
Dialog state is ideally maintained in the user agents in which the
dialog resides. Therefore, the elements that maintain the dialog are
the ones best suited to handle subscriptions to it. Therefore, the
usage of state agents is NOT RECOMMENDED for this package.
3 Dialog Data Format
J. Rosenberg et. al. [Page 9]
Internet Draft call-pkg March 1, 2002
We specify an XML-based data format to describe the state of a
dialog. The MIME type for this format is "application/dialog-
info+xml", consistent with the recommendations provided in RFC 3023
[6].
3.1 Structure of Dialog Information
A dialog-info document starts with a user tag that identitifies the
user. Within that tag are a series of dialog tags. Each of those use
attributes to identify the dialog and provide its version number.
There are also attributes to provide the formal dialog identifier,
using the local and remote tags, and the Call-ID. Additional
attributes are present to specify the local and remote URIs. There is
also an attribute that indicates whether the user initiated this
dialog or not. Within the dialog tags are a single mandatory tag
which contains the status, followed by a series of optional tags that
contain additional information about the dialog.
The top level tag is user:
<!ELEMENT user (dialog*)>
<!ATTLIST user uri CDATA #REQUIRED>
The mandatory uri attribute is the identifier of the user whose
dialog state is being reported.
What follows is a series of dialog tags:
<!ELEMENT dialog (status,local-sdp?,remote-sdp?,
route-set?,remote-target?,local-cseq?,remote-cseq?)
<!ATTLIST dialog id CDATA #REQUIRED
version CDATA #REQUIRED
call-id CDATA #IMPLIED
local-uri CDATA #IMPLIED
local-tag CDATA #IMPLIED
remote-uri CDATA #IMPLIED
remote-tag CDATA #IMPLIED
direction (iniatiator|recipient) #IMPLIED>
The local-uri, local-tag, remote-uri, remote-tag and call-id
attributes convey their corresponding components of the dialog state
as defined in [2]. The direction attribute is "initiator" if the user
J. Rosenberg et. al. [Page 10]
Internet Draft call-pkg March 1, 2002
initiated this dialog, and "recipient" if it did not. The remote tag
attribute won't be present if there is only a "half-dialog",
resulting from generation of a request that can create a dialog.
For example, if a UAC sends an INVITE that looks like, in part:
INVITE sip:callee@foo.com SIP/2.0
From: sip:caller@bar.com;tag=123
To: sip:callee@foo.com
Call-ID: 987@1.2.3.4
the dialog tag sent out in a notification might looks like:
<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
local-uri="sip:caller@bar.com"
local-tag="123" remote-uri="sip:callee@foo.com"
direction="initiator">
If a 200 OK is received, which looks like, in part:
SIP/2.0 200 OK
From: sip:caller@bar.com;tag=123
To: sip:callee@foo.com;tag=abc
Call-ID: 987@1.2.3.4
The dialog is now confirmed, and the notification sent out will have
a dialog tag which looks like:
<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
local-uri="sip:caller@bar.com"
local-tag="123" remote-uri="sip:callee@foo.com"
remote-tag="abc" direction="initiator">
3.2 Dialog Sub-Elements
There are many sub-elements defined for the dialog element.
J. Rosenberg et. al. [Page 11]
Internet Draft call-pkg March 1, 2002
3.2.1 Status
The only mandatory sub-element of dialog is status.
<!ELEMENT status CDATA>
<!ATTLIST status code CDATA #REQUIRED>
The mandatory code attribute contains the status code. This is the
SIP response code last sent or received for this leg in the initial
INVITE that established the leg. If no response has been sent or
received, the value of zero is used. If the call ends, a value of -1
is used.
The value within the status tag is a textual phrase that can be
rendered to described call status. The reason phrase from the
response is RECOMMENDED.
Example:
<status code="180">Ringing</status>
3.2.2 Local SDP
The local SDP tag contains the SDP used by the notifier for its end
of the dialog. This tag should generally NOT be included in the
notifications, unless explicitly requested by the subscriber.
<!ELEMENT local-sdp CDATA>
The SDP is included, verbatim, between the tags.
3.2.3 Remote SDP
The remote SDP tag contains the SDP used by the notifier for the
other end of the dialog. This tag should generally NOT be included in
the notifications, unless explicitly requested by the subscriber.
<!ELEMENT remote-sdp CDATA>
J. Rosenberg et. al. [Page 12]
Internet Draft call-pkg March 1, 2002
The SDP is included, verbatim, between the tags.
3.2.4 Route Set
The route-set tag contains the route set as constructed by the user
agent for this dialog, as defined in RFC BBBB [2]. It is constructed
from the Record-Route header field used for this dialog. This tag
should generally NOT be included in the notifications, unless
explicitly requested by the subscriber.
<!ELEMENT route-set CDATA>
The route set is included verbatim. It is structured as a comma
separated list of URLs.
Example:
<route-set>sip:proxy2.example.com;lr</route-set>
3.2.5 Remote Target
The remote-target contains the remote-target URI as constructed by
the user agent for this dialog, as defined in RFC BBBB [2]. It is
constructed from the Contact header of the INVITE. This tag should
generally not be included in notifications, unless explicitly
requested by the subscriber.
<!ELEMENT remote-target CDATA>
The remote target URI is included verbatim between the tags.
Example:
<remote-target>sip:user@pc33.example.com</remote-target>
3.2.6 Local CSeq
J. Rosenberg et. al. [Page 13]
Internet Draft call-pkg March 1, 2002
The local-cseq tag contains the most recent value of the CSeq header
used by the UA in an outgoing request on the dialog. This tag should
generally NOT be included in the notifications, unless explicitly
requested by the subscriber.
<!ELEMENT local-cseq CDATA>
The numeric value of the CSeq is included as the CDATA.
3.2.7 Remote CSeq
The remote-cseq tag contains the most recent value of the CSeq header
seen by the UA in an incoming request on the dialog. This tag should
generally NOT be included in the notifications, unless explicitly
requested by the subscriber.
<!ELEMENT remote-cseq CDATA>
The numeric value of the CSeq is included as the CDATA.
4 Conference Event Package
The conference event package allows a user to subscribe to a
conference. A conference is a collection of users that are all able
to communicate with each other. Generally, when multicast is not
used, a conference is associated by a set of dialogs that have their
media mixed together. This is true for all of the non-multicast
models in [7]. However, some of the models use topologies where there
is no root to which all dialogs are connected. These topologies do
not work well with the mechanism here.
This package allows a user to subscribe to a conference, identified
by a SIP URI. Ideally, this SIP URI routes the SUBSCRIBE to the
entity acting as the root of the topology (which is why it doesn't
work well for the non-centralized topologies). The notifications
contain information on the participants in the conference. The
specific information conveyed is:
o The SIP URI identifying the user.
o The dialog state associated with that users attachment to the
conference.
J. Rosenberg et. al. [Page 14]
Internet Draft call-pkg March 1, 2002
o Their status in the conference (active, declined, departed).
o Their status in terms of receiving media in the conference.
This section provides the details for defining a SIP Events package,
as specified by [1].
4.1 Event Package Name
The name of this event package is "conference". This package name is
carried in the Event and Allow-Events header, as defined in [1].
4.2 Event Package Parameters
This event package does not define any event package parameters.
4.3 SUBSCRIBE Bodies
A SUBSCRIBE for a dialog package MAY contain a body. This body
defines a filter to apply to the subscription.
A SUBSCRIBE for a conference package MAY be sent without a body. This
implies the default subscription filtering policy. The default policy
is:
o Notifications are generated every time there is any change in
the set of users participating in the conference, or a change
their state (dialog state, media mixing state, etc.)
o Notifications do not normally contain full state; rather, they
only indicate the state of the participant whose state has
changed. The exception is a NOTIFY sent in response to a
SUBSCRIBE. These NOTIFYs contain the complete view of
conference state.
o For a given user, the notifications contain the identity
information and status.
4.4 Subscription Duration
The default expiration time for a subscription to a conference is one
hour. Of course, once the conference ends, all subscriptions to that
particular conference are terminated, with a reason of "noresource"
[1].
4.5 NOTIFY Bodies
The body of the notification contains a conference information
J. Rosenberg et. al. [Page 15]
Internet Draft call-pkg March 1, 2002
document. The format of this document is described in Section 5. Its
MIME type is "application/conference-info+xml". All subscibers MUST
support this format, and MUST list its type in an Accept header in
the SUBSCRIBE. The default value for the Accept header when it is not
present in a request is "application/conference-info+xml".
Other conference information formats might be defined in the future.
In that case, the subscriptions MAY indicate support for other
formats. However, they MUST always support and list
"application/conference-info+xml" as an allowed format.
Of course, the notifications generated by the server MUST be in one
of the formats specified in the Accept header in the SUBSCRIBE
request.
4.6 Notifier Processing of SUBSCRIBE Requests
The conference information contains very sensitive information.
Therefore, all subscriptions SHOULD be authenticated and then
authorized before approval. Authorization policy is at the discretion
of the administrator, as always. However, a few recommendations can
be made.
It is RECOMMENDED that all users in the conference be allowed to
subscribe to the conference.
4.7 Notifier Generation of NOTIFY Requests
Notifications SHOULD be generated for the conference whenever a new
participant joins, a participant leaves, and a dial-out attempt
succeeds or fails. Notifications MAY be generated for the conference
whenever the media mixing status of a user changes.
4.8 Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to contruct a coherent
view of the state of the subscribed resource.
Typically, the NOTIFY for the conference package will only contain
information about those users whose state has changed. To construct a
coherent view of the total state of the entire conference, a
subscriber to the conference package will need to combine NOTIFYs
received over time. The subscriber maintains is complete user list in
a table, indexed by the id in the dialog element. If the dialog
information in a NOTIFY has a dialog listed with an ID not in the
table, an entry is added to that table. The version number from the
J. Rosenberg et. al. [Page 16]
Internet Draft call-pkg March 1, 2002
dialog element is also extracted, and placed in the table. If the
dialog information in a NOTIFY has a dialog listed with an ID in the
table, and the version in the NOTIFY is greater than the version
stored in the table, the dialog information in the table for that
dialog is updated, including the version number. If a dialog is
updated such that its status is now "-1", that entry MAY be removed
from the table at any time.
4.9 Handling of Forked Requests
By their nature, the conferences supported by this package are
centralized. Therefore, SUBSCRIBE requests for a conference should
not generally fork. Users of this package MUST NOT install more than
a single subscription as a result of a single SUBSCRIBE request.
4.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds.
4.11 State Agents
Conference state is ideally maintained in the element in which the
conference resides. Therefore, the elements that maintain the
conference are the ones best suited to handle subscriptions to it.
Therefore, the usage of state agents is NOT RECOMMENDED for this
package.
5 Conference Data Format
The conference data format is an XML document of MIME type
"application/conference-info+xml", consistent with the
recommendations provided in RFC 3023 [6].
5.1 Structute of the Format
The conference data format has the top level tag of conference. It
consists of a set of sub-tags of type user, which contain information
on the users in the conference. Each user tag contains the identity
of the user, their dialog information, their status in the
conference, and their media reception information.
The top level tag is conference:
<!ELEMENT conference (user*)>
J. Rosenberg et. al. [Page 17]
Internet Draft call-pkg March 1, 2002
<!ATTLIST conference uri CDATA #REQUIRED>
The mandatory uri attribute contains the URI used to join the
conference call (and to subscribe to its state).
What follows are a series of user tags:
<!ELEMENT user (status,dialog,media-status?)>
<!ATTLIST user uri CDATA #REQUIRED
name CDATA #IMPLIED>
The uri attribute contains the URI for the user. This is a logical
identifier, not a machine specific one (i.e., its taken from the
To/From, not the Contact). The name is a textual name for rendering
to a human. It is ususally taken from the display name.
5.2 User Sub-Elements
The sub-elements of the user tag are status, dialog aned media-
status.
Status contains the status of the user in the conference.
<!ELEMENT status>
<!ATTLIST status
value (active|departed|booted|failed) "active" >
The statuses have the following meaning:
active: The user is in an active dialog with the conference
host.
departed: The user sent a BYE, thus leaving the conference.
booted: The user was sent a BYE by the conference host, booting
them out of the conference.
failed: The conference host is a dialout conference server, and
its attempt to contact the specific user resulted in a
non-200 class final response.
J. Rosenberg et. al. [Page 18]
Internet Draft call-pkg March 1, 2002
The dialog element is the same one from the dialog package above.
The media-status attribute is a series of media streams. Each media
stream is associated with a media type, a sending status, and a
receiving status.
<!ELEMENT media-status (media-stream*)>
<!ELEMENT media-stream>
<!ATTLIST media-stream
type (audio|video|message|application) #REQUIRED
send-status (received-by-all|muted) "received-by-all"
recv-status (receiving-all|anchor-only) "receiving-all">
If the send-status is "received-by-all", it means that the media for
that stream that is being generated by the user is being mixed by the
server and sent to all recipients. "muted" means that no one is
receiving their media. If the receive-status is "receiving-all" it
means that the user is hearing all other participants. If it is
"anchor-only", the user is hearing media from just a single
participant.
5.3 Example
The following is an example conference information document:
<conference>
<user uri="sip:jdrosen@dynamicsoft.com" name="Jonathan Rosenberg">
<status value="active"/>
<dialog id="as7d900as8" version="0" call-id="987@1.2.3.4"
local-uri="conference3@example.com"
local-tag="123" remote-uri="sip:jdrosen@dynamicsoft.com"
remote-tag="abc" direction="recipient"/>
<media-status>
<media-stream type="audio"/>
</media-status>
</user>
<user uri="sip:hgs@cs.columbia.edu" name="Henning Schulzrinne">
<status value="active"/>
<dialog id="as7d900as8" version="0" call-id="654@8.8.7.7"
local-uri="conference3@example.com"
local-tag="xyz" remote-uri="sip:hgs@cs.columbia.edu"
remote-tag="efg" direction="recipient"/>
</user>
</conference>
J. Rosenberg et. al. [Page 19]
Internet Draft call-pkg March 1, 2002
This document describes a conference with two users, both of which
are active.
6 Relationship to User Presence
The SIP events package for user presence [3] has a close relationship
with these two event packages. It is fundamental to the presence
model that the information used to obtain user presence is
constructed from any number of different input sources. Examples of
such sources include SIP REGISTER requests and uploads of presence
documents. These two packages can be considered another mechanism
that allows a presence agent to determine the presence state of the
user. Specifically, a user presence server can act as a subscriber
for the dialog and conference packages to obtain additional
information that can be used to construct a presence document.
7 Open Issues and To-Dos
o There is a strong relationship between the dialog event
package, and the notifications used by the REFER specification
[8]. Should these be unified, so that a REFER basically
implies a subscription to the dialog state created by that
REFER?.
o Reuse of dialogs for conference and dialog subscriptions needs
to be discussed. It has an implication for the dialog state
package. Now, the session may be terminated, but the dialog
remains.
o Need to add IANA considerations
o Should we split this into two documents, or even four?
Probably two.
8 Security Considerations
Subscriptions to dialog state and conference state can reveal very
sensitive information. For this reason, the document recommends
authentication and authorization, and provides guidelines on sensible
authorization policies.
Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME SHOULD be used to protect it.
9 IANA Considerations
TODO.
J. Rosenberg et. al. [Page 20]
Internet Draft call-pkg March 1, 2002
10 Acknowledgements
The authors would like to thank Dan Petrie for his comments.
11 Changes since -00
o Alignment with bis and sip-events
o Added direction attribute to dialog format
o Removed To-Join and To-Replace header, along with joining and
replacing URIs from the various formats.
o Conference data format reuses dialog formats
o Added media mixing information to conference format
o Removal of example services (will go into service examples
specification)
o Removal of floor control from conference package; rather,
place it into a separate event package, as was done in
12 Authors Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
13 Normative References
[1] A. Roach et al. , "SIP-specific event notification," Internet
Draft, Internet Engineering Task Force, Feb. 2002. Work in progress.
[2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
J. Rosenberg et. al. [Page 21]
Internet Draft call-pkg March 1, 2002
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
14 Informative References
[3] J. Rosenberg, "SIP extensions for presence," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Work in progress.
[4] J. Rosenberg, "A SIP event sub-package for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[5] R. Mahy and I. Slain, "SIP event package for message waiting
indication," Internet Draft, Internet Engineering Task Force, Nov.
2001. Work in progress.
[6] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request
for Comments 3023, Internet Engineering Task Force, Jan. 2001.
[7] J. Rosenberg and H. Schulzrinne, "Models for multi party
conferencing in SIP," Internet Draft, Internet Engineering Task
Force, Nov. 2001. Work in progress.
[8] R. Sparks, "The refer method," Internet Draft, Internet
Engineering Task Force, Oct. 2001. Work in progress.
Full Copyright Statement
Copyright (c) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
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
revoked by the Internet Society or its successors or assigns.
J. Rosenberg et. al. [Page 22]
Internet Draft call-pkg March 1, 2002
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
J. Rosenberg et. al. [Page 23]