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.
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. 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 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 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.
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.
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 terminated. 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 group: 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.
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:sa-dialog-info" xmlns="urn:ietf:params:xml:ns:sa-dialog-info" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="joined-dialog" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="call-id" type="xs:string" use="mandatory"/> <xs:attribute name="local-tag" type="xs:string" use="mandatory"/> <xs:attribute name="remote-tag" type="xs:string" use="mandatory"/> </xs:complexType> </xs:element> <xs:element name="replaced-dialog" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:attribute name="call-id" type="xs:string" use="mandatory"/> <xs:attribute name="local-tag" type="xs:string" use="mandatory"/> <xs:attribute name="remote-tag" type="xs:string" use="mandatory"/> </xs:complexType> </xs:element> <xs:element name="appearance" minOccurs="0" maxOccurs="1"> <xs:simpleType type="xs:integer"> </xs:simpleType> </xs:element> <xs:element name="exclusive" minOccurs="0" maxOccurs="1"> <xs:simpleType type="xs:boolean"> </xs:simpleType> </xs:element> </xs:schema>
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 registered UAs. 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.
ensure that the presentation order is related to the appearance number and not the order of call arrival. 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.