Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 7463

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

Pages: 72
Proposed Standard
Errata
Updates:  32614235
Part 2 of 4 – Pages 10 to 26
First   Prev   Next

Top   ToC   RFC7463 - Page 10   prevText

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
Top   ToC   RFC7463 - Page 11
      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
Top   ToC   RFC7463 - Page 12
   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
Top   ToC   RFC7463 - Page 13
   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.
Top   ToC   RFC7463 - Page 14
   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).
Top   ToC   RFC7463 - Page 15
   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
Top   ToC   RFC7463 - Page 16
   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
Top   ToC   RFC7463 - Page 17
   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.
Top   ToC   RFC7463 - Page 18

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.
Top   ToC   RFC7463 - Page 19
   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>
Top   ToC   RFC7463 - Page 20
   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.
Top   ToC   RFC7463 - Page 21
   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:
Top   ToC   RFC7463 - Page 22
   <?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>
Top   ToC   RFC7463 - Page 23

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

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


(page 26 continued on part 3)

Next Section