Internet Engineering Task Force SIP WG
Internet Draft Rosenberg,Schulzrinne
draft-rosenberg-sip-call-package-00.txt dynamicsoft,Columbia U.
July 13, 2001
Expires: February 2001
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 floor control
information. We also define two new SIP headers, To-Replace and To-
Join, that can be used to convey globally routable join and
replacement URLS. These general purpose packages and the new headers
enable many new SIP services. We discuss how they can be used to
support some of the more challenging services that have been
discussed, including single line extension, automatic callback,
Rosenberg,Schulzrinne [Page 1]
Internet Draft call-pkg July 13, 2001
unattended consultation-hold transfer, call park and pickup, and IM-
a-call.
1 Introduction
The SIP Events architecture [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 [2], watcher
information [3], and message waiting indicators [4], amongst others.
Here, we define two new packages - one for call legs, 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 calls
and conferences. In the case of call legs, we see many potential
applications that require knowledge of call-leg 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 call-legs 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 call 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.
Rosenberg,Schulzrinne [Page 2]
Internet Draft call-pkg July 13, 2001
In general, defining call-leg and conference state packages allows
for construction of distributed applications, where the application
requires information on call-leg and conference state, but is not
co-resident with the end user or conference server. We think this is
a very important piece of the SIP services model.
2 Call-Leg Event Package
This section fills in the template that is needed in order to fully
specify a SIP event package for call-leg state.
2.1 Package Name
The name of this event package is "call-leg". This package name is
carried in the Event and Allow-Events header, as defined in [1].
2.2 SUBSCRIBE Bodies
A SUBSCRIBE for a call-leg package MAY contain a body. This body
defines a filter to apply to the subscription.
A SUBSCRIBE for a call-leg 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 call legs 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 call-leg whose state has
changed. The exception is a NOTIFY sent in response to a
SUBSCRIBE. These NOTIFYs contain the complete view of call leg
state.
o The notifications contain the identities of the participants
in the call leg, the call-leg identifiers, and a join URL.
Additional information, such as the route set, CSeq numbers,
SDP information, and so on, are not included normally unless
explicitly requested.
2.3 Expiration
Call leg 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.
Rosenberg,Schulzrinne [Page 3]
Internet Draft call-pkg July 13, 2001
We do note that there are two distinct use cases for call leg state.
The first is when a subscriber is interested in the state of a
specific call leg (and they are authorized to find out about just the
state of that call leg). In that case, when the call leg 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, a default of one day for
these subscriptions is RECOMMENDED.
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. One hour is RECOMMENDED as the default.
2.4 NOTIFY Bodies
The body of the notification contains a call-leg information
document. The format of this document is described in Section 3. All
subscibers MUST support this format, and MUST list its type in an
Accept header in the SUBSCRIBE.
Other call leg 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/call-leg-
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.5 Authorization Considerations
The call-leg 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 called to
call them, subscriptions from user A be allowed. However, the
information provided in the notifications does not contain any call
leg identification information; merely an indication of whether the
user in in one or more calls, or not. Specifically, they should 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 call leg state SHOULD be sent in this case. This
Rosenberg,Schulzrinne [Page 4]
Internet Draft call-pkg July 13, 2001
authorization behavior allows a group of devices representing a
single user to all become aware of each other's state.
2.6 Generation of Notifications
Notifications are generated for the call-leg package when a new
call-leg comes into existence at a UA, or when the state of an
existing call leg changes.
For the purposes of this package, we define the states of a call leg
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 call-leg is considered terminated, and no further
state changes are possible. Multiple 2xx responses received create
additional call legs, 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.
2.7 Rate Limitations on NOTIFY
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.
3 Call-Leg Data Format
Rosenberg,Schulzrinne [Page 5]
Internet Draft call-pkg July 13, 2001
We specify an XML-based data format to describe the state of call
legs. The MIME type for this format is application/call-leg-info+xml,
consistent with the recommendations provided in RFC 3023 [5].
3.1 Structure of Call Leg Information
A call-leg-info document starts with a user tag that identitifies the
user. Within that tag are a series of call-leg tags. Each of those
use attributes to identify the call leg, using the local and remote
URIs, local and remote tags, and the Call-ID. Within the call leg
tags are a single mandatory tag which contains the status, followed
by a series of optional tags that contain additional information
about the call leg. There is also an optional tag called join, which
contains a URL that can be used to join the conference associated
with the call leg (and if there is none, one is created). There is
another pair of optional tags called replace-local and replace-
remote, which contain a URL to use that can replace the specific call
leg at either side.
The top level tag is user:
<!ELEMENT user (call-leg*)>
<!ATTLIST user uri CDATA #REQUIRED>
The mandatory uri attribute is the identifier of the user whose
call-leg state is being reported.
What follows is a series of call-leg tags:
<!ELEMENT call-leg (status,join?,replace-local?,replace-remote?,
local-sdp?,remote-sdp?,
route-set?,local-cseq?,remote-cseq?>
<!ATTLIST call-leg call-id CDATA #IMPLIED
local-uri CDATA #IMPLIED
local-tag CDATA #IMPLIED
remote-uri CDATA #IMPLIED
remote-tag CDATA #IMPLIED>
The local-uri and local-tag specify the URL and tag placed in the
From field of outgoing INVITEs, and present in the From field of
incoming INVITEs. The remote-uri and remote-tag specify the URL and
tag placed in the To field of outgoing INVITEs, and present in the
Rosenberg,Schulzrinne [Page 6]
Internet Draft call-pkg July 13, 2001
From field of incoming INVITEs. The call-id is the Call-ID for the
leg. The tag attributes are not present if the tag is not specified
(or not yet specified).
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 call-leg tag sent out in a notification might looks like:
<call-leg call-id="987@1.2.3.4" local-uri="sip:caller@bar.com"
local-tag="123" remote-uri="sip:callee@foo.com">
If a 200 OK is received, which looks like, in part:
INVITE sip:callee@foo.com SIP/2.0
From: sip:caller@bar.com;tag=123
To: sip:callee@foo.com;tag=abc
Call-ID: 987@1.2.3.4
The call-leg ID is now complete, and the notification sent out will
have a call-leg tag which looks like:
<call-leg 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">
3.2 Call Leg Subtags
There are many subtags defined for the call-leg.
The only mandatory subtag of call-leg is status.
Rosenberg,Schulzrinne [Page 7]
Internet Draft call-pkg July 13, 2001
<!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>
The optional join tag provides a URL that can be used to join any
conference associated with the call-leg. When the notifier receives
an INVITE with this URL, it MUST treat that as a request to join the
conference. The notifier can use any method to create the conference
call, if it doesn't already exist. Several approaches are described
in [6]. The format of the URL is at the discretion of the notifier.
It is RECOMMENDED that it be structured so that the notifier can
associate it with the specific call leg. As with any other
invitiations, an INVITE received with this URL SHOULD be
authenticated.
The URL MUST be globally routable.
OPEN ISSUE: Tall order. This means UAs will need a way to
generate URLs which they know are globally routable to
them.
<!ELEMENT join >
<!ATTLIST join uri CDATA #REQUIRED>
Rosenberg,Schulzrinne [Page 8]
Internet Draft call-pkg July 13, 2001
Clearly, the notifier SHOULD only insert this tag if it can execute a
multi-party conference call for the user.
3.2.3 Replace Tags
The optional replace-local and replace-remote tags provide URLs that
can be used to replace the given call leg at either side. In other
words, if A are B are in a call, and A generated a NOTIFY with a
replace-local and replace-remote tag, the replace-local URL would get
routed to A, and replace the call leg with B. The replace-remote URL
would get routed to B, and replace the call leg with A.
Replacement means that the new call leg is silently accepted, and a
BYE is sent on the old call leg.
<!ELEMENT replace-local >
<!ELEMENT replace-remote >
<!ATTLIST replace-local uri CDATA #REQUIRED>
<!ATTLIST replace-remote uri CDATA #REQUIRED>
This has the very interesting implication of removing the
need for a separate Replaces header. Instead, the URI
itself would indicate to the UA that a replaces for a
specific call leg is desired. This is very much in the
spirit of the web, and of RFC 3087 [7], where URLs are
almost always server generated, and the semantics of the
URL have meaning only within the context of the server that
created them.
Clearly, the notifier SHOULD only insert this tag if it can execute
the call replacement.
3.2.4 Discussion on Join and Replaces
The inclusion of the join and replace tags merits discussion.
Do we really need join and replaces as part of this specification? We
could instead define a Join header, and revive the Replaces header
draft. That has the benefit of being explicit. The benefit of the
approach here is that we get to define a totally different URL. By
making it globally routable, we fix the "unassisted transfer with
consultation hold" problem [8]. Specifically, this transfer variant
is hard since the transferor needs to pass, in the Refer-To header, a
globally routable URL that reaches the specific UA that is the
Rosenberg,Schulzrinne [Page 9]
Internet Draft call-pkg July 13, 2001
transfer target. Neither the Contact nor the To/From have this
property. But, by defining a specific URL just for the purposes of
replacement, we can, by definition, make it globally routable to the
UA which generated it. That seems very, very useful. It means that,
unlike Contact and To/From, this URL can be emailed, IM'd, REFERed,
placed in html, or whatever, and it is guaranteed to get to the right
place and do the right thing. Furthermore, by generating the URLs for
each call, the notifier can embed information into the URLs for
cookie functionality. Finally, using a separate URL means the join or
replace requests can go to different hosts that the ones owning the
call leg. Not sure if this is useful, though.
The replace-remote URL can only be known to a notifier for call-leg
events if its received from the other party in the call-leg in the
INVITE or 200 OK. As such, we would also propose a To-Join and To-
Replace header, which is present in either INVITE or 200 OK. It
contains a URL that can be used to replace the call leg for each
respective side. Putting them both in a NOTIFY means that other
entities besides the participants in a call can get at them, which is
possibly useful (operator barge-in, for example).
Its worth observing that currently, there is an asymmetry between the
way one joins a conference, and the way one replaces a call leg. To
join a conference call, we have agreed that one sends an INVITE to a
URL on a conference server which interprets that URL to mean "mix me
into the call with everyone else that has used the same URL". This is
exactly consistent with the approach here for joining. However, we
have defined an explicit Replaces header. Why the difference? We
should either have both a Join and Replaces header, or neither.
Indeed, there is a problem right now with ad-hoc conferences that is
related to the proposal here. Lets say A clicks a URL in a web page
that says "click here to call". This results in some call being
placed to B. At some point during the call, A decides to add another
party, C. According to the multiparty conferencing models draft [6],
A would obtain a URL for a conference server, and REFER B to that
server. However, this is totally unneeded (and bad), if B is already
a conference server! Indeed, A has no way, right now, of
ascertaining whether that URL in the web page is for a single user,
or to a conference server that automatically dials out to B. In one
case (where its a user), A would need to obtain a conference URL, and
REFER B to it. In the other, A could directly REFER C to the URL it
used to call B.
The problem is solved when we stop making assumptions about the
semantics of the URL. URLs should ideally be handed to a user, either
through interpersonal contact (i.e., on a business card), or through
a transmission mechanism that defines a specific usage for those
Rosenberg,Schulzrinne [Page 10]
Internet Draft call-pkg July 13, 2001
URLs. In the above scenario, if A wants to add C, A should not make
any assumptions about whether the URL to call B can be used for
adding users to a conference. Only B can know this. So, A needs to
ask B what URL to use to join. That can be done using the
SUBSCRIBE/NOTIFY mechanisms here (although this is a lot of overhead;
these URLs could be passed directly in the INVITE and 200 OK). B
would then provide the URL, which would be the same URL used to call
it in the case of a dial-out conference server, or a new URL obtained
by B, pointing to a conference server, if B was for an end user that
didn't want to do endpoint mixing. Indeed, many different URLs could
be used, and B is the ideal party to decide.
The local SDP tag contains the SDP used by the notifier for its end
of the call leg. 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.6 Remote SDP
The remote SDP tag contains the SDP used by the notifier for the
other end of the call leg. This tag should generally NOT be included
in the notifications, unless explicitly requested by the subscriber.
<!ELEMENT remote-sdp CDATA>
The SDP is included, verbatim, between the tags.
The route-set tag contains the route set, as defined in RFC 2543bis
[9]. It is the combination of the Record-Route and Contact headers
used for this call leg. This tag should generally NOT be included in
the notifications, unless explicitly requested by the subscriber.
<!ELEMENT route-set CDATA>
Rosenberg,Schulzrinne [Page 11]
Internet Draft call-pkg July 13, 2001
The route set is included verbatim. It is structured as a comma
separated list of URLs.
Example:
<route-set>sip:user@host,sip:user@proxy</route-set>
3.2.8 Local CSeq
The local-cseq tag contains the most recent value of the CSeq header
used by the UA in an outgoing request on the call leg. 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.9 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 call leg. 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 call legs that have
their media mixed together. This is true for all of the non-multicast
models in [6]. However, some of the models use topologies where there
is no root to which all call-legs are connected. These topologies do
not work well with the mechanism here.
Rosenberg,Schulzrinne [Page 12]
Internet Draft call-pkg July 13, 2001
This package allows a user to subscribe to a conference, identified
by a SIP URL. Ideally, this SIP URL 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 URL identifying the user.
o Their status in the conference (active, declined, departed).
o The replace URLs for the call leg connecting to that user.
o If floor control policies are in place, what the user's floor
control status is.
This section fills in the template that is needed in order to fully
specify the SIP event package for conferences.
4.1 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 SUBSCRIBE Bodies
A SUBSCRIBE for a call-leg 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
in floor control status (assuming floor control is in use).
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, status, and replace URLs. The floor control
information is not provided unless explicitly requested.
4.3 Expiration
Rosenberg,Schulzrinne [Page 13]
Internet Draft call-pkg July 13, 2001
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.
4.4 NOTIFY Bodies
The body of the notification contains a conference information
document. The format of this document is described in Section 5. All
subscibers MUST support this format, and MUST list its type in an
Accept header in the SUBSCRIBE.
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.5 Authorization Considerations
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.6 Generation of Notifications
Notifications are generated for the conference whenever a new
participant joins, a participant leaves, a dial-out attempt succeeds
or fails, floor control status changes, or the call leg replace URLs
change.
4.7 Rate Limitations on NOTIFY
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.
5 Conference Data Format
The conference data format is an XML document of MIME type
Rosenberg,Schulzrinne [Page 14]
Internet Draft call-pkg July 13, 2001
application/conference-info+xml, consistent with the recommendations
provided in RFC 3023 [5].
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 status, their replace URL, and their floor control
status.
The top level tag is conference:
<!ELEMENT conference (user*)>
<!ATTLIST conference uri CDATA #REQUIRED>
The mandatory uri attribute contains the URL used to join the
conference call (and to subscribe to its state).
What follows are a series of user tags:
<!ELEMENT user (status,replace?,floor-status?)>
<!ATTLIST user uri CDATA #REQUIRED
name CDATA #IMPLIED>
The uri attribute contains the URL 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, replace, and floor-
status.
Status contains the status of the user in the conference.
<!ELEMENT status>
<!ATTLIST status
value (active|departed|booted|failed) "active" >
Rosenberg,Schulzrinne [Page 15]
Internet Draft call-pkg July 13, 2001
The statuses have the following meaning:
active: The user is in an active call leg 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.
The replace URL is the same replace-remote URL defined for the call
leg package above. It is exposed through the conference server, so
that subscribers have, if authorized, the ability to pull a user out
of the conference.
OPEN ISSUE: Do we really want or need this? The only real
use I found was to back out of a centralized conference
server, to a point-to-point call, when only two users
remain. Is this sufficient need? Other uses?
<!ELEMENT replace>
<!ATTLIST url CDATA #IMPLIED>
The floor-status contains the status of the user as far as floor
control is concerned.
<!ELEMENT floor-status>
<!ATTLIST status
value (owner|non-owner|chair) "non-owner" >
The values have the following meaning:
owner: The user has floor control.
non-owner: The user does not have floor control.
chair: The user is the chair, and is the one who controls who
Rosenberg,Schulzrinne [Page 16]
Internet Draft call-pkg July 13, 2001
gets floor control.
OPEN ISSUE: Does this belong here? If we have a separate
floor control protocol, perhaps the notifications of state
changes are in the specific protocol for floor control. Or,
perhaps this is a separate package.
5.3 Example
The following is an example conference information document:
<conference>
<user uri="sip:jdrosen@dynamicsoft.com" name="Jonathan Rosenberg">
<status value="active"/>
<replace uri="sip:p09asd8asd-0-f88a70@dynamicsoft.com"/>
</user>
<user uri="sip:hgs@cs.columbia.edu" name="Henning Schulzrinne">
<status value="active"/>
<replace uri="sip:nj99999skasdka@cs.columbia.edu"/>
</user>
</conference>
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 [2] 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 call-leg and conference packages to obtain additional
information that can be used to construct a presence document.
7 Example Services
This section overviews some example services that can be enabled by
the extensions described here.
7.1 Automatic Callback
Rosenberg,Schulzrinne [Page 17]
Internet Draft call-pkg July 13, 2001
Automatic callback is a simple service. User A calls user B. User B
is already on the phone, and so returns a 486 Busy to the INVITE from
A. Rather than continually trying to call B, user A asks for
automatic callback. With this service, A's phone will ring when B is
available. When A picks up, A hears ringing, which is B's phone.
The call flow for this service is shown in Figure 1. In (1-3), A
calls B, but B is busy. So, in (4), A sends a SUBSCRIBE to B. This
results in a 200 OK (5) followed by a NOTIFY with the current call-
leg state for B. This is a call state document which looks like:
<user uri="sip:B@B.com">
<call-leg>
<status code="200"/>
</call-leg>
</user>
The call leg identifiers are not included in this notification,
because this is not information that A would normally be able to
obtain by sending an INVITE.
When B hangs up their call, this causes a second notify containing
document 2:
<user uri="sip:B@B.com">
<call-leg>
<status code="-1"/>
</call-leg>
</user>
A can then try the INVITE again.
7.2 Single Line Extension
In the single line extension application, we wish to have a group of
phones which are all treated as "extensions" of a single line. This
means that a call for one rings them all. As soon as one picks up,
the others stop ringing (all of that is standard forking behavior).
The additional complexity is that once the call is answered, one of
the extensions should be able to "pick up" and join the call. This
emulates the home phone behavior.
Rosenberg,Schulzrinne [Page 18]
Internet Draft call-pkg July 13, 2001
|(1) INVITE |
|---------------------------->| B is in another call
|(2) 486 Busy |
|<----------------------------|
|(3) ACK |
|---------------------------->|
| |
user |(4) SUBSCRIBE Event:call-leg |
requests|---------------------------->|
cb |(5) 200 OK |
|<----------------------------|
|(6) NOTIFY doc1 |
|<----------------------------|
|(7) 200 OK |
|---------------------------->|
| |
| |
| |
| |
| |
|(8) NOTIFY doc2 | B's other call
|<----------------------------| ends
A's phone rings|(9) 200 OK |
|---------------------------->|
A picks up |(10) INVITE |
|---------------------------->| B's phone rings
|(11) 200 OK |
|<----------------------------|
|(12) ACK |
|---------------------------->|
| |
|(13) SUBSCRIBE Expires:0 |
|---------------------------->|
|(14) 200 OK |
|<----------------------------|
| |
| |
A B
Figure 1: Automatic callback flow
This feature is enabled by the mechanisms described in this draft.
The basic idea is that the phones all share a common SIP URL, and
there is a forking proxy that forwards calls to all of them. The
Rosenberg,Schulzrinne [Page 19]
Internet Draft call-pkg July 13, 2001
belonging to the same extension group. The phones are also configured
with the address of a standard conferencing server, as described in
[10]. To support the feature, only the phones have to know about how
to do it.
The call flow for this feature is shown in Figures 2 and 3. First,
the caller sends an INVITE to call a phone in the extension group
(1). This is a normal INVITE, with a request URI of
sip:joe@joeshouse.net, for example. This INVITE arrives at the proxy
serving Joe's house. Since both extension 1 and extension 2 had
registered contacts for this URL previously (not shown), the INVITE
is forked to extension 1 (2) and extension 2 (3). Joe picks up
extension 1, generating a 200 OK to the INVITE (4). The proxy
forwards the 200 OK from extension 1 upstream (5), and cancels the
other branch (6), which causes extension B to stop ringing, and then
response 200 OK to the CANCEL (7), followed by a 487 to the INVITE
(8). The proxy ACKs the 487 (9). The caller sends an ACK for the 200
OK (10), and the caller is now talking to Joe on extension 1. In
order to keep track of that call, so that its status can be displayed
in its UI, extension 2 now generates a SUBSCRIBE for
sip:joe@joeshouse.net. This goes to the proxy (11), which forks it as
it would any normal request. It gets forked to extension 1 (12) and
extension 2 (13). Extension 2 receives its own SUBSCRIBE, and
generates a 482 Loop Detected error response (14). Extension 1
accepts the SUBSCRIBE, and sends a 200 OK (15) (its assumed that the
SUBSCRIBE was authenticated with the shared secret; the 401 and
resubmission are not shown). The 200 OK is forwarded back to
extension 2 (16). In the event that there were more than two
extensions, only a single 200 OK would still be returned to extension
2. However, as described in [1], the NOTIFY's that are generated will
allow extension 2 to find out about all of the other extensions which
accepted the subscription. In this case, its just one, extension 1.
It generates a NOTIFY (17) that contains document 1, shown below:
<user uri="sip:joe@joeshouse.net">
<call-leg local-uri="sip:joe@joeshouse.net"
remote-uri="sip:caller@foo.edu"
local-tag="00a9"
remote-tag="ffd2"
call-id="aa9@1.2.3.4">
<status code="200"/>
<replace-local uri="sip:00a9.ffd2.aa9_1-2-3-4@ex1.joeshouse.net">
<replace-remote uri="sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu">
<join uri="sip:join-00a9.ffd2.aa9_1-2-3-4@ex1.joeshouse.net">
</call-leg>
</user>
Rosenberg,Schulzrinne [Page 20]
Internet Draft call-pkg July 13, 2001
|(1) INVITE | | | |
|-------------->|(2) INVITE | | |
| |-------------->| | |
| |(3) INVITE | | |
| |------------------------------->| |
| |(4) 200 OK | | |
|(5) 200 OK |<--------------| | |
|<--------------|(6) CANCEL | | |
| |------------------------------->| |
| |(7) 200 CANCEL | | |
| |<-------------------------------| |
| |(8) 487 | | |
| |<-------------------------------| |
| |(9) ACK | | |
| |------------------------------->| |
|(10) ACK | | | |
|------------------------------>| | |
| |(11) SUBSCRIBE | | |
| |<-------------------------------| |
| |(12) SUBSCRIBE | | |
| |-------------->| | |
| |(13) SUBSCRIBE | | |
| |------------------------------->| |
| |(14) 482 | | |
| |<-------------------------------| |
| |(15) 200 OK | | |
| |<--------------| | |
| |(16) 200 OK | | |
| |------------------------------->| |
| | |(17) NOTIFY doc1| |
| | |--------------->| |
| | |(18) 200 OK | |
| | |<---------------| |
| | | | |
| | | | |
Caller Proxy Extension Extension Conf.
1 2 Server
Figure 2: Single line extension flow: Part I
Rosenberg,Schulzrinne [Page 21]
Internet Draft call-pkg July 13, 2001
This allows extension 2 to show that a call is active on the
extension group, and a UI can be provided for the call to be picked
up by someone on extension 2.
At some point, Joe's wife picks up extension 2 in order to join the
active call. That causes the phone to send an INVITE to the join URI
in the notification it received. This INVITE (19) goes directly to
extension 1. When extension 1 receives this, it knows this is a
request to join the call. It challenges and authenticates the INVITE
to make sure that its another extension in the group (not shown). It
then redirects the call, providing a Contact header which is a new
conference URI at the conference server (20). Presumably, each
extension is configured with the domain name of the conference
server, and can create conferences by choosing usernames that are
globally unique in space and time. The resulting user@domain SIP URL
can be used for ad-hoc conference calls, like this one. Extension 2
ACKs the 300 (21). Extension 1 knows it needs to join that conference
call. So, it sends an INVITE to the conference URL it just returned
to extension 2 (23), which is accepted (25) and acknowledged (26).
Extension 1 is now the only member of the call. In the meantime,
extension 1 knows that it needs to get the caller into the conference
as well. So, it sends out a REFER (22), containing a Refer-To URL
that points to the conference URL being used. The REFER is accepted
by the caller (24). Extension 2 recurses on the redirect it receives,
and sends an INVITE to the conference URL (27), which is accepted
(28) and acknowledged (29). Finally, the caller acts on the REFER,
and generates an INVITE (30) that will join it into the conference as
well. This is accepted (31) and acknowleged (32). Now, there is a
three-party conference between the caller, extension 1 and extension
2. The caller generates a NOTIFY as discussed in [8] (33) which is
accepted (34). The NOTIFY tells extension 1 that the caller has been
connected to the conference server. So, extension 1 terminates its
direct call leg with the caller (35).
If other extensions pick up, a similar thing happens - they are
redirected to the conference URL. By using a conference server, we
have the advantage that the call remains active as long as any one
extension is in the call. This also emulates typical home phone line
behavior.
OPEN ISSUE: Its not clear that extension 1 should REFER the
caller to the conference server. We want the change to the
conference server to be transparent to the caller. A REFER
will trigger a UI query at the caller, most likely. An
alternative is to have extension 1 REFER the conference
server to the caller, using the replaces URL learned from
Rosenberg,Schulzrinne [Page 22]
Internet Draft call-pkg July 13, 2001
| | |(19) INVITE | |
| | |<---------------| |
| | |(20) 300 | |
| | |--------------->| |
| | |(21) ACK | |
|(22) REFER | |<---------------| |
|<------------------------------|(23) INVITE | |
|(24) 200 OK | |------------------------------->|
|------------------------------>|(25) 200 OK | |
| | |<-------------------------------|
| | |(26) ACK | |
| | |------------------------------->|
| | | |(27) INVITE |
| | | |-------------->|
| | | |(28) 200 OK |
| | | |<--------------|
| | | |(29) ACK |
| | | |-------------->|
|(30) INVITE | | | |
|--------------------------------------------------------------->|
|(31) 200 OK | | | |
|<---------------------------------------------------------------|
|(32) ACK | | | |
|--------------------------------------------------------------->|
|(33) NOTIFY | | | |
|------------------------------>| | |
|(34) 200 OK | | | |
|<------------------------------| | |
|(35) BYE | | | |
|<------------------------------| | |
|(36) 200 OK | | | |
|------------------------------>| | |
| | | | |
| | | | |
| | | | |
Caller Proxy Extension Extension Conf.
1 2 Server
Figure 3: Single line extension flow: Part II
Rosenberg,Schulzrinne [Page 23]
Internet Draft call-pkg July 13, 2001
the caller as the Refer-To header. This works better.
However, the INVITE triggered from this will be challenged
by the caller, and its not clear how the conference server
will obtain credentials.
7.3 Unattended Consultation-Hold Transfer
In unattended consultation-hold transfer, A is talking to B. A wishes
to transfer B to C. So, A first calls C, and talks to them to OK the
transfer.If C agrees, B is connected to C.
As discussed in [8], this flow is difficult. The main problem is that
once the transfer has been verbally approved, A needs to send a REFER
to C, containing B in the Refer-To header. However, what is desired
is to refer C to that very specific instance of B. Placing the
To/From with B into the Refer-To therefore won't work, since it won't
necessarily route to the UA that user B is using. Putting the Contact
at B may not work either, since it may not be globally routable.
Our To-Replace header fixes this. By definition, it contains a
globally routable URL which can be used to replace the specific call
leg. B would return this in its 200 OK to A. When A REFERs C to B,
this URL would be placed in the Refer-To header. The result is that
the service executes perfectly.
7.4 Call Park and Pickup
In the PSTN, call park and pickup is defined as follows. Joe (using
UA A) is talking to Bob (using UA B). Joe would like to walk over to
another phone (UA C) that Joe can see, but doesn't have the number
for, and pick continue on the call at that new phone. To do that, Joe
places Bob on hold, walks over to the phone, picks it up, dials some
numbers, and then talks to Bob.
A SIP flow for call park is given in the service examples document
[11]. However, that service only works when the parking phone is the
same as the picking up phone (and thus is more like music-on-hold).
There is also a flow for pickup. This relies on registrations to
cause an in-progress INVITE to fork to the new phone. However, this
only works for calls that haven't yet completed at the first phone.
The flow for the call park and pickup service is shown in Figure 4.
First, A calls B as a normal SIP call (1-3). The INVITE (1) contains
a To-Replace header with the value sip:00a9.ffd2.aa9_1-2-3-
4@mypc.company.com, and the 200 OK has a To-Replace header with value
sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu. At some point, Joe decides
to park the call for later pickup. A simply places B on hold (4-6).
Rosenberg,Schulzrinne [Page 24]
Internet Draft call-pkg July 13, 2001
Joe walks over to another phone, C, and enters in his extension (i.e,
the identity of the phone which the call is being retrieved from). To
pickup, C needs to learn the call legs at A. So, it sends a SUBSCRIBE
to A's extension (7). The SUBSCRIBE is authenticated (Joe will need
to enter his own username and password), which is not shown, and the
resubmitted SUBSCRIBE generates a 200 OK (8). That triggers a NOTIFY
(9) which contains the call leg state at A:
<user uri="sip:A@company.com">
<call-leg local-uri="sip:A@company.com"
remote-uri="sip:B@foo.edu"
local-tag="00a9"
remote-tag="ffd2"
call-id="aa9@1.2.3.4">
<status code="200"/>
<replace-local uri="sip:00a9.ffd2.aa9_1-2-3-4@mypc.company.com">
<replace-remote uri="sip:ffd2.00a9.aa9_1-2-3-4@hispc.foo.edu">
</call-leg>
</user>
From this, C learns there is a single accepted call at A. The
notification also contains a replace-remote URL, which can be used to
replace the existing call leg at B with a new one. So, C takes that
URL, and generates an INVITE for it (15). This is authenticated and
authorized by B (specifically, B allows a call-leg to be replaced if
the authenticated identity of the new leg matches the identity of the
replaced leg), and then silently accepted (16). Now, Joe is talking
to Bob using UA C. Since B has replaced its old call leg, it sends a
BYE on it (18). UA A is now disconnected from the call.
7.5 IM a call
This service is a much "cooler" variant on transfer. A calls B, and
they talk. During the call, A wants C to take over the call. Rather
than sending a REFER to execute a transfer, A sends C an instant
message. This IM has HTML inside of it, which asks C to click on a
URL to take the call. When C clicks on it, they take over the call,
and A is disconnected.
The call flow for this is shown in Figure 5. A calls B using a
standard INVITE sequence (1-3). The 200 OK from B contains a To-
Replace URL. A decides to send the call to B using an IM. So, it
sends a MESSAGE (4) that has an HTML body. This request looks like:
Rosenberg,Schulzrinne [Page 25]
Internet Draft call-pkg July 13, 2001
| |(1) INVITE |
| |--------------------->|
| |(2) 200 OK |
| |<---------------------|
| |(3) ACK |
| |--------------------->|
| |(4) INVITE hold |user A holds
| |--------------------->|
| |(5) 200 OK |
| |<---------------------|
| |(6) ACK |
user A | |--------------------->|
picks up |(7) SUBSCRIBE | |
at C |-------------------->| |
|(8) 200 OK | |
|---------------------| |
|(9) NOTIFY doc1 | |
|<--------------------| |
|(10) 200 OK | |
|-------------------->| |
|(11) SUBSCRIBE | |
|------------------------------------------->|
|(12) 200 OK | |
|<-------------------------------------------|
|(13) NOTIFY doc2 | |
|<-------------------------------------------|
|(14) 200 OK | |
|------------------------------------------->|
|(15) INVITE | |
|------------------------------------------->|
|(16) 200 OK | |
|<-------------------------------------------|
|(17) ACK | |
|------------------------------------------->|
| |(18) BYE |
| |<---------------------|
| |(19) 200 OK |
| |--------------------->|
| | |
| | |
C A B
Figure 4: Call Park and Pickup
Rosenberg,Schulzrinne [Page 26]
Internet Draft call-pkg July 13, 2001
|(1) INVITE | |
|<----------------| |
|(2) 200 OK | |
|---------------->| |
|(3) ACK | |
|<----------------| |
| |(4) MESSAGE |
| |---------------->|
| |(5) 200 OK |
| |<----------------|
| | |
| | |
| | |
| | |
| | |
|(6) INVITE | |
|<----------------------------------|
|(7) 200 OK | |
|---------------------------------->|
|(8) ACK | |
|<----------------------------------|
|(9) BYE | |
|---------------->| |
|(10) 200 OK | |
|-----------------| |
| | |
| | |
| | |
B A C
Figure 5: Call flow for IM-a-call
MESSAGE sip:C@foo.com SIP/2.0
Via: SIP/2.0/UDP pc22.foo.com
From: sip:A@foo.com
To: sip:C@foo.com
Call-ID: 9as8da8s@1.2.3.4
CSeq: 99 MESSAGE
Content-Type: text/html
Content-Length: ...
Rosenberg,Schulzrinne [Page 27]
Internet Draft call-pkg July 13, 2001
<html>
<body>
Hi, Jack. Would you take this <a href="sip:hhggff@bar.com">call</a>?
Thanks, Bob.
</body>
</html>
Where sip:hhggff@bar.com is the URL from the To-Replace header in the
200 OK from B (message 2).
C returns a 200 OK to this MESSAGE (5). At some time later, C clicks
on the URL in the MESSAGE, which causes a call to be made to the
replace URL. This goes to B. This is a standard INVITE sequence (7-
9). Once done, since B knows this is a replace URL, it hangs up with
A (10-11).
8 Open Issues and To-Dos
There is a strong relationship between the call-leg event package,
and the notifications used by the REFER specification [8]. We believe
that these should be unified, so that a REFER basically implies a
subscription to the call leg state created by that REFER. That still
needs to be done.
There are many security issues to be worked out. Authentication of
join and replaces INVITEs are complex, and need further
investigation.
The requirement for globally routable join and replaces URLs is a
real issue. Its not clear how that can be done. Using the hostname of
the UA won't work in general, since calls may need to flow through a
proxy. This introduces the need for a UA to generate a new URL which
contains the domain name of the top-level proxy in its network, yet
is routed to that UA. The UA could then REGISTER this URL at its
proxy. This might work in some networks, but not in more complex ones
with multiple tiers of proxies, some of which use database queries to
route calls to specific users. More thinking on this is needed.
More details and examples are needed.
9 Security Considerations
Subscriptions to call-leg 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.
Rosenberg,Schulzrinne [Page 28]
Internet Draft call-pkg July 13, 2001
Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms SHOULD be used to protect it.
Furthermore, the To-Replace and To-Join URLs provide significant
power to any user that can obtain them. INVITEs to these URLs SHOULD
be authenticated and authorized.
10 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
11 Bibliography
[1] A. Roach, "SIP specific event notification," Internet Draft,
Internet Engineering Task Force, July 2001. Work in progress.
[2] J. Rosenberg et al. , "SIP extensions for presence," Internet
Draft, Internet Engineering Task Force, Apr. 2001. Work in progress.
[3] J. Rosenberg, "A SIP event sub-package for watcher information,"
Internet Draft, Internet Engineering Task Force, July 2001. Work in
progress.
[4] R. Mahy and I. Slain, "SIP extensions for message waiting
indication," Internet Draft, Internet Engineering Task Force, Feb.
2001. Work in progress.
[5] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," Request
for Comments 3023, Internet Engineering Task Force, Jan. 2001.
[6] J. Rosenberg and H. Schulzrinne, "Models for multi party
conferencing in SIP," Internet Draft, Internet Engineering Task
Rosenberg,Schulzrinne [Page 29]
Internet Draft call-pkg July 13, 2001
Force, Nov. 2000. Work in progress.
[7] J. Myers, "IMAP4 QUOTA extension," Request for Comments 2087,
Internet Engineering Task Force, Jan. 1997.
[8] R. Sparks, "SIP call control," Internet Draft, Internet
Engineering Task Force, Feb. 2001. Work in progress.
[9] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session initiation protocol," Internet Draft, Internet Engineering
Task Force, Nov. 2000. Work in progress.
[10] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
server component architecture for SIP," Internet Draft, Internet
Engineering Task Force, Mar. 2001. Work in progress.
[11] A. Johnston, R. Sparks, C. Cunningham, S. Donovan, and K.
Summers, "SIP service examples," Internet Draft, Internet Engineering
Task Force, Mar. 2001. Work in progress.
Rosenberg,Schulzrinne [Page 30]