    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.

    Johnston, et al.             Standards Track                    [Page 1]

    RFC 7463                 SIP Shared Appearances               March 2015

       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

    Johnston, et al.             Standards Track                    [Page 2]

    RFC 7463                 SIP Shared Appearances               March 2015

       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

    Johnston, et al.             Standards Track                    [Page 3]

    RFC 7463                 SIP Shared Appearances               March 2015

       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

    Johnston, et al.             Standards Track                    [Page 4]

    RFC 7463                 SIP Shared Appearances               March 2015

       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.

    Johnston, et al.             Standards Track                    [Page 5]

    RFC 7463                 SIP Shared Appearances               March 2015

    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

    Johnston, et al.             Standards Track                    [Page 6]

    RFC 7463                 SIP Shared Appearances               March 2015

                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.

    Johnston, et al.             Standards Track                    [Page 7]

    RFC 7463                 SIP Shared Appearances               March 2015

       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

    Johnston, et al.             Standards Track                    [Page 8]

    RFC 7463                 SIP Shared Appearances               March 2015

       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

    Johnston, et al.             Standards Track                    [Page 9]

    RFC 7463                 SIP Shared Appearances               March 2015

           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.

    5.  Normative Description

       This section normatively describes the shared appearances feature
       extensions.  The following definitions are used throughout this
       document:

       Appearance number:  An appearance number is a positive integer
          associated with one or more dialogs of an AOR.  Appearance numbers
          are managed by an Appearance Agent and displayed and rendered to
          the user by UAs that support this specification.  When an
          appearance number is assigned or requested, generally the assigned
          number is the smallest positive integer that is not currently
          assigned as an appearance number to a dialog for this AOR.  This
          specification does not define an upper limit on appearance
          numbers; however, using appearance numbers that are not easily
          represented using common integer representations is likely to
          cause failures.

       Seizing:  An appearance can be reserved prior to a call being placed
          by seizing the appearance.  An appearance can be seized by
          communicating an artificial state of "trying" prior to actually
          initiating a dialog (i.e., sending the INVITE), in order to appear
          as if it were already initiating a dialog.

       Selecting (or Not-Seizing):  An appearance is merely selected (i.e.,
          not seized) if there is no such communication of artificial state
          of "trying" prior to initiating a dialog: i.e., the state is

    Johnston, et al.             Standards Track                   [Page 10]

    RFC 7463                 SIP Shared Appearances               March 2015

          communicated when the dialog is actually initiated.  The
          appearance number is learned after the INVITE is sent.

    5.1.  Elements

       A complete system to implement this feature consists of:

       1.  UAs that support publications, subscriptions, and notifications
           for the SIP dialog event package and the shared appearance dialog
           package extensions and behavior.

       2.  An Appearance Agent consisting of a State Agent for the dialog
           event package that implements an Event State Compositor (ESC) and
           the shared appearance dialog package extensions and behavior.
           The Appearance Agent also has logic for assigning and releasing
           appearance numbers and resolving appearance number contention.

       3.  A forking proxy server that can communicate with the State Agent.

       4.  A registrar that supports the registration event package.

       The behavior of these elements is described normatively in the
       following sections after the definitions of the dialog package
       extensions.

    5.2.  Shared Appearance Dialog Package Extensions

       This specification defines four new elements as extensions to the SIP
       Dialog Event package [RFC4235].  The schema is defined in Section 6.
       The elements are <appearance>, <exclusive>, <joined-dialog>, and
       <replaced-dialog>, which are sub-elements of the <dialog> element.

    5.2.1.  The <appearance> Element

       The <appearance> element, a child of the <dialog> element, is used to
       convey the appearance number of the dialog described by the parent
       <dialog> element.  When sent by a UA in a PUBLISH with parent
       <dialog> with state attribute "trying" to the Appearance Agent, the
       UA is requesting assignment of the given appearance number to the
       current or future dialog with the given dialog identifiers.  When an
       <appearance> element is sent by the Appearance Agent in a NOTIFY, it
       indicates that the appearance number has been assigned to the
       specified dialog.

       Note that a <dialog-info> element describes the contained dialogs
       from the point of view of the UA (named by the "entity" attribute),
       regardless of whether the containing request is sent by the UA or the
       Appearance Agent.  In particular, if the UA sent a request within the

    Johnston, et al.             Standards Track                   [Page 11]

    RFC 7463                 SIP Shared Appearances               March 2015

       described dialog, the To header field URI would match the <remote>
       <identity> value and the to-tag parameter would match the remote-tag
       attribute.  Similarly, the From header field URI would match the
       <local> <identity> value and the from-tag parameter would match the
       local-tag attribute.

    5.2.2.  The <exclusive> Element

       The <exclusive> element, a child of the <dialog> element, is a
       boolean, which, when true, indicates that the UA is not willing to
       accept an INVITE with a Join or Replaces header field targeted to the
       dialog described by the <dialog> element that is the parent of the
       <exclusive> element.  For example, some shared appearance systems
       only allow call pickup when the call is on hold.  In this case, the
       <exclusive> element should be set to "false" when the call is held
       and "true" when the call is not held, rather than having the
       "exclusive" value implied by the hold state.

       It is important to note that this element is a hint.  In order to
       prevent another UA from taking or joining a call, a UA can, in
       addition to setting the <exclusive> tag, not report full dialog
       information to the Appearance Agent.  Not having the full dialog
       information (Call-ID, remote-tag, and local-tag) prevents another UA
       from constructing a Join or Replaces header field.  Although a UA may
       set <exclusive> to "true", the UA must still be ready to reject an
       INVITE Join relating to this dialog.  If these dialog identifiers
       have already been shared with the Appearance Agent, the UA could send
       an INVITE Replaces to change them and then not report the new ones to
       the Appearance Agent.

       If the proxy knows which dialogs are marked exclusive, the proxy MAY
       enforce this exclusivity by rejecting INVITE Join and INVITE Replaces
       requests containing those dialog identifiers with a 403 (Forbidden)
       response.

          Note that exclusivity has nothing to do with appearance number
          selection or seizing -- instead, it is about call control
          operations that can be performed on a dialog.

       If the <exclusive> element is not present, it is assumed to be false.

    5.2.3.  The <joined-dialog> Element

       The <joined-dialog> element, a child of the <dialog> element, is used
       to convey dialog identifiers of any other dialogs that are joined
       (mixed or bridged) with the dialog.  Only the UA that is the common
       endpoint of the mixed dialogs (and thus controlling the mixing
       operation) should include this element in publications to the

    Johnston, et al.             Standards Track                   [Page 12]

    RFC 7463                 SIP Shared Appearances               March 2015

       Appearance Agent.  Note that this element should still be used even
       when the Join header field was not used to join the dialogs.  For
       example, two separate dialogs on a UA could be joined without any SIP
       call control operations.  Joined dialogs will share the same
       appearance number.

       If the <joined-dialog> element is not present, it is assumed that the
       dialog is not joined or to be joined to any other dialog.

    5.2.4.  The <replaced-dialog> Element

       The <replaced-dialog> element, a child of the <dialog> element, is
       used to convey dialog identifiers of any other dialogs that will be
       or have been replaced with this dialog.  For example, a UA in the
       group picking up a call on another UA by sending an INVITE with
       Replaces would include this element for the replacing dialog.
       Replaced dialogs will share the same appearance number.

       If the <replaced-dialog> element is not present, it is assumed that
       the dialog has not replaced or is not to replace to any other dialog.

    5.3.  Shared Appearance User Agents

       UAs that support the shared appearances feature use the dialog state
       package [RFC4235] with the shared appearance extensions and the
       'shared' Event header field parameter defined in Section 13.

       UAs use the dialog package extensions in Section 5.2 along with
       SUBSCRIBE [RFC6665], NOTIFY [RFC6665], and PUBLISH [RFC3903].
       SUBSCRIBE, NOTIFY, and PUBLISH requests for the dialog event package
       include the 'shared' Event header field parameter as required by this
       specification.

          The presence of the 'shared' Event header field parameter tells
          the Appearance Agent that the UA supports this specification.

       Upon initialization, the UA MUST subscribe to the dialog event
       package of the AOR and refresh the subscription per the SIP Events
       Framework [RFC6665].  If the SUBSCRIBE request fails, then no
       Appearance Agent may be present and this feature is not active for
       this AOR.  The UA MAY periodically retry the subscription to see if
       conditions have changed at intervals no shorter than four hours.

          Four hours was chosen to limit the subscription test to six per
          day per UA.  Increasing this interval would reduce this failure
          traffic but take longer for a newly activated Appearance Agent to
          be discovered.

    Johnston, et al.             Standards Track                   [Page 13]

    RFC 7463                 SIP Shared Appearances               March 2015

       UAs can also use the presence of the 'shared' Event header field
       parameter in NOTIFYs to discover the presence of an Appearance Agent
       for the AOR.

       UAs that implement the shared appearances feature, call pickup,
       joining, and bridging MUST support sending an INVITE with Replaces
       [RFC3891]  or Join [RFC3911].  The User Agent Client (UAC) needs to
       include the to-tag and from-tag information in the Replaces or Join
       header so that the correct dialog will be matched by the User Agent
       Server (UAS) per the rules in RFCs 3891 and 3911.

       All UAs that implement the shared appearances feature and support
       INVITE MUST support receiving an INVITE with a Replaces [RFC3891] or
       a Join [RFC3911] header field.

       When publishing or notifying dialog package information, a UA
       includes the largest set of dialog identification available at the
       time of publication, with the exception that a UA may omit
       information if it wishes to prevent other UAs from joining or picking
       up a call.  Dialog identification includes local and remote target
       URIs, call-id, to-tag, and from-tag.  While this dialog
       identification information is optional in [RFC4235], it is essential
       in the shared appearances feature, allowing call control operations.
       When placing calls on hold, use the "+sip.rendering=no" feature tag
       to indicate this in dialog package notifications.  Using the full SDP
       session description instead forces the endpoint to do a lot of extra
       parsing, unnecessarily complicating the code and inviting errors.

          The accurate rendering of the idle/active/alerting/hold state of
          other UAs in the group is an important part of the shared
          appearances feature.

       A UA that does not need to seize a particular appearance number (or
       doesn't care) would just send an INVITE as normal to place an
       outbound call.

       If the call is an emergency call, a UA MUST never wait for a
       confirmed seizure before sending an INVITE.  Instead, the emergency
       call MUST proceed without waiting for the PUBLISH transaction.

       If a UA requires a particular appearance number, the a UA MUST send a
       dialog package PUBLISH request and wait for a 2xx response before
       sending the INVITE.  This is required in the following situations:

       1.  When the user seizes a particular appearance number for an
           outgoing call (e.g., seizing the appearance and going "off-hook",
           if the UA's user interface uses this metaphor).

    Johnston, et al.             Standards Track                   [Page 14]

    RFC 7463                 SIP Shared Appearances               March 2015

       2.  When the user has requested that an appearance number not be used
           for an outgoing call (i.e., during a consultation call, a
           'service media' call such as for music on hold [RFC7088], or for
           a call not considered part of the shared appearance group).

       3.  When the user has selected to join (or bridge) an existing call.

       4.  When the user has selected to replace (or take) an existing call.

       Note that when a UA seizes an appearance prior to establishment of a
       dialog (numbers 1 and 2 in the above list), not all dialog
       information will be available.  In particular, when a UA publishes an
       attempt to seize an appearance prior to knowing the destination URI,
       minimal or no dialog information may be available.  For example, in
       some cases, only the local target URI for the call will be known: not
       any dialog information.  If the From tag and Call-ID were not present
       in the initial PUBLISH, a new PUBLISH MUST be sent as soon as this
       information is available.

          The first publication will cause the Appearance Agent to reserve
          the appearance number for this UA.  If the publication does not
          have any dialog identifiers (e.g., Call-ID or local-tag), the
          Appearance Agent cannot assign the appearance number to a
          particular dialog of the UA until the second publication, which
          will contain some dialog identifiers.

       This publication state is refreshed as described in [RFC3903] during
       the early dialog state or the Appearance Agent may reassign the
       appearance number.  Once the dialog has transitioned to the confirmed
       state, no publication refreshes are necessary.

          This specification assumes that the Appearance Agent has other
          means besides UA publication to learn about the state of UA
          dialogs.  In this specification, PUBLISH is used to indicate
          desired and intended appearance number operations.  Once a dialog
          transitions from early to confirmed, this role is over; hence, no
          publication refreshes are needed.

       Appearance numbers are a shorthand label for active and pending
       dialogs related to an AOR.  Many of the features and services built
       using this extension rely on the correct rendering of this
       information to the human user.  In addition, the group nature of the
       feature means that the rendering must be similar between different
       vendors and different models.  Failure to do so will greatly reduce
       the value and usefulness of these protocol extensions.  In a
       correctly designed user interface for this feature, the appearances
       number for each active and pending dialog is explicitly (i.e., by
       appearance number) or implicitly (using a user interface metaphor

    Johnston, et al.             Standards Track                   [Page 15]

    RFC 7463                 SIP Shared Appearances               March 2015

       that makes the numbering and ordering clear to the user) rendered to
       the user.  The far-end identity of each dialog (e.g., the remote
       party identity) is not a useful replacement for the appearance
       number.  The state of each appearance is also to be rendered (idle,
       active, busy, joined, etc.).  UAs can tell that a set of dialogs are
       joined (bridged or mixed) together by the presence of one or more
       <joined-dialog> elements containing other SIP dialog identifiers.
       Appearance numbers of dialogs can be learned by dialog package
       notifications containing the <appearance> element from the Appearance
       Agent or from the 'appearance' Alert-Info parameter in an incoming
       INVITE.  Should they conflict, the dialog package notification takes
       precedence.

       A user may select an appearance number but then abandon placing a
       call (go back on-hook).  In this case, the UA frees up the appearance
       number by removing the event state with a PUBLISH as described in
       [RFC3903].  A failure to do this will require unnecessary operations
       by the Appearance Agent and tie up appearance numbers that could
       otherwise be used by other UAs in the shared appearance group.

       A UA SHOULD register against the AOR only if it is likely the UA will
       be answering incoming calls.  If the UA is mainly going to be
       monitoring the status of the shared appearance group calls and
       picking or joining calls, the UA SHOULD only subscribe to the AOR and
       not register against the AOR.  If a monitoring UA registers rather
       than just subscribing, it generates large amounts of unnecessary
       network traffic.

          All subscribed UAs will receive dialog package NOTIFYs of trying
          state for incoming INVITEs.

       A UA MUST NOT insert an 'appearance' parameter into an Alert-Info
       header field in an INVITE or other request.

          The Appearance Agent is solely responsible for doing this.

    5.3.1.  Appearance Numbers and Call Context

       There are cases where two separate dialogs at a UA are not mixed but
       share the same 'context'.  That is, they relate to each other and
       should not be treated the same as any other two dialogs within the
       group.  One example of this is a 'consultation call' where a user
       puts an existing dialog on hold, then calls another user, before
       switching back to the original dialog.  Another case, described
       below, occurs during transfer operations, where for a transient
       period, a UA is involved in dialogs with two other UAs, but the
       dialogs are related, and should not be treated as independent
       dialogs.  These cases are best handled by not assigning an appearance

    Johnston, et al.             Standards Track                   [Page 16]

    RFC 7463                 SIP Shared Appearances               March 2015

       number to a newly created dialog when it shares a context with an
       existing dialog.  But if the preexisting dialog is terminated, its
       appearance number should be reassigned to the newly created dialog.

       A UA that wants to place a call but does not have an appearance
       number assigned sends a PUBLISH before sending the INVITE.  The
       PUBLISH does not have an 'appearance' element present, but it does
       have the 'shared' Event header field parameter present.  If the
       Appearance Agent policy does not allow calls without an assigned
       appearance number, a 400 (Bad Request) response is sent by the
       Appearance Agent and the UA will republish either selecting/seizing
       an appearance number or send the INVITE without publishing, in which
       case the Appearance Agent will assign one.

          Note that if an Appearance Agent rejects calls without an
          appearance number, certain operations such as consultation calls,
          transfer, and music on hold may be negatively impacted.

    5.3.2.  Appearance Numbers and Call Control

       When an INVITE is generated to attempt to bridge or take a call
       (i.e., contains Join or Replaces with a dialog identifier of another
       dialog in the shared appearance group), the UA MUST first send a
       PUBLISH to the Appearance Agent.  This PUBLISH will contain:

       1.  The appearance number of the joined or replaced call in the
           <appearance> element

       2.  The dialog information from the Join header field in the <joined-
           dialog> element, if the dialog is being joined

       3.  The dialog information from the Replaces header field in the
           <replaced-dialog> element, if the dialog is being replaced

          Note that this information is provided to the Appearance Agent so
          that it can provide proper appearance assignment behavior.  If the
          INVITE Join or Replaces was sent without publishing first, the
          Appearance Agent might assign a new appearance number to this
          INVITE, which would be a mistake.  With Join, the publication has
          the <joined-dialog> element to prevent the Appearance Agent from
          generating a 400 (Bad Request) response due to the reuse of an
          appearance number.  For Replaces, the purpose of the <replaced-
          dialog> is to prevent a race condition where the BYE could cause
          the appearance number to be released when it should stay with the
          replacing dialog.

    Johnston, et al.             Standards Track                   [Page 17]

    RFC 7463                 SIP Shared Appearances               March 2015

    5.3.3.  Appearance Numbers and Transfer

       During a transfer operation, it is important that the appearance
       number not change during the operation.  Consider the example of
       Alice, a member of a shared appearance group, who is talking to
       Carol, who is outside the shared appearance group.  Carol transfers
       Alice to David, who is also outside the shared appearance group.  For
       example, if Alice is using appearance 3 for the session with Carol,
       the resulting session with David should also use appearance number 3.
       Otherwise, an appearance number change can cause a "jump" on the UI
       and confusion to the user.  There are two possible scenarios using
       the terminology of RFC 5589: Alice is the transferee in any type of
       transfer (receives the REFER) or the transfer target in an attended
       transfer (receives the INVITE with Replaces).

       If Alice is the transferee, the triggered INVITE from the REFER is
       treated as a consultation call.  Alice SHOULD publish requesting that
       the Appearance Agent not assign an appearance number for this INVITE.
       When the transfer completes, Alice SHOULD publish again to move the
       appearance number from the dialog with Carol to the dialog with
       David.  If a PUBLISH is sent to move the appearance number, the
       publication MUST be sent prior to sending the BYE to Carol to avoid a
       race condition where the Appearance Agent reassigns the appearance
       number after seeing the BYE.

       If Alice is the target, the incoming INVITE will contain a Replaces
       header field.  As a result, the Appearance Agent will have reused the
       appearance number of the dialog with Carol, and this appearance
       number will continue to be used after the dialog with Carol has been
       terminated.

    5.4.  Appearance Agent

       An Appearance Agent defined in this specification MUST implement a
       dialog package state agent for the UAs registered against the AOR.
       The Appearance Agent MUST support the appearance dialog package
       extensions defined in Section 5.2 and use the 'shared' Event header
       field parameter.  The Appearance Agent MUST support publications and
       subscriptions for this event package.

       The Appearance Agent MUST have a way of discovering the state of all
       dialogs associated with the AOR.  If this information is not
       available from a call stateful proxy or Back-to-Back User Agent
       (B2BUA), the Appearance Agent can use the registration event package
       [RFC3680] to learn of UAs associated with the AOR and subscribe to
       their dialog event state.  An Appearance Agent can also subscribe to
       a UA's dialog event state in order to reconstruct state.  As a
       result, the registrar MUST support the registration event package.

    Johnston, et al.             Standards Track                   [Page 18]

    RFC 7463                 SIP Shared Appearances               March 2015

       Dialog package notifications are recommended by RFC 4235 to "only
       contain information on the dialogs whose state or participation
       information has changed."  This specification extends RFC 4235 as
       follows.  The Appearance Agent SHOULD send dialog event state
       notifications whenever the following events happen to UAs in the AOR
       group:

       1.  A call is received, placed, answered, or terminated.

       2.  A call is placed on or off hold.

       3.  A call is joined or replaced.

       4.  An appearance number is reserved or released.

       The Appearance Agent MUST allocate an appearance number for all
       incoming calls and send immediate notifications to the UAs subscribed
       to the shared group AOR.  A new appearance number is allocated except
       for an incoming INVITE with a Join or Replaces header field.  For
       this case, the appearance number should match the appearance number
       of the dialog being joined or replaced.  If the INVITE Replaces or
       Join comes from outside the shared appearance group, the Appearance
       Agent will include a <joined-dialog> or <replaced-dialog> element in
       the NOTIFY containing the dialog information from the Replaces or
       Joined header field.

       The Appearance Agent MUST be able to communicate with the forking
       proxy to learn about incoming calls and also to pass the appearance
       number to the proxy or ensure the Alert-Info header field is included
       in the INVITE with the appropriate appearance number.

          Note that UAs need to be able to handle incoming INVITEs without
          an appearance number assigned.  This could be caused by a failure
          of the Appearance Agent or other error condition.  Although the
          proper rendering of the INVITE may not be possible, this is better
          than ignoring or failing the INVITE.

       An Appearance Agent SHOULD assign an appearance number to an outgoing
       dialog if a PUBLISH has not been received selecting/seizing a
       particular appearance number.

          Note that if the shared appearance group has appearance-unaware
          UAs making calls, the Appearance Agent will still allocate
          appearance numbers for INVITEs sent by those UAs.

       An Appearance Agent receiving a PUBLISH with an appearance number
       checks to make sure the publication is valid.  An appearance number
       can be assigned to only one dialog unless there is a <joined-dialog>

    Johnston, et al.             Standards Track                   [Page 19]

    RFC 7463                 SIP Shared Appearances               March 2015

       or <replaced-dialog> element indicating that the dialog will be/has
       been replaced or joined.  A 400 (Bad Request) response is returned if
       the chosen appearance number is invalid, and an immediate NOTIFY
       SHOULD be sent to the UA containing full dialog event state.

       An Appearance Agent receiving a PUBLISH without an appearance number
       but with the 'shared' Event header field parameter present interprets
       this as a request by the UA to not assign an appearance number.  If
       the Appearance Agent policy does not allow this, a 400 (Bad Request)
       response is returned.  If policy does allow this, a 200 (OK) response
       is returned and no appearance number is allocated.  An Appearance
       Agent does not have to share this dialog information (i.e., send a
       NOTIFY) with other UAs in the group as the information will not be
       rendered by the other UAs.

       The Appearance Agent allocates an appearance number to a dialog from
       the time the appearance is requested via a PUBLISH or from the
       receipt of an INVITE to the time when the last dialog associated with
       the appearance is terminated, including all dialogs that are joined
       or replaced.  During the early dialog state, the Appearance Agent
       controls the rate of dialog state publication using the Expires
       header field in 200 (OK) responses to PUBLISH requests.  An interval
       of 3 minutes is RECOMMENDED.  After the dialog associated with the
       publication has been confirmed, the expiration of the publication
       state has no effect on the appearance allocation.  If the publication
       contains no dialog state information, the Appearance Agent MUST
       reserve the appearance number for the UA but cannot assign the
       appearance to any particular dialog of the UA.  When the publication
       state is updated with any dialog information, the appearance number
       can then be assigned to the particular dialog.  A UA that has been
       allocated an appearance number using a PUBLISH MAY free up the
       appearance number by removing the event state with a PUBLISH as
       described in [RFC3903].

       If an INVITE is sent by a member of the group to the shared AOR
       (i.e., they call their own AOR), the Appearance Agent MUST assign two
       appearance numbers.  The first appearance number will be the one
       selected or assigned to the outgoing INVITE.  The second appearance
       number will be another one assigned by the Appearance Agent for the
       INVITE as it is forked back to the members of the group.

          The is to preserve a common behavior in legacy systems.

       If an INVITE is sent by a member of the group using the shared AOR or
       sent to the shared AOR and no appearance number is available, the
       proxy MAY reject the INVITE with a 403 (Forbidden) response code.

    Johnston, et al.             Standards Track                   [Page 20]

    RFC 7463                 SIP Shared Appearances               March 2015

       Appearance numbers are only used for dialogs in which one or more UAs
       associated with the group AOR are participants.  If an incoming
       INVITE to the group AOR is forwarded to another AOR, the appearance
       number is immediately freed up and can be assigned to another dialog.

    6.  XML Schema Definition

       The 'appearance', 'joined-dialog', 'replaced-dialog', and 'exclusive'
       elements are defined within a new XML namespace URI.  This namespace
       is "urn:ietf:params:xml:ns:sa-dialog-info".  The schema for these
       elements is:

    Johnston, et al.             Standards Track                   [Page 21]

    RFC 7463                 SIP Shared Appearances               March 2015

       <?xml version="1.0" encoding="UTF-8"?>
         <xs:schema
           targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info"
           xmlns="urn:ietf:params:xml:ns:sa-dialog-info"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">

          <xs:element name="joined-dialog" minOccurs="0"
                                                maxOccurs="unbounded">
               <xs:complexType>
                   <xs:attribute name="call-id" type="xs:string"
                     use="mandatory"/>
                   <xs:attribute name="local-tag" type="xs:string"
                     use="mandatory"/>
                   <xs:attribute name="remote-tag" type="xs:string"
                     use="mandatory"/>
               </xs:complexType>
          </xs:element>

          <xs:element name="replaced-dialog" minOccurs="0"
                                                 maxOccurs="unbounded">
               <xs:complexType>
                   <xs:attribute name="call-id" type="xs:string"
                     use="mandatory"/>
                   <xs:attribute name="local-tag" type="xs:string"
                     use="mandatory"/>
                   <xs:attribute name="remote-tag" type="xs:string"
                     use="mandatory"/>
               </xs:complexType>
           </xs:element>

           <xs:element name="appearance" minOccurs="0" maxOccurs="1">
               <xs:simpleType type="xs:integer">
               </xs:simpleType>
           </xs:element>

           <xs:element name="exclusive" minOccurs="0" maxOccurs="1">
               <xs:simpleType type="xs:boolean">
               </xs:simpleType>
           </xs:element>
       </xs:schema>

    Johnston, et al.             Standards Track                   [Page 22]

    RFC 7463                 SIP Shared Appearances               March 2015

    7.  Alert-Info Appearance Parameter Definition

       This specification extends [RFC3261] to add an 'appearance' parameter
       to the Alert-Info header field and also to allow proxies to modify or
       delete the Alert-Info header field.

       The changes to the ABNF [RFC5234] in RFC 3261 are:

            alert-param      =  LAQUOT absoluteURI RAQUOT *( SEMI
                                  (generic-param / appearance-param) )
            appearance-param = "appearance" EQUAL 1*DIGIT

       A proxy inserting an 'appearance' Alert-Info parameter follows normal
       Alert-Info policies.  To indicate the appearance number for this
       dialog, the proxy adds the Alert-Info header field with the
       'appearance' parameter to the INVITE.  If an Alert-Info is already
       present, the proxy adds the 'appearance' parameter to the Alert-Info
       header field.  If an appearance number parameter is already present
       (associated with another AOR or by mistake), the value is rewritten
       adding the new appearance number.  There MUST NOT be more than one
       appearance parameter in an Alert-Info header field.

       If no special ringtone is desired, a normal ringtone SHOULD be
       indicated using the urn:alert:service:normal in the Alert-Info, as
       per [RFC7462].  The appearance number present in an Alert-Info header
       field SHOULD be rendered by the UA to the user, following the
       guidelines in Section 5.3.  If the INVITE is forwarded to another
       AOR, the appearance parameter in the Alert-Info SHOULD be removed
       before forwarding outside the group.

       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 is a variety of ways the proxy can 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 shared 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 shared appearance

    Johnston, et al.             Standards Track                   [Page 23]

    RFC 7463                 SIP Shared Appearances               March 2015

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

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

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

    8.1.1.  Single Appearance UAs

       These devices are constrained by only having the capability of
       displaying status indications for a single appearance.  The UA SHOULD
       still send messages annotated with appearance number "1".  Any call
       indications for appearances other than for number "1" SHOULD be
       rejected with a 480 (Temporarily Unavailable) or 486 (Busy Here)
       response.  Note that this means that a single appearance UA cannot
       answer its own call to the shared AOR, since this call would use a
       second appearance number.

    8.1.2.  Dual Appearance UAs

       These devices are essentially single appearance 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.
       Only appearance numbers "1" and "2" will be used by these UAs.

    Johnston, et al.             Standards Track                   [Page 24]

    RFC 7463                 SIP Shared Appearances               March 2015

    8.1.3.  Shared 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
       buttons, and calls may be managed using these configured appearances.
       Any calls outside this range should be rejected, and not mapped to a
       free button.  Users of these devices often seize specific appearance
       numbers for outgoing calls, and the UA will need to seize the
       appearance number and wait for confirmation from the Appearance Agent
       before proceeding with calls.

    8.1.4.  Shared Appearance UAs with Variable Appearance Numbers

       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.  These devices can typically
       make calls without waiting for confirmation from the Appearance Agent
       on the appearance number.

    8.1.5.  Example User Interface Issues

       The problems faced by each style of user interface are readily seen
       in this example:

       1.  A call arrives at the shared appearance group and is assigned an
           appearance number of "1".  All UAs should be able to render to
           the user the arrival of this call.

       2.  Another call arrives at the shared appearance group and is
           assigned an appearance number of "2".  The single appearance UA
           should not present this call to the user.  Other UAs should have
           no problems presenting this call distinctly from the first call.

       3.  The first call clears, releasing appearance number "1".  The
           single appearance UA should now be indicating no calls since it
           is unable to manage calls other than on the first appearance.
           Both shared appearance UAs should clearly show that appearance
           number "1" is now free, but that there is still a call on
           appearance number "2".

       4.  A third call arrives and is assigned the appearance number of
           "1".  All UAs should be able to render the arrival of this new
           call to the user.  Multiple appearance UAs should continue to
           indicate the presence of the second call, and they should also

    Johnston, et al.             Standards Track                   [Page 25]

    RFC 7463                 SIP Shared Appearances               March 2015

           ensure that the presentation order is related to the appearance
           number and not the order of call arrival.

    8.2.  Call State Rendering

       UAs that implement the shared appearances feature typically have a
       user interface that provides the state of other appearances in the
       group.  As dialog 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, means that an appearance number is
       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 shared appearance
       group is hold.  This can be determined by the presence of the
       "+sip.rendering=no" feature tag [RFC3840] 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.

    9.  Interoperability with Non-shared Appearance UAs

       It is desirable to allow a basic UA that does not directly support
       shared appearance to be part of a shared appearance group.  To
       support this, the Proxy must collaborate with the Appearance Agent.
       This is not required in the basic shared appearance architecture;
       consequently, shared appearance interoperability with non-shared
       appearance UAs will not be available in all shared appearance
       deployments.

       First, a UA that does not support dialog events or the shared
       appearances feature will be discussed.  Then, a UA that does support
       dialog events but not the shared appearances feature will be
       discussed.

    9.1.  Appearance Assignment

       A UA that has no knowledge of appearances will only have appearance
       numbers for outgoing calls if assigned by the Appearance Agent.  If
       the non-shared appearance UA does not support Join or Replaces, all
       dialogs SHOULD be marked "exclusive" to indicate that these options
       are not available.  Marking these dialogs "exclusive" provides a
       better user experience and avoids extra SIP messaging failures.

    Johnston, et al.             Standards Track                   [Page 26]

    RFC 7463                 SIP Shared Appearances               March 2015

    9.2.  Appearance Release

       In all cases, the Appearance Agent must be aware of the 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 that Record-
       Routes for dialogs from the non-shared-appearance-aware UA, the
       Appearance Agent will know about the state of dialogs including hold,
       etc.  This information could be determined from inspection of non-
       end-to-end-encrypted INVITE and re-INVITE messages and added to the
       dialog information conveyed to other UAs.

    9.3.  UAs Supporting Dialog Events but Not Shared Appearance

       Interoperability with UAs that support dialog events but not the
       shared appearances feature is more straightforward.  As before, all
       appearance number assignments must be done by the Appearance Agent.
       The Appearance Agent SHOULD still include appearance information in
       NOTIFYs -- this UA will simply ignore this extra information.  This
       type of UA will also ignore appearance number limitations and may
       attempt to join or replace dialogs marked exclusive.  As a result,
       the Proxy or UAs need to reject such requests or the dialogs will be
       joined or taken.

    10.  Provisioning Considerations

       UAs can automatically discover if this feature is active for an AOR
       by looking for the 'shared' Event header field parameter in a
       response to a dialog package SUBSCRIBE to the AOR, so no provisioning
       for this is needed.

       The registrar will need to be provisioned to accept either first or
       third party registrations for the shared AOR.  First party
       registration means the To and From URIs in the REGISTER request are
       the shared AOR URI.  Third-party registration means the To URI is the
       shared AOR URI and the From URI is a different AOR, perhaps that of
       the individual user.  Either the credentials of the shared AOR or the
       user MUST be accepted by the registrar and the Appearance Agent,
       depending on the authorization policy in place for the domain.

       If the Appearance Agent needs to subscribe to the dialog state of the
       UAs, then the Appearance Agent and the UAs need to be provisioned
       with credentials so the UAs can authenticate the Appearance Agent.

       In some cases, UAs in the shared appearance group might have a UI
       limitation on the number of appearances that can be rendered.

    Johnston, et al.             Standards Track                   [Page 27]

    RFC 7463                 SIP Shared Appearances               March 2015

       Typically, this will be hard-phones with buttons/lamps instead of
       more flexible UIs.  In this case, it can be useful for the Appearance
       Agent to know this maximum number.  This can allow the Appearance
       Agent to apply policy when this limit is reached, e.g., deny a call.
       However, this mechanism does not provide any way to discover this by
       protocol means.

    11.  Example Message Flows

       The next section shows call flow and message examples.  The flows and
       descriptions are non-normative.  Note that, in these examples, all
       INVITEs sent by a UA in the group will be From the shared AOR
       (sip:HelpDesk@example.com in this case), and all INVITES sent to the
       group will have a Request-URI of the shared AOR.  Any other requests
       would not apply to this feature and would be handled using normal SIP
       mechanisms.

       Note that the first 12 examples assume the Appearance Agent is aware
       of dialog state events.  The example in Section 11.13 shows the case
       where this is not the case, and, as a result, the Appearance Agent
       initiates a subscription to users of the shared AOR.  Any of the
       other call flow examples could have shown this mode of operation as
       it is equally valid.

    11.1.  Registration and Subscription

       Bob and Alice are in a shared appearance group identified by the
       shared appearance AOR sip:HelpDesk@example.com.  Bob REGISTERs using
       contact sip:bob@ua2.example.com.  Alice REGISTERs with contact
       sip:alice@ua1.example.com.

       UAs for Alice and Bob subscribe to the dialog package for the
       appearance AOR and publish dialog state to the Appearance Agent.
       Message exchanges between the Registrar, Appearance Agent, Alice, and
       Bob are shown below.  The call flow examples below do not show the
       authentication of subscriptions, publications, and notifications.  It
       should be noted that for security purposes, all publications and
       subscriptions must be authorized before they are accepted.

       Also note that registrations and subscriptions must all be refreshed
       by Alice at intervals determined by the expiration intervals returned
       by the Registrar or Appearance Agent.

       Registrar     Appearance Agent          Alice             Bob
       |                    |                    |                |
       |                    |                    |                |
       |<--------------------------- REGISTER F1<|                |
       |                    |                    |                |

    Johnston, et al.             Standards Track                   [Page 28]

    RFC 7463                 SIP Shared Appearances               March 2015

       |>F2 200 OK ----------------------------->|                |
       |                    |                    |                |
       |                    |<----- SUBSCRIBE F3<|                |
       |                    |                    |                |
       |                    |>F4 200 OK -------->|                |
       |                    |                    |                |
       |                    |>F5 NOTIFY -------->|                |
       |                    |                    |                |
       |                    |<-------- 200 OK F6<|                |
       |                    |                    |                |
       |<-------------------------------------------- REGISTER F7<|
       |                    |                    |                |
       |>F8 200 OK ---------------------------------------------->|
       |                    |                    |                |
       |                    |<---------------------- SUBSCRIBE F9<|
       |                    |                    |                |
       |                    |>F10 200 OK ------------------------>|
       |                    |                    |                |
       |                    |>F11 NOTIFY ------------------------>|
       |                    |                    |                |
       |                    |<------------------------ 200 OK F12<|
       |                    |                    |                |

       Figure 1. Registration and Subscription Example

       F1-F2: Alice registers AOR with
              contact: <sip:alice@ua1.example.com>

       F1 Alice ----> Registrar

       REGISTER sip:registrar.example.com SIP/2.0
       Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
       From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
       To: <sip:HelpDesk@example.com>
       CSeq: 2 REGISTER
       Call-ID: d3281184-518783de-cc23d6bb
       Contact: <sip:alice@ua1.example.com>
       Max-Forwards: 70
       Expires: 3600
       Content-Length: 0

       F2 Registrar ----> Alice

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
       CSeq: 2 REGISTER
       Call-ID: d3281184-518783de-cc23d6bb

    Johnston, et al.             Standards Track                   [Page 29]

    RFC 7463                 SIP Shared Appearances               March 2015

       From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
       To: <sip:HelpDesk@example.com>;tag=1664573879820199
       Contact:  <sip:alice@ua1.example.com>;expires=3600
       Content-Length: 0

       F3 to F6: Alice also subscribes to the events associated with the
       Appearance AOR.  Appearance Agent notifies Alice of the status.

       F3 Alice ----> Appearance Agent

       SUBSCRIBE sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
       From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
       To: <sip:HelpDesk@example.com>
       CSeq: 91 SUBSCRIBE
       Call-ID: ef4704d9-bb68aa0b-474c9d94
       Contact: <sip:alice@ua1.example.com>
       Event: dialog;shared
       Accept: application/dialog-info+xml
       Max-Forwards: 70
       Expires: 3700
       Content-Length: 0

       F4 Appearance Agent ----> Alice

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
       CSeq: 91 SUBSCRIBE
       Call-ID: ef4704d9-bb68aa0b-474c9d94
       From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
       To: <sip:HelpDesk@example.com>;tag=1636248422222257
       Allow-Events: dialog
       Expires: 3700
       Contact: <sip:appearanceagent.example.com>
       Content-Length: 0

       F5 Appearance Agent ----> Alice

       NOTIFY sip:alice@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=1636248422222257
       To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
       Call-ID: ef4704d9-bb68aa0b-474c9d94
       CSeq: 232 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
       Max-Forwards: 70

    Johnston, et al.             Standards Track                   [Page 30]

    RFC 7463                 SIP Shared Appearances               March 2015

       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=3000
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    version="40"
                    state="full"
                    entity="sip:HelpDesk@example.com">
       </dialog-info>

       F6 Alice ----> Appearance Agent

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1846
       From: <sip:HelpDesk@example.com>;tag=1636248422222257
       To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
       CSeq: 232 NOTIFY
       Call-ID: ef4704d9-bb68aa0b-474c9d94
       Contact: <sip:alice@ua1.example.com>
       Content-Length: 0

       F7 Bob ----> Registrar

       REGISTER sip:registrar.example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
       From: <sip:bob@example.com>;tag=34831131
       To: <sip:HelpDesk@example.com>
       CSeq: 72 REGISTER
       Call-ID: 139490230230249348
       Contact: <sip:bob@ua2.example.com>
       Max-Forwards: 70
       Expires: 3600
       Content-Length: 0

       F8 Registrar ----> Bob

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4b53b54d87B
       From: <sip:bob@example.com>;tag=34831131
       To: <sip:HelpDesk@example.com>;tag=fkwlwqi1
       CSeq: 72 REGISTER
       Call-ID: 139490230230249348

    Johnston, et al.             Standards Track                   [Page 31]

    RFC 7463                 SIP Shared Appearances               March 2015

       Contact: <sip:alice@ua1.example.com>;expires=3200
       Contact: <sip:bob@ua2.example.com>;expires=3600
       Content-Length: 0

    11.2.  Appearance Selection for Incoming Call

       In the call flow below, Bob and Alice are in a shared appearance
       group.  Carol places a call to the shared appearance group AOR.  The
       Appearance Agent sends NOTIFYs to Alice and Bob telling them what
       appearance the call is using.  Both Alice and Bob's devices are
       alerted of the incoming call.  Bob answers the call.

       Note that it is possible that both Alice and Bob answer the call and
       send 200 (OK) responses to Carol.  It is up to Carol to resolve this
       situation.  Typically, Carol will send ACKs to both 200 OKs but send
       a BYE to terminate one of the dialogs.  As a result, either Alice or
       Bob will receive the BYE and publish that their dialog is over.
       However, if Carol answers both Alice and Bob and keeps both dialogs
       active, then the Appearance Agent will need to resolve the situation
       by moving either Alice or Bob's dialog to a different appearance.

       All NOTIFY messages in the call flow below carry dialog events and
       only dialog states are mentioned for simplicity.  For brevity, the
       details of some messages are not shown below.  Note that the order of
       F2 - F5 and F7 - F8 could be reversed.

                  Forking     Appearance
       Carol      Proxy         Agent         Alice      Bob
       |            |             |             |         |
       |>F1 INVITE >|             |             |         |
       |            |< - - - - - >|             |         |
       |            |             |>F2 NOTIFY ----------->|
       |            |             |             |         |
       |            |             |<F3 200 OK -----------<|
       |            |             |             |         |
       |            |             |>F4 NOTIFY ->|         |
       |            |             |             |         |
       |            |             |<-200 OK F5-<|         |
       |<- 100 F6 -<|             |             |         |
       |            |>F7 INVITE (appearance=1) ---------->|
       |            |             |             |         |
       |            |>F8 INVITE (appearance=1) >|         |
       |            |             |             |         |
       |            |<-------------------- Ringing 180 F9<|
       |< 180 F10 -<|             |             |         |

    Johnston, et al.             Standards Track                   [Page 32]

    RFC 7463                 SIP Shared Appearances               March 2015

       |            |<--------- 180 Ringing F11<|         |
       |< 180 F12 -<|             |             |         |
       |            |             |             |         |
       |            |<------------------------ 200 OK F13<|
       |< 200 F14 -<|             |             |         |
       |            |             |             |         |
       |            |>F15 CANCEL -------------->|         |
       |            |             |             |         |
       |            |<-------------- 200 OK F16<|         |
       |            |             |             |         |
       |            |<Request Cancelled 487 F17<|         |
       |            |             |             |         |
       |            |>F18 ACK ----------------->|         |
       |>F19 ACK -->|             |             |         |
       |            |>F20 ACK --------------------------->|
       |            |             |             |         |
       |<=============Both way RTP established===========>|
       |            |             |             |         |
       |            |< - - - - - >|             |         |
       |            |             |             |         |
       |            |             |>F21 NOTIFY >|         |
       |            |             |             |         |
       |            |             |<- 200 F22 -<|         |
       |            |             |             |         |
       |            |             |>F23 NOTIFY ---------->|
       |            |             |             |         |
       |            |             |<F24 200 OK ----------<|
       |            |             |                       |

       Figure 2. Appearance Selection for Incoming Call Example

       F4 Appearance Agent ----> Alice

       NOTIFY sip:alice@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=151702541050937
       To: <sip:alice@example.com>;tag=18433323-C3D237CE
       Call-ID: 1e361d2f-a9f51109-bafe31d4
       CSeq: 12 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK1403
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=2800
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>

    Johnston, et al.             Standards Track                   [Page 33]

    RFC 7463                 SIP Shared Appearances               March 2015

       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="13"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
          <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
               call-id="14-1541707345"
               remote-tag="44BAD75D-E3128D42"
               direction="recipient">
             <sa:appearance>1</sa:appearance>
             <state>trying</state>
             <remote>
               <identity>sip:carol@ua.example.com</identity>
             </remote>
          </dialog>
       </dialog-info>

       F7 Proxy ----> Bob

       INVITE sip:bob@ua2.example.com SIP/2.0
       Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea
       Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
       From: <sip:carol@example.com>;tag=44BAD75D-E3128D42
       To: <sip:HelpDesk@example.com>
       CSeq: 106 INVITE
       Call-ID: 14-1541707345
       Contact: <sip:carol@ua3.example.com>
       Max-Forwards: 69
       Alert-Info: <urn:alert:service:normal>;appearance=1
       Content-Type: application/sdp
       Content-Length: ...

       v=0
       o=- 1102980499 1102980499 IN IP4 ua3.example.com
       s=
       c=IN IP4 ua3.example.com
       t=0 0
       m=audio 2238 RTP/AVP 0 8 101
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:101 telephone-event/8000

       F21 Appearance Agent ----> Alice

       NOTIFY sip:alice@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=151702541050937

    Johnston, et al.             Standards Track                   [Page 34]

    RFC 7463                 SIP Shared Appearances               March 2015

       To: <sip:alice@example.com>;tag=18433323-C3D237CE
       Call-ID: 1e361d2f-a9f51109-bafe31d4
       CSeq: 13 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK4164F03j
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=2500
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="17"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
          <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
               call-id="14-1541707345"
               remote-tag="44BAD75D-E3128D42"
               local-tag="7349dsfjkFD03s"
               direction="recipient">
             <sa:appearance>1</sa:appearance>
             <state>confirmed</state>
             <local>
               <target>sip:bob@ua2.example.com</target>
             </local>
             <remote>
               <identity>sip:carol@ua.example.com</identity>
             </remote>
          </dialog>
       </dialog-info>

    11.3.  Outgoing Call without Appearance Seizure

       In this scenario, Bob's UA places a call without first selecting/
       seizing an appearance number.  After Bob sends the INVITE, the
       appearance assigns an appearance number for it and notifies both
       Alice and Bob.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |                  |
       |              |<------------------------------------- INVITE F1<|
       |              |               |              |                  |
       |              |>F2 100 Trying --------------------------------->|

    Johnston, et al.             Standards Track                   [Page 35]

    RFC 7463                 SIP Shared Appearances               March 2015

       |<-- INVITE F3<|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<-- NOTIFY F4<|                  |
       |              |               |              |                  |
       |              |               |>F5 200 OK -->|                  |
       |              |               |              |------- NOTIFY F6>|
       |              |               |              |                  |
       |              |               |              |<F7 200 OK ------<|
       |>F8 180  ---->|               |              |                  |
       |              |>F9 180 Ringing -------------------------------->|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F10<|                  |
       |              |               |              |                  |
       |              |               |>F11 200 OK ->|                  |
       |              |               |              |------ NOTIFY F12>|
       |              |               |              |                  |
       |              |               |              |<F13 200 OK -----<|
       |>F14 200 OK ->|               |              |                  |
       |              |>F15 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F16<|
       |<---- ACK F17<|               |              |                  |
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F18<|                  |
       |              |               |              |                  |
       |              |               |>F19 200 OK ->|                  |
       |              |               |              |------ NOTIFY F20>|
       |              |               |              |                  |
       |              |               |              |<F21 200 OK -----<|
       |              |               |              |                  |

       Figure 3. Outgoing Call without Appearance Seizure Example

       F1 Bob ----> Proxy

       INVITE sip:carol@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
       From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
       To: <sip:carol@example.com>
       CSeq: 1 INVITE

    Johnston, et al.             Standards Track                   [Page 36]

    RFC 7463                 SIP Shared Appearances               March 2015

       Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
       Contact: <sip:bob@ua2.example.com>
       Max-Forwards: 70
       Content-Type: application/sdp
       Content-Length: 223

       v=0
       o=- 1102980499 1102980499 IN IP4 ua2.example.com
       s=IP SIP UA
       c=IN IP4 ua2.example.com
       t=0 0
       a=sendrecv
       m=audio 2236 RTP/AVP 0 8 101
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:101 telephone-event/8000

       F4 Appearance Agent ----> Alice

       NOTIFY sip:alice@ua1.example.com SIP/2.0
       Via: SIP/2.0/UDP appearanceagent.example.com;branch=z9hG4bK81d84f62
       From: <sip:HelpDesk@example.com>;tag=1636248422222257
       To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
       Call-ID: ef4704d9-bb68aa0b-474c9d94
       CSeq: 233 NOTIFY
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=2200
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="27"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
           <dialog id="fa02538339df3ce597f9e3e3699e28fc"
                call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                local-tag="15A3DE7C-9283203B"    direction="initiator">
                   <sa:appearance>1</sa:appearance>
                   <sa:exclusive>false</sa:exclusive>
                      <state>trying</state>
                       <local>
                           <target uri="sip:bob@ua2.example.com">
                           </target>

    Johnston, et al.             Standards Track                   [Page 37]

    RFC 7463                 SIP Shared Appearances               March 2015

                          </local>
               </dialog>
       </dialog-info>

       F6 Appearance Agent ----> Bob

       NOTIFY sip:bob@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=497585728578386
       To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
       Call-ID: a7d559db-d6d7dcad-311c9e3a
       CSeq: 7 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com
        ;branch=z9hG4bK1711759878512309
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=2000
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="78"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
           <dialog id="02538339hfgdf3ce597f9e3egkl3699e28fc"
                call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                local-tag="15A3DE7C-9283203B"    direction="initiator">
                   <sa:appearance>1</sa:appearance>
                   <sa:exclusive>false</sa:exclusive>
                      <state>trying</state>
                       <local>
                           <target uri="sip:bob@ua2.example.com">
                           </target>
                          </local>
               </dialog>
       </dialog-info>

    11.4.  Outgoing Call with Appearance Seizure

       In this scenario, Bob's UA sends out a dialog event PUBLISH with
       state (trying) selecting/seizing an appearance number before sending
       the INVITE.  After receiving the 200 (OK) from the Appearance Agent
       confirming the appearance number, Bob's UA sends the INVITE to Carol
       and establishes a session.  For brevity, details of some of the
       messages are not included in the message flows.  Bob's UA puts as

    Johnston, et al.             Standards Track                   [Page 38]

    RFC 7463                 SIP Shared Appearances               March 2015

       much of the dialog information from F7 as can be determined in
       advance.  In this case, the minimum of the Contact URI is included,
       which allows the Appearance Agent to correlate the INVITE with the
       PUBLISH.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |<----- PUBLISH F1<|
       |              |               |              |                  |
       |              |               |              |>F2 200 OK ------>|
       |              |               |              |                  |
       |              |               |<-- NOTIFY F3<|                  |
       |              |               |              |                  |
       |              |               |>F4 200 OK -->|                  |
       |              |               |              |------- NOTIFY F5>|
       |              |               |              |                  |
       |              |               |              |<F6 200 OK ------<|
       |              |               |              |                  |
       |              |<------------------------------------- INVITE F7<|
       |              |               |              |                  |
       |              |>F8 100 Trying --------------------------------->|
       |<-- INVITE F9<|               |              |                  |
       |              |               |              |<---- PUBLISH F10<|
       |              |               |              |                  |
       |              |               |              |>F11 200 OK ----->|
       |              |               |              |                  |
       |>F12 180  --->|               |              |                  |
       |              |>F13 180 Ringing ------------------------------->|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F14<|                  |
       |              |               |              |                  |
       |              |               |>F15 200 OK ->|                  |
       |              |               |              |------ NOTIFY F16>|
       |              |               |              |                  |
       |              |               |              |<F17 200 OK -----<|
       |>F18 200 OK ->|               |              |                  |
       |              |>F19 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F20<|
       |<---- ACK F21<|               |              |                  |
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F22<|                  |

    Johnston, et al.             Standards Track                   [Page 39]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |                  |
       |              |               |>F23 200 OK ->|                  |
       |              |               |              |------ NOTIFY F24>|
       |              |               |              |                  |
       |              |               |              |<F25 200 OK -----<|
       |              |               |              |                  |

       Figure 4. Outgoing Call with Appearance Seizure Example

       F1 to F4: Bob uses the shared appearance of the Help Desk on his UA
       to place an outgoing call (e.g., he goes off-hook).  Before sending
       the outgoing INVITE request, Bob publishes to the Appearance Agent
       reserving appearance number 1.  The Appearance Agent notifies Alice
       (and all other UAs, including Bob) of the event by sending NOTIFYs.

       F1 Bob ----> Appearance Agent

       PUBLISH sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
       From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
       To: <sip:HelpDesk@example.com>
       CSeq: 7 PUBLISH
       Call-ID: 44fwF144-F12893K38424
       Contact: <sip:bob@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="6"
                    state="full"
                    entity="sip:HelpDesk@example.com">
           <dialog id="id3d4f9c83" direction="initiator">
               <sa:appearance>1</sa:appearance>
               <sa:exclusive>false</sa:exclusive>
               <state>trying</state>
               <local>
                   <target uri="sip:bob@ua2.example.com">
                   </target>
               </local>
           </dialog>
       </dialog-info>

    Johnston, et al.             Standards Track                   [Page 40]

    RFC 7463                 SIP Shared Appearances               March 2015

       F2 Appearance Agent  ----> Bob

       SIP/2.0 200 OK
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
       From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
       To: <sip:HelpDesk@example.com>
       CSeq: 7 PUBLISH
       Call-ID: 44fwF144-F12893K38424
       Contact: <sip:bob@ua2.example.com>
       Event: dialog;shared
       SIP-Etag: 482943245
       Allow-Events: dialog
       Expires: 60
       Content-Length: 0

       F7 Bob ---> Proxy

       INVITE sip:carol@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK342122
       Max-Forwards: 70
       From: <sip:HelpDesk@example.com>;tag=15A3DE7C-9283203B
       To: <sip:carol@example.com>
       Call-ID: f3b3cbd0-a2c5775e-5df9f8d5
       CSeq: 31 INVITE
       Contact: <sip:bob@ua2.example.com>
       Content-Type: application/sdp
       Content-Length: ...

       (SDP Not Shown)

       F10 Bob ----> Appearance Agent

       PUBLISH sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6d644638E7
       From: <sip:bob@example.com>;tag=0CCf6-A7FdsB79D
       To: <sip:HelpDesk@example.com>
       CSeq: 437 PUBLISH
       Call-ID: fwF14d4-F1FFF2F2893K38424
       Contact: <sip:bob@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"

    Johnston, et al.             Standards Track                   [Page 41]

    RFC 7463                 SIP Shared Appearances               March 2015

                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="6"
                    state="full"
                    entity="sip:HelpDesk@example.com">
           <dialog id="id3d4f9c83"
                call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                local-tag="15A3DE7C-9283203B"
                                                direction="initiator">
               <sa:appearance>1</sa:appearance>
               <sa:exclusive>false</sa:exclusive>
               <state>trying</state>
               <local>
                   <target uri="sip:bob@ua2.example.com">
                   </target>
               </local>
               <remote>
                   <identity uri="sip:carol@example.com">
                   </identity>
               </remote>
           </dialog>
       </dialog-info>

    11.5.  Outgoing Call without Using an Appearance Number

       In this scenario, Bob's UA sends out a dialog event PUBLISH with
       state (trying) indicating that he does not want to utilize an
       appearance number for this dialog.  The PUBLISH does not have an
       appearance element but does have the 'shared' Event header field
       parameter.  As a result, the Appearance Agent knows the UA does not
       wish to use an appearance number for this call.  If the Appearance
       Agent does not wish to allow this, it would reject the PUBLISH with a
       400 (Bad Request) response and the UA would know to re-PUBLISH
       selecting/seizing an appearance number.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |<----- PUBLISH F1<|
       |              |               |              |                  |
       |              |               |              |>F2 200 OK ------>|
       |              |               |              |                  |
       |              |               |<-- NOTIFY F3<|                  |
       |              |               |              |                  |
       |              |               |>F4 200 OK -->|                  |
       |              |               |              |------- NOTIFY F5>|
       |              |               |              |                  |
       |              |               |              |<F6 200 OK ------<|
       |              |               |              |                  |
       |              |<------------------------------------- INVITE F7<|

    Johnston, et al.             Standards Track                   [Page 42]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |                  |
       |              |>F8 100 Trying --------------------------------->|
       |<-- INVITE F9<|               |              |                  |
       |              |               |              |<---- PUBLISH F10<|
       |              |               |              |                  |
       |              |               |              |>F11 200 OK ----->|
       |              |               |              |                  |
       |>F12 180  --->|               |              |                  |
       |              |>F13 180 Ringing ------------------------------->|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F14<|                  |
       |              |               |              |                  |
       |              |               |>F15 200 OK ->|                  |
       |              |               |              |------ NOTIFY F16>|
       |              |               |              |                  |
       |              |               |              |<F17 200 OK -----<|
       |>F18 200 OK ->|               |              |                  |
       |              |>F19 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F20<|
       |<---- ACK F21<|               |              |                  |
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F22<|                  |
       |              |               |              |                  |
       |              |               |>F23 200 OK ->|                  |
       |              |               |              |------ NOTIFY F24>|
       |              |               |              |                  |
       |              |               |              |<F25 200 OK -----<|
       |              |               |              |                  |

       Figure 5. Outgoing Call without using an Appearance Number Example

       F1 Bob ----> Appearance Agent

       PUBLISH sip:appearanceagent.example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
       From: <sip:bob@example.com>;tag=4415df82k39sf
       To: <sip:HelpDesk@example.com>
       CSeq: 7 PUBLISH
       Call-ID: 44fwF144-F12893K38424
       Contact: <sip:bob@ua2.example.com>

    Johnston, et al.             Standards Track                   [Page 43]

    RFC 7463                 SIP Shared Appearances               March 2015

       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="6"
                    state="full"
                    entity="sip:HelpDesk@example.com">
           <dialog id="id3d4f9c83" direction="initiator">
               <sa:exclusive>false</sa:exclusive>
               <state>trying</state>
               <local>
                   <target uri="sip:bob@ua2.example.com">
                   </target>
               </local>
           </dialog>
       </dialog-info>

       Note that F7 would be the same as the previous example.

    11.6.  Appearance Release

       Bob and Carol are in a dialog, created, for example as in
       Section 11.3.  Carol sends a BYE to Bob to terminate the dialog and
       the Appearance Agent de-allocates the appearance number used, sending
       notifications out to the UAs in the shared group.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |>F22 BYE ---->|               |              |                  |
       |              |>F23 BYE --------------------------------------->|
       |              |               |              |                  |
       |              |<------------------------------------ 200 OK F24<|
       |<--200 OK F25<|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F26<|                  |
       |              |               |              |                  |
       |              |               |>F27 200 OK ->|                  |
       |              |               |              |------ NOTIFY F28>|
       |              |               |              |                  |
       |              |               |              |<F29 200 OK -----<|

    Johnston, et al.             Standards Track                   [Page 44]

    RFC 7463                 SIP Shared Appearances               March 2015

       Figure 6. Appearance Release Example

       F28 Appearance Agent ----> Bob

       NOTIFY sip:bob@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=497585728578386
       To: <sip:bob@example.com>
       Call-ID: a7d559db-d6d7dcad-311c9e3a
       CSeq: 7 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com
        ;branch=z9hG4bK759878512309
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=1800
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="27"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
           <dialog id="fa02538339df3ce597f9e3e3699e28fc"
                call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                local-tag="15A3DE7C-9283203B"
                remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
                                                direction="initiator">
                   <sa:appearance>1</sa:appearance>
                   <sa:exclusive>false</sa:exclusive>
                      <state>terminated</state>
                       <local>
                           <target uri="sip:bob@ua2.example.com">
                           </target>
                          </local>
               </dialog>
       </dialog-info>

    11.7.  Appearance Pickup

       In this scenario, Bob has an established dialog with Carol created
       using the call flows of Figures 1 or 2.  Bob then places Carol on
       hold.  Alice receives a notification of this and renders this on
       Alice's UI.  Alice subsequently picks up the held call and has a
       established session with Carol.  Finally, Carol hangs up.  Alice must
       PUBLISH F32 to indicate that the INVITE F38 will be an attempt to

    Johnston, et al.             Standards Track                   [Page 45]

    RFC 7463                 SIP Shared Appearances               March 2015

       pickup the dialog between Carol and Bob and, hence, may use the same
       appearance number.  This example also shows Secure SIP (sips) being
       used.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |<------------------------------(hold) INVITE F22<|
       |<- INVITE F23<|               |              |                  |
       |              |               |              |                  |
       |>F24 200 OK ->|               |              |                  |
       |              |>F25 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F26<|
       |<---- ACK F27<|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F28<|                  |
       |              |               |              |                  |
       |              |               |>F29 200 OK ->|                  |
       |              |               |              |>F30 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F31<|
       |              |               |              |                  |
       |              |  Alice decides to pick up the call              |
       |              |               |              |                  |
       |              |               |>F32 PUBLISH->|                  |
       |              |               |              |                  |
       |              |               |<- 200 OK F33<|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F34<|                  |
       |              |               |              |                  |
       |              |               |>F35 200 OK ->|                  |
       |              |               |              |>F36 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F37<|
       |              |<-- INVITE F38<|              |                  |
       |<- INVITE F39<|(w/ Replaces)  |              |                  |
       |( w/ Replaces)|               |              |                  |
       |>F40 200 OK ->|               |              |                  |
       |              |>F41 200 OK -->|              |                  |
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |              |>F42 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F43<|

    Johnston, et al.             Standards Track                   [Page 46]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |<- NOTIFY F44<|                  |
       |              |               |              |                  |
       |              |               |>F45 200 OK ->|                  |
       |              |               |              |                  |
       |              |<----- ACK F46<|              |                  |
       |<---- ACK F47<|               |              |                  |
       |              |               |              |                  |
       |<= Both way RTP established =>|              |                  |
       |              |               |              |                  |
       |>F48 BYE ---->|               |              |                  |
       |              |>F49 BYE --------------------------------------->|
       |              |               |              |                  |
       |              |<------------------------------------ OK 200 F50<|
       |<- 200 OK F51<|               |              |                  |
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F52<|                  |
       |              |               |              |                  |
       |              |               |>F53 200 OK ->|                  |
       |              |               |              |                  |
       |              |               |              |>F54 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F55<|

       Figure 7. Appearance Pickup Example

       F28 Appearance ----> Alice

       NOTIFY sips:alice@ua1.example.com SIP/2.0
       From: <sips:HelpDesk@example.com>;tag=151702541050937
       To: <sips:alice@example.com>;tag=18433323-C3D237CE
       Call-ID: 1e361d2f-a9f51109-bafe31d4
       CSeq: 12 NOTIFY
       Via: SIP/2.0/TLS appearanceagent.example.com
        ;branch=z9hG4bK1403
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=1800
       Contact: <sips:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"

    Johnston, et al.             Standards Track                   [Page 47]

    RFC 7463                 SIP Shared Appearances               March 2015

                    state="partial"
                    entity="sips:HelpDesk@example.com">
          <dialog id="id3d4f9c83"
                call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                local-tag="15A3DE7C-9283203B"
                remote-tag="65a98f7c-1dd2-11b2-88c6-b0316298f7c"
                direction="initiator">
                <sa:appearance>1</sa:appearance>
                <sa:exclusive>false</sa:exclusive>
                <state>active</state>
                <local>
                  <target uri="sips:bob@ua2.example.com">
                    <param pname="+sip.rendering" pval="no"/>
                  </target>
                </local>
                <remote>
                  <identity>sips:carol@example.com</identity>
                  <target uri="sips:carol@ua3.example.com" />
                </remote>
           </dialog>
       </dialog-info>

       F32 Alice ----> Appearance Agent

       PUBLISH sips:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
       From: <sips:HelpDesk@example.com>;tag=44150CC6-A7B7919D
       To: <sips:alice@example.com>;tag=428765950880801
       CSeq: 11 PUBLISH
       Call-ID: 87837Fkw87asfds
       Contact: <sips:alice@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"
                    state="full"
                    entity="sips:HelpDesk@example.com">
          <dialog id="id3d4f9c83"
              call-id="3d57cd17-47deb849-dca8b6c6"
                             local-tag="8C4183CB-BCEAB710" >
                <sa:appearance>1</sa:appearance>
                <sa:exclusive>false</sa:exclusive>

    Johnston, et al.             Standards Track                   [Page 48]

    RFC 7463                 SIP Shared Appearances               March 2015

                <sa:replaced-dialog
                  call-id="f3b3cbd0-a2c5775e-5df9f8d5"
                  from-tag="15A3DE7C-9283203B"
                  to-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c" />
                <state>trying</state>
                <local>
                  <target uri="sips:alice@ua1.example.com">
                    <param pname="+sip.rendering" pval="yes"/>
                  </target>
                </local>
                <remote>
                    <target uri="sips:carol@ua3.example.com" />
                </remote>
           </dialog>
       </dialog-info>

       F38 Alice ----> Proxy

       INVITE sips:carol@example.com SIP/2.0
       Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
       From: <sips:HelpDesk@example.com>;tag=8C4183CB-BCEAB710
       To: <sips:carol@example.com:5075>
       CSeq: 1 INVITE
       Call-ID: 3d57cd17-47deb849-dca8b6c6
       Contact: <sips:alice@ua1.example.com>
       <all-one-line>
       Replaces: f3b3cbd0-a2c5775e-5df9f8d5;to-tag=65a98f7c
       -1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
       </all-one-line>
       Max-Forwards: 70
       Content-Type: application/sdp
       Content-Length: 223

       v=0
       o=- 1102980497 1102980497 IN IP4 ua1.example.com
       s=IP SIP UA
       c=IN IP4 ua1.example.com
       t=0 0
       a=sendrecv
       m=audio 2238 RTP/AVP 0 8 101
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:101 telephone-event/8000

    Johnston, et al.             Standards Track                   [Page 49]

    RFC 7463                 SIP Shared Appearances               March 2015

    11.8.  Call between UAs within the Group

       In this scenario, Bob calls Alice who is also in the shared
       appearance group.  Only one appearance number is used for this
       dialog.  This example also shows the use of the 'exclusive' tag to
       indicate that other UAs in the group can not join or take this
       dialog.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |<--------------------  INVITE (to Alice's UA) F1<|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |              |                  |
       |              |               |<-- NOTIFY F2<|                  |
       |              |               |              |                  |
       |              |               |>F3 200 OK -->|                  |
       |              |               |              |>F4 NOTIFY ------>|
       |              |               |              |                  |
       |              |               |              |<------ 200 OK F5<|
       |              |>F6 INVITE --->|              |                  |
       |              | (appearance=1)|              |                  |
       |              |               |              |                  |
       |              |<------ 180 F7<|              |                  |
       |              |               |              |                  |
       |              |>F8 180  --------------------------------------->|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<-- NOTIFY F9<|                  |
       |              |               |              |                  |
       |              |               |>F10 200 OK ->|                  |
       |              |               |              |>F11 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F12<|
       |              |<-- 200 OK F13<|              |                  |
       |              |               |              |                  |
       |              |>F14 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F15<|
       |              |               |              |                  |
       |              |>F16 ACK ----->|              |                  |
       |              |               |              |                  |
       |              |               |<======= RTP established =======>|
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |

    Johnston, et al.             Standards Track                   [Page 50]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |<- NOTIFY F17<|                  |
       |              |               |              |                  |
       |              |               |>F18 200 OK ->|                  |
       |              |               |              |>F19 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F24<|
       |              |               |              |                  |

       Figure 8. Call between UAs within the Group Example

       F19 Appearance Agent ----> Bob

       NOTIFY sip:bob@ua1.example.com SIP/2.0
       From: <sip:HelpDesk@example.com>;tag=497585728578386
       To: <sip:bob@example.com>;tag=633618CF-B9C2EDA4
       Call-ID: a7d559db-d6d7dcad-311c9e3a
       CSeq: 7 NOTIFY
       Via: SIP/2.0/UDP appearanceagent.example.com
        ;branch=z9hG4bK1711759878512309
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Event: dialog;shared
       Subscription-State: active;expires=1500
       Contact: <sip:appearanceagent.example.com>
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"
                    state="partial"
                    entity="sip:HelpDesk@example.com">
          <dialog id="3xdsd4f9c83"
                  call-id="b3cbd0-ad2c5775e-5df9f8d5"
                     local-tag="34322kdfr234f"
                  remote-tag="3153DE7C-928203B"
                  direction="initiator">
                <sa:exclusive>true</sa:exclusive>
                <sa:appearance>1</sa:appearance>
                <state>confirmed</state>
                <local>
                  <target uri="sip:bob@ua2.example.com">
                  </target>
                </local>
                <remote>
                  <identity>sip:HelpDesk@example.com</identity>
                  <target uri="sip:alice@ua1.example.com" />

    Johnston, et al.             Standards Track                   [Page 51]

    RFC 7463                 SIP Shared Appearances               March 2015

                </remote>
           </dialog>

           <dialog id="4839589"
                  call-id="b3cbd0-ad2c5775e-5df9f8d5"
                  local-tag="3153DE7C-928203B"
                     remote-tag="34322kdfr234f"
                  direction="responder">
                <sa:exclusive>true</sa:exclusive>
                <sa:appearance>1</sa:appearance>
                <state>confirmed</state>
                <local>
                   <target uri="sip:alice@ua1.example.com" />
                </local>
                <remote>
                  <identity>sip:HelpDesk@example.com</identity>
                  <target uri="sip:bob@ua2.example.com" />
                </remote>
           </dialog>

       </dialog-info>

    11.9.  Consultation Hold with Appearances

       In this scenario, Bob has a call with Carol.  Bob makes a
       consultation call to Alice by putting Carol on hold and calling
       Alice.  Bob's UA chooses not to have an appearance number for the
       call to Alice since it is treating it as part of the call to Carol.
       He indicates this in the PUBLISH F32, which contains the 'shared'
       Event header field parameter but no <appearance> element.  The
       PUBLISH is sent before the INVITE to Alice to ensure no appearance
       number is assigned by the Appearance Agent.  Finally, Bob hangs up
       with Alice and resumes the call with Carol.  Dialog notifications of
       the consultation call are not shown, as they are not used.

       Note that if Carol hangs up while Bob is consulting with Alice, Bob
       can decide if he wants to reuse the appearance number used with Carol
       for the call with Alice.  If not, Bob publishes the termination of
       the dialog with Carol and the Appearance Agent will re-allocate the
       appearance.  If he wants to keep the appearance, Bob will publish the
       termination of the dialog with Carol and also publish the appearance
       with the dialog with Alice.  This will result in Bob keeping the
       appearance number until he reports the dialog with Alice terminated.

       Note that the call flow would be similar if Bob called a music on
       hold server instead of Alice to implement a music on hold service as
       described in [RFC7088].

    Johnston, et al.             Standards Track                   [Page 52]

    RFC 7463                 SIP Shared Appearances               March 2015

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |<------------------------------(hold) INVITE F22<|
       |<- INVITE F23<|               |              |                  |
       |              |               |              |                  |
       |>F24 200 OK ->|               |              |                  |
       |              |>F25 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F26<|
       |<---- ACK F27<|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F28<|                  |
       |              |               |              |                  |
       |              |               |>F29 200 OK ->|                  |
       |              |               |              |>F30 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F31<|
       |              |               |              |                  |
       |              |  Bob makes a consultation call to Alice         |
       |              |               |              |                  |
       |              |               |              |<---- PUBLISH F32<|
       |              |               |              |                  |
       |              |               |              |>F33 200 OK ----->|
       |              |               |              |                  |
       |              |<------------------------------------ INVITE F34<|
       |              |               |              |                  |
       |              |>F35 INVITE -->|              |                  |
       |              |               |              |                  |
       |              |<-- 200 OK F36<|              |                  |
       |              |               |              |                  |
       |              |>F37 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F38<|
       |              |               |              |                  |
       |              |>F39 ACK ----->|              |                  |
       |              |               |              |                  |
       |              |               |<======= RTP established =======>|
       |              |               |              |                  |
       |              |            Bob hangs up with Alice              |
       |              |               |              |                  |
       |              |<--------------------------------------- BYE F40<|
       |              |               |              |                  |
       |              |>F41 BYE ----->|              |                  |
       |              |               |              |                  |
       |              |<-- 200 OK F42<|              |                  |

    Johnston, et al.             Standards Track                   [Page 53]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |                  |
       |              |>F43 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<----------------------------(unhold) INVITE F44<|
       |<- INVITE F45<|               |              |                  |
       |              |               |              |                  |
       |>F46 200 OK ->|               |              |                  |
       |              |>F47 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F48<|
       |<---- ACK F49<|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F50<|                  |
       |              |               |              |                  |
       |              |               |>F51 200 OK ->|                  |
       |              |               |              |>F52 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F53<|
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |

       Figure 9. Consultation Hold with Appearances Example

       F32 Bob ----> Appearance Agent

       PUBLISH sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
       From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
       To: <sip:HelpDesk@example.com>;tag=428765950880801
       CSeq: 11 PUBLISH
       Call-ID: 44fwF144-F12893K38424
       Contact: <sip:bob@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"
                    state="full"
                    entity="sip:HelpDesk@example.com">
          <dialog id="id3d4f9c83"
                  call-id="b3cbd0-ad2c5775e-5df9f8d5"
                  local-tag="3153DE7C-928203B"

    Johnston, et al.             Standards Track                   [Page 54]

    RFC 7463                 SIP Shared Appearances               March 2015

                  direction="initiator">
                <sa:exclusive>true</sa:exclusive>
                <state>trying</state>
                <local>
                  <target uri="sip:bob@ua2.example.com">
                  </target>
                </local>
                <remote>
                  <identity>sip:HelpDesk@example.com</identity>
                  <target uri="sip:alice@ua1.example.com" />
                </remote>
           </dialog>
       </dialog-info>

    11.10.  Joining or Bridging an Appearance

       In this call flow, a call answered by Bob is joined by Alice or
       "bridged".  The Join header field is used by Alice to request this
       bridging.  If Bob did not support media mixing, Bob could obtain
       conferencing resources as described in [RFC4579].

       Carol    Forking Proxy Appearance Agent  Alice      Bob
         |            |             |             |         |
         |<=============Both way RTP established===========>|
         |            |             |             |         |
         |            |             |< PUBLISH F22|         |
         |            |             |             |         |
         |            |             |>F23 200 OK >|         |
         |            |             |             |         |
         |            |<---- INVITE (w/ Join) F24<|         |
         |            |             |             |         |
         |            |>F25 INVITE (w/Join)---------------->|
         |            |             |             |         |
         |            |<---- OK 200 Contact:Bob;isfocus F26<|
         |            |             |             |         |
         |            |< - - - - - >|             |         |
         |            |             |             |         |
         |            |             |>F27 NOTIFY >|         |
         |            |             |             |         |
         |            |             |< 200 OK F28<|         |
         |            |             |             |         |
         |            |             |>F29 NOTIFY ---------->|
         |            |             |             |         |
         |            |             |<F30 200 OK ----------<|
         |            |             |             |         |
         |            |>F31 200 OK Contact:B----->|         |
         |            |             |             |         |
         |            |<----------------- ACK F32<|         |

    Johnston, et al.             Standards Track                   [Page 55]

    RFC 7463                 SIP Shared Appearances               March 2015

         |            |             |             |         |
         |            |>ACK F33---------------------------->|
         |            |             |             |         |
         |            |<-----INVITE Contact:Bob;isfocus F34<|
         |<-INVITE F35|             |             |         |
         |            |             |             |         |
         |>F26 200 -->|             |             |         |
         |            |>F37 200 OK ------------------------>|
         |            |             |             |         |
         |            |<--------------------------- ACK F38<|
         |<--- ACK F39|             |             |         |
         |            |             |             |<==RTP==>|
         |<=============Both way RTP established===========>|
         |            |             |             |         |
         |            |< - - - - - >|             |         |
         |            |             |             |         |
         |            |             |>F40 NOTIFY >|         |
         |            |             |             |         |
         |            |             |< 200 OK F41<|         |
         |            |             |             |         |
         |            |             |>F42 NOTIFY ---------->|
         |            |             |             |         |
         |            |             |<F43 200 OK ----------<|
         |            |             |             |         |

       Figure 10. Joining or Bridging an Appearance Example

       F22 Alice ----> Appearance Agent

       PUBLISH sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
       From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
       To: <sip:HelpDesk@example.com>;tag=428765950880801
       CSeq: 11 PUBLISH
       Call-ID: 87837Fkw87asfds
       Contact: <sip:alice@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"
                    state="full"
                    entity="sip:HelpDesk@example.com:5060">
          <dialog id="id3d4f9c83"

    Johnston, et al.             Standards Track                   [Page 56]

    RFC 7463                 SIP Shared Appearances               March 2015

              call-id="dc95da63-60db1abd-d5a74b48"
              local-tag="605AD957-1F6305C2" >
                <sa:appearance>1</sa:appearance>
                <sa:exclusive>false</sa:exclusive>
                <sa:joined-dialog
                  call-id="14-1541707345"
                  from-tag="44BAD75D-E3128D42"
                  to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
                <state>trying</state>
                <local>
                  <target uri="sip:alice@ua1.example.com">
                  </target>
                </local>
                <remote>
                    <target uri="sip:bob@example.com" />
                </remote>
           </dialog>
       </dialog-info>

       F24 Alice ----> Proxy

       INVITE sip:bob@ua.example.com SIP/2.0
       Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
       From: <sip:HelpDesk@example.com>;tag=605AD957-1F6305C2
       To: <sip:bob@ua.example.com>
       CSeq: 2 INVITE
       Call-ID: dc95da63-60db1abd-d5a74b48
       Contact: <sip:alice@ua1.example.com>
       <all-one-line>
       Join: 14-1541707345;to-tag=d3b06488-1dd1-11b2-88c5
       -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
       </all-one-line>
       Max-Forwards: 70
       Content-Type: application/sdp
       Content-Length: 223

       v=0
       o=- 1103061265 1103061265 IN IP4 ua1.example.com
       s=IP SIP UA
       c=IN IP4 ua1.example.com
       t=0 0
       a=sendrecv
       m=audio 2236 RTP/AVP 0 8 101
       a=rtpmap:0 PCMU/8000
       a=rtpmap:8 PCMA/8000
       a=rtpmap:101 telephone-event/8000

    Johnston, et al.             Standards Track                   [Page 57]

    RFC 7463                 SIP Shared Appearances               March 2015

    11.11.  Loss of Appearance during Allocation

       Bob reserves an appearance with a PUBLISH, sends an INVITE to Carol,
       then becomes unreachable.  When he fails to refresh his publication
       to the appearance agent, the Appearance Agent declares the dialog
       terminated and frees up the appearance using NOTIFYs F14 and F16.
       After retransmitting the NOTIFY to Bob (in not shown messages F17,
       F18, etc.), the subscription is terminated.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |<----- PUBLISH F1<|
       |              |               |              |                  |
       |              |               |              |>F2 200 OK ------>|
       |              |               |              |                  |
       |              |               |<-- NOTIFY F3<|                  |
       |              |               |              |                  |
       |              |               |>F4 200 OK -->|                  |
       |              |               |              |------- NOTIFY F5>|
       |              |               |              |                  |
       |              |               |              |<F6 200 OK ------<|
       |              |               |              |                  |
       |              |<------------------------------------- INVITE F7<|
       |              |               |              |                  |
       |              |>F8 100 Trying --------------------------------->|
       |<-- INVITE F9<|               |              |                  |
       |              |               |              |<---- PUBLISH F10<|
       |              |               |              |                  |
       |              |               |              |>F11 200 OK ----->|
       |              |               |              |                  |
       |>F12 180  --->|               |              |                  |
       |              |>F13 180 Ringing ------------------------------->|
       |              |               |              |                  |
       |              |               |              | Bob goes offline |
       |              |               |              |                  |
       |              |               | Appearance selection times out  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F14<|                  |
       |              |               |              |                  |
       |              |               |>F15 200 OK ->|                  |
       |              |               |              |------ NOTIFY F16>|
       |              |               |              |                  |
       |              |               |   NOTIFY is retransmitted       |

       Figure 11. Loss of Appearance during Allocation Example

    Johnston, et al.             Standards Track                   [Page 58]

    RFC 7463                 SIP Shared Appearances               March 2015

    11.12.  Appearance Seizure Contention Race Condition

       Bob and Alice both try to reserve appearance 2 by publishing at the
       same time.  The Appearance Agent allocates the appearance to Bob by
       sending a 200 OK and denies it to Alice by sending a 400 (Bad
       Request) response.  After the NOTIFY F5, Alice learns that Bob is
       using appearance 2.  Alice then attempts to reserve appearance 3 by
       publishing, which is then accepted.

    Johnston, et al.             Standards Track                   [Page 59]

    RFC 7463                 SIP Shared Appearances               March 2015

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |               |              |<----- PUBLISH F1<|
       |              |               |              |        (appearance=2)
       |              |               |>F2 PUBLISH ->|                  |
       |              |               |     (appearance=2)              |
       |              |               |              |                  |
       |              |               |              |>F3 200 OK ------>|
       |              |               |<---- F4 400 <|                  |
       |              |               |              |                  |
       |              |               |<-- NOTIFY F5<|                  |
       |              |               |              |                  |
       |              |               |>F6 200 OK -->|                  |
       |              |               |              |------- NOTIFY F7>|
       |              |               |              |                  |
       |              |               |              |<F8 200 OK ------<|
       |              |               |              |                  |
       |              |<------------------------------------- INVITE F9<|
       |              |               |              |                  |
       |              |>F10 100 Trying -------------------------------->|
       |<- INVITE F11<|               |              |                  |
       |              |               |              |<---- PUBLISH F12<|
       |              |               |              |        (appearance=2)
       |              |               |              |>F13 200 OK ----->|
       |              |               |>F14 PUBLISH->|                  |
       |              |               |     (appearance=3)              |
       |              |               |              |                  |
       |              |               |<--- F15 200 <|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F16<|                  |
       |              |               |              |                  |
       |              |               |>F17 200 OK ->|                  |
       Dave           |               |              |------ NOTIFY F18>|
       |              |               |              |                  |
       |              |               |              |<F19 200 OK -----<|
       |              |<-- INVITE F20<|              |                  |
       |              |               |              |                  |
       |              |>F21 100 ----->|              |                  |
       |<- INVITE F22<|               |              |                  |

       Figure 12. Appearance Seizure Contention Race Condition Example

    11.13.  Appearance Agent Subscription to UAs

       In this scenario, the Appearance Agent does not have any way of
       knowing Bob's dialog state information, except through Bob.  This
       could be because the Appearance Agent is not part of a B2BUA, or

    Johnston, et al.             Standards Track                   [Page 60]

    RFC 7463                 SIP Shared Appearances               March 2015

       perhaps Bob is remotely registering.  When Bob registers, the
       Appearance Agent receives a registration event package notification
       from the registrar.  The Appearance Agent then SUBSCRIBEs to Bob's
       dialog event state using Event:dialog in the SUBSCRIBE.  Whenever
       Bob's dialog state changes, Bob's UA sends a NOTIFY to the Appearance
       Agent which then notifies the other UAs in the group.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |              |<----------------------------------- REGISTER F1<|
       |              |               |              |                  |
       |              |>F2 200 OK ------------------------------------->|
       |              |               |              |                  |
       |              |>F3 NOTIFY ------------------>|                  |
       |              |               |              |                  |
       |              |<------------------ 200 OK F4<|                  |
       |              |               |              |---- SUBSCRIBE F5>|
       |              |               |              |                  |
       |              |               |              |<F6 200 OK ------<|
       |              |               |              |                  |
       |              |               |              |<------ NOTIFY F7<|
       |              |               |              |                  |
       |              |               |              |>F8 200 OK ------>|
       |              |               |              |                  |
       |              |               |              |<--- SUBSCRIBE F9<|
       |              |               |              |                  |
       |              |               |              |>F10 200 OK ----->|
       |              |               |              |                  |
       |              |               |              |------ NOTIFY F11>|
       |              |               |              |                  |
       |              |               |              |<F12 200 OK -----<|
       |              |               |              |                  |
       |              |<------------------------------------ INVITE F13<|
       |              |               |              |                  |
       |              |>F14 100 Trying -------------------------------->|
       |<- INVITE F15<|               |              |                  |
       |              |               |              |<----- NOTIFY F16<|
       |              |               |              |                  |
       |              |               |              |>F17 200 OK ----->|
       |              |               |<- NOTIFY F18<|                  |
       |              |               |              |                  |
       |              |               |>F19 200 OK ->|                  |
       |              |               |              |------ NOTIFY F20>|
       |              |               |              |                  |
       |              |               |              |<F21 200 OK -----<|
       |>F22 180  --->|               |              |                  |
       |              |>F23 180 Ringing ------------------------------->|
       |              |               |              |                  |

    Johnston, et al.             Standards Track                   [Page 61]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |<----- NOTIFY F24<|
       |              |               |              |                  |
       |              |               |              |>F25 200 OK ----->|
       |              |               |<- NOTIFY F26<|                  |
       |              |               |              |                  |
       |              |               |>F27 200 OK ->|                  |
       |              |               |              |------ NOTIFY F28>|
       |              |               |              |                  |
       |              |               |              |<F29 200 OK -----<|
       |>F30 200 OK ->|               |              |                  |
       |              |>F31 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |               |              |<----- NOTIFY F32<|
       |              |               |              |                  |
       |              |               |              |>F33 200 OK ----->|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F34<|
       |<---- ACK F35<|               |              |                  |
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |               |<- NOTIFY F36<|                  |
       |              |               |              |                  |
       |              |               |>F37 200 OK ->|                  |
       |              |               |              |------ NOTIFY F38>|
       |              |               |              |                  |
       |              |               |              |<F39 200 OK -----<|
       |              |               |              |                  |

       Figure 13. Appearance Agent Subscription to UAs Example

    11.14.  Appearance Pickup Race Condition Failure

       In this scenario, Bob has an established dialog with Carol created
       using the call flows of Figure 1 or Figure 2.  Bob then places Carol
       on hold.  Alice receives a notification of this and renders this on
       Alice's UI.  Alice attempts to pick up the call but Carol hangs up
       before the pickup can complete.  Alice cancels the pickup attempt
       with the PUBLISH F48.  Note that the call flow for a failed Join
       would be almost identical.

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |<================= Both way RTP established ===================>|
       |              |               |              |                  |
       |              |<------------------------------(hold) INVITE F22<|
       |<- INVITE F23<|               |              |                  |

    Johnston, et al.             Standards Track                   [Page 62]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |                  |
       |>F24 200 OK ->|               |              |                  |
       |              |>F25 200 OK ------------------------------------>|
       |              |               |              |                  |
       |              |<--------------------------------------- ACK F26<|
       |<---- ACK F27<|               |              |                  |
       |              |               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F28<|                  |
       |              |               |              |                  |
       |              |               |>F29 200 OK ->|                  |
       |              |               |              |>F30 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F31<|
       |              |               |              |                  |
       |              |  Alice decides to pick up the call              |
       |              |               |              |                  |
       |              |               |>F32 PUBLISH->|                  |
       |              |               |              |                  |
       |              |               |<- 200 OK F33<|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F34<|                  |
       |              |               |              |                  |
       |              |               |>F35 200 OK ->|                  |
       |              |               |              |>F36 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F37<|
       |>F38 BYE ---->|               |              |                  |
       |              |>F39 BYE --------------------------------------->|
       |              |               |              |                  |
       |              |<------------------------------------ OK 200 F40<|
       |<- 200 OK F41<|               |              |                  |
       |              |<-- INVITE F42<|              |                  |
       |<- INVITE F43<|(w/ Replaces)  |              |                  |
       |( w/ Replaces)|               |              |                  |
       |              |               |              |                  |
       |>F44 481 ---->|               |              |                  |
       |              |>F45 481 ----->|              |                  |
       |<---- ACK F46<|               |              |                  |
       |              |<----- ACK F47<|              |                  |
       |              |               |>F48 PUBLISH->|                  |
       |              |               |              |                  |
       |              |               |<- 200 OK F49<|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F50<|                  |
       |              |               |              |                  |
       |              |               |>F51 200 OK ->|                  |

    Johnston, et al.             Standards Track                   [Page 63]

    RFC 7463                 SIP Shared Appearances               March 2015

       |              |               |              |>F52 NOTIFY ----->|
       |              |               |              |                  |
       |              |               |              |<----- 200 OK F53<|

       Figure 14. Appearance Pickup Race Condition Failure Example

       F48 Alice ----> Appearance Agent

       PUBLISH sip:HelpDesk@example.com SIP/2.0
       Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
       From: <sip:alice@example.com>;tag=44150CC6-A7B7919D
       To: <sip:HelpDesk@example.com>;tag=428765950880801
       CSeq: 11 PUBLISH
       Call-ID: 87837Fkw87asfds
       Contact: <sip:alice@ua2.example.com>
       Event: dialog;shared
       Max-Forwards: 70
       Content-Type: application/dialog-info+xml
       Content-Length: ...

       <?xml version="1.0"?>
       <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                    xmlns:sa="urn:ietf:params:xml:ns:sa-dialog-info"
                    version="10"
                    state="full"
                    entity="sip:HelpDesk@example.com">
          <dialog id="id3d4f9c83"
              call-id="dc95da63-60db1abd-d5a74b48"
              local-tag="605AD957-1F6305C2" >
                <sa:appearance>1</sa:appearance>
                <sa:exclusive>false</sa:exclusive>
                <sa:replaced-dialog
                  call-id="14-1541707345"
                  from-tag="44BAD75D-E3128D42"
                  to-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c" />
                <state>terminated</state>
                <local>
                  <target uri="sip:alice@ua1.example.com">
                  </target>
                </local>
                <remote>
                    <target uri="sip:carol@ua3.example.com" />
                </remote>
           </dialog>
       </dialog-info>

    Johnston, et al.             Standards Track                   [Page 64]

    RFC 7463                 SIP Shared Appearances               March 2015

    11.15.  Appearance Seizure Incoming/Outgoing Contention Race Condition

       Alice tries to seize appearance 2 at the same time appearance 2 is
       allocated to an incoming call.  The Appearance Agent resolves the
       conflict by sending a 400 (Bad Request) to Alice.  After the NOTIFY
       F6, Alice learns that the incoming call is using appearance 2.  Alice
       republishes for appearance 3, which is accepted.  Note that this
       example shows the INVITE being received before the NOTIFY from the
       Appearance Agent.

    Johnston, et al.             Standards Track                   [Page 65]

    RFC 7463                 SIP Shared Appearances               March 2015

       Carol        Proxy           Alice     Appearance Agent         Bob
       |              |               |              |                  |
       |>-- INVITE F1>|               |              |                  |
       |              |< - - - - - - - - - - - - - ->|                  |
       |              |               |              |                  |
       |              |               |>F2 PUBLISH ->|                  |
       |              |               |     (appearance=2)              |
       |              |               |              |                  |
       |              |>F3 INVITE (appearance=2) ---------------------->|
       |              |               |              |                  |
       |              |>F4 INVITE     |              |                  |
       |              |(appearance=2)>|              |                  |
       |              |               |<---- F5 400 <|                  |
       |              |               |              |                  |
       |              |               |<-- NOTIFY F6<|                  |
       |              |               |              |                  |
       |              |               |>F7 200 OK -->|                  |
       |              |               |              |------- NOTIFY F8>|
       |              |               |              |                  |
       |              |               |              |<F9 200 OK ------<|
       |              |               |              |                  |
       |              |               |>F10 PUBLISH->|                  |
       |              |               |     (appearance=3)              |
       |              |               |              |                  |
       |              |               |< F11 200 OK <|                  |
       |              |               |              |                  |
       |              |               |<- NOTIFY F12<|                  |
       |              |               |              |                  |
                      |               |>F13 200 OK ->|                  |
       Dave           |               |              |------ NOTIFY F14>|
       |              |               |              |                  |
       |              |               |              |<F15 200 OK -----<|
       |              |<-- INVITE F16<|              |                  |
       |              |               |              |                  |
       |              |>F17 100 ----->|              |                  |
       |<- INVITE F18<|               |              |                  |

       Figure 15. Appearance Seizure Incoming/Outgoing Contention
                  Race Condition Example

    12.  Security Considerations

       Since multiple line appearance features are implemented using
       semantics provided by SIP [RFC3261], the SIP Event Package for Dialog
       State [RFC4235], and the SIP Event Framework [RFC6665] and [RFC3903],
       security considerations in these documents apply to this document as
       well.

    Johnston, et al.             Standards Track                   [Page 66]

    RFC 7463                 SIP Shared Appearances               March 2015

       To provide confidentiality, NOTIFY or PUBLISH message bodies that
       provide the dialog state information and the dialog identifiers MAY
       be encrypted end-to-end using the standard mechanisms such as S/MIME
       described in [RFC3261].  Alternatively, sending the NOTIFY and
       PUBLISH requests over TLS also provides confidentiality, although on
       a hop-by-hop basis.  All SUBSCRIBEs and PUBLISHes between the UAs and
       the Appearance Agent MUST be authenticated.  Without proper
       authentication and confidentiality, a third party could learn
       information about dialogs associated with a AOR and could try to use
       this information to hijack or manipulate those dialogs using SIP call
       control primitives.

       This feature relies on standard SIP call control primitives such as
       Replaces and Join.  Proper access controls on their use MUST be used
       so that only members of the shared appearance group can use these
       mechanisms.  All INVITEs with Replaces or Join header fields MUST
       only be accepted if the peer requesting dialog replacement or joining
       has been properly authenticated using a standard SIP mechanism (such
       as Digest or S/MIME), and authorized to request a replacement.
       Otherwise, a third party could disrupt or hijack existing dialogs in
       the shared appearance group.

       For an emergency call, a UA MUST NOT wait for a confirmed seizure of
       an appearance before sending an INVITE.  Waiting for confirmation
       could inadvertently delay or block the emergency call, which by its
       nature needs to be placed as expeditiously as possible.  Instead, a
       emergency call MUST proceed regardless of the status of the PUBLISH
       transaction.

    13.  IANA Considerations

       This section registers the SIP Event header field parameter 'shared',
       the SIP Alert-Info header field parameter 'appearance', and the XML
       namespace extensions to the SIP Dialog Package.

    13.1.  SIP Event Header Field Parameter: shared

       This document defines the 'shared' header field parameter in the
       Event header field in the "Header Field Parameters and Parameter
       Values" registry defined by [RFC3968].

                                                        Predefined
      Header Field                  Parameter Name      Values     Reference
      ----------------------------  ------------------  ---------- ---------
      Event                         shared               No        RFC 7463

    Johnston, et al.             Standards Track                   [Page 67]

    RFC 7463                 SIP Shared Appearances               March 2015

    13.2.  SIP Alert-Info Header Field Parameter: appearance

       This document defines the 'appearance' parameter in the Alert-Info
       header in the "Header Field Parameters and Parameter Values" registry
       defined by [RFC3968].

                                                        Predefined
       Header Field                  Parameter Name     Values     Reference
       ----------------------        ---------------    ---------  ---------
       Alert-Info                    appearance         No         RFC 7463

    13.3.  URN Sub-Namespace Registration: sa-dialog-info

       This section registers a new XML namespace per the procedures in
       [RFC3688].

          URI: urn:ietf:params:xml:ns:sa-dialog-info.

          Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
          Alan Johnston <alan.b.johnston@gmail.com>

          XML:

          BEGIN
           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
           <html xmlns="http://www.w3.org/1999/xhtml">
           <head>
             <meta http-equiv="content-type"
                content="text/html;charset=iso-8859-1"/>
             <title>Shared Appearance Dialog Information Namespace</title>
           </head>
           <body>
            <h1>Namespace for Shared Appearance Dialog Information</h1>
            <h2>urn:ietf:params:xml:ns:sa-dialog-info</h2>
            <p>See <a href="http://www.rfc-editor.org/rfc/rfc7463.txt">
               RFC 7463</a>.</p>
           </body>
           </html>
          END

    13.4.  XML Schema Registration

       This section registers an XML schema per the procedures in [RFC3688].

    Johnston, et al.             Standards Track                   [Page 68]

    RFC 7463                 SIP Shared Appearances               March 2015

          URI: urn:ietf:params:xml:schesa:sa-dialog-info.

          Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
           Alan Johnston <alan.b.johnston@gmail.com>

          The XML for this schema can be found in Section 6.

    14.  References

    14.1.  Normative References

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997,
                  <http://www.rfc-editor.org/info/rfc2119>.

       [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, <http://www.rfc-editor.org/info/rfc3261>.

       [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
                  Method", RFC 3515, April 2003,
                  <http://www.rfc-editor.org/info/rfc3515>.

       [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
                  January 2004, <http://www.rfc-editor.org/info/rfc3688>.

       [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
                  "Indicating User Agent Capabilities in the Session
                  Initiation Protocol (SIP)", RFC 3840, August 2004,
                  <http://www.rfc-editor.org/info/rfc3840>.

       [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
                  Protocol (SIP) "Replaces" Header", RFC 3891, September
                  2004, <http://www.rfc-editor.org/info/rfc3891>.

       [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
                  for Event State Publication", RFC 3903, October 2004,
                  <http://www.rfc-editor.org/info/rfc3903>.

       [RFC3911]  Mahy, R. and D. Petrie, "The Session Initiation Protocol
                  (SIP) "Join" Header", RFC 3911, October 2004,
                  <http://www.rfc-editor.org/info/rfc3911>.

    Johnston, et al.             Standards Track                   [Page 69]

    RFC 7463                 SIP Shared Appearances               March 2015

       [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
                  (IANA) Header Field Parameter Registry for the Session
                  Initiation Protocol (SIP)", BCP 98, RFC 3968, December
                  2004, <http://www.rfc-editor.org/info/rfc3968>.

       [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
                  Initiated Dialog Event Package for the Session Initiation
                  Protocol (SIP)", RFC 4235, November 2005,
                  <http://www.rfc-editor.org/info/rfc4235>.

       [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", STD 68, RFC 5234, January 2008,
                  <http://www.rfc-editor.org/info/rfc5234>.

       [RFC6665]  Roach, A., "SIP-Specific Event Notification", RFC 6665,
                  July 2012, <http://www.rfc-editor.org/info/rfc6665>.

       [RFC7462]  Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and
                  P. Kyzivat, "URNs for the Alert-Info Header Field of the
                  Session Initiation Protocol (SIP)", RFC 7462, March 2015,
                  <http://www.rfc-editor.org/info/rfc7462>.

    14.2.  Informative References

       [RFC3680]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
                  Package for Registrations", RFC 3680, March 2004,
                  <http://www.rfc-editor.org/info/rfc3680>.

       [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
                  (SIP) Call Control - Conferencing for User Agents", BCP
                  119, RFC 4579, August 2006,
                  <http://www.rfc-editor.org/info/rfc4579>.

       [RFC5359]  Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
                  K. Summers, "Session Initiation Protocol Service
                  Examples", BCP 144, RFC 5359, October 2008,
                  <http://www.rfc-editor.org/info/rfc5359>.

       [RFC7088]  Worley, D., "Session Initiation Protocol Service Example
                  -- Music on Hold", RFC 7088, February 2014,
                  <http://www.rfc-editor.org/info/rfc7088>.

    Johnston, et al.             Standards Track                   [Page 70]

    RFC 7463                 SIP Shared Appearances               March 2015

    Acknowledgements

       The following individuals were part of the shared appearance design
       team and have provided input and text to the document (in
       alphabetical order):

       Martin Dolly, Andrew Hutton, Raj Jain, Fernando Lombardo, Derek
       MacDonald, Bill Mitchell, Michael Procter, and Theo Zourzouvillys.

       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 and JD Smith of
          Siemens Communications; Dale R. Worley of Pingtel; and Graeme
          Dollar of Yahoo, Inc.

       Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell,
       Dan York, Spenser Dawkins, Martin Dolly, and Brett Tate for their
       comments.

       Thanks to Carolyn Beeton, Francois Audet, Andy Hutton, Tim Ross, Raji
       Chinnappa, and Harsh Mendiratta for their detailed review of the
       document.

    Authors' Addresses

       Alan Johnston (editor)
       Avaya
       St. Louis, MO
       United States

       EMail: alan.b.johnston@gmail.com

       Mohsen Soroushnejad (editor)
       Sylantro Systems Corp.

       EMail: msoroush@gmail.com

    Johnston, et al.             Standards Track                   [Page 71]

    RFC 7463                 SIP Shared Appearances               March 2015

       Venkatesh Venkataramanan
       Sylantro Systems Corp.

       EMail: vvenkatar@gmail.com

    Johnston, et al.             Standards Track                   [Page 72]