Skip to main content

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.

Last updated on