RFC 7463

Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)

Internet Engineering Task Force (IETF) A. Johnston, Ed.
Request for Comments: 7463 Avaya
Updates: 3261, 4235 M. Soroushnejad, Ed.
Category: Standards Track V. Venkataramanan
ISSN: 2070-1721 Sylantro Systems Corp.
March 2015 Shared Appearances of a Session Initiation Protocol (SIP)
Address of Record (AOR)
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 shared appearances of an Address
of Record (AOR) since SIP does not have the concept of lines. This
feature is commonly offered in IP Centrex services and IP Private
Branch Exchange (IPBX) offerings and is likely to be implemented on
SIP IP telephones and SIP feature servers used in a business
environment. This feature allows several user agents (UAs) to share
a common AOR, learn about calls placed and received by other UAs in
the group, and pick up or join calls within the group. This document
discusses use cases, lists requirements, and defines extensions to
implement this feature. This specification updates RFCs 3261 and
4235.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7463.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.

addition to basic SIP support [RFC3261], many of the services in a
business environment require the support for SIP extensions such as
REFER [RFC3515], SUBSCRIBE/NOTIFY [RFC6665], PUBLISH [RFC3903], the
SIP Replaces [RFC3891], and Join [RFC3911] header fields, etc. Many
of the popular business services have been documented in the SIP
Service Examples [RFC5359].
This specification details a method for implementing a group
telephony feature known variously 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 [RFC3261] in conjunction with SIP events [RFC6665] and
publication [RFC3903] (carrying the SIP dialog state event package
[RFC4235]) for exchanging status among UAs.
In traditional telephony, the line is physical. A common scenario in
telephony is for a number of business telephones to share a single or
a small number of lines. The sharing or appearance of these lines
between a number of phones is what gives this feature its name. A
common scenario in SIP is for a number of business telephones to
share a single or a small number of Address of Record (AOR) URIs.
In addition, an AOR can have multiple appearances on a single UA in
terms of the user interface. The appearance number relates to the
user interface for the telephone; typically, each appearance of an
AOR has a visual display (lamp that can change color or blink or a
screen icon) and a button (used to select the appearance) where each
appearance number is associated with a different dialog to/from the
AOR. The telephony concept of line 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").
2. It is a useful structure for user interface representation.
The purpose of the appearance number is to identify active calls to
facilitate sharing between users (e.g., passing a call from one user
to another). If a telephone has enough buttons/lamps, the appearance
number could be the positional sequence number of the button. If

not, it may still be desirable to present the call state, but the
appearance number should be displayed so that users know which call,
for example, is on hold on which key.
In this document, except for the usage scenarios in the next section,
we will use the term "appearance" rather than "line appearance" since
SIP does not have the concept of 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. Each AOR has a
separate appearance numbering space. As a result, a given UA user
interface may have multiple occurrences of the same appearance
number, but they will be for different AORs.
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 [RFC2119]
and indicate requirement levels for compliant mechanisms.
3. Usage Scenarios
The following examples are common applications of the shared
appearances feature and are mentioned here as informative use cases.
All these example usages can be supported by the shared appearances
feature described in this document. The main differences relate to
the user interface considerations of the device.
3.1. Executive/Assistant Arrangement
The appearances on the executive's UA 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. Call Group
Users with similar business needs or tasks can be assigned to
specific groups and share an AOR. For example, an IT department
staff of five might answer a help line that 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/joined/
bridged to an existing appearance resulting in a conference call.

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
seizes 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.
3.4. Changing UAs
A user is on a call on one UA and wishes to change devices and
continue the call on another UA. They place the call on hold, note
the appearance number of the call, then walk to another UA. They are
able to identify the same appearance number on the other UA, pick up
the call, and continue the conversation.
4. Requirements and Implementation
The next section details the requirements and discusses the
implementation of the shared appearances feature.
4.1. Requirements
The basic requirements of the shared appearances 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: A UA must be able to join (also called bridge or conference
together) or pick up (take) an active call of 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 participate in the shared appearance group
without manual configuration of group members.
REQ-5: The mechanism must scale for large numbers of appearances
and large numbers of UAs without introducing excessive
messaging traffic.
REQ-6: Each call or session (incoming or outgoing) should 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 status of all
appearances of the group.
REQ-8: There must be mechanisms to resolve appearance contention
among the UAs in the group. Contention in this context
means an appearance number being associated with multiple
dialogs that are not mixed or otherwise associated.
REQ-9: The mechanism must allow all UAs receiving an incoming
session request to utilize the same appearance number at the
time of alerting.
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 that 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, seize, 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 a private conversation with the
external party and other UAs must not be allowed to join or
take the call. 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 shared appearance 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 seize 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 seize a
particular appearance number and also send the request at
the same time. This is needed when an automatic ringdown
feature (a telephone configured to immediately dial a phone
number when it goes off-hook) is combined with shared
appearances. In this case, seizing the line is integrated
with dialing.
4.2. Implementation
This section non-normatively discusses the implementation of the
shared appearances feature. The normative description is in
Section 5. Many of the requirements for this service can be met
using standard SIP mechanisms such as:
o A SIP Forking Proxy and Registrar/Location Service meets REQ-1.
o The SIP Dialog Package meets REQ-2.
o The combination of the SIP Replaces and Join header fields meets
REQ-3.
o The use of a State Agent for the Dialog Package meets REQ-4 and
REQ-5.
REQ-6 suggests the need for an entity that manages the appearance
resource. Just as conferencing systems commonly have a single point
of control, known as a focus, a shared 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 UA that has taken on this functionality for a group. The
Appearance Agent knows or is able to determine the dialog state of
all members of the group.
While the appearance resource could be managed cooperatively by a
group of UAs without any central control, this is outside the scope
of this document. 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.
To best meet REQ-9, the appearance number for an incoming INVITE
needs to be contained in the INVITE, in addition to being delivered
in the dialog package NOTIFY. Otherwise, if the NOTIFY is delayed or

lost, a UA in the group might receive an incoming INVITE but might
not know which appearance number to render during alerting.
This specification defines an extension parameter, which is
normatively defined in Section 7, for the Alert-Info header field in
RFC 3261 to carry the appearance number:
Alert-Info: <urn:alert:service:normal>;appearance=1
The following list describes the operation of the shared appearances
feature.
1. A UA is configured with the AOR of a shared appearance group. It
registers against the AOR, then attempts a dialog state
subscription to the AOR. If the subscription fails, loops back
to itself, or returns an error, it knows there is no State Agent
and, hence, no Appearance Agent and this feature is not
implemented.
2. If the subscription receives a 200 OK, the UA knows there is a
State Agent and that the feature is implemented. The UA then
follows the steps in this list.
3. Information learned about the dialog state of other UAs in the
group is rendered to the user.
4. Incoming calls are forked to all UAs in the group, and any may
answer. UAs receive the appearance number to use in rendering
the incoming call in a NOTIFY from the Appearance Agent and in
the INVITE itself. The UA will also receive a notification if
the call is answered by another UA in the group so this
information can be rendered to the user.
5. For outgoing calls, the operation depends on the implementation.
If the user seizes a particular appearance number for the call,
the UA publishes the trying state dialog information with the
desired appearance number and waits for a 2xx response before
sending the INVITE.
6. For outgoing calls, if the user does not seize a particular
appearance or does not care, the INVITE can be sent immediately,
and the appearance number learned as the call progresses from a
notification from the Appearance Agent.
7. For outgoing calls, if the user does not want an appearance
number assigned (such as during a consultation call or if a UA is
fetching 'service media' such as music on hold [RFC7088]), the UA

also publishes prior to sending the INVITE but does not include
an appearance number in the publication.
8. Established calls within the group may be joined (bridged) or
taken (picked) by another UA. Information in the dialog package
notifications can be used to construct Join or Replaces header
fields. Since the same appearance number is used for these types
of operations, this information is published prior to sending the
INVITE Join or INVITE Replaces.
9. The Appearance Agent may not have direct access to the complete
dialog state of some or all of the UAs in the group. If this is
the case, the Appearance Agent will subscribe to the dialog state
of individual UAs in the group to obtain this information. In
any case, the Appearance Agent will send normal notifications
(via the subscriptions established by the UAs in step 1) every
time the aggregate dialog state of the AOR changes, including
when calls are placed, answered, placed on and off hold, and hung
up.