SIPPING WG Mohsen Soroushnejad Internet Draft (Editor) Expires: December 15, 2006 Venkatesh Venkataramanan Category: Informational Sylantro Systems Paul Pepper Citel Technologies Anil Kumar Yahoo Inc. June 15, 2006 Implementing Bridged Line Appearances (BLA) Using Session Initiation Protocol (SIP) draft-anil-sipping-bla-03.txt Status of this Memo 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet Draft will expire on December 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the implementation of Bridged Line Appearance (BLA) feature based on Session Initiation Protocol (SIP). The BLA feature is commonly offered in the IP Centrex services and IP-PBX offerings. This feature is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. Table of Contents 1. Introduction....................................................3 Soroushnejad, et al. [Page 1] Internet-Draft Bridged Line Appearance June 15 2006 2. Terminology.....................................................3 3. Conventions used in this document...............................3 4. Feature Description.............................................3 4.1 Usage Scenarios................................................4 5. Overview of Operation...........................................4 5.1 Line Appearance Resources......................................6 5.2 Bridged Line Appearance Resource Allocation....................7 6 Example Message Flows............................................8 6.1 Registration and Subscription Flows............................8 6.1.1 Alice Registration and Subscription Flow.....................8 6.1.2 Bob Registration and Subscription Flow......................13 6.2 Call Originated by a UA in a BLA group........................18 6.3 Call Offered to a BLA Group...................................28 7. New Event Package Parameter....................................32 8. State and Error Recovery.......................................33 8.1 Line Seize (Refresh Subscription).............................33 8.2 Line Seize (Notifier Failure).................................34 8.3 Line Seize (Race Condition)...................................35 9. Security Considerations........................................35 10. References....................................................36 11. Acknowledgements..............................................36 12. Author’s Contact Information..................................36 13. Full Copyright Statement......................................37 14. Intellectual Property Statement...............................37 Soroushnejad, et al. [Page 2] Internet-Draft Bridged Line Appearance June 15 2006 1. Introduction The feature and functionality requirements for SIP user agents supporting business telephony applications differ vastly from basic SIP user agents, both in terms of services and end user experience. In addition to basic SIP support in [2], many of the services in a business environment require the support for SIP extensions such as REFER [3], SUBSCRIBE/NOTIFY primitives [4], SIP Replaces header [5], etc. Many of the popular business services have been documented in the SIPPING service-examples draft [6]. In the same spirit, this document details a proposal for implementing Bridged Line Appearance (BLA), one of the more advanced popular features expected of SIP IP telephony devices in a business environment. Another common name for the BLA feature is Shared Call/Line Appearance (SCA). The proposal for the most part uses standard SIP RFC 3261 [2], in conjunction with RFC 3265 [4] for exchanging presence status among user agents, and the dialog state draft [7] to exchange dialog state information to achieve the same. 2. Terminology Directory Address (DA): An Address Of Record that is assigned to a user and typically bounded to the user’s SIP device. Line Appearance: A logical object that supports a single SIP session or call. On SIP telephony devices, a line appearance is typically realized as a hard or soft button to place outgoing calls or receive incoming calls. It may also provide visual indications for the status of the line appearance. Primary Appearance: A DA that can be used as a primary identifier of a user and the associated user agent. Bridged Line Appearance (BLA): A DA that is bounded onto multiple SIP user agents. BLA group: All users that share a BLA on their SIP devices are referred to as belonging to a BLA group. In a BLA group, the users may have a primary appearance in addition to the BLA DA. Furthermore, the BLA DA may be a primary appearance of another user in the group. 3. Conventions used in this document 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. 4. Feature Description BLA allows an Address Of Record (AOR) to be assigned onto different line appearances of group of SIP user agents (e.g., SIP IP telephony Soroushnejad, et al. [Page 3] Internet-Draft Bridged Line Appearance June 15 2006 clients). When a call is made to this DA, the call is offered to all user agents that have mapping to this DA. Users may choose via local settings to use distinctive alerting for incoming calls to the BLA address or use a standard alerting for all incoming calls. Regardless, one user among the BLA group may answer the call. Once the call is answered, all other devices reflect the current state of the call (mark the appropriate line appearance as in use). The feature allows other users that belong to this BLA group to pick this call based on the state of the call. Typically, the feature allows users to pick a call only when the dialog is placed on hold. Visual indications may be provided to the user to indicate that the call is being held and can be picked up on a line appearance associated with the BLA DA. Similarly, when a user places an outgoing call using such an appearance, all members that belong to the BLA group are notified of this usage, and are blocked from using this line appearance until the line appearance goes back to Idle state or if the call is placed on hold. User agents can be configured with the multiple instances of the BLA line appearance of same DA in order to support multiple calls or dialogs on the same DA. 4.1 Usage Scenarios The following examples are common applications of the BLA feature and are mentioned here as an infomative use cases: 1. Executive/Assistant arrangement: The executive DA may appear as a BLA on the assistant SIP telephony device. Assistant may answer incoming calls to executive and then place the call on hold for the executive to pick it up. 2. BLA Call Group: 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. 3. Virtual BLA: Allows a DA, not assigned as a primary appearance to any user, to be set up as a BLA on a given set of user devices. All the example usages above can be supported by the BLA feature described in this document, however the details of setup and usage of the above examples are not relevant to understanding of the BLA mechanism itself. 5. Overview of Operation This proposal uses the following components to enable this feature: - SIP Registrar - SIP Forking Proxy - State Agent (SA) The following figure illustrates the SIP components involved in supporting the BLA feature as described in this document. +----------------------------+ +----+ | | | | | State Agent | | UA | | | | | Soroushnejad, et al. [Page 4] Internet-Draft Bridged Line Appearance June 15 2006 +----------------------------+ +----+ A A |1)SUBSCRIBE A A 4)NOTIFY INVITE | | | |(Event:reg) | | registration alice@example.com | | | V | | events V | | +--------------------+ +----------+7)Query+--------+ | | | (example.com) | | |<===== | | | | | |3) Store| Location | | Proxy | | | | Registrar |=======>| Service | | | | | | | | |=====> | | | | +--------------------+ +----------+8)Resp +--------+ | | A A | | | | | | 2) REGISTER (alice) | | | | | | | | | | +----+ +----+ | | | | | | | | | | | | |UA1 | |UA2 | | | | | | | | | | | | | +----+ +----+ | | | | A A A A | | | | | | | | | | | +----+ | | | | | | | | +--------------------------------------+ | | +----+-------------------------------------------+ | | 8) INVITE +--------------+ alice@example.com 5-7) SUBSCRIBE (Event:dialog) 1. The State Agent SUBSCRIBES to the registration event package as outlined in [8] for contacts registered to BLA AOR. Thus, it has knowledge of all User Agents registered to BLA AOR at any point of time. 2. User Agents (UA1 and UA2 in above figure) belong to a BLA group and REGISTER for the same address-of-record (e.g., alice@example.com). If a given UA has a primary appearance different from the BLA AOR, it registers the BLA AOR using the SIP third-party registration mechanism [2]. 3. Each registration is recorded. 4. The registrar notifies the State Agent of successful registration at each UA. 5. The State Agent SUBSCRIBE to User Agents for the state of all dialogs associated with the BLA Contact URI, as defined in [7]. All User Agents that belong to the BLA group MUST support the dialog state package as outlined in [7] to NOTIFY other User Agents of the dialog-state. Further, they SHOULD understand and support the (sla) event parameter outlined in this draft. Section 7 of this draft outlines how this parameter is to be interpreted by the UA. The local session description MUST be included in the dialog payload, when the local user has placed a call on hold. The element should indicate that the call that is the subject of the dialog is being held (use of a=inactive or a=sendonly is RECOMMENDED [9]). Soroushnejad, et al. [Page 5] Internet-Draft Bridged Line Appearance June 15 2006 6. The User Agents SUBSCRIBE to State Agent for the state of all dialogs as defined in [7] using the contact information it received in the incoming subscription from the state agent. 7. The User Agents act as the notifier for the dialog state events as defined in [7]. 8. Forking Proxy forks an incoming INVITE for the BLA address to the registered user agents. The State Agent sends a NOTIFY of dialog state events to all the User Agents. 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 helps in managing large groups better. Further, the State Agent MAY filter dialog state events and NOTIFY User Agents of the dialog state events which are required for the application or feature. The State Agent MAY 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 BLA group. 5.1 Line Appearance Resources There are many user agents that support the concept of line appearances. On SIP telephony devices, a line appearance is typically realized as a hard or soft button to place outgoing calls or receive incoming calls. It may also provide visual indications for the status of the line appearance. Typically, the end users configure an AOR per line appearance offered with a user agent. In turn, the UA offers/sends the call to/from the specific line appearance when a call is placed or received for that AOR. It is possible to configure the same Address of Record for multiple line appearances on the same user agent. In such scenarios, the UA uses its own local resource management to offer the first incoming call to the first line, the second to the next idle line up to the maximum configured before it starts rejecting calls with a 486 Busy request. Such a configuration has some implications on how Bridged (Shared) Line Appearances operate. User agents that support such a concept MUST send only one REGISTER for the AOR instead of sending one per line appearance. Furthermore, in such scenarios, user agents MAY indicate which line appearance a call is being offered to or placed from in the NOTIFY payload. Generally, it is desirable, if more that one line appearance is configured for a given BLA DA, to map calls on the BLA line appearances so a call will appear on the same line appearance instance for every configured UA. To do this, the "x-line-id" parameter is used in the examples in this document. When calls are presented to a UA, the Alert-Info header will contain an x-line-id parameter. Alert-Info was selected over the request- URI because intermediate proxies are less likely to change the Alert-Info header. The UA should use the number indicated to select a line appearance to present to the user. For example: Soroushnejad, et al. [Page 6] Internet-Draft Bridged Line Appearance June 15 2006 Alert-Info: ;alert=normal;x-line-id=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 x-line-id parameter can be done at the proxy that forks the incoming request to all the registered UA's. 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 for the BLA DA to fetch the list of lines that are in use. Alternatively, it could act like a UA that is a part of the BLA group and SUBSCRIBE to the State-Agent like any other UA. This would ensure that the active dialog information is availabe without having to poll on a need basis. It could keep track of the list of active calls for the BLA AOR based on how many unique INVITE requests it has forked to or received from the BLA AOR. The actual mechanism is left to the implementation. When a UA indicates, via a dialog-info NOTIFY command, a state change on a dialog, the x-line-id parameter is placed in the parameters of the local target of the dialog-info. For example: trying ... The UA MUST send dialog-info in state "trying" with the appropriate x-line-id parameter present in the local target when it is attempting to 'seize' a line. It MUST do this before it sends out the INVITE request. It should be noted that the x-line-id parameter is relative to the DA. Thus a UA can support multiple DA's with each DA capable of supporting x-line-id's sequentially numbered from 0 through 'n' where 'n' is the number of lines the UA supports for each of the DA's. 5.2 Bridged Line Appearance Resource Allocation Even in trivial deployments of two BLA-enabled user agents, race conditions can exist when both user agents attempt to seize a shared line simultaneously (i.e. when the NOTIFY messages, that each user Soroushnejad, et al. [Page 7] Internet-Draft Bridged Line Appearance June 15 2006 agent sends to the other, are active within the network during an overlapping time period). The SIP-specific event notification framework, described in [4], defines the use of state agents. State agents act on behalf of resources to publish state. The State Agent can use any policy deemed necessary to resolve races and ensure no two user agents obtain the same line seize during overlapping periods. It is also necessary to distinguish between a line seize for the purpose of initiating a call (i.e. as an initiator) and a line seize used to accept a call (i.e. as a recipient). Without this distinction we quickly run into problems. To illustrate the type of problems that can result, consider an incoming call on a BLA. If there were only one type of seize, and only one instance of a line seize per BLA, one of either the initiator or recipient must perform the seize operation or neither should seize the line. If the initiator seizes the line, then there is no way the recipient can seize the line to accept the call. Alternatively, if the recipient performs the seize operation, more than one call could be placed on the shared line before the recipient seizes the share line just prior to answering the call. Finally, if neither initiator nor recipient seizes the line, then it becomes possible for other user agents to place outbound calls on the shared line. By distinguishing between the initiator and recipient of a call we can ensure only one user is allowed to initiate a call on a shared line and ditto for receiving a call. A full lock on a shared line resource is only achieved when both its initiator and recipient locks have been issued. The use of the element (specified in [4]) on line seize operations suffices for this purpose. It is worth making a distinction between a shared line and the users of that shared line. A shared line will normally have an association with a number of users. However, distinguishing users from lines encourages thinking of the shared line as a resource on which calls can be initiated and received by an initiator and a recipient, respectively. 6 Example Message Flows 6.1 Registration and Subscription Flows Bob has bridged line appearance for Alice. Bob REGISTER for Alice’s AOR using contact sip:alice@ua2.example.com. Furthermore, Bob REGISTER his primary address with contact sip: bob@ua2.example.com. Alice REGISTER with contact sip:alice@ua1.example.com. The State Agent subscribes to dialog states of the BLA DA (i.e., sip:alice@example.com) at the User Agents for Alice and Bob. Message exchange between the Registrar, State 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. 6.1.1 Alice Registration and Subscription Flow Registrar State Agent Alice Soroushnejad, et al. [Page 8] Internet-Draft Bridged Line Appearance June 15 2006 | | | | | | |<--------------------------- REGISTER F1<| | | | |>F2 401 Unauthorized ------------------->| | | | |<--------------------------- REGISTER F3<| | | | |>F4 200 OK ----------------------------->| | | | | |>F5 SUBSCRIBE ----->| | | | | |<-------- 200 OK F6<| | | | | |<-------- NOTIFY F7<| | | | | |>F8 200 OK -------->| | | | | |<----- SUBSCRIBE F9<| | | | | |>F10 202 Accepted ->| | | | | |>F11 NOTIFY ------->| | | | | |<------- OK 200 F12<| | | | F1-F4: Alice registers AOR with contact: F1 Alice ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 From: ;tag=CDF9A668-909E2BDD To: CSeq: 1 REGISTER Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com Contact: User-Agent: ABC-UA/1.2.3 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F2 Registrar ----> Alice SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09 CSeq: 1 REGISTER Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com From: ;tag=CDF9A668-909E2BDD To: ;tag=1026148581664839 Soroushnejad, et al. [Page 9] Internet-Draft Bridged Line Appearance June 15 2006 WWW-Authenticate: Digest realm="example.com",nonce="3281fad606d8b0fe89f60d9292b842fc",opaque= "",stale=FALSE,algorithm=MD5 Content-Length: 0 F3 Alice ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2 From: ;tag=CDF9A668-909E2BDD To: CSeq: 2 REGISTER Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com Contact: User-Agent: ABC-UA/1.2.3 Authorization: Digest username="alice", realm="example.com", nonce="3281fad606d8b0fe89f60d9292b842fc", opaque="", uri="sip:registrar.example.com", response="b90508e14cec5ae95d9d5aa878a4cb75", algorithm=MD5 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F4 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: ;tag=CDF9A668-909E2BDD To: ;tag=1664573879820199 Contact: Expires: 3600 Content-Length: 0 F5 to F8: Once Alice registers, State Agent subscribes to the events at the contact registered for Alice and Alice notifies the State Agent of its status. F5 State Agent ----> Alice SUBSCRIBE sip:alice@ua1.example.com SIP/2.0 From: ;tag=110286377866002 To: Call-ID: 284-425690188@example.com CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532 Event: dialog;sla Expires: 3700 Contact: Content-Length: 0 Soroushnejad, et al. [Page 10] Internet-Draft Bridged Line Appearance June 15 2006 F6 Alice ----> State Agent SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1979345546866532 From: ;tag=110286377866002 To: ;tag=717A8C26-BA734CE3 CSeq: 2 SUBSCRIBE Call-ID: 284-425690188@example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Expires: 3700 Content-Length: 0 F7 Alice ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870 From: ;tag=717A8C26-BA734CE3 To: ;tag=110286377866002 CSeq: 1 NOTIFY Call-ID: 284-425690188@example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Subscription-State: active;expires=3698 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 164 F8 State 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: ;tag=717A8C26-BA734CE3 To: ;tag=110286377866002 Allow-Events: dialog;sla Contact: Content-Length: 0 F9 to F12: Alice also subscribes to the events associated with the Alice AOR with State Agent. State Agent also notifies Alice of the status. Soroushnejad, et al. [Page 11] Internet-Draft Bridged Line Appearance June 15 2006 F9 Alice ----> State Agent SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A From: ;tag=925A3CAD-CEBB276E To: CSeq: 1 SUBSCRIBE Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Accept: application/dialog-info+xml Max-Forwards: 70 Expires: 3700 Content-Length: 0 F10 State 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: ;tag=925A3CAD-CEBB276E To: ;tag=1636248422222257 Allow-Events: dialog;sla Expires: 3700 Contact: Content-Length: 0 F11 State Agent ----> Alice NOTIFY sip:alice@ua1.example.com SIP/2.0 From: ;tag=1636248422222257 To: ;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;sla Subscription-State: active Contact: Content-Length: 162 F12 Alice ----> State Agent Soroushnejad, et al. [Page 12] Internet-Draft Bridged Line Appearance June 15 2006 SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1846984327225734 From: ;tag=1636248422222257 To: ;tag=925A3CAD-CEBB276E CSeq: 2 NOTIFY Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Content-Length: 0 6.1.2 Bob Registration and Subscription Flow Registrar State Agent Bob | | | | | | |<--------------------------- REGISTER F1<| | | | |>F2 401 Unauthorized ------------------->| | | | |<--------------------------- REGISTER F3<| | | | |>F4 200 OK ----------------------------->| | | | |<--------------------------- REGISTER F5<| | | | |>F6 401 Unauthorized ------------------->| | | | |<--------------------------- REGISTER F7<| | | | |>F8 200 OK ----------------------------->| | | | | |>F9 SUBSCRIBE ----->| | | | | |<------- 200 OK F10<| | | | | |<------- NOTIFY F11<| | | | | |>F12 200 OK ------->| | | | | |<---- SUBSCRIBE F13<| | | | | |>F14 202 Accepted ->| | | | | |>F15 NOTIFY ------->| | | | | |<------- 200 OK F16<| | | | Soroushnejad, et al. [Page 13] Internet-Draft Bridged Line Appearance June 15 2006 F1 to F4: Bob registers his (primary) AOR with contact sip:bob@ua2.example.com. F1 Bob ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK41599ad63A2E521F From: ;tag=9F80647C-94355FE3 To: CSeq: 1 REGISTER Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com Contact: User-Agent: XYZ-UA/4.5.6 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F2 Registrar ----> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK41599ad63A2E521F CSeq: 1 REGISTER Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com From: ;tag=9F80647C-94355FE3 To: ;tag=1370290862415334 WWW-Authenticate: Digest realm="example.com",nonce="fbfa92fb954eb092de6b89433154f093",opaque= "",stale=FALSE,algorithm=MD5 Content-Length: 0 F3 Bob ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK1b1c1d25FB82B2DE From: ;tag=9F80647C-94355FE3 To: CSeq: 2 REGISTER Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com Contact: User-Agent: XYZ-UA/4.5.6 Authorization: Digest username="bob", realm="example.com", nonce="fbfa92fb954eb092de6b89433154f093", opaque="", uri="sip:registrar.example.com", response="59f805336b9b7e81470d3841f3d0016a", algorithm=MD5 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F4 Registrar ----> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK1b1c1d25FB82B2DE CSeq: 2 REGISTER Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com From: ;tag=9F80647C-94355FE3 Soroushnejad, et al. [Page 14] Internet-Draft Bridged Line Appearance June 15 2006 To: ;tag=468305689550907 Contact: Expires: 3600 Content-Length: 0 F5 to F8: Bob registers Alice AOR with his client using SIP third- party registration. F5 Bob ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK5f3f2c694DF31062 From: ;tag=81B52F2F-7EA64EE6 To: CSeq: 1 REGISTER Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com Contact: User-Agent: XYZ-UA/4.5.6 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F6 Registrar ----> Bob SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK5f3f2c694DF31062 CSeq: 1 REGISTER Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com From: ;tag=81B52F2F-7EA64EE6 To: ;tag=631889299347457 WWW-Authenticate: Digest realm="example.com",nonce="04ff2106fd51729fb22d99b959787417",opaque= "",stale=FALSE,algorithm=MD5 Content-Length: 0 F7 Bob ----> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKdf17f688391F7DF1 From: ;tag=81B52F2F-7EA64EE6 To: CSeq: 2 REGISTER Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com Contact: User-Agent: XYZ-UA/4.5.6 Authorization: Digest username="bob", realm="example.com", nonce="04ff2106fd51729fb22d99b959787417", opaque="", uri="sip:registrar.example.com", response="e87fbce1a68320cdc81353020f50f695", algorithm=MD5 Max-Forwards: 70 Expires: 3600 Content-Length: 0 F8 Registrar ----> Bob Soroushnejad, et al. [Page 15] Internet-Draft Bridged Line Appearance June 15 2006 SIP/2.0 200 OK Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKdf17f688391F7DF1 CSeq: 2 REGISTER Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com From: ;tag=81B52F2F-7EA64EE6 To: ;tag=773736136499990 Contact: Expires: 3600 Content-Length: 0 F9 to F12: Once Bob registers with Alice AOR, State Agent subscribes to the events at the contact registered for Alice and Bob notifies the State Agent of its status. F9 State Agent ----> Bob SUBSCRIBE sip:alice@ua2.example.com SIP/2.0 From: ;tag=1326816553546535 To: Call-ID: 285-1728540768@example.com CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1444292281547026 Event: dialog;sla Expires: 3700 Contact: Content-Length: 0 F10 Bob ----> State Agent SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1444292281547026 From: ;tag=1326816553546535 To: ;tag=9A4180F3-B934AE6A CSeq: 2 SUBSCRIBE Call-ID: 285-1728540768@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Expires: 3700 Content-Length: 0 F11 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa07137bdB2E512F6 From: ;tag=9A4180F3-B934AE6A To: ;tag=1326816553546535 CSeq: 1 NOTIFY Call-ID: 285-1728540768@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Soroushnejad, et al. [Page 16] Internet-Draft Bridged Line Appearance June 15 2006 Subscription-State: active;expires=3698 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 164 F12 Sate Agent ----> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa07137bdB2E512F6 CSeq: 1 NOTIFY Call-ID: 285-1728540768@example.com From: ;tag=9A4180F3-B934AE6A To: ;tag=1326816553546535 Allow: NOTIFY,SUBSCRIBE Allow-Events: dialog;sla Contact: Content-Length: 0 F13 to F16: Bob also subscribes to the events associated with the Alice AOR with State Agent. State Agent also notifies Bob of the status. F13 Bob ----> State Agent SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98 From: ;tag=410F7345-F7EBA89C To: CSeq: 1 SUBSCRIBE Call-ID: 42fed01-850cb203-de12767a@ua2.example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Accept: application/dialog-info+xml Max-Forwards: 70 Expires: 3700 Content-Length: 0 F14 State Agent ----> Bob SIP/2.0 202 Accepted Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98 CSeq: 1 SUBSCRIBE Call-ID: 42fed01-850cb203-de12767a@ua2.example.com From: ;tag=410F7345-F7EBA89C To: ;tag=521018280364802 Soroushnejad, et al. [Page 17] Internet-Draft Bridged Line Appearance June 15 2006 Allow: NOTIFY,SUBSCRIBE Allow-Events: dialog;sla Expires: 3700 Contact: Content-Length: 0 F15 State Agent ----> Bob NOTIFY sip:alice@ua2.example.com SIP/2.0 From: ;tag=521018280364802 To: "bob" ;tag=410F7345-F7EBA89C Call-ID: 42fed01-850cb203-de12767a@ua2.example.com CSeq: 2 NOTIFY Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK516254789368301 Max-Forwards: 70 Content-Type: application/dialog-info+xml Event: dialog;sla Subscription-State: active Contact: Content-Length: 162 F16 Bob ----> State Agent SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK516254789368301 From: ;tag=521018280364802 To: ;tag=410F7345-F7EBA89C CSeq: 2 NOTIFY Call-ID: 42fed01-850cb203-de12767a@ua2.example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Content-Length: 0 6.2 Call Originated by a UA in a BLA group In this scenario, the UA just before allowing the user to place a call, shall send out a dialog event NOTIFY with state (trying). The User Agent MUST wait for a 200 OK response from the State Agent, before it proceeds with sending out the INVITE to the address entered by the end user. In case a UA receives a 500 final response for the NOTIFY, it MUST inspect the Retry-After interval. If one is present, the UA must wait for this interval before it retries sending the NOTIFY. Further it should continue to delay sending out the INVITE. Should the UA Soroushnejad, et al. [Page 18] Internet-Draft Bridged Line Appearance June 15 2006 receive a NOTIFY of (trying) from the State Agent before the expiry of this interval, it MUST honor the same by providing appropriate end user indication; cancel any timers it has started for retrying the NOTIFY request; and abandon reinitiating of the NOTIFY request. The UA MUST then abandon sending out INVITE to the address in such a scenario. It should be noted that this 500 response does not amount to a NOTIFY failure. Specifically, this response MUST not result in the UA terminating Subscriptions of the State Agent. This is needed to disallow use of the BLA line appearance once one of the users has chosen the same. Sending NOTIFY dialog state of (trying) before an INVITE is a departure from [7], but this MUST be implemented to resolve glare issues. Further, the dialog state definition [7] has no restrictions on the number of dialogs that MAY be conveyed in a single SIP NOTIFY message. However, since the NOTIFY for going off-hook can be rejected by the State Agent, such a NOTIFY MUST be presented to the State Agent as a single dialog payload in the NOTIFY. In the following call flow, Bob, as a member of the Alice BLA group, places an outgoing call to Carol using Alice line appearance. 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 state 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 State Agent Bob | | | | | | | | |<------ NOTIFY 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 ===================>| | | | | | | | | |<----- NOTIFY F12<| | | | | | | | | |>F13 200 OK ----->| Soroushnejad, et al. [Page 19] Internet-Draft Bridged Line Appearance June 15 2006 | | |<- NOTIFY F14<| | | | | | | | | |>F15 200 OK ->| | | | | | | | |<------------------------------(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<| | Soroushnejad, et al. [Page 20] Internet-Draft Bridged Line Appearance June 15 2006 | | | |>F48 NOTIFY ----->| | | | | | | | | |<----- OK 200 F49<| 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. State 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). F1 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79 From: ;tag=44150CC6-A7B7919D To: ;tag=428765950880801 CSeq: 7 NOTIFY Call-ID: 144-1289338424@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Subscription-State: active;expires=3347 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 365 trying F2 State 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: ;tag=44150CC6-A7B7919D Soroushnejad, et al. [Page 21] Internet-Draft Bridged Line Appearance June 15 2006 To: ;tag=428765950880801 Allow-Events: dialog;sla Contact: Content-Length: 0 F3 State Agent ----> Alice NOTIFY sip:alice@ua1.example.com SIP/2.0 From: ;tag=497585728578386 To: ;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;sla Subscription-State: active Contact: Content-Length: 402 trying F4 Alice ----> State Agent SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK1711759878512309 From: ;tag=497585728578386 To: ;tag=633618CF-B9C2EDA4 CSeq: 7 NOTIFY Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Content-Length: 0 Soroushnejad, et al. [Page 22] Internet-Draft Bridged Line Appearance June 15 2006 F5 to F11: 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). F5 Bob ----> Proxy INVITE sip:carol@example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF From: ;tag=15A3DE7C-9283203B To: CSeq: 1 INVITE Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com Contact: User-Agent: XYZ-UA/4.5.6 P-Preferred-Identity: 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 F12 to F15: Bob notifies the state agent of the status of the dialog (i.e., confirmed). State agent notifies Alice of the same. F12 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602 From: ;tag=44150CC6-A7B7919D To: ;tag=428765950880801 CSeq: 9 NOTIFY Call-ID: 144-1289338424@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Subscription-State: active;expires=3342 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 675 confirmed sip:carol@example.com F16 to F20: Bob places Carol on hold. F22 to F24: Bob notifies state 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). State agent notifies Alice of the same. F22 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E From: ;tag=44150CC6-A7B7919D To: ;tag=428765950880801 CSeq: 10 NOTIFY Call-ID: 144-1289338424@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Subscription-State: active;expires=3338 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 942 confirmed sip:carol@example.com 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: ;tag=8C4183CB-BCEAB710 To: CSeq: 1 INVITE Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com Contact: User-Agent: ABC-UA/1.2.3 P-Preferred-Identity: Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to- tag=65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C- 9283203B 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 state agent of the termination of dialog at his UA. Alice notifies the state agent of the confirmed state of the dialog at her UA. Soroushnejad, et al. [Page 25] Internet-Draft Bridged Line Appearance June 15 2006 F34 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A From: ;tag=44150CC6-A7B7919D To: "State_Agent" ;tag=428765950880801 CSeq: 11 NOTIFY Call-ID: 144-1289338424@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Subscription-State: active;expires=3334 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 677 terminated sip:carol@example.com F38 Alice ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572 From: ;tag=5861255C-14C04045 To: "State_Agent" ;tag=920163082722420 CSeq: 10 NOTIFY Call-ID: 143-1840952798@example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Subscription-State: active;expires=3315 Max-Forwards: 70 Content-Type: application/dialog-info+xml Soroushnejad, et al. [Page 26] Internet-Draft Bridged Line Appearance June 15 2006 Content-Length: 640 confirmed sip:carol@example.com F42 to F59: Carol terminates the dialog with Alice. Alice notifies state agent of the dialog state (terminated). State agent notifies Bob of the same. F46 Alice ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C From: ;tag=5861255C-14C04045 To: "State_Agent" ;tag=920163082722420 CSeq: 11 NOTIFY Call-ID: 143-1840952798@example.com Contact: Event: dialog;sla User-Agent: ABC-UA/1.2.3 Subscription-State: active;expires=3311 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 642 terminated sip:carol@example.com 6.3 Call Offered to a BLA Group In the call flow below Bob has bridged appearance of Alice. 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. Carol Forking Proxy State 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<| | | | | | | | |F14 ACK ----------------->| | |>F15 ACK -->| | | | | |>F16 ACK --------------------------->| | | | | | |<=============Both way RTP established===========>| Soroushnejad, et al. [Page 28] Internet-Draft Bridged Line Appearance June 15 2006 | | | | | | | |<---------- NOTIFY F17<| | | | | | | | |>F18 200 OK ---------->| | | | | | | | |>F19 NOTIFY >| | | | | | | | | |<- 200OK F20<| | | | | | | | |<----------------("Hold") INVITE F21<| |F23 200OK->| | | | | |>F24 200 OK ------------------------>| | | | | | | |<--------------------------- ACK F25<| |<-- ACK F26<| | | | | | |<---------- NOTIFY F27<| | | | | | | | |>F28 200 OK ---------->| | | | | | | | |>F29 NOTIFY >| | | | | | | | | |<- 200OK F30<| | | | | | | | |< INVITE (w/ Replaces) F31<| | |F33 200 OK>| | | | | |>F34 200 OK -------------->| | | | | | | | |<----------------- ACK F35<| | |<-- ACK F36<| | | | | | | | | |<=======Both way RTP established=======>| | | | | | | |>F37 BYE -->| | | | | |>F38 BYE --------------------------->| | | | | | | |<------------------------ OK 200 F39<| |<-200OK F40<| | | | | | |<---------- NOTIFY F41<| | | | | | | | |>F42 200 OK ---------->| | | | | | | | |>F43 NOTIFY >| | | | | | | | | |<-200 OK F44<| | | | | | | | | |<-NOTIFY F45<| | | | | | | | | |>F46 200 OK->| | | | | | | | | |>F47 NOTIFY ---------->| | | | | | Soroushnejad, et al. [Page 29] Internet-Draft Bridged Line Appearance June 15 2006 | | |<---------- 200 OK F48<| |>49 BYE --->| | | | | |>F50 BYE ----------------->| | | | | | | | |<-------------- OK 200 F51<| | |<-200OK F52<| | | | | | |< NOTIFY F53<| | | | | | | | | |>F54 200 OK >| | | | | | | | | |>F55 NOTIFY ---------->| | | | | | | | |<---------- 200 OK F56<| | | | | | 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. F17 - F20: Bob notifies the State Agent with dialog state payload indicating the dialog in confirmed state. State Agent notifies Alice of the status of the dialog at Bob. F17 Bob ----> State Agent NOTIFY sip:sa@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263 From: ;tag=558C18F7-DB9DF7BC To: ;tag=1894685100249086 CSeq: 14 NOTIFY Call-ID: 77-505889516@example.com Contact: Event: dialog;sla User-Agent: XYZ-UA/4.5.6 Subscription-State: active;expires=3427 Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 575 confirmed Soroushnejad, et al. [Page 30] Internet-Draft Bridged Line Appearance June 15 2006 sip:carol@ua.example.com F19 State Agent ----> Alice NOTIFY sip:alice@ua1.example.com SIP/2.0 From: ;tag=151702541050937 To: ;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;sla Subscription-State: active Contact: Content-Length: 618 confirmed sip:carol@ua.example.com F21 to F26: Bob places Carol on hold. F27 to F30: Bob notifies the State Agent of the status of the dialog on hold with inclusion of the session description in the NOTIFY Soroushnejad, et al. [Page 31] Internet-Draft Bridged Line Appearance June 15 2006 payload. Subsequently, State Agent notifies Alice of the status of dialog. F31 to F40: Alice picks up the held call by sending an INVITE with Replaces: header populated with the dialog data received in the NOTIFY from the State Agent. Carol establishes a session with Alice and terminates the dialog with Bob. F31 Alice ----> Proxy INVITE sip:carol@ua.example.com SIP/2.0 Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31 From: ;tag=605AD957-1F6305C2 To: CSeq: 2 INVITE Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com Contact: User-Agent: ABC-UA/1.2.3 P-Preferred-Identity: Replaces: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5- b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42 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 F41 to F48: Bob notifies the State Agent of the termination of the dialog and State Agent notifies the same to Alice. Alice notifies the State Agent of the confirmed state of dialog at Alice and State Agent informs Bob of the same. F49 to F52: Carol terminates dialog with Alice. F53 to F56: Alice notifies the State Agent of the termination of the dialog and State Agent notifies Bob of the same. 7. New Event Package Parameter 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 Soroushnejad, et al. [Page 32] Internet-Draft Bridged Line Appearance June 15 2006 of a SUBSRIBE request. 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 (sla). User Agents that understand this parameter will only provide dialog state information as detailed in this draft. 8. State and Error Recovery 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 experiences 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 gets 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 State Agent attempts to refresh its dialog-state subscription with this UA. To recover from such a failure, the State 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 Event 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 BLA 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 user 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. 8.1 Line Seize (Refresh Subscription) UA - Called State Agent UA - Calling | | | | | F1: NOTIFY (trying)| | |<-------------------| | | F2: 200 OK | | |------------------->| | F3: INVITE/180 Ring/200 OK/ACK | |<-------------------+--------------------| | | F4: SUBSCRIBE | | |------------------->| | | F5: 200 OK | | |<-------------------| | | F6: NOTIFY(confirm)| Soroushnejad, et al. [Page 33] Internet-Draft Bridged Line Appearance June 15 2006 | |<-------------------| | | F7: 200 OK | | |------------------->| | | | This figure shows UA seizing a bridged line (F1 and F2) from the state agent. State agent refreshes its subscription to UA (F4-F7) ensuring continuity of service (whilst also verifying User agents shared line service). UA should maintain a policy of shortened expires periods so long as it holds a line seize (throughout the period of a call). Subscription refreshes will therefore continue to use a shortened expires period. Although UA will determine the expiration period of subscriptions to it, the state agent may choose to refresh subscriptions on a more regular basis as an extra means of ensuring continuity of shared line service. 8.2 Line Seize (Notifier Failure) UA State 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 | | |<--------------------------------| | | | The flow shown in this figure illustrates the failure of a user agent after it has obtained a line seize (F1-F2). Messages used to refresh the subscription from State Agent to UA1 are shown at F7. The discontinuation of the bridged line service within user agent UA1 is shown by the abrupt termination of the UA1 vertical time line. When the state agent attempts to refresh its subscription and no response is received, indicating the shared line service maintained by UA1 has failed. State agent should at this point free Soroushnejad, et al. [Page 34] Internet-Draft Bridged Line Appearance June 15 2006 the seize lock held by UA1 and issue NOTIFY messages (F8) indicating the termination of the dialog associated with the shared line. 8.3 Line Seize (Race Condition) UA State Agent UA1 UA2 | | | | | | F1: NOTIFY (trying) | | |<---------------| | | | F2: NOTIFY (trying) | | |<---------------+----------------| | | F03: 200 OK | | | |--------------->| | | | F4: 500 | | | |----------------+--------------->| | | F5 : NOTIFY (trying) | | |----------------+--------------->| | | F6: 200 OK | | | |<---------------+----------------| | F09: INVITE | | | |<---------------+----------------| | | | | | This figure illustrates two user agents, UA1 and UA2, attempting to seize the same bridged line simultaneously. This type of race condition is often referred as a glare condition. State agent provides only one of UA1 and UA2 with the initiator’s line seize (UA1 in this case) and may choose any policy deemed appropriate to resolve the race. 9. Security Considerations Since many of these 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 a BLA 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 Event Agent MUST be authenticated. Soroushnejad, et al. [Page 35] Internet-Draft Bridged Line Appearance June 15 2006 10. References [1] S. Bradner, Key words for use in RFCs to indicate requirement levels, RFC 2119, Internet Engineering Task Force, Mar. 1997. [2] J. Rosenberg, H. Schulzrinne, et al., SIP: Session initiation protocol, RFC 3261, Internet Engineering Task Force, June 2002. [3] R. Sparks, The Session Initiation Protocol (SIP) Refer Method, RFC 3515, Internet Engineering Task Force, April 2003. [4] A.B. Roach, Session Initiation Protocol (SIP)-Specific Event Notification, RFC 3265, Internet Engineering Task Force, June 2002. [5] R. Mahy, et al., Session Initiation Protocol (SIP) Replaces Header, RFC 3891, Internet Engineering Task Force, September 2004. [6] A. Johnston, et al., Session Initiation Protocol Service Examples, draft-ietf-sipping-service-examples-10, (work in progress) March 16, 2006. [7] J. Rosenberg, et al, An INVITE Initiated Dialog Event Package for Session Initiation Protocol (SIP), RFC 4235, November 2005. [8] J. Rosenberg, A Session Initiation Protocol (SIP) Event Package for Registrations, RFC 3680, Internet Engineering Task Force, April 2003. [9] J. Rosenberg, H.Schulzrinne, An Offer/Answer Model with Session Description Protocol, RFC 3264, Internet Engineering Task Force, June 2002. [10] C. Jennings, et al., Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, RFC 3325, Internet Engineering Task Force, November 2002. 11. Acknowledgements The authors would like to thank Kent Fritz, John Weald, and Sunil Veluvali of Sylantro Systems, Steve Towlsen, 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, and Graeme Dollar of Yahoo Inc, for their numerous corrections, comments and suggestions during authoring of this draft. 12. Author’s Contact Information Mohsen Soroushnejad Email: mohsen.soroush@sylantro.com (408) 626 3028 Sylantro Systems Corp. 910 E Hamilton Ave, Campbell,CA 95008 Venkatesh Venkataramanan Email: venkatar@sylantro.com (408) 626 3025 Sylantro Systems Corp. 910 E Hamilton Ave, Campbell,CA 95008 Soroushnejad, et al. [Page 36] Internet-Draft Bridged Line Appearance June 15 2006 Paul Pepper Email: paul.pepper@citel.com Citel Technologies 1420 Fifth Avenue, 22nd Floor, Seattle WA 98101 Anil Kumar Email: anil@yahoo-inc.com Yahoo Inc. 701 First Avenue Sunnyvale, CA 94089 13. Full Copyright Statement "Copyright (C) The Internet Society (2006). 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 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." 14. Intellectual Property Statement 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. Soroushnejad, et al. [Page 37]