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.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Executive/Assistant Arrangement . . . . . . . . . . . . . 5 3.2. Call Group . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Single Line Extension . . . . . . . . . . . . . . . . . . 6 3.4. Changing UAs . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements and Implementation . . . . . . . . . . . . . . . 6 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8 5. Normative Description . . . . . . . . . . . . . . . . . . . . 10 5.1. Elements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Shared Appearance Dialog Package Extensions . . . . . . . 11 5.2.1. The <appearance> Element . . . . . . . . . . . . . . 11 5.2.2. The <exclusive> Element . . . . . . . . . . . . . . . 12 5.2.3. The <joined-dialog> Element . . . . . . . . . . . . . 12 5.2.4. The <replaced-dialog> Element . . . . . . . . . . . . 13 5.3. Shared Appearance User Agents . . . . . . . . . . . . . . 13 5.3.1. Appearance Numbers and Call Context . . . . . . . . . 16 5.3.2. Appearance Numbers and Call Control . . . . . . . . . 17 5.3.3. Appearance Numbers and Transfer . . . . . . . . . . . 18 5.4. Appearance Agent . . . . . . . . . . . . . . . . . . . . 18 6. XML Schema Definition . . . . . . . . . . . . . . . . . . . . 21 7. Alert-Info Appearance Parameter Definition . . . . . . . . . 23
8. User Interface Considerations . . . . . . . . . . . . . . . . 24 8.1. Appearance Number Rendering . . . . . . . . . . . . . . . 24 8.1.1. Single Appearance UAs . . . . . . . . . . . . . . . . 24 8.1.2. Dual Appearance UAs . . . . . . . . . . . . . . . . . 24 8.1.3. Shared Appearance UAs with Fixed Appearance Number . 25 8.1.4. Shared Appearance UAs with Variable Appearance Numbers . . . . . . . . . . . . . . . . . . . . . . . 25 8.1.5. Example User Interface Issues . . . . . . . . . . . . 25 8.2. Call State Rendering . . . . . . . . . . . . . . . . . . 26 9. Interoperability with Non-shared Appearance UAs . . . . . . . 26 9.1. Appearance Assignment . . . . . . . . . . . . . . . . . . 26 9.2. Appearance Release . . . . . . . . . . . . . . . . . . . 27 9.3. UAs Supporting Dialog Events but Not Shared Appearance . 27 10. Provisioning Considerations . . . . . . . . . . . . . . . . . 27 11. Example Message Flows . . . . . . . . . . . . . . . . . . . . 28 11.1. Registration and Subscription . . . . . . . . . . . . . 28 11.2. Appearance Selection for Incoming Call . . . . . . . . . 32 11.3. Outgoing Call without Appearance Seizure . . . . . . . . 35 11.4. Outgoing Call with Appearance Seizure . . . . . . . . . 38 11.5. Outgoing Call without Using an Appearance Number . . . . 42 11.6. Appearance Release . . . . . . . . . . . . . . . . . . . 44 11.7. Appearance Pickup . . . . . . . . . . . . . . . . . . . 45 11.8. Call between UAs within the Group . . . . . . . . . . . 50 11.9. Consultation Hold with Appearances . . . . . . . . . . . 52 11.10. Joining or Bridging an Appearance . . . . . . . . . . . 55 11.11. Loss of Appearance during Allocation . . . . . . . . . . 58 11.12. Appearance Seizure Contention Race Condition . . . . . . 59 11.13. Appearance Agent Subscription to UAs . . . . . . . . . . 60 11.14. Appearance Pickup Race Condition Failure . . . . . . . . 62 11.15. Appearance Seizure Incoming/Outgoing Contention Race Condition . . . . . . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 13.1. SIP Event Header Field Parameter: shared . . . . . . . . 67 13.2. SIP Alert-Info Header Field Parameter: appearance . . . 68 13.3. URN Sub-Namespace Registration: sa-dialog-info . . . . . 68 13.4. XML Schema Registration . . . . . . . . . . . . . . . . 68 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 14.1. Normative References . . . . . . . . . . . . . . . . . . 69 14.2. Informative References . . . . . . . . . . . . . . . . . 70 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 711. Introduction
The feature and functionality requirements for SIP user agents (UAs) supporting business telephony applications differ greatly from basic SIP UAs, both in terms of services and end-user experience. In
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.
(page 10 continued on part 2)
