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

      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

   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

   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.

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

   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

   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

   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.

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.

   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>

   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.

   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:

   <?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>

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

      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.

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

       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.