tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7463

Proposed STD
Pages: 72
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: BLISS

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

Part 1 of 4, p. 1 to 10
None       Next RFC Part

Updates:    3261    4235


Top       ToC       Page 1 
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.

Page 2 
   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

Top      ToC       Page 3 
   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  . . . . . . . . . . . . . . . . . . . . . . .  71

1.  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

Top      ToC       Page 4 
   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

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
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

Top      ToC       Page 7 
            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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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

Top      ToC       Page 10 
       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)

Next RFC Part