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