Skip to main content

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.