Skip to main content

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

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:

  • A SIP Forking Proxy and Registrar/Location Service meets REQ-1.

  • The SIP Dialog Package meets REQ-2.

  • The combination of the SIP Replaces and Join header fields meets REQ-3.

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

Last updated on