| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008.
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances (MA) since SIP does not have lines. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. Extensions to the SIP dialog event package are proposed.
1.
Introduction
2.
Conventions used in this document
3.
Usage Scenarios
3.1.
Executive/Assistant Arrangement
3.2.
BLA Call Group
3.3.
Single Line Extension
4.
Requirements
5.
Implementation Options
5.1.
Appearance Implementation Options
5.1.1.
URI parameter Approach
5.1.2.
Dialog Package Parameter
5.1.3.
Appearance Contention Resolution
5.2.
Comparison
6.
Normative Description
6.1.
MA Dialog Package Extensions
6.1.1.
The <appearance> element
6.1.2.
The <exclusive> element
6.1.3.
The <joined-dialog> element
6.2.
Multiple Appearance User Agents
6.3.
Appearance Agent
7.
XML Schema Definition
8.
User Interface Considerations
8.1.
Appearance Number Rendering
8.1.1.
Single Appearance UAs
8.1.2.
Dual Appearance UAs
8.1.3.
Multiple Appearance UAs with Fixed Appearance Number
8.1.4.
Multiple Appearance UAs with Variable Appearance Number
8.2.
Call State Rendering
9.
Interop with non-MA UAs
9.1.
Appearance Assignment
9.2.
Appearance Release
9.3.
UAs Supporting Dialog Events but Not MA
10.
Provisioning Considerations
11.
Example Message Flows
11.1.
Registration and Subscription
11.2.
Appearance Selection for Outgoing Call
11.3.
Taking an Appearance
11.4.
Appearance Selection for Incoming Call
11.5.
Appearance Publication
11.6.
Joining an Appearance
11.7.
Appearance Allocation - Loss of Subscription with UA
11.8.
Appearance Selection Contention Race Condition
12.
IANA Considerations
12.1.
SIP Event Package Parameter: ma
12.2.
URN Sub-Namespace Registration: ma-dialog-info
12.3.
XML Schema Registration
13.
Appendix A - Incoming Appearance Assignment
14.
Acknowledgements
15.
Security Considerations
16.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The feature and functionality requirements for SIP user agents (UAs) supporting business telephony applications differ greatly from basic SIP user agents, both in terms of services and end user experience. In addition to basic SIP support, many of the services in a business environment require the support for SIP extensions such as REFER [3], SUBSCRIBE/NOTIFY primitives [4], the SIP Replaces [5] and Join [9] header fields, etc. Many of the popular business services have been documented in the SIP Service Examples [6].
This specification details a method for implementing a group telephony feature known in telephony as Bridged Line Appearance (BLA) or Multiple Line Appearances (MLA), one of the more popular advanced features expected of SIP IP telephony devices in a business environment. Other names for this feature include Shared Call/Line Appearance (SCA), Shared Call Status and Multiple Call Appearance (MCA). A variant of this feature is known as Single Line Extension.
This document looks at how this feature can be implemented using standard SIP RFC 3261 [2] in conjunction with RFC 3265 [4] for exchanging status among user agents, and the SIP dialog state event package [7] to exchange dialog state information to achieve the same. Different approaches will be discussed including the use of URI parameters, feature tags, and dialog package extensions along with the strengths and weaknesses of the various approaches.
A call flow for Single Line Extension was formerly included in the SIP Service Examples [6]. However, the attempt to implement using standard SIP primitives ultimately failed, leading to its removal from that document. This document defines SIP extensions to implement this service.
In traditional telephony, the line is physical. A common scenario is for a number of business telephones to share a single or a small number of lines. The appearance number relates to the user interface for the telephone - typically each appearance has a visual display (lamp that can change color or blink) and a button (used to select the appearance). In SIP terms, the line is virtual. However, the concept of appearance is still relevant to SIP due to the user interface considerations. It is important to keep the appearance number construct because:
In this document, we will use the term "appearance" as a stand-in for "line appearance" since SIP does not have lines. Note that this does not mean that a conventional telephony user interface (lamps and buttons) must be used - implementations may use another metaphor as long as the appearance number is readily apparent to the user.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1] and indicate requirement levels for compliant mechanisms.
| TOC |
The following examples are common applications of the Multiple Appearances feature and are mentioned here as informative use cases. All these example usages can be supported by the Multiple Appearances feature described in this document. The differences relate to the user interface considerations of the device.
| TOC |
The appearances on the executive's UA may also appear on the assistant's UA. The assistant may answer incoming calls to the executive and then place the call on hold for the executive to pick up. The assistant can always see the state of all calls on the executive's UA.
| TOC |
Users with similar business needs or tasks can be assigned to specific groups and share the line appearances of each other on each others SIP telephony devices. For example, an IT department staff of five might answer a help line which has three appearances on each phone in the IT work area. A call answered on one phone can be put on hold and picked up on another phone. A shout or an IM to another staff member can result in them taking over a call on a particular appearance. Another phone can request to be added to an appearance resulting in a conference call.
| TOC |
In this scenario, incoming calls are offered to a group of UAs. When one answers, the other UAs are informed. If another UA in the group selects the line (i.e. goes off hook), it is immediately bridged or joined in with the call. This mimics the way residential telephone extensions usually operate.
| TOC |
The basic requirements of the multiple appearance 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 Calls can be joined (also called bridged or conferenced together) or can be picked up (taken) by 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 learn about each other and join the appearance group.
REQ-5 The mechanism must scale for large numbers of appearances, n, and large numbers of UAs, N, without introducing excessive messaging traffic.
REQ-6 Each call or session (incoming or outgoing) must 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 appearance status of the the group.
REQ-8 There must be mechanisms to resolve appearance contention among the UAs in the group.
REQ-9 The mechanism must allow all UAs receiving an incoming session request to select 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 which 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 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 to have a private conversation with the external party and other UAs must not be allowed to barge-in. 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 MA service. Therefore, the mechanism must provide a way of communicating the result back to the requester UA.
| TOC |
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 SIP Replaces and Join header fields meets REQ-3.
- The SIP Registration Package meets REQ-4.
- The use of a State Agent for the Dialog Package meets REQ-5.
REQ-6 suggests the need for an entity which manages the appearance resource. Just as conferencing systems commonly have a single point of control, known as a focus, a Multiple 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 User Agent who has taken on this functionality for a group. The Appearance Agent learns the group state either by subscribing to the dialog state of each member UA individually or by dialog state publications from members.
While the appearance resource could be managed co-operatively by a group of UAs without any central control, this is not discussed in this draft, but instead is left as a research project for future standardization. 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.
REQs 6-13 can be implemented using a number of approaches, as discussed in the following sections.
Figure 1 illustrates the SIP components involved in supporting these common requirements of the Multiple Appearance using standard SIP messages including REGISTER, INVITE, SUBSCRIBE, NOTIFY, and PUBLISH.
+----------------------------+ +----+
| | | |
| Appearance Agent | | UA |
| | | |
+----------------------------+ +----+
^ ^ |1)SUBSCRIBE ^ ^ 4)NOTIFY INVITE |
| | |(Event:reg) | | registration sip:alice@example.com|
| | V | | events V
| | +--------------------+ +----------+7)Query+--------+
| | | (example.com) | | |<===== | |
| | | |3) Store| Location | | Proxy |
| | | Registrar |=======>| Service | | |
| | | | | |=====> | |
| | +--------------------+ +----------+8)Resp +--------+
| | ^ ^ | |
| | | | 2) REGISTER (alice) | |
| | | | | |
| | +----+ +----+ | |
| | | | | | | |
| | |UA1 | |UA2 | | |
| | | | | | | |
| | +----+ +----+ | |
| | ^ ^ ^ ^ | |
| | | | | | | |
| +----+ | | | | |
| | | +--------------------------------------+ |
| +----+-------------------------------------------+
| | 8) INVITE
+--------------+ sip:alice@example.com
5-7) SUBSCRIBE and/or PUBLISH
(Event:dialog)
Figure 1.
The next section discusses normal SIP operations used to implement parts of the multiple appearance feature.
The User Agents in the group could SUBSCRIBE to each other and NOTIFY dialog state events, but in a large group the User Agents have to manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS. The State Agent in the Appearance Agent helps in managing large groups better. Further, the State Agent can filter dialog state events and NOTIFY User Agents of the dialog state events which are required for the application or feature. The State Agent can also SUBSCRIBE to dialog state events with filters to reduce the number of NOTIFY messages exchanged between the State Agent and the user agents in the group. This allows a group of N UAs to each only establish a pair of dialog state subscriptions (one in each direction) to learn the dialog state of all other group members. This results in 2N total subscriptions for the entire group. A full mesh of subscriptions without a state agent would result in N(N-1) total subscriptions.
The Appearance Agent can select the appearance number for an incoming call. An Appearance agent can use the registration event package to learn how many UAs are part of the group. The Appearance Agent sends a NOTIFY of dialog state events to all the User Agents.
| TOC |
This section discusses and compares two methods of implementing, conveying, and selecting appearances in SIP while meeting the requirements of Section 4. One approach involves a URI parameter and is discussed in section 5.1.1. The other approach uses a SIP dialog package extension parameter and is discussed in section 5.1.2. Both approaches assume the common elements and operations of Figure 1. In addition, this section discusses approaches for incoming appearance indication, REQ-9, and appearance contention, REQ-8. These approaches will be discussed for an example appearance group of N phones each with n line appearances. The usage of the word phone does not imply that this feature is limited to telephony devices.
| TOC |
Some implementations of this feature utilize a URI parameter such as "line=3" on the Contact URI. Each appearance is effectively a logical UA, so each line appearance requires a separate registration. The number of line appearances needs to be provisioned on each phone. Each appearance also requires a separate dialog package subscription. Even using a State Agent for the dialog package, each phone must maintain n subscriptions to the dialog package.
This results in 2nN total subscriptions and nN registrations for this implementation.
Since Contact URI parameters will be conveyed by the dialog package, REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to each UA and line number to obtain the current dialog state - this will result in nN SUBSCRIBEs and NOTIFYs.
It is not obvious how to meet REQ-11 with this approach. A UA registering against the AOR but does not implement the appearance URI parameter will not include a line appearance number in Contact URIs and dialog package NOTIFYs. The Appearance Agent will have no way of indicating to the other UAs the appearance number being used by this UA, as adding a parameter to the Contact URI would cause call control operations such as Replaces and Join to fail.
REQs 12 and 13 are difficult to meet with this approach as the line appearance number will be present in the Request-URI of incoming requests and the Contact URI in INVITE and 200 OK messages. This approach will require integrity protection of all dialog creating requests and responses, and privacy mechanisms to hide the Contact URI from other UAs.
Also, this approach will require mechanisms to protect against another UA sending an INVITE directly to a group member with the line appearance number already set.
| TOC |
Instead of the URI parameter approach, consider an extension parameter "appearance" to the SIP dialog package. The e.g.:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="6"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83" from-tag="3423" to-tag="a3f423j88uju1"
direction="initiator">
<ma:appearance>2</appearance>
<ma:exclusive>false</exclusive>
<ma:joined-dialog call-id="sdfg" from-tag="832d1" to-tag="4542454" />
<ma:joined-dialog call-id="873287876" from-tag="433" to-tag="jwjwuf5" />
<state>connected</state>
<local>
<target uri="sip:bob@pc.example.com" />
</local>
</dialog>
</dialog-info>
...
In this approach, the appearance number is never carried in a Request-URI or Contact URI. Instead, it is only present in dialog package NOTIFY and PUBLISH messages. As a result, only a single registration per AOR is required. Also, only a single dialog package subscription in each direction per AOR.
This results in 2N total subscriptions and N registrations for this approach.
If the dialog package is extended to carry the appearance number, then REQ-7 is met.
REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to each UA and line number to obtain the current dialog state - this will result in N SUBSCRIBEs and NOTIFYs.
REQ-11 can be met by this approach. Even though a UA does not provide an appearance number in dialog package NOTIFYs, the Appearance Agent can assign one and include it in NOTIFYs to the other UAs. This parameter would simply be ignored by the UAs that did not understand the parameter, and have no impact on call control operations.
REQs 12 and 13 are met because the appearance number is only conveyed in dialog package NOTIFYs. Integrity and privacy of NOTIFY bodies can be achieved using normal SIP mechanisms independent of the security mechanisms used for other requests.
The dialog-package [7] describes a mechanism whereby shared-line privacy REQ-14 can be accomplished by suppressing certain dialog information from being presented to the UAs. The reasoning behind that is if the UAs were unaware of a dialog's call-id, local-tag and remote-tag then they will be unable to create requests such as INVITE with Join [9] or Replaces [5] headers to barge-in or pickup the line appearance. Below is a quote from section 3.6 of dialog-package[7] that describes this approach:
Note that many implementations of "shared-lines" have a feature that allows details of calls on a shared address-of-record to be made private. This is a completely reasonable authorization policy that could result in notifications that contain only the id attribute of the dialog element and the state element when shared-line privacy is requested, and notifications with more complete information when shared-line privacy is not requested.
There are certain fundamental drawbacks in the privacy-by-obscurity approach described in [7]. It models exclusivity as a static property of the appearance AOR. There are situations where exclusivity needs to be a dynamic property (e.g. boss does not want secretary to listen-in on a particular part of the conversation). In addition, [7] does not address how a UA can request exclusivity at the start of a session or mid-session and how that request will be granted or rejected.
Exclusivity being a dynamic property means that a UA can request it to be turned on or off in the middle of a session. When exclusivity is turned off all the UAs that share the line AOR will need to see the complete dialog information. Once they have that information it can not be taken back from them. This will not allow exclusivity to be turned on later on in the dialog lifetime. Therefore, there needs to be a centralized entity that will actually enforce exclusivity.
The approach proposed for meeting REQ-14 is to include an exclusivity parameter to the dialog package. This allows a UA to request exclusivity, by setting the exclusive parameter in notifications. This could be done prior to a call being made or answered, or during a call at any time. A UA can remove exclusivity by sending a notification at any time during a call and setting "exclusive=no". It also allows a UA to learn that a particular dialog is exclusive by the presence of this parameter in a NOTIFY. In addition, a UA can still apply policy to any INVITE Join or Replaces requests it receives, as per normal SIP call control mechanisms.
With this approach, the number of appearances is centrally managed and controlled by the Appearance Agent. For UAs with soft keys or buttons, this gives a great deal of flexibility in system management.
| TOC |
In the selection of an appearance for requests initiated by UAs in the group, there is the possibility of contention where more than one UA select the same appearance number.
One way to solve this and meet REQ-8 is to require UAs to send a notification (trying) to the Appearance Agent indicating the appearance number to be used for the session. The Appearance Agent would confirm the allocation of the appearance number in a NOTIFY sent to the group UAs. Should the appearance number be unavailable or otherwise not allowed, there are two options:
- The notification could be rejected with a 500 response and a Retry-After header field. The Appearance Agent would send an immediate NOTIFY indicating that the appearance is unavailable. If the NOTIFY is received before the expiration of the Retry-After time, the notification state information would become out of date and would be discarded without resending. The UA would select another appearance number and send another notification.
- The notification could be accepted but an immediate NOTIFY generated by the Appearance Agent indicating that the appearance is unavailable. The UA would then select another appearance number and PUBLISH again.
UAs would wait for a notification from the Appearance Agent before sending the INVITE.
| TOC |
In comparing the URI parameter and the dialog package parameter, there are clear differences in the number of registrations and subscriptions, with the dialog package approach requiring n times fewer in both cases.
The security model for the dialog package parameter approach is much cleaner, since only NOTIFYs need integrity and privacy. The security model for the URI parameter approach would likely require a B2BUA which introduces many undesirable properties.
The dialog package parameter approach has better backwards compatibility than the URI parameter approach.
In summary, the dialog package parameter approach better meets REQs 5, 10, 11, 12, and 13 while the URI parameter approach better meets REQ-9. However, the combined dialog package parameter approach and the Alert-Info parameter approach meets REQ-9.
The rest of this document discusses the dialog package parameter approach.
| TOC |
This section normatively describes the MA feature extensions.
| TOC |
This specification defines three new elements as extensions to the SIP Dialog Event package [7]. The schema is defined in Section 7. The elements are <appearance>, <exclusive>;, and <joined-dialog>. All three elements are sub-elements of the <dialog> element.
| TOC |
The <appearance> element is used convey the appearance number. The appearance number is a non-negative integer. When sent in a notification in state Trying to the Appearance Agent, it is used to request an appearance number. When sent by the Appearance Agent, it indicates that the appearance number is associated with a dialog.
When used to select an appearance number, the attributes "selection", "start", and "stop" may be present. The "selection" attribute is used to indicate UA preference in the appearance number selection as follows. If an appearance number is included in the element, and that appearance number is available, the Appearance Agent will assign that appearance number to the dialog and return a NOTIFY containing the appearance number in an <appearance> element. If the appearance number is not available, or no appearance number is present, then:
- If selection=only is set, the Appearance Agent will return a NOTIFY without an <appearance> element.
- If selection=any is set, the Appearance Agent may select any available appearance and include this appearance in the NOTIFY.
- If selection=range is set, the attributes "start" and "stop" MUST be present. The Appearance Agent may return any available appearance number that is in the range set by the "start" and "stop" attributes. If none are available, no appearance number is assigned.
- If selection=set is set, the Appearance Agent may return any available appearance number which is listed in the comma separated set. If none are available, no appearance number is assigned.
| TOC |
The <exclusive> element is a boolean used indicate whether the UA will accept Join or Replaces INVITEs for this dialog. For example, some MA systems only allow call takes when the call is on hold. In this case, the <exclusive> element should be used to explicitly indicate this, rather than implicitly by the hold state.
It is important to note that this element is a hint. Although a UA may set exclusive to true, the UA must still be ready to reject an INVITE Join relating to this dialog. Also, an INVITE Replaces might be sent to the non-MA UA to take the call. For this reason, a UA MAY also not report full dialog identifier information to the Appearance Agent for calls set to exclusive. 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 Replace requests containing those dialog identifiers with a 403 Forbidden response.
| TOC |
The <joined-dialog> element is used convey dialog identifiers of any other dialogs which are joined (mixed or bridged) with the dialog. Only the UA which is performing the actual media mixing should include this element in notifications 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. The UA would report this using this header field.
| TOC |
User Agents that support the Multiple Appearance feature MUST support the dialog state package as outlined in [7] to NOTIFY the Appearance Agent of the dialog-state.
User Agents MUST support Replaces [5] and MAY support Join [9]. Note that for the Call Take operation, the remote UA must support Replaces. If the UA does not support Join, it SHOULD support conference creation in [11].
Editor's Note: Should this be a MUST? If not, bridging could fail.
They MUST support the MA extensions to the dialog package defined in this specification. They SHOULD understand and support the (ma) event parameter outlined in this draft.
When generating dialog package notifications, UAs MUST include full dialog identification information including local and remote target URIs (Contacts) call-id, to-tag and from-tag. The exception is when a UA does not want other UAs in the group to be able to Join or Take the call. In this case, the dialog identification information MAY be omitted in addition to setting the exclusive flag. When calls are placed on hold, the "+sip.rendering=no" [12] feature tag MUST be included in dialog package notifications.
The UA MUST send dialog-info in state "trying" with the appropriate appearance parameter present in the local target when it is attempting to select ('seize') an appearance number. If the user interface of the UA requires that it know the appearance number before the call is placed, the UA can not send the INVITE until a NOTIFY from the Appearance Agent is received confirming the appearance number selection.
Note: Sending NOTIFY dialog state of (trying) before an INVITE is a departure from [7], but this must be implemented by UAs that need to select a specific appearance number for a call.
There are two exceptions to the requirement for seizing an appearance before sending an INVITE. One is an emergency call, which should proceed regardless of the status of NOTIFY/PUBLISH transaction. The other is when the INVITE is an attempt to bridge or take a call (i.e. contains Join or Replaces with a dialog identifier of another member of the MA group). In this case, the INVITE Join or Replaces should be sent without selecting an appearance. After the INVITE succeeds, the NOTIFY/PUBLISH MUST be sent, reusing the appearance number of the dialog that has been bridged or taken.
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.
There are a number of ways in which a UA can request an appearance number from the Appearance Agent. They are:
1. <appearance selection="any" /> This allows the Appearance Agent to select any appearance number on behalf of the requesting UA. 2. <appearance selection="any">2</appearance> This allows the Appearance Agent to select appearance 2 if available, if not, assign any appearance number. 3. <appearance selection="only">3</appearance> This allows the Appearance Agent to select appearance 3 if available, but make no selection if it is not available. 4. <appearance selection="range" start="0" stop="5" /> This allows the Appearance Agent to select an appearance number within the range 0-5.
The dialog state package defined in [7] defines the set of messages that MAY be provided by a UA to publish state information of dialogs. For satisfactory operation of this feature, the flows require that the UA SUBSCRIBE to the dialog-event package on receipt of a SUBSRIBE request containing the "ma" event parameter. It MUST use the contact in this SUBSCRIBE for making 'line reservations' when placing calls from the AOR. Also, as seen in the above example message flows, not all of these messages need to be published by a UA to effectively participate in a BLA group. In order to indicate this preference, this draft proposes a new Event parameter for the dialog package called (ma). User Agents that understand this parameter will always provide dialog state information as detailed in this draft.
A UA should only register against the AOR if it is likely the UA will be answering incoming calls. If the UA is mainly going to be monitoring the status of the MA group calls and taking or joining calls, the UA SHOULD only subscribe to the Appearance Agent and not register against the AOR.
| TOC |
An Appearance Agent defined in this specification MUST implement a dialog package state agent for the UAs registered against the AOR.
The dialog package XML element dialog id (NOT the SIP dialog identifier consisting of the Call-ID, To tag, and From tag) is used for partial update processing. RFC 4235 only requires the dialog id be unique for the UA, not unique across all UAs associated with the same AOR. As a result, is possible that two UAs in a MA group might choose the same XML element dialog id for different dialogs. If this is the case, the Appearance Agent, acting as the dialog package event state compositor may need to produce different notification documents for the UAs that have conflicting dialog package XML element dialog ids.
The Appearance Agent MUST support the appearance dialog package extensions defined in this specification.
Even in trivial deployments of two multiple appearance enabled user agents, race conditions can exist when both user agents attempt to utilize an appearance simultaneously (i.e. when the NOTIFY messages, that each user agent sends to the other, are active within the network during an overlapping time period). The Appearance Agent can use any policy deemed necessary to resolve races and ensure no two user agents are not allocated the same appearance number at the same time.
Appearance Agents are responsible for resolving conflicts in the appearance resource. If a UA requests the use of an appearance number that is in use by another UA, the Appearance Agent will respond based on the presence of the selection attribute in the <appearance> element as described in the previous section.
In the case where a UA is bridging two calls, the Appearance Agent may receive dialog package NOTIFYs/PUBLISHes that contain multiple dialogs with the same appearance number. This is valid and does not represent appearance number contention.
A critical aspect for reliable operation of this feature is the ability for all user agents in the BLA group to recover from network failures caused at a single UA. For example, one of the user agents in the BLA group may have answered an incoming call, notified the dialog state to other members and then experienced a network outage. The calling UA could have detected the same (using RTP or some other means) and could have hung up. However, none of the other user agents in the BLA group would get notification of this change in dialog state and their BLA appearances could stay out of sync for a long time; depending on when the network is restored, or when the Appearance Agent attempts to refresh its dialog-state subscription with the failed UA. To recover from such a failure, the Appearance Agent MUST SUBSCRIBE with a shorter expiration (expiration interval not smaller than 300 seconds is RECOMMENDED) following the notification of a "confirmed" dialog or when a Appearance Agent honors a "trying" for call origination, with the user agents that notified it of this information.
Alternatively, while a user agent is acquiring, or holds a line seize, the dialog subscriptions to it act as MA status indicators to the subscriber. If subscription refresh requests to the user agent are not honored, then it must be determined that the user agent's capacity to maintain line seize has been lost. For this reason, during the period a user agent is acquiring or holds a line seize, the remaining expiry period of subscriptions to it MAY be reduced by the Appearance Agent to minimize the outage problem (expiration interval not smaller than 300 seconds is RECOMMENDED). This can be accomplished by setting the Expires parameter in the Subscription-State header in the NOTIFY message sent out by the UA.
| TOC |
The 'appearance' and 'exclusive' elements are defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:ma-dialog-info". The schema for these elements is:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:ma-dialog-info-info"
xmlns="urn:ietf:params:xml:ns:ma-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="appearance" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:integer">
<xs:attribute name="selection" type="xs:string" use="optional">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="any"/>
<xs:enumeration value="range"/>
<xs:enumeration value="set"/>
<xs:enumeration value="only"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="start" type="xs:integer"
use="optional"/>
<xs:attribute name="stop" type="xs:integer"
use="optional"/>
<xs:attribute name="set" type="xs:string"
use="optional"/>
</xs:simpleType>
</xs:element>
<xs:element name="exclusive" minOccurs="0" maxOccurs="1">
<xs:simpleType type="xs:boolean">
</xs:simpleType>
</xs:element>
</xs:schema>
| TOC |
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.
| TOC |
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.
| TOC |
These devices are constrained by only having the capability of displaying status indications for a single appearance. Despite this, it is important that devices of this type do not ignore the appearance number. The UA should still send messages annotated with an appropriate appearance number (i.e. "0"). Any call indications for appearances other than for number "0" should be rejected with a 486 or 480 response.
| TOC |
These devices are essentially single line 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.
| TOC |
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 ignored, and not mapped to a free button. Users of these devices often select specific appearance numbers for outgoing calls, and the UA will need to select the appearance number and wait for confirmation from the Appearance Agent before proceeding with calls.
| TOC |
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. Thought should also be given to how an appearance number that has no call associated with it should be rendered to the user. These devices can typically make calls without waiting for confirmation from the Appearance Agent on the appearance number.
The problems faced by each style of user interface are readily seen in this example:
| TOC |
UAs that implement the MA 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, is indicated by an appearance number being 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 MA group is hold. This can be determined by the presence of the "sip+rendering=no" feature tag 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.
| TOC |
It is desirable to allow a basic UA that does not directly support MA to be part of a MA group. To support this the Proxy must collaborate with the Appearance Agent. This is not required in the basic MA architecture, consequently MA interop with non-MA UAs will not be available in all MA deployments.
First, a UA which does not support dialog events or the MA feature will be discussed. Then, a UA which does support dialog events but not the MA feature will be discussed.
| TOC |
A UA that has no knowledge of appearances must have appearance numbers assigned by the Appearance Agent for both incoming and outgoing calls. The Appearance Agent will know about this type of UA as the UA will be registered against the AOR but not subscribed to the dialog events for the AOR. If the non-MA UA does not support Join or Replaces, all dialogs could be marked "exclusive" to indicate that these options are not available.
| TOC |
In all cases the Appearance Agent must be aware of dialog lifetime to release appearances back into the group.
It is also desirable that any dialog state changes (such as hold, etc) be made available to other UAs in the group through the Dialog Event Package. If the Appearance Agent includes a proxy which Record-Routes for dialogs from the non-MA aware UA, the Appearance Agent will know about the state of dialogs including hold, etc. This information could be determined from inspection of INVITE and re-INVITE messages and added to the dialog information conveyed to other UAs.
| TOC |
Interoperability with UAs which support dialog events but not the MA feature is more straightforward. As before, all appearance number assignment must be done by the Appearance Agent. This type of UA will be detected by the Appearance Agent by the absence of the ma event parameter in SUBSCRIBE or PUBLISH messages. The Appearance Agent can include appearance information in NOTIFYs - this UA will simply ignore this extra information. This type of UA will ignore appearance number limitations and may attempt to Join or Replace dialogs marked exclusive. As a result, the Proxy or UAs may need to reject such requests.
The need for close cooperation between the Proxy and the Appearance Agent is not needed as the Appearance Agent will learn about all dialogs from the UA itself.
| TOC |
TBD.
| TOC |
The next section shows call flow and message examples. The flows and descriptions are non-normative.
| TOC |
Bob and Alice are in an appearance group identified by Alice's AOR. Bob REGISTERs using contact sip:bob@ua2.example.com. Furthermore, Bob REGISTERs his primary address with contact sip: bob@ua2.example.com. Alice REGISTERs with contact sip:alice@ua1.example.com.
The Appearance Agent subscribes to dialog states of the MA AOR (i.e., sip:alice@example.com) at the User Agents for Alice and Bob. Message exchange between the Registrar, Appearance Agent, Alice, and Bob are shown below. The call flow examples below do not show challenging of subscriptions or notifications. It should be noted that for security purposes, all subscriptions must be authorized before the same is accepted.
Registrar Appearance Agent Alice
| | |
| | |
|<--------------------------- REGISTER F1<|
| | |
|>F2 200 OK ----------------------------->|
| | |
| |>F3 SUBSCRIBE ----->|
| | |
| |<-------- 200 OK F4<|
| | |
| |<-------- NOTIFY F5<|
| | |
| |>F6 200 OK -------->|
| | |
| |<----- SUBSCRIBE F7<|
| | |
| |>F8 202 Accepted -->|
| | |
| |>F9 NOTIFY -------->|
| | |
| |<------- OK 200 F10<|
| | |
Figure 2.
F1-F2: Alice registers AOR with contact: <sip:alice@ua1.example.com>
F1 Alice ----> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:alice@example.com>
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
Contact: <sip:alice@ua1.example.com>
User-Agent: ABC-UA/1.2.3
Max-Forwards: 70
Expires: 3600
Content-Length: 0
F2 Registrar ----> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2
CSeq: 2 REGISTER
Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
To: <sip:alice@example.com>;tag=1664573879820199
Contact: <sip:alice@ua1.example.com>
Expires: 3600
Content-Length: 0
F3 to F6: Once Alice registers, Appearance Agent subscribes
to the events at the contact registered for Alice and Alice
notifies the Appearance Agent of its status.
F3 Appearance Agent ----> Alice
SUBSCRIBE sip:alice@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=110286377866002
To: <sip:alice@example.com>
Call-ID: 284-425690188@example.com
CSeq: 2 SUBSCRIBE
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532
Event: dialog;ma
Expires: 3700
Contact: <sip:sa@stateagent.example.com>
Content-Length: 0
F4 Alice ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532
From: <sip:alice@example.com>;tag=110286377866002
To: <sip:alice@example.com>;tag=717A8C26-BA734CE3
CSeq: 2 SUBSCRIBE
Call-ID: 284-425690188@example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Expires: 3700
Content-Length: 0
F5 Alice ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870
From: <sip:alice@example.com>;tag=717A8C26-BA734CE3
To: <sip:alice@example.com>;tag=110286377866002
CSeq: 1 NOTIFY
Call-ID: 284-425690188@example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Subscription-State: active;expires=3698
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0"
state="full"
entity="sip:alice@example.com">
</dialog-info>
F6 Appearance Agent ----> Alice
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870
CSeq: 1 NOTIFY
Call-ID: 284-425690188@example.com
From: <sip:alice@example.com>;tag=717A8C26-BA734CE3
To: <sip:alice@example.com>;tag=110286377866002
Allow-Events: dialog;ma
Contact: <sip:sa@stateagent.example.com>
Content-Length: 0
F7 to F10: Alice also subscribes to the events associated with the
Appearance AOR. Appearance Agent also notifies Alice of the status.
F7 Alice ----> Appearance Agent
SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:sa@stateagent.example.com>
CSeq: 1 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Accept: application/dialog-info+xml
Max-Forwards: 70
Expires: 3700
Content-Length: 0
F8 Appearance Agent ----> Alice
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
CSeq: 1 SUBSCRIBE
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
To: <sip:sa@stateagent.example.com>;tag=1636248422222257
Allow-Events: dialog;ma
Expires: 3700
Contact: <sip:sa@stateagent.example.com>
Content-Length: 0
F9 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:sa@stateagent.example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
CSeq: 2 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;ma
Subscription-State: active
Contact: <sip:sa@stateagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="40"
state="full"
entity="sip:alice@example.com">
</dialog-info>
F10 Alice ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734
From: <sip:sa@stateagent.example.com>;tag=1636248422222257
To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
CSeq: 2 NOTIFY
Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Content-Length: 0
| TOC |
In this scenario, Bob's UA sends out a dialog event NOTIFY with state (trying) selecting an appearance number. After receiving the NOTIFY from the Appearance Agent confirming the appearance number, Bob's UA sends the INVITE to Carol and establishes a session. For brevity, details of some of the messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | |<------ NOTIFY F1<|
| | | | |
| | | |>F2 200 OK ------>|
| | | | |
| | |<-- NOTIFY F3<| |
| | | | |
| | |>F4 200 OK -->| |
| | | |------- NOTIFY F5>|
| | | | |
| | | |<F6 200 OK ------<|
| | | | |
| | | |---- SUBSCRIBE F7>|
| | | | |
| | | |<F8 200 OK ------<|
| | | | |
| | | |<------ NOTIFY F9<|
| | | | |
| | | |>F10 200 OK ----->|
| | | | |
| |<------------------------------------ INVITE F11<|
| | | | |
|<- INVITE F12<| | | |
| | | | |
|>F13 180 --->| | | |
| |>F14 180 Ringing ------------------------------->|
|>F15 200 OK ->| | | |
| |>F16 200 OK ------------------------------------>|
| | | | |
|<------------------------------------------------------ ACK F17<|
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | | |<----- NOTIFY F18<|
| | | | |
| | | |>F19 200 OK ----->|
| | |<- NOTIFY F20<| |
| | | | |
| | |>F21 200 OK ->| |
| | | |------ NOTIFY F22>|
| | | | |
| | | |<F23 200 OK -----<|
| | | | |
Figure 3.
F1 to F4: Bob uses the BLA appearance of Alice on his UA to place an outgoing call (e.g., he goes off-hook). Before sending the outgoing INVITE request, Bob notifies the sate agent that Alice line appearance is in (trying) state. Appearance Agent notifies Alice of the same event by forwarding the NOTIFY payload provided by Bob after appropriately changing the dialog id field in the XML payload to a unique value towards each of the entities it is forwarding to (Alice in this example).
</t>
<figure><artwork><![CDATA[
F1 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801
CSeq: 7 NOTIFY
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;ma
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3347
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="6"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83" direction="initiator">
<ma:appearance selection="any">0</appearance>
<ma:exclusive>false</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@example.com">
</target>
</local>
</dialog>
</dialog-info>
F2 Appearance Agent ----> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
CSeq: 7 NOTIFY
Call-ID: 144-1289338424@example.com
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801
Allow-Events: dialog;ma
Contact: <sip:sa@stateagent.example.com>
Content-Length: 0
F3 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=497585728578386
To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
CSeq: 7 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;ma
Subscription-State: active
Contact: <sip:sa@stateagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="27"
state="partial"
entity="sip:alice@example.com">
<dialog id="fa02538339df3ce597f9e3e3699e28fc" direction="initiator">
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<state>trying</state>
<local>
<target uri="sip:bob@example.com">
</target>
</local>
</dialog>
</dialog-info>
F4 Alice ----> Appearance Agent
SIP/2.0 200 OK
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309
From: <sip:alice@example.com>;tag=497585728578386
To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4
CSeq: 7 NOTIFY
Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Content-Length: 0
F5 and F6: The Appearance Agent sends a NOTIFY to Bob confirming appearance number.
F7 to F10: The Appearance Agent re-subscribes to Bob reducing the expiration interval while Bob holds the appearance.
F11 to F17: Bob places a call to Carol by sending the INVITE request
towards the Proxy. The INVITE (see F5 message below) includes a
P-Preferred-Identity header [10] to designate the identity to be
used as the calling party for this call (i.e., Alice instead of Bob).
F11 Bob ----> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
From: <sip:bob@example.com>;tag=15A3DE7C-9283203B
To: <sip:carol@example.com>
CSeq: 1 INVITE
Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
Contact: <sip:bob@ua2.example.com>
User-Agent: XYZ-UA/4.5.6
P-Preferred-Identity: <sip:alice@example.com>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua2.example.com
s=IP SIP UA
c=IN IP4 ua2.example.com
t=0 0
a=sendrecv
m=audio 2236 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F18 to F21: Bob notifies the Appearance Agent of the status of the
dialog (i.e., confirmed). Appearance Agent notifies Alice of the
same.
F18 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801
CSeq: 9 NOTIFY
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;ma
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3342
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="8"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>confirmed</state>
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<local>
<target uri="sip:bob@example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com;user=phone" />
</remote>
</dialog>
</dialog-info>
| TOC |
In this scenario, Bob has an established dialog with Carol. Bob then places Carol on hold. Alice subsequently picks up the held call and has a established session with Carol. Finally, Carol hangs up. The details of the notifications amongst the user agents and the Appearance Agent in updating the status of the BLA group members are shown below. For brevity, details of some of the messages are not included in the message flows.
Carol Proxy Alice Appearance Agent Bob
| | | | |
| | | | |
|<================= Both way RTP established ===================>|
| | | | |
| | | | |
| |<------------------------------(hold) INVITE F16<|
|<- INVITE F17<| | | |
| | | | |
|>F18 200 OK ->| | | |
| |>F19 200 OK ------------------------------------>|
| | | | |
|<------------------------------------------------------ ACK F20<|
| | | | |
| | | |<----- NOTIFY F21<|
| | | | |
| | | |>F22 200 OK ----->|
| | |<- NOTIFY F23<| |
| | | | |
| | |>F24 200 OK ->| |
| |<-- INVITE F25<| | |
|<- INVITE F26<|(w/ Replaces) | | |
|( w/ Replaces)| | | |
|>F27 200 OK ->| | | |
| |>F28 200 OK -->| | |
| | | | |
|<-------------------- ACK F29<| | |
| | | | |
|<= Both way RTP established =>| | |
| | | | |
|>F30 BYE ---->| | | |
| |>F31 BYE --------------------------------------->|
| | | | |
| |<------------------------------------ OK 200 F32<|
|<- 200 OK F33<| | | |
| | | | |
| | | |<----- NOTIFY F34<|
| | | | |
| | | |>F35 200 OK ----->|
| | |<- NOTIFY F36<| |
| | | | |
| | |>F37 200 OK ->| |
| | | | |
| | |>F38 NOTIFY ->| |
| | | | |
| | |<- 200 OK F39<| |
| | | |>F40 NOTIFY ----->|
| | | | |
| | | |<----- 200 OK F41<|
|>F42 BYE ---->| | | |
| |>F43 BYE ----->| | |
| | | | |
| |<-- 200 OK F44<| | |
|<--200 OK F45<| | | |
| | |>F46 NOTIFY ->| |
| | | | |
| | |<- 200 OK F47<| |
| | | |>F48 NOTIFY ----->|
| | | | |
| | | |<----- OK 200 F49<|
Figure 4.
F16 to F20: Bob places Carol on hold.
F22 to F24: Bob notifies Appearance Agent of the status of the dialog to
indicate the held state. It indicates this by setting the sip.rendering
parameter in the NOTIFY payload to (no). Appearance Agent notifies
Alice of the same.
F22 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: <sip:alice@example.com>;tag=428765950880801
CSeq: 10 NOTIFY
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;ma
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3338
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="9"
state="partial"
entity="sip:alice@example.com">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>confirmed</state>
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<local>
<target uri="sip:bob@example.com">
<param pname="+sip.rendering" pval="no"/>
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog>
</dialog-info>
F26 to F34 : Alice picks up the held call by sending an INVITE with
Replaces: header (F26). Session is established between Alice and
Carol. The dialog between Carol and Bob is terminated.
F26 Alice ----> Proxy
INVITE sip:carol@example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710
To: <sip:carol@example.com:5075>
CSeq: 1 INVITE
Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
Contact: <sip:alice@ua1.example.com>
User-Agent: ABC-UA/1.2.3
P-Preferred-Identity: <sip:alice@example.com>
<all-one-line>
Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-tag=65a98f7c
-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-9283203B
</all-one-line>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980497 1102980497 IN IP4 ua1.example.com
s=IP SIP UA
c=IN IP4 ua1.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F34 to F41: Bob notifies the Appearance Agent of the termination of
dialog at his UA. Alice notifies the Appearance Agent of the
confirmed state of the dialog at her UA.
F34 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
To: "State_Agent" <sip:alice@example.com>;tag=428765950880801
CSeq: 11 NOTIFY
Call-ID: 144-1289338424@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;ma
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3334
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="10"
state="partial"
entity="sip:alice@example.com:5060">
<dialog id="id3d4f9c83"
call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
local-tag="15A3DE7C-9283203B"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<state>terminated</state>
<local>
<target uri="sip:bob@example.comsip:bob@example.com">
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog>
</dialog-info>
F38 Alice ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572
From: <sip:alice@example.com>;tag=5861255C-14C04045
To: "State_Agent" <sip:alice@example.com>;tag=920163082722420
CSeq: 10 NOTIFY
Call-ID: 143-1840952798@example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Subscription-State: active;expires=3315
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="9"
state="partial"
entity="sip:alice@example.com:5060">
<dialog id="id402f024e"
call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com"
local-tag="8C4183CB-BCEAB710"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>confirmed</state>
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<local>
<target uri="sip:alice@example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog>
</dialog-info>
F42 to F59: Carol terminates the dialog with Alice. Alice notifies the
Appearance Agent of the dialog state (terminated). The Appearance Agent
notifies Bob of the same.
F46 Alice ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C
From: <sip:alice@example.com>;tag=5861255C-14C04045
To: "State_Agent" <sip:alice@example.com>;tag=920163082722420
CSeq: 11 NOTIFY
Call-ID: 143-1840952798@example.com
Contact: <sip:alice@ua1.example.com>
Event: dialog;ma
User-Agent: ABC-UA/1.2.3
Subscription-State: active;expires=3311
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="10"
state="partial"
entity="sip:alice@example.com">
<dialog id="id402f024e"
call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com"
local-tag="8C4183CB-BCEAB710"
remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
direction="initiator">
<state>terminated</state>
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<local>
<target uri="sip:alice@example.com">
</target>
</local>
<remote>
<identity>sip:carol@example.com</identity>
<target uri="sip:carol@example.com" />
</remote>
</dialog>
</dialog-info>
| TOC |
In the call flow below Bob and Alice are in an appearance group identified by Alice's AOR. Carol places a call to Alice. Both Alice and Bob's devices are alerted of the incoming call. Bob answers the call. He then places Carol on hold. Alice picks up the held call and has a established session with Carol. Finally, Carol terminates the session. All NOTIFY messages in the call flow below carry dialog events and only dialog states are mentioned for simplicity. For brevity, the details of some messages are not shown below.
Forking Appearance
Carol Proxy Agent Alice Bob
| | | | |
|>F1 INVITE >| | | |
| |< - - - - - >| | |
| | |>F2 NOTIFY ----------->|
| | | | |
| | |<F3 200 OK -----------<|
| | | | |
| | |>F4 NOTIFY ->| |
| | | | |
| | |<-200 OK F5-<| |
| | | | |
| |>F6 INVITE ------------------------->|
| | | | |
| |>F7 INVITE --------------->| |
| | | | |
|<- 100 F8 -<| | | |
| | | | |
| |<-------------------- Ringing 180 F9<|
|< 180 F10 -<| | | |
| |<--------- 180 Ringing F11<| |
|< 180 F12 -<| | | |
| |<------------------------ 200 OK F13<|
|< 200 F14 -<| | | |
| | | | |
| |>F14 CANCEL -------------->| |
| | | | |
| |<-------------- 200 OK F15<| |
| | | | |
| |<Request Cancelled 487 F16<| |
| | | | |
| |>F17 ACK ----------------->| |
|>F18 ACK -->| | | |
| |>F19 ACK --------------------------->|
| | | | |
|<=============Both way RTP established===========>|
| | | | |
| | |<---------- NOTIFY F20<|
| | | | |
| | |>F21 200 OK ---------->|
| | | | |
| | |>F22 NOTIFY >| |
| | | | |
| | |<- 200 F22 -<| |
| | | | |
| | |-------- SUBSCRIBE F23>|
| | | |
| | |<F24 200 OK ----------<|
| | | |
| | |<---------- NOTIFY F25<|
| | | |
| | |>F26 200 OK ---------->|
| | | |
Figure 5.
F1 to F16: An incoming call from Carol to Alice is forked to
Bob and Alice. Both Alice and Bob indicate an incoming call
(e.g., ringing) from Carol. Bob answers the call and two-way
media is established between Carol and Bob.
F2 Proxy ----> Bob
INVITE sip:alice@ua3.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK38432ji
From: <sip:carol@example.com>;tag=94183CB-BCEAB7
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 47deb849-dca8b6c6-3d342
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F3 Proxy ----> Alice
INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/UDP ua3.example.com;branch=z9hG4bK4324ea695b5B376A
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK348281
From: <sip:carol@example.com>;tag=94183CB-BCEAB7
To: <sip:alice@example.com>
CSeq: 106 INVITE
Call-ID: 47deb849-dca8b6c6-3d342
Contact: <sip:carol@ua3.example.com>
Max-Forwards: 69
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
Content-Type: application/sdp
Content-Length: 223
v=0
o=- 1102980499 1102980499 IN IP4 ua3.example.com
s=
c=IN IP4 ua3.example.com
t=0 0
a=sendrecv
m=audio 2238 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
F17 - F20: Bob notifies the Appearance Agent with dialog state
payload indicating the dialog in confirmed state. Appearance
Agent notifies Alice of the status of the dialog at Bob.
F17 Bob ----> Appearance Agent
NOTIFY sip:sa@stateagent.example.com SIP/2.0
Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
From: <sip:bob@example.com>;tag=558C18F7-DB9DF7BC
To: <sip:alice@example.com>;tag=1894685100249086
CSeq: 14 NOTIFY
Call-ID: 77-505889516@example.com
Contact: <sip:bob@ua2.example.com>
Event: dialog;ma
User-Agent: XYZ-UA/4.5.6
Subscription-State: active;expires=3427
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="13"
state="partial"
entity="sip:alice@example.com">
<dialog id="ida0f8dc17"
call-id="14-1541707345@example.com"
local-tag="44BAD75D-E3128D42"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c"
direction="recipient">
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<state>confirmed</state>
<local>
<target uri="sip:alice@example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
F19 Appearance Agent ----> Alice
NOTIFY sip:alice@ua1.example.com SIP/2.0
From: <sip:alice@example.com>;tag=151702541050937
To: <sip:alice@example.com>;tag=18433323-C3D237CE
Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com
CSeq: 12 NOTIFY
Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413
Max-Forwards: 70
Content-Type: application/dialog-info+xml
Event: dialog;ma
Subscription-State: active
Contact: <sip:sa@stateagent.example.com>
Content-Length: ...
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:ma="urn:ietf:params:xml:ns:ma-dialog-info"
version="13"
state="partial"
entity="sip:alice@example.com">
<dialog id="2a7294823093f5274e3fd2ec54a2d76c"
call-id="14-1541707345@example.com"
local-tag="44BAD75D-E3128D42"
remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c"
direction="recipient">
<ma:appearance>0</appearance>
<ma:exclusive>false</exclusive>
<state>confirmed</state>
<local>
<target uri="sip:alice@example.com">
<param pname="+sip.rendering" pval="yes"/>
</target>
</local>
<remote>
<identity>sip:carol@ua.example.com</identity>
</remote>
</dialog>
</dialog-info>
| TOC |
This call flow shows the use of PUBLISH instead of SUBSCRIBE/NOTIFY between the members of the appearance group and the Appearance Agent.
Carol Proxy Alice Appearance Agent Bob | | | | | | | | |<----- PUBLISH F1<| | | | | | | | | |>F2 200 OK ------>| | | | | | | | |<-- NOTIFY F3<| | | | | | | | | |>F4 200 OK -->| | | | | | | | |<------------------------------------- INVITE F5<| | | | | | |<-- INVITE F6<| | | | | | | | | |>F7 180 Ring >| | | | | |>F8 180 Ringing -------------------------------->| |>F9 200 OK -->| | | | | |>F10 200 OK ------------------------------------>| | | | | | |<------------------------------------------------------ ACK F11<| | | | | | |<================= Both way RTP established ===================>| | | | | | | | | |<---- PUBLISH F12<| | | | | | | | | |>F13 200 OK ----->| | | |<- NOTIFY F14<| | | | | | | | | |>F15 200 OK ->| | | | | | | | |<------------------------------(hold) INVITE F16<| |<- INVITE F17<| | | | | | | | | |>F18 200 OK ->| | | | | |>F19 200 OK ------------------------------------>| | | | | | |<------------------------------------------------------ ACK F20<| | | | | | | | | |<---- PUBLISH F21<| | | | | | | | | |>F22 200 OK ----->| | | |<- NOTIFY F23<| | | | | | | | | |>F24 200 OK ->| | | |<-- INVITE F25<| | | |<- INVITE F26<|(w/ Replaces) | | | |( w/ Replaces)| | | | |>F27 200 OK ->| | | | | |>F28 200 OK -->| | | | | | | | |<-------------------- ACK F29<| | | | | | | | |<= Both way RTP established =>| | | | | | | | |>F30 BYE ---->| | | | | |>F31 BYE --------------------------------------->| | | | | | | |<------------------------------------ OK 200 F32<| |<- 200 OK F33<| | | | | | | | | | | | |<---- PUBLISH F34<| | | | | | | | | |>F35 200 OK ----->| | | |<- NOTIFY F36<| | | | | | | | | |>F37 200 OK ->| | | | | | | | | |>F38 PUBLISH >| | | | | | | | | |<- 200 OK F39<| | | | | |>F40 NOTIFY ----->| | | | | | | | | |<----- 200 OK F41<| |>F42 BYE ---->| | | | | |>F43 BYE ----->| | | | | | | | | |<-- 200 OK F44<| | | |<--200 OK F45<| | | | | | |>F46 PUBLISH >| | | | | | | | | |<- 200 OK F47<| | | | | |>F48 NOTIFY ----->| | | | | | | | | |<----- OK 200 F49<| Figure 6.
| TOC |
In this call flow, a call answered by Bob is joined by Alice or "bridged". The Join header field is used by Alice to request this bridging. If Bob did not support media mixing, Bob could obtain conferencing resources as described in [11].
Carol Forking Proxy Appearance Agent Alice Bob | | | | | |>F1 INVITE >| | | | | |>F2 INVITE ------------------------->| | | | | | | |>F3 INVITE --------------->| | | | | | | |<-100Try F4<| | | | | | | | | | |<-------------------- Ringing 180 F5<| |<180Ring F6<| | | | | |<---------- Ringing 180 F7<| | |<180Ring F8<| | | | | |<------------------------- 200 OK F9<| |<-200OK F10<| | | | | | | | | | |>F11 CANCEL -------------->| | | | | | | | |<-------------- 200 OK F12<| | | | | | | | |<Request Cancelled 487 F13<| | | | | | | | |>F14 ACK ----------------->| | |>F15 ACK -->| | | | | |>F16 ACK --------------------------->| | | | | | |<=============Both way RTP established===========>| | | | | | | | |<---------- NOTIFY F17<| | | | | | | | |>F18 200 OK ---------->| | | | | | | | |>F19 NOTIFY >| | | | | | | | | |<- 200OK F20<| | | | | | | | |<---- INVITE (w/ Join) F21<| | | | | | | | |>F22 INVITE (w/Join)---------------->| | | | | | | |<---- OK 200 Contact:Bob;isfocus F23<| | | | | | | |>F24 200 OK Contact:Bob;isfocus----->| | | | | | | |<----------------- ACK F25<| | | | | | | | |>ACK F26---------------------------->| | | | | | | |<-----INVITE Contact:Bob;isfocus F27<| |<-INVITE F28| | | | |>F29 200 -->| | | | | |>F30 200 OK ------------------------>| | | | | | | |<--------------------------- ACK F31<| |<--- ACK F32| | | | | | | |<==RTP==>| |<=============Both way RTP established===========>| Figure 7. F21 Alice ----> Proxy INVITE sip:bob@ua.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 From: <sip:alice@example.com>;tag=605AD957-1F6305C2 To: <sip:bob@ua.example.com> CSeq: 2 INVITE Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com Contact: <sip:alice@ua1.example.com> User-Agent: ABC-UA/1.2.3 P-Preferred-Identity: <sip:alice@example.com> <all-one-line> Join: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5 -b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 </all-one-line> Max-Forwards: 70 Content-Type: application/sdp Content-Length: 223 v=0 o=- 1103061265 1103061265 IN IP4 ua1.example.com s=IP SIP UA c=IN IP4 ua1.example.com t=0 0 a=sendrecv m=audio 2236 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
| TOC |
UA Appearance Agent UA1 UA2 | | | | | | F1: NOTIFY (trying) | | |<---------------| | | | F2: 200 OK | | | |--------------->| | | | F3: NOTIFY (trying) | | |----------------+--------------->| | | F4: 200 OK | | | |<---------------+----------------| | F5: INVITE | | | |<--------------------------------| | | F6: 180 Ringing| | | |-------------------------------->| | | | | | | | End | | | | | | | | | F7: SUBSCRIBE x 6 retries | | |---------------> | | | | | | F8: NOTIFY (terminated) | | |-------------------------------->| | | F9: 200 OK | | |<--------------------------------| | | | Figure 8.
The flow shown in this figure illustrates the failure of a user agent after it has obtained an appearance number (F1-F2). Messages used to refresh the subscription from Appearance Agent to UA1 are shown at F7. When the Appearance Agent attempts to refresh its subscription but receives no response. In this case, the Appearance Agent may apply policy and free up the appearance number as it wishes. In this case, after a delay, the Appearance Agent frees up the appearance number and sends NOTIFY messages (F8) indicating the termination of the dialog associated with the shared line.
| TOC |
UA Appearance Agent UA1 UA2 | | | | | | F1 NOTIFY (trying appearance=1) | | |<---------------| | | | F2 NOTIFY (trying appearance=1) | | |<---------------+----------------| | | F3 200 OK | | | |--------------->| | | | F4 200 OK | | | |----------------+--------------->| | | F5 NOTIFY (trying appearance=1)| | |--------------->| | | | F6 200 OK | | | |<---------------| | | | F7 NOTIFY (trying) | | |----------------+--------------->| | | F8 200 OK | | | |<---------------+----------------| | F9 INVITE | | | |<--------------------------------| | | | F10 NOTIFY (trying appearance=2)| | |<---------------+----------------| | | F11 200 OK | | | |----------------+--------------->| | | F12 NOTIFY (trying appearance=2)| | |----------------+--------------->| | | F13 200 OK | | | |<---------------+----------------| | F14 INVITE | | | |<-------------------------------------------------| | | | | Figure 9.
This figure illustrates two user agents, UA1 and UA2, attempting to select the same appearance number (i.e. seize the same line number) simultaneously. This type of race condition is often referred to in telephony as a glare condition. Appearance Agent may use any desired policy to decide which UA receives the appearance and which does not. In this case UA1 obtains the appearance number, as indicated by the NOTIFY from the Appearance Agent with the appearance number. UA2 learns that it did not obtain the appearance number since its NOTIFY does not contain the appearance number from its NOTIFY.
| TOC |
This section registers the SIP Alert-Info header field parameter "appearance" and the XML namespace extensions to the SIP Dialog Package.
| TOC |
This specification also defines a new event parameter "ma" for the Dialog Package.
| TOC |
This section registers a new XML namespace per the procedures in
[RFC3688].
URI: urn:ietf:params:xml:ns:ma-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Multiple Appearance Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Multiple Appearance Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfcXXXX.txt">
RFCXXXX</a>.</p>
</body>
</html>
END
| TOC |
This section registers an XML schema per the procedures in [RFC3688].
URI: urn:ietf:params:xml:schema:ma-dialog-info.
Registrant Contact: IETF BLISS working group, <bliss@ietf.org>,
Alan Johnston <alan@sipstation.com>
The XML for this schema can be found in Section 7.
| TOC |
To best meet REQ-9, the appearance number for an incoming INVITE should be contained in the INVITE itself.
For the dialog package parameter approach, REQ-9 could be met in two ways. When an incoming request is received, the Appearance Agent could send out a NOTIFY with state trying and include the appearance number to be used for this request. Upon receipt of this NOTIFY, the UAs could begin alerting using the appearance number selected. This approach is sub-optimal since the UAs could receive the INVITE but be unable to begin alerting if the NOTIFY from the Appearance Agent is delayed or lost
An alternative approach is to define an extension parameter for the Alert-Info header field in RFC 3261 such as:
Alert-Info: <file://ring.pcm>;alert=normal;appearance=0
This Alert-Info header would indicate to place the call on the first line appearance instance.
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 are a variety of ways the proxy can use to 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 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 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 select 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.
The changes to RFC 3261 ABNF would be:
alert-param = LAQUOT absoluteURI RAQUOT *( SEMI (generic-param / appearance-param) )
appearance-param = "appearance" EQUAL *DIGIT
| TOC |
The following individuals were part of the MA Design team and have provided input and text to the document (in alphabetical order):
Andrew Hutton, Raj Jain, Fernando Lombardo, Derek MacDonald, Bill Mitchell, Michael Procter, Theo Zowzouvillys.
Thanks to Chris Boulton for helping with the XML schema.
Much of the material has been drawn from previous work by Mohsen Soroushnejad, Venkatesh Venkataramanan, Paul Pepper and Anil Kumar, who in turn received assistance from:
Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve Towlson, and Michael Procter of Citel Technologies, Rob Harder and Hong Chen of Polycom Inc, John Elwell, J D Smith of Siemens Communications, Dale R. Worley of Pingtel, Graeme Dollar of Yahoo Inc.
Also thanks to Geoff Devine, Paul Kyzivat, Jerry Yin, John Elwell, Dan York, Spenser Dawkins, and Martin Dolly for their comments.
| TOC |
Since multiple line appearance features are implemented using semantics provided by RFC 3261 [2], Event Package for Dialog State as define in [7], and Event Notification [4], security considerations in these documents apply to this draft as well.
Specifically, since dialog state information and the dialog identifiers are supplied by UA's in an appearance group to other members, the same is prone to "call hijacks". For example, a rogue UA could snoop for these identifiers and send an INVITE with Replaces header containing these call details to take over the call. As such INVITES with Replaces header MUST be authenticated using the standard mechanism (like Digest or S/MIME) described in RFC 3261 [2] before it is accepted. NOTIFY message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanics. All SUBSCRIBES between the UA's and the Appearance Agent MUST be authenticated.
| TOC |
| TOC |
| Alan Johnston (editor) | |
| Avaya | |
| St. Louis, MO 63124 | |
| Email: | alan@sipstation.com |
| Mohsen Soroushnejad | |
| Sylantro Systems Corp | |
| Email: | mohsen.soroush@sylantro.com |
| Venkatesh Venkataramanan | |
| Sylantro Systems Corp | |
| Email: | vvenkatar@gmail.com |
| Paul Pepper | |
| Citel Technologies | |
| Email: | paul.pepper@citel.com |
| Anil Kumar | |
| Yahoo Inc. | |
| Email: | anil@yahoo-inc.com |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.