5. Normative Description
This section normatively describes the shared appearances feature
extensions. The following definitions are used throughout this
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
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.
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
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
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
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)
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
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
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
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
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
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).
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
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
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
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
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
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
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
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.
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
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>
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.
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
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
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
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
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"