BLISS A. Johnston, Ed.
Internet-Draft Avaya
Expires: January 14, 2009 M. Soroushnejad
V. Venkataramanan
Sylantro Systems Corp
P. Pepper
Citel Technologies
A. Kumar
Yahoo Inc.
July 13, 2008
The Multiple Appearance Feature using the Session Initiation Protocol
(SIP)
draft-johnston-bliss-mla-req-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2009.
Abstract
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as Multiple Appearances (MA) since
Johnston, et al. Expires January 14, 2009 [Page 1]
Internet-Draft SIP MA July 2008
SIP does not have lines. This feature is commonly offered in the IP
Centrex services and IP-PBX offerings and is likely to be implemented
on SIP IP telephones and SIP feature servers used in a business
environment. This document lists requirements and compares
implementation options for this feature. Extensions to the SIP
dialog event package are proposed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 4
3.2. BLA Call Group . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Options . . . . . . . . . . . . . . . . . . . . 6
5.1. Appearance Implementation Options . . . . . . . . . . . . 9
5.1.1. URI parameter Approach . . . . . . . . . . . . . . . . 10
5.1.2. Dialog Package Parameter . . . . . . . . . . . . . . . 10
5.1.3. Appearance Selections Mechanisms . . . . . . . . . . . 13
5.2. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Comparison of Appearance Selection Methods . . . . . . 21
6. User Interface Considerations . . . . . . . . . . . . . . . . 22
6.1. Appearance Number Rendering . . . . . . . . . . . . . . . 22
6.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 22
6.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 22
6.1.3. Multiple Appearance UAs with Fixed Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1.4. Multiple Appearance UAs with Variable Appearance
Number . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. Call State Rendering . . . . . . . . . . . . . . . . . . . 23
7. Interop with non-MA UAs . . . . . . . . . . . . . . . . . . . 24
7.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 24
7.2. Appearance Release . . . . . . . . . . . . . . . . . . . . 24
7.3. UAs Supporting Dialog Events but Not MA . . . . . . . . . 25
8. Provisioning Considerations . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. SIP Event Package Parameter: ma . . . . . . . . . . . . . 25
9.2. URN Sub-Namespace Registration: ma-dialog-info . . . . . . 26
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 26
10. Appendix A - Incoming Appearance Assignment . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
13. Informative References . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Johnston, et al. Expires January 14, 2009 [Page 2]
Internet-Draft SIP MA July 2008
1. Introduction
The feature and functionality requirements for SIP user agents (UAs)
supporting business telephony applications differ greatly from basic
SIP user agents, both in terms of services and end user experience.
In addition to basic SIP support, many of the services in a business
environment require the support for SIP extensions such as REFER [3],
SUBSCRIBE/NOTIFY primitives [4], the SIP Replaces [5] and Join [9]
header fields, etc. Many of the popular business services have been
documented in the SIP Service Examples [6].
This specification details a method for implementing a group
telephony feature known in telephony as Bridged Line Appearance (BLA)
or Multiple Line Appearances (MLA), one of the more popular advanced
features expected of SIP IP telephony devices in a business
environment. Other names for this feature include Shared Call/Line
Appearance (SCA), Shared Call Status and Multiple Call Appearance
(MCA). A variant of this feature is known as Single Line Extension.
This document looks at how this feature can be implemented using
standard SIP RFC 3261 [2] in conjunction with RFC 3265 [4] for
exchanging status among user agents, and the SIP dialog state event
package [7] to exchange dialog state information to achieve the same.
Different approaches will be discussed including the use of URI
parameters, feature tags, and dialog package extensions along with
the strengths and weaknesses of the various approaches.
A call flow for Single Line Extension was formerly included in the
SIP Service Examples [6]. However, the attempt to implement using
standard SIP primitives ultimately failed, leading to its removal
from that document. This document defines SIP extensions to
implement this service.
In traditional telephony, the line is physical. A common scenario is
for a number of business telephones to share a single or a small
number of lines. The appearance number relates to the user interface
for the telephone - typically each appearance has a visual display
(lamp that can change color or blink) and a button (used to select
the appearance). In SIP terms, the line is virtual. However, the
concept of appearance is still relevant to SIP due to the user
interface considerations. It is important to keep the appearance
number construct because:
1. Human users are used to the concept and will expect it in
replacement systems (e.g. an overhead page announcement says "Joe
pickup line 3").
Johnston, et al. Expires January 14, 2009 [Page 3]
Internet-Draft SIP MA July 2008
2. It is a useful structure for user interface representation.
3. There are cases where for bandwidth or gateway limitations, it is
useful to limit the number of concurrent sessions.
In this document, we will use the term "appearance" as a stand-in for
"line appearance" since SIP does not have lines. Note that this does
not mean that a conventional telephony user interface (lamps and
buttons) must be used - implementations may use another metaphor as
long as the appearance number is readily apparent to the user.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1] and
indicate requirement levels for compliant mechanisms.
3. Usage Scenarios
The following examples are common applications of the Multiple
Appearances feature and are mentioned here as informative use cases.
All these example usages can be supported by the Multiple Appearances
feature described in this document. The differences relate to the
user interface considerations of the device.
3.1. Executive/Assistant Arrangement
The appearances on the executive's UA may also appear on the
assistant's UA. The assistant may answer incoming calls to the
executive and then place the call on hold for the executive to pick
up. The assistant can always see the state of all calls on the
executive's UA.
3.2. BLA Call Group
Users with similar business needs or tasks can be assigned to
specific groups and share the line appearances of each other on each
others SIP telephony devices. For example, an IT department staff of
five might answer a help line which has three appearances on each
phone in the IT work area. A call answered on one phone can be put
on hold and picked up on another phone. A shout or an IM to another
staff member can result in them taking over a call on a particular
appearance. Another phone can request to be added to an appearance
resulting in a conference call.
Johnston, et al. Expires January 14, 2009 [Page 4]
Internet-Draft SIP MA July 2008
3.3. Single Line Extension
In this scenario, incoming calls are offered to a group of UAs. When
one answers, the other UAs are informed. If another UA in the group
selects the line (i.e. goes off hook), it is immediately bridged or
joined in with the call. This mimics the way residential telephone
extensions usually operate.
4. Requirements
The basic requirements of the multiple appearance feature can be
summarized as follows:
REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
can be answered by any of them.
REQ-2 Each UA in the group must be able to learn the call status of
the others in the group for the purpose of rendering this information
to the user.
REQ-3 Calls can be joined (also called bridged or conferenced
together) or can be picked up (taken) by another UA in the group in a
secure way.
REQ-4 The mechanism should require the minimal amount of
configuration. UAs registering against the group AOR should be able
to learn about each other and join the appearance group.
REQ-5 The mechanism must scale for large numbers of appearances, n,
and large numbers of UAs, N, without introducing excessive messaging
traffic.
REQ-6 Each call or session (incoming or outgoing) must be assigned a
common "appearance" number from a managed pool administered for the
AOR group. Once the session has terminated, the appearance number is
released back into the pool and can be reused by another incoming or
outgoing session.
REQ-7 Each UA in the group must be able to learn the appearance
status of the the group.
REQ-8 There must be mechanisms to resolve appearance contention among
the UAs in the group.
REQ-9 The mechanism must allow all UAs receiving an incoming session
request to select the same appearance number at the time of alerting.
Johnston, et al. Expires January 14, 2009 [Page 5]
Internet-Draft SIP MA July 2008
REQ-10 The mechanism must have a way of reconstructing appearance
state after an outage that does not result in excessive traffic and
processing.
REQ-11 The mechanism must have backwards compatibility such that a UA
which is unaware of the feature can still register against the group
AOR and make and receive calls.
REQ-12 The mechanism must not allow UAs outside the group to select
or manipulate appearance numbers.
REQ-13 For privacy reasons, there must be a mechanism so that
appearance information is not leaked outside the group of UAs. (e.g.
"So who do you have on line 1?")
REQ-14 The mechanism must support a way for UAs to request
exclusivity on a line appearance. Exclusivity means that the UA
requesting it desires to have a private conversation with the
external party and other UAs must not be allowed to barge-in.
Exclusivity may be requested at the start of an incoming or outgoing
session or during the session. An exclusivity request may be
accepted or rejected by the entity providing the MA service.
Therefore, the mechanism must provide a way of communicating the
result back to the requester UA.
REQ-15 The mechanism should support a way for a UA to select a
particular appearance number for outgoing requests prior to sending
the actual request. This is often called seizure.
REQ-16 The mechanism should support a way for a UA to select a
particular appearance number and also send the request at the same
time. This is needed when a ringdown feature is combined with
multiple appearances - in this case, seizing the line is the same
thing as dialing.
5. Implementation Options
Many of the requirements for this service can be met using standard
SIP mechanisms such as:
- A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
- The SIP Dialog Package meets REQ-2.
- The SIP Replaces and Join header fields meets REQ-3.
- The SIP Registration Package meets REQ-4.
Johnston, et al. Expires January 14, 2009 [Page 6]
Internet-Draft SIP MA July 2008
- The use of a State Agent for the Dialog Package meets REQ-5.
REQ-6 suggests the need for an entity which manages the appearance
resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a Multiple Appearance group has a
single point of control of the appearance shared resource. This is
defined as an Appearance Agent for a group. While an Appearance
Agent can be part of a centralized server, it could also be co-
resident in a member User Agent who has taken on this functionality
for a group. The Appearance Agent learns the group state either by
subscribing to the dialog state of each member UA individually or by
dialog state publications from members.
While the appearance resource could be managed co-operatively by a
group of UAs without any central control, this is not discussed in
this draft, but instead is left as a research project for future
standardization. It is also possible that the Appearance Agent logic
could be distributed in all UAs in the group. For example, rules
that govern assigning appearance numbers for incoming requests (e.g.
lowest available appearance number) and rules for contention handling
(e.g. when two UAs request the use of the same appearance number,
hash dialog identifiers and compare with the lowest hash winning)
would need to be defined and implemented.
REQs 6-13 can be implemented using a number of approaches, as
discussed in the following sections.
Figure 1 illustrates the SIP components involved in supporting these
common requirements of the Multiple Appearance using standard SIP
messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
Johnston, et al. Expires January 14, 2009 [Page 7]
Internet-Draft SIP MA July 2008
+----------------------------+ +----+
| | | |
| Appearance Agent | | UA |
| | | |
+----------------------------+ +----+
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
| | |(Event:reg) | | registration sip:alice@example.com|
| | V | | events V
| | +--------------------+ +----------+7)Query+--------+
| | | (example.com) | | |<===== | |
| | | |3) Store| Location | | Proxy |
| | | Registrar |=======>| Service | | |
| | | | | |=====> | |
| | +--------------------+ +----------+8)Resp +--------+
| | ^ ^ | |
| | | | 2) REGISTER (alice) | |
| | | | | |
| | +----+ +----+ | |
| | | | | | | |
| | |UA1 | |UA2 | | |
| | | | | | | |
| | +----+ +----+ | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| +----+ | | | | |
| | | +--------------------------------------+ |
| +----+-------------------------------------------+
| | 8) INVITE
+--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog)
Figure 1.
The next section discusses normal SIP operations used to implement
parts of the multiple appearance feature.
1. The Appearance Agent SUBSCRIBES to the registration event package
as outlined in [8] for contacts registered to the group AOR.
Thus, it has knowledge of all User Agents registered against the
AOR at any point of time.
2. UAs (UA1 and UA2 in Figure 1) belong to the appearance group and,
after authentication, register against the same AOR (e.g.,
sip:alice@example.com).
3. Each registration is stored in the Location Service.
4. The registrar notifies the Appearance Agent of successful
registration at each UA.
Johnston, et al. Expires January 14, 2009 [Page 8]
Internet-Draft SIP MA July 2008
5. UAs PUBLISH their dialog state to the State Agent in the
Appearance Agent. Alternatively, the Appearance Agent could
SUBSCRIBE to the dialog state of each UA in the group.
6. The UAs SUBSCRIBE to the Appearance Agent for the state of all
dialogs as defined in [7]. The Request-URI of the SUBSCRIBE
could be either the AOR of the group, the Contact URI information
it received in the incoming subscription from the Appearance
Agent, or a provisioned URI.
7. The UAs PUBLISH their dialog information to the Appearance Agent
every time their dialog state changes (i.e. receive an INVITE,
enter alerting state, answer a call, terminate a call, generate
an INVITE, etc.) Note that alternatively the Appearance Agent
could also SUBSCRIBE to the dialog state of each UA in the group.
8. Forking Proxy forks an incoming INVITE for the AOR address to the
registered user agents.
The User Agents in the group could SUBSCRIBE to each other and NOTIFY
dialog state events, but in a large group the User Agents have to
manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State
Agent in the Appearance Agent helps in managing large groups better.
Further, the State Agent can filter dialog state events and NOTIFY
User Agents of the dialog state events which are required for the
application or feature. The State Agent can also SUBSCRIBE to dialog
state events with filters to reduce the number of NOTIFY messages
exchanged between the State Agent and the user agents in the group.
This allows a group of N UAs to each only establish a pair of dialog
state subscriptions (one in each direction) to learn the dialog state
of all other group members. This results in 2N total subscriptions
for the entire group. A full mesh of subscriptions without a state
agent would result in N(N-1) total subscriptions.
The Appearance Agent can select the appearance number for an incoming
call. An Appearance agent can use the registration event package to
learn how many UAs are part of the group. The Appearance Agent sends
a NOTIFY of dialog state events to all the User Agents.
5.1. Appearance Implementation Options
This section discusses and compares two methods of implementing,
conveying, and selecting appearances in SIP while meeting the
requirements of Section 4. One approach involves a URI parameter and
is discussed in section 5.1.1. The other approach uses a SIP dialog
package extension parameter and is discussed in section 5.1.2. Both
approaches assume the common elements and operations of Figure 1. In
addition, this section discusses approaches for incoming appearance
indication, REQ-9, and appearance contention, REQ-8. These
approaches will be discussed for an example appearance group of N
phones each with n line appearances. The usage of the word phone
Johnston, et al. Expires January 14, 2009 [Page 9]
Internet-Draft SIP MA July 2008
does not imply that this feature is limited to telephony devices.
5.1.1. URI parameter Approach
Some implementations of this feature utilize a URI parameter such as
"line=3" on the Contact URI. Each appearance is effectively a
logical UA, so each line appearance requires a separate registration.
The number of line appearances needs to be provisioned on each phone.
Each appearance also requires a separate dialog package subscription.
Even using a State Agent for the dialog package, each phone must
maintain n subscriptions to the dialog package.
This results in 2nN total subscriptions and nN registrations for this
implementation.
Since Contact URI parameters will be conveyed by the dialog package,
REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in nN SUBSCRIBEs and NOTIFYs.
It is not obvious how to meet REQ-11 with this approach. A UA
registering against the AOR but does not implement the appearance URI
parameter will not include a line appearance number in Contact URIs
and dialog package NOTIFYs. The Appearance Agent will have no way of
indicating to the other UAs the appearance number being used by this
UA, as adding a parameter to the Contact URI would cause call control
operations such as Replaces and Join to fail.
REQs 12 and 13 are difficult to meet with this approach as the line
appearance number will be present in the Request-URI of incoming
requests and the Contact URI in INVITE and 200 OK messages. This
approach will require integrity protection of all dialog creating
requests and responses, and privacy mechanisms to hide the Contact
URI from other UAs.
Also, this approach will require mechanisms to protect against
another UA sending an INVITE directly to a group member with the line
appearance number already set.
5.1.2. Dialog Package Parameter
Instead of the URI parameter approach, consider an extension
parameter "appearance" to the SIP dialog package. The e.g.:
Johnston, et al. Expires January 14, 2009 [Page 10]
Internet-Draft SIP MA July 2008
...
In this approach, the appearance number is never carried in a
Request-URI or Contact URI. Instead, it is only present in dialog
package NOTIFY and PUBLISH messages. As a result, only a single
registration per AOR is required. Also, only a single dialog package
subscription in each direction per AOR.
This results in 2N total subscriptions and N registrations for this
approach.
If the dialog package is extended to carry the appearance number,
then REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
each UA and line number to obtain the current dialog state - this
will result in N SUBSCRIBEs and NOTIFYs.
REQ-11 can be met by this approach. Even though a UA does not
provide an appearance number in dialog package NOTIFYs, the
Appearance Agent can assign one and include it in NOTIFYs to the
other UAs. This parameter would simply be ignored by the UAs that
did not understand the parameter, and have no impact on call control
operations.
REQs 12 and 13 are met because the appearance number is only conveyed
in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies
can be achieved using normal SIP mechanisms independent of the
security mechanisms used for other requests.
Johnston, et al. Expires January 14, 2009 [Page 11]
Internet-Draft SIP MA July 2008
The dialog-package [7] describes a mechanism whereby shared-line
privacy REQ-14 can be accomplished by suppressing certain dialog
information from being presented to the UAs. The reasoning behind
that is if the UAs were unaware of a dialog's call-id, local-tag and
remote-tag then they will be unable to create requests such as INVITE
with Join [9] or Replaces [5] headers to barge-in or pickup the line
appearance. Below is a quote from section 3.6 of dialog-package[7]
that describes this approach:
Note that many implementations of "shared-lines" have a feature that
allows details of calls on a shared address-of-record to be made
private. This is a completely reasonable authorization policy that
could result in notifications that 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.
There are certain fundamental drawbacks in the privacy-by-obscurity
approach described in [7]. It models exclusivity as a static
property of the appearance AOR. There are situations where
exclusivity needs to be a dynamic property (e.g. boss does not want
secretary to listen-in on a particular part of the conversation). In
addition, [7] does not address how a UA can request exclusivity at
the start of a session or mid-session and how that request will be
granted or rejected.
Exclusivity being a dynamic property means that a UA can request it
to be turned on or off in the middle of a session. When exclusivity
is turned off all the UAs that share the line AOR will need to see
the complete dialog information. Once they have that information it
can not be taken back from them. This will not allow exclusivity to
be turned on later on in the dialog lifetime. Therefore, there needs
to be a centralized entity that will actually enforce exclusivity.
The approach proposed for meeting REQ-14 is to include an exclusivity
parameter to the dialog package. This allows a UA to request
exclusivity, by setting the exclusive parameter in notifications.
This could be done prior to a call being made or answered, or during
a call at any time. A UA can remove exclusivity by sending a
notification at any time during a call and setting "exclusive=no".
It also allows a UA to learn that a particular dialog is exclusive by
the presence of this parameter in a NOTIFY. In addition, a UA can
still apply policy to any INVITE Join or Replaces requests it
receives, as per normal SIP call control mechanisms.
With this approach, the number of appearances is centrally managed
and controlled by the Appearance Agent. For UAs with soft keys or
buttons, this gives a great deal of flexibility in system management.
Johnston, et al. Expires January 14, 2009 [Page 12]
Internet-Draft SIP MA July 2008
5.1.3. Appearance Selections Mechanisms
Regardless of how the appearance number is conveyed by UAs, there is
still the issue of how appearance numbers are selected. For example,
some UAs might have actual buttons and lamps, and pressing a
particular button requires the UA to reserve a particular appearance
number. For devices with this type of user interface, the selection
must be done before the user continues with the call and dials digits
or a URI. Other UAs with different user interfaces can be flexible
at the time of dialing, updating the display with the appearance
number at a later date. For devices which require advance appearance
selection, there are three options discussed in the following
sections for meeting REQ-15.
5.1.3.1. Floor Control Appearance Selection Mechanism
This approach models each appearance number as a floor (shared
resource) and uses a floor control server to arbitrate exclusive
access (seizure of a particular appearance number). This approach
uses a standard SIP Event State Compositor (ESC), a standard Floor
Control Server that uses the Appearance Agent as Moderator. The
Binary Floor Control Protocol (BFCP) is used between the UAs and the
Floor Control Server. A Registrar/Forking Proxy Server talks to
Appearance Agent about incoming calls. The Appearance Agent acts as
a Moderator for the floor control server and tells forking proxy to
insert the appearance number in incoming and outgoing requests.
Appearance numbers are allocated/selected/reserved in two ways:
For incoming calls, the Forking Proxy interacts with the Appearance
Agent. The Appearance Agent selects an appearance by taking a
particular floor and marking it "moderator controlled". This
appearance number is then included by the Forking Proxy in INVITEs
using the Alert-Info parameter. When a UA answers the call, it takes
the appearance number from the Alert-Info and includes it in the
dialog state publication. It then requests the floor associated with
the appearance number from the floor control server, which forwards
the request to the Appearance Agent (moderator). The Appearance
Agent correlates the floor control request with the dialog state
notification with the dialog ID from the INVITE with the Alert-Info.
If they match, the floor is granted. If they do not match, it means
the floor request is not an answer of the call but is a random
appearance selection by the UA and will be rejected.
For outgoing calls, the UA sends an INVITE and requests a particular
floor from the floor control server. Depending on the User Interface
requirements, the floor request can be done before or after sending
the INVITE. The floor grant policy for most appearances is set to
Johnston, et al. Expires January 14, 2009 [Page 13]
Internet-Draft SIP MA July 2008
"first come first serve". Once the floor has been granted and the
call answered, the dialog state publication by the UA will include
the appearance number.
When a call has ended, the UA releases the floor to the floor control
server and this appearance is now available for incoming and outgoing
calls.
When a UA in the group which does not support BFCP is in a call, the
Appearance Agent will grant the floor associated with that appearance
to that UA. When that call is over, the Appearance Agent will
release the floor. Since the UA will not publish the appearance
number to the ESC, the Appearance Agent will need to do that on their
behalf. If the UA does publish dialog state but without the
appearance number, the Appearance Agent will still need to re-publish
the dialog state including the appearance number. UAs in the group
will be able to recognize these two dialogs as one since they will
have the same SIP dialog ID.
5.1.3.2. INVITE Appearance Selection Mechanism
This is an alternative approach that utilizes sending an INVITE to
select/reserve/seize an appearance number.
A UA that does not need to select a particular appearance number (or
doesn't care) would just send an INVITE as normal. The Appearance
Agent would tell the proxy which appearance number was being used by
inserting this information in a header field in the first non-100
provisional response sent back to the calling UA. The UA would then
PUBLISH this appearance number to the Dialog Event State Compositor
for the AOR which would distribute details of the dialog and the
appearance number to the other UAs in the group.
If an INVITE is sent and no appearance number is available, the proxy
would reject the INVITE with a suitable response code and perhaps a
header field indication.
A UA that does need to select a particular appearance number would
use an approach similar to overlap dialing (multi-stage dialing). An
INVITE would be sent when the appearance number is requested (i.e.
when the button is pressed, before dialing begins). The appearance
number selected would be carried in the INVITE, in a header field or
in the Request-URI, for example. The proxy would reject the INVITE
with a 484 Address Incomplete response (see RFC 3578) if the
appearance number is Available and start a timer. The UA could then
resend the INVITE after the URI has been dialed and then PUBLISH this
appearance number to the ESC. If the appearance number is not
available, another response code such as 403 would be sent. The user
Johnston, et al. Expires January 14, 2009 [Page 14]
Internet-Draft SIP MA July 2008
could then select a different appearance number and resend the
INVITE. If no INVITE with a matching Call-ID is received before the
timer expires, the appearance seizure is cancelled and is made
available for other calls.
Note that this approach does not actually require a B2BUA, but it
does require a proxy that can act as a UAS and communicate with an
Appearance Agent which keeps track of appearance number allocations.
Figure 2 shows a call flow for a UA which does not need to seize an
appearance. The proxy inserts a header field into F8 which tells
Alice which appearance number is being used for this call. Alice
then publishes this to the other UAs in the group so they know this
appearance is available. When the proxy sees the BYE F16, it frees
up the appearance number, and Alice publishes the end of the dialog
which tells the other UAs the appearance number is no longer in use.
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |--------------->| INVITE F5 |
|<---------------| 100 F4 |--------------->|
| |<---------------| |
| | | 180 F6 |
| | 180 F7 |<---------------|
| 180 (app=2) F8 |<---------------| |
|<---------------| | 200 F9 |
| | 200 F10 |<---------------|
| 200 F11 |<---------------| |
|<---------------| | |
| ACK F12 | | |
|--------------->| ACK F13 | |
| |--------------->| ACK F14 |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | BYE F16 |<---------------|
| BYE F17 |<---------------| |
|<---------------| | |
| 200 F18 | | |
|--------------->| 200 F19 | |
| |--------------->| 200 F20 |
| | |--------------->|
| | | |
Johnston, et al. Expires January 14, 2009 [Page 15]
Internet-Draft SIP MA July 2008
Figure 2. Call Flow for UA without Seizure
Figure 3 below shows the call flow for a normal appearance selection
or seizure. The INVITE F1 and F4 would use the same Call-ID and
From, but the To and Request URI would differ. F1 would have some
pre-defined URI while F4 would have the actual dialed number/URI. F1
would be sent at appearance seizure while F4 would be sent when the
call is dialed.
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE (app=2) F1 | |
|--------------->| | |
| 484 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | | |
|--------------->| INVITE F5 | |
| 100 F6 |--------------->| INVITE F7 |
|<---------------| 100 F8 |--------------->|
| |<---------------| |
| | | 180 F9 |
| | 180 F10 |<---------------|
| 180 (app=2) F11|<---------------| |
|<---------------| | 200 F12 |
| | 200 F13 |<---------------|
| 200 F14 |<---------------| |
|<---------------| | |
| ACK F15 | | |
|--------------->| ACK F16 | |
| |--------------->| ACK F17 |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F18 |
| | BYE F19 |<---------------|
| BYE F20 |<---------------| |
|<---------------| | |
| 200 F21 | | |
|--------------->| 200 F22 | |
| |--------------->| 200 F23 |
| | |--------------->|
| | | |
Figure 3. Successful Appearance Seizure Call Flow
Johnston, et al. Expires January 14, 2009 [Page 16]
Internet-Draft SIP MA July 2008
Figure 4 shows a race condition in which the seizure fails. In this
flow, the first appearance selected by Alice in F1 is not available,
perhaps due to a race condition where another incoming or outgoing
call used the appearance Alice thought was available. Alice then
selects another appearance in F4 which is available. Then, Alice
completes the call using F7.
Johnston, et al. Expires January 14, 2009 [Page 17]
Internet-Draft SIP MA July 2008
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE (app=2) F1 | |
|--------------->| | |
| 403 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE (app=3) F4 | |
|--------------->| | |
| 484 F5 | | |
|<---------------| | |
| ACK F6 | | |
|--------------->| | |
| INVITE F7 | | |
|--------------->| INVITE F8 | |
| 100 F9 |--------------->| INVITE F10 |
|<---------------| 100 F11 |--------------->|
| |<---------------| |
| | | 180 F12 |
| | 180 F13 |<---------------|
| 180 (app=3) F14|<---------------| |
|<---------------| | 200 F15 |
| | 200 F16 |<---------------|
| 200 F17 |<---------------| |
|<---------------| | |
| ACK F18 | | |
|--------------->| ACK F19 | |
| |--------------->| ACK F20 |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F21 |
| | BYE F22 |<---------------|
| BYE F23 |<---------------| |
|<---------------| | |
| 200 F24 | | |
|--------------->| 200 F25 | |
| |--------------->| 200 F26 |
| | |--------------->|
| | | |
Figure 4. Un-Successful Appearance Seizure Call Flow
Figure 5 shows an appearance seizure timeout. In this flow, Alice
successfully seizes an appearance with F1 but waits too long before
completing the call in F4. As a result, the appearance has timed out
and reassigned to another incoming or outgoing call. As a result,
Johnston, et al. Expires January 14, 2009 [Page 18]
Internet-Draft SIP MA July 2008
the proxy sends 403 and Alice has to try to seize a new appearance in
F7 which succeeds. The call is completed in F10. Note that this
call flow is the worse case scenario of a seizure timeout, then
reassignment of the appearance.
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE (app=2) F1 | |
|--------------->| | |
| 484 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| | | |
| Too much time passes | |
| | | |
| INVITE F4 | | |
|--------------->| | |
| 403 F5 | | |
|<---------------| | |
| ACK F6 | | |
|--------------->| | |
| INVITE (app=3) F7 | |
|--------------->| | |
| 484 F8 | | |
|<---------------| | |
| ACK F9 | | |
|--------------->| | |
| INVITE F10 | | |
|--------------->| INVITE F11 | |
| 100 F12 |--------------->| INVITE F13 |
|<---------------| 100 F14 |--------------->|
| |<---------------| |
| | | 180 F15 |
| | 180 F16 |<---------------|
| 180 (app=3) F17|<---------------| |
|<---------------| | 200 F18 |
| | 200 F19 |<---------------|
| 200 F20 |<---------------| |
|<---------------| | |
| ACK F21 | | |
|--------------->| ACK F22 | |
| |--------------->| ACK F23 |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F24 |
Johnston, et al. Expires January 14, 2009 [Page 19]
Internet-Draft SIP MA July 2008
| | BYE F25 |<---------------|
| BYE F26 |<---------------| |
|<---------------| | |
| 200 F27 | | |
|--------------->| 200 F28 | |
| |--------------->| 200 F29 |
| | |--------------->|
| | | |
Figure 5. Appearance Seizure Timeout Call Flow
5.1.3.3. PUBLISH Appearance Selection Mechanism
The approach used in previous versions of this draft is to use the
PUBLISH (or NOTIFY) to the event state compositor to select an
appearance number. This approach requires a special event state
compositor and special behavior on the part of the UA.
In the selection of an appearance for requests initiated by UAs in
the group, there is the possibility of contention where more than one
UA select the same appearance number.
One way to solve this and meet REQ-8 is to require UAs to send a
notification (trying) to the Appearance Agent indicating the
appearance number to be used for the session. The Appearance Agent
would confirm the allocation of the appearance number in a NOTIFY
sent to the group UAs. Should the appearance number be unavailable
or otherwise not allowed, there are two options:
- The notification could be rejected with a 500 response and a Retry-
After header field. The Appearance Agent would send an immediate
NOTIFY indicating that the appearance is unavailable. If the NOTIFY
is received before the expiration of the Retry-After time, the
notification state information would become out of date and would be
discarded without resending. The UA would select another appearance
number and send another notification.
- The notification could be accepted but an immediate NOTIFY
generated by the Appearance Agent indicating that the appearance is
unavailable. The UA would then select another appearance number and
PUBLISH again.
UAs would wait for a notification from the Appearance Agent before
sending the INVITE.
Johnston, et al. Expires January 14, 2009 [Page 20]
Internet-Draft SIP MA July 2008
5.2. Comparison
In comparing the URI parameter and the dialog package parameter,
there are clear differences in the number of registrations and
subscriptions, with the dialog package approach requiring n times
fewer in both cases.
The security model for the dialog package parameter approach is much
cleaner, since only NOTIFYs need integrity and privacy. The security
model for the URI parameter approach would likely require a B2BUA
which introduces many undesirable properties.
The dialog package parameter approach has better backwards
compatibility than the URI parameter approach.
In summary, the dialog package parameter approach better meets REQs
5, 10, 11, 12, and 13 while the URI parameter approach better meets
REQ-9. However, the combined dialog package parameter approach and
the Alert-Info parameter approach meets REQ-9.
The rest of this document discusses the dialog package parameter
approach.
5.2.1. Comparison of Appearance Selection Methods
All three approaches meet REQ-15 and REQ-16.
Previous versions of this draft proposed the publish/notify method of
appearance selection. The advantage of this approach is that the
appearance number is only carried in one place (dialog package XML
documents) and the same protocol/mechanism is used to select and
learn appearance numbers. The disadvantage of this approach is that
a specialized event state compositor must be used, since it is aware
of appearance numbers. Also, concerns have been raised about whether
this approach defines new semantics for publish/notify beyond that in
RFC 3265.
The floor control approach makes good reuse of existing protocols
such as Binary Floor Control Protocol (BFCP) and cleanly models the
state. However, while BFCP can be used in conferencing applications,
it is unlikely most UAs implementing multiple appearances would
utilize the protocol. Also, having appearance state in two places
(dialog package XML documents and floor control messages) complicates
the application. Also, BFCP only runs over TCP and requires a
separate offer/answer exchange to establish the connection, making
operation through NATs and firewalls more difficult.
The INVITE approach does not require any new protocols and makes only
Johnston, et al. Expires January 14, 2009 [Page 21]
Internet-Draft SIP MA July 2008
small behavior changes to the UA operation. It reuses standard
overlap dialing methods defined in RFC 3574. As such, it seems a
good candidate for standardization. An open issue is how to set the
Request-URI in the first INVITE and the way the proxy conveys the
appearance number to UAs in 18x or 2xx responses.
6. User Interface Considerations
The "appearance number" allocated to a call is an important concept
that enables calls to be handled by multiple devices with
heterogeneous user interfaces in a manner that still allows users to
see a consistent model. Careful treatment of the appearance number
is essential to meet the expectations of the users. Also, rendering
the correct call/appearance state to users is also important.
6.1. Appearance Number Rendering
Since different UAs have different user interface capabilities, it is
usual to find that some UAs have restrictions that others do not.
Perfect interoperability across all UAs is clearly not possible, but
by careful design, interoperability up to the limits of each UA can
be achieved.
The following guidelines suggest how the appearance number should be
handled in three typical user interface implementations.
6.1.1. Single Appearance UAs
These devices are constrained by only having the capability of
displaying status indications for a single appearance. Despite this,
it is important that devices of this type do not ignore the
appearance number. The UA should still send messages annotated with
an appropriate appearance number (i.e. "0"). Any call indications
for appearances other than for number "0" should be rejected with a
486 or 480 response.
6.1.2. Dual Appearance UAs
These devices are essentially single line phones that implement call
waiting. They have a very simple user interface that allows them to
switch between two appearances (toggle or flash hook) and perhaps
audible tones to indicate the status of the other appearance.
6.1.3. Multiple Appearance UAs with Fixed Appearance Number
This UA is the typical 'business-class' hard-phone. A number of
appearances are typically configured statically and labeled on
Johnston, et al. Expires January 14, 2009 [Page 22]
Internet-Draft SIP MA July 2008
buttons, and calls may be managed using these configured appearances.
Any calls outside this range should be ignored, and not mapped to a
free button. Users of these devices often select specific appearance
numbers for outgoing calls, and the UA will need to select the
appearance number and wait for confirmation from the Appearance Agent
before proceeding with calls.
6.1.4. Multiple Appearance UAs with Variable Appearance Number
This UA is typically a soft-phone or graphically rich user interface
hard-phone. In these cases, even the idea of an appearance index may
seem unnecessary. However, for these phones to be able to interwork
successfully with other phone types, it is important that they still
use the appearance index to govern the order of appearance of calls
in progress. No specific guidance on presentation is given except
that the order should be consistent. Thought should also be given to
how an appearance number that has no call associated with it should
be rendered to the user. These devices can typically make calls
without waiting for confirmation from the Appearance Agent on the
appearance number.
The problems faced by each style of user interface are readily seen
in this example:
1. A call arrives at the MA group, and is assigned an appearance
number of 0. All UAs should be able to render to the user the
arrival of this call.
2. Another call arrives at the MA group, and is assigned an
appearance number of 1. The single appearance UA should not
present this call to the user. Other user agents should have no
problems presenting this call distinctly from the first call.
3. The first call clears, releasing appearance number "0". The
single appearance UA should now be indicating no calls since it
is unable to manage calls other than on the first appearance.
Both multiple appearance UAs should clearly show that appearance
number 0 is now free, but that there is still a call on
appearance number 1.
4. A third call arrives, and is assigned the appearance number of 0.
All UAs should be able to render the arrival of this new call to
the user. Multiple appearnce UAs should continue to indicate the
presence of the second call, and should also ensure that the
presentation order is related to the appearance number and not
the order of call arrival.
6.2. Call State Rendering
UAs that implement the MA feature typically have a user interface
that provides the state of other appearances in the group. As dialog
Johnston, et al. Expires January 14, 2009 [Page 23]
Internet-Draft SIP MA July 2008
state NOTIFYs from the Appearance Agent are processed, this
information can be rendered. Even the simplest user interface
typically has three states: idle, active, and hold. The idle state,
usually indicated by lamp off, is indicated for an appearance when
the appearance number is not associated with any dialogs, as reported
by the Appearance Agent. The active state, usually indicated by a
lamp on, is indicated by an appearance number being associated with
at least one dialog, as reported by the Appearance Agent. The hold
state, often indicated by a blinking lamp, means the call state from
the perspective of the UA in the MA group is hold. This can be
determined by the presence of the "sip+rendering=no" feature tag with
the local target URI. Note that the hold state of the remote target
URI is not relevant to this display. For joined dialogs, the state
is rendered as hold only if all local target URIs are indicated with
the "sip+rendering=no" feature tag.
7. Interop with non-MA UAs
It is desirable to allow a basic UA that does not directly support MA
to be part of a MA group. To support this the Proxy must collaborate
with the Appearance Agent. This is not required in the basic MA
architecture, consequently MA interop with non-MA UAs will not be
available in all MA deployments.
First, a UA which does not support dialog events or the MA feature
will be discussed. Then, a UA which does support dialog events but
not the MA feature will be discussed.
7.1. Appearance Assignment
A UA that has no knowledge of appearances must have appearance
numbers assigned by the Appearance Agent for both incoming and
outgoing calls. The Appearance Agent will know about this type of UA
as the UA will be registered against the AOR but not subscribed to
the dialog events for the AOR. If the non-MA UA does not support
Join or Replaces, all dialogs could be marked "exclusive" to indicate
that these options are not available.
7.2. Appearance Release
In all cases the Appearance Agent must be aware of dialog lifetime to
release appearances back into the group.
It is also desirable that any dialog state changes (such as hold,
etc) be made available to other UAs in the group through the Dialog
Event Package. If the Appearance Agent includes a proxy which
Record-Routes for dialogs from the non-MA aware UA, the Appearance
Johnston, et al. Expires January 14, 2009 [Page 24]
Internet-Draft SIP MA July 2008
Agent will know about the state of dialogs including hold, etc. This
information could be determined from inspection of INVITE and re-
INVITE messages and added to the dialog information conveyed to other
UAs.
7.3. UAs Supporting Dialog Events but Not MA
Interoperability with UAs which support dialog events but not the MA
feature is more straightforward. As before, all appearance number
assignment must be done by the Appearance Agent. This type of UA
will be detected by the Appearance Agent by the absence of the ma
event parameter in SUBSCRIBE or PUBLISH messages. The Appearance
Agent can include appearance information in NOTIFYs - this UA will
simply ignore this extra information. This type of UA will ignore
appearance number limitations and may attempt to Join or Replace
dialogs marked exclusive. As a result, the Proxy or UAs may need to
reject such requests.
The need for close cooperation between the Proxy and the Appearance
Agent is not needed as the Appearance Agent will learn about all
dialogs from the UA itself.
8. Provisioning Considerations
TBD.
9. IANA Considerations
This section registers the SIP Alert-Info header field parameter
"appearance" and the XML namespace extensions to the SIP Dialog
Package.
9.1. SIP Event Package Parameter: ma
This specification also defines a new event parameter "ma" for the
Dialog Package.
Johnston, et al. Expires January 14, 2009 [Page 25]
Internet-Draft SIP MA July 2008
9.2. URN Sub-Namespace Registration: ma-dialog-info
This section registers a new XML namespace per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:ns:ma-dialog-info.
Registrant Contact: IETF BLISS working group, ,
Alan Johnston
XML:
BEGIN
Multiple Appearance Dialog Information Namespace
Namespace for Multiple Appearance Dialog Information
urn:ietf:params:xml:ns:dialog-info
See
RFCXXXX.
END
9.3. XML Schema Registration
This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:ma-dialog-info.
Registrant Contact: IETF BLISS working group, ,
Alan Johnston
The XML for this schema can be found in Section 7.
Johnston, et al. Expires January 14, 2009 [Page 26]
Internet-Draft SIP MA July 2008
10. Appendix A - Incoming Appearance Assignment
To best meet REQ-9, the appearance number for an incoming INVITE
should be contained in the INVITE itself.
For the dialog package parameter approach, REQ-9 could be met in two
ways. When an incoming request is received, the Appearance Agent
could send out a NOTIFY with state trying and include the appearance
number to be used for this request. Upon receipt of this NOTIFY, the
UAs could begin alerting using the appearance number selected. This
approach is sub-optimal since the UAs could receive the INVITE but be
unable to begin alerting if the NOTIFY from the Appearance Agent is
delayed or lost
An alternative approach is to define an extension parameter for the
Alert-Info header field in RFC 3261 such as:
Alert-Info: ;alert=normal;appearance=0
This Alert-Info header would indicate to place the call on the first
line appearance instance.
The determination as to what value to use in the appearance parameter
can be done at the proxy that forks the incoming request to all the
registered UAs. There are a variety of ways the proxy can use to
determine what value it should use to populate this parameter. For
example, the proxy could fetch this information by initiating a
SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
to fetch the list of lines that are in use. Alternatively, it could
act like a UA that is a part of the appearance group and SUBSCRIBE to
the State-Agent like any other UA. This would ensure that the active
dialog information is available without having to poll on a need
basis. It could keep track of the list of active calls for the
appearance AOR based on how many unique INVITE requests it has forked
to or received from the appearance AOR. Another approach would be
for the Proxy to first send the incoming INVITE to the Appearance
Agent which would redirect to the appearance group URI and escape the
proper Alert-Info header field for the Proxy to recurse and
distribute to the other UAs in the group.
The Appearance Agent needs to know about all incoming requests to the
AOR in order to select the appearance number. One way in which this
could be done is for the Appearance Agent to register against the AOR
with a higher q value. This will result in the INVITE being sent to
the Appearance Agent first, then being offered to the UAs in the
group.
The changes to RFC 3261 ABNF would be:
Johnston, et al. Expires January 14, 2009 [Page 27]
Internet-Draft SIP MA July 2008
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param /
appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT
11. Acknowledgements
The following individuals were part of the MA Design team and have
provided input and text to the document (in alphabetical order):
Andrew Hutton, Raj Jain, Fernando Lombardo, Derek MacDonald, Bill
Mitchell, Michael Procter, Theo Zowzouvillys.
Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen
Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar,
who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve
Towlson, and Michael Procter of Citel Technologies, Rob Harder and
Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens
Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo
Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
Dan York, Spenser Dawkins, and Martin Dolly for their comments.
12. Security Considerations
Since multiple line appearance features are implemented using
semantics provided by RFC 3261 [2], Event Package for Dialog State as
define in [7], and Event Notification [4], security considerations in
these documents apply to this draft as well.
Specifically, since dialog state information and the dialog
identifiers are supplied by UA's in an appearance group to other
members, the same is prone to "call hijacks". For example, a rogue
UA could snoop for these identifiers and send an INVITE with Replaces
header containing these call details to take over the call. As such
INVITES with Replaces header MUST be authenticated using the standard
mechanism (like Digest or S/MIME) described in RFC 3261 [2] before it
is accepted. NOTIFY message bodies that provide the dialog state
information and the dialog identifiers MAY be encrypted end-to-end
using the standard mechanics. All SUBSCRIBES between the UA's and
the Appearance Agent MUST be authenticated.
Johnston, et al. Expires January 14, 2009 [Page 28]
Internet-Draft SIP MA July 2008
13. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[I-D.ietf-sipping-service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-15 (work in
progress), July 2008.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
(SIP) Call Control - Conferencing for User Agents",
BCP 119, RFC 4579, August 2006.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
Johnston, et al. Expires January 14, 2009 [Page 29]
Internet-Draft SIP MA July 2008
Authors' Addresses
Alan Johnston (editor)
Avaya
St. Louis, MO 63124
Email: alan@sipstation.com
Mohsen Soroushnejad
Sylantro Systems Corp
Email: mohsen.soroush@sylantro.com
Venkatesh Venkataramanan
Sylantro Systems Corp
Email: vvenkatar@gmail.com
Paul Pepper
Citel Technologies
Email: paul.pepper@citel.com
Anil Kumar
Yahoo Inc.
Email: anil@yahoo-inc.com
Johnston, et al. Expires January 14, 2009 [Page 30]
Internet-Draft SIP MA July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Johnston, et al. Expires January 14, 2009 [Page 31]