SIPPING WG Anil Kumar Internet Draft Venkatesh Venkataramanan Sylantro Systems Document: draft-anil-sipping-bla-01.txt August 2004 Paul Pepper Category: Informational Citel Technologies Implementing Bridged Line Appearances (BLA) Using Session Initiation Protocol (SIP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes a proposal for implementing Bridged Line Appearance for SIP phones. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................3 2. Terminology.....................................................3 3. Conventions used in this document...............................3 4. Feature Description/Overview....................................3 4.1 Usage Scenarios................................................4 5. Overview of Operation...........................................4 6 Example Message Flows............................................6 6.1 Subscription...................................................6 Anil Kumar Expires August 2004 1 1 Internet-Draft Bridged Line Appearance 2/18/2004 6.2 Call Originated by a UA in a BLA group........................15 6.3 Call Offered to a BLA Group...................................24 7. New Event Package Parameter....................................26 8. State Recovery.................................................26 9. Security Considerations........................................27 Acknowledgements..................................................28 Author's Addresses................................................28 Full Copyright Statement..........................................29 Anil Kumar Expires August 2004 2 Internet-Draft Bridged Line Appearance 2/18/2004 1. Introduction The requirements for business telephones differ vastly from single line telephones in terms of the features that they support and end user experience. This document details a proposal for implementing one of the most popular features expected of business phones, viz. Bridged Line Appearance (BLA). The proposal for most part uses standard SIP RFC 3261 [2] in conjunction with RFC 3265 [3] for exchanging presence status between UAÆs and the dialog state draft [4] to exchange dialog/call state information to achieve the same. The call flows borrow heavily from the SIPPING Call flows document. 2. Terminology Directory Number (DN): A telephone number or a SIP-URL identifying a phone. Bridged Line Appearance (BLA): A DN that appears on more than one userÆs phone. Single Call Arrangement (SCA): An arrangement where in only one phone among a group of phones that share a DN can be active at any point of time. Line Key/Appearance: A button on a phone used for outgoing/incoming calls and monitoring calls. Primary Appearance: A user or a telephone that ôownsö a particular DN. BLA group: All users that share a BLA appearance on their telephone are referred to as belonging to a BLA 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/Overview BLA allows a single DN to be assigned on to different line keys of multiple phones. When a call is made to this DN, the call is offered to all phones that have mapping to this DN. Users are allowed to have local settings by means of which calls that are being offered to these DNÆs either provide regular ring tone, a visual alert or a call waiting beep and so on. Regardless, only one of the users is allowed to answer this call. Once the call is answered, all other Anil Kumar Expires August 2004 3 Internet-Draft Bridged Line Appearance 2/18/2004 phones 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 are provided to the user to indicate that the call is ôpick-ableö. Also, when a user places an outgoing call using such an appearance, all members that belong to the BLA group for the DN of the line used 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 media is placed on Hold. 4.1 Usage Scenarios There are many applications of this feature: 1. An assistant might have bridged line appearances of supervisorÆs extensions 2. Business main numbers can be bridged on multiple phones & answered by group of users 3. Work at more than one location in a huge campus like University, Hospital etc. 5. Overview of Operation This proposal uses the following components to enable this feature: Anil Kumar Expires August 2004 4 Internet-Draft Bridged Line Appearance 2/18/2004 - SIP Registrar - SIP Forking Proxy - SIP State Agent (SA) +----------------------------+ +----+ | | | | | State Agent | | UA | | | | | +----------------------------+ +----+ | | | |1)SUBSCRIBE A A A 4)NOTIFY 6)INVITE | | | | |(Event:reg) | | | (registration bridged1@example|.com | | | V | | | events) V | | | +--------------------+ +----------+7)Query+--------+ | | | | (example.com) | | |<===== | | | | | | |3) Store| Location | | Proxy | | | | | Registrar |=======>| Service | | | | | | | | | |=====> | | | | | +--------------------+ +----------+8)Resp +--------+ | | | A A A | | | | | | | | | 2) REGISTER | | | | | | | | | | | | | | | +----+ +----+ +----+ bridged1 | | | | | | | | | | | | | | | | | | |UA1 | |UA2 | |UA3 | | | | | | | | | | | | | | | | | | | +----+ +----+ +----+ | | | | | | A A A A A A | | | | | | | | | | | | | | | | | +----+ | | | | +-----------------------------+ | | | | | | +---+-----------------------------------+ | | | +----+-----+--------------------------------------+ | | | | 9) INVITE | +--------------+ | bridged1@example.com | | +----------------------+ 5) SUBSCRIBE (Event:dialog) 1. The State Agent SUBSCRIBES to the registration event package as outlined in [5] for users belonging to a BLA group. Thus, it has knowledge of all users registered to a BLA group at any point of time. 2. User Agents UA1, UA2 & UA3 belong to a BLA group and REGISTER for the same address-of-record (bridged1@example.com). 3. Each registration is recorded. 4. The registrar notifies the State Agent of successful registration at each UA. 5. The State Agent SUBSCRIBEs to User Agents for the state of all Dialogs as defined in [4]. Anil Kumar Expires August 2004 5 Internet-Draft Bridged Line Appearance 2/18/2004 All User Agents that belong to the BLA group MUST support the dialog state package as outlined in [4] to NOTIFY other User Agents of the dialog-state. Further, they SHOULD understand and support the ôslaö event parameter outlined in this draft. 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). 6. The User Agents SUBSCRIBE to State Agent for the state of all Dialogs as defined in [4]. 7. The User Agents act as the notifier for the dialog state events as defined in [4]. Forking Proxy forks INVITE. 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 & NOTIFY dialog state events, but in a large group the User Agents have to manage a larger number of SUBSCRIPTIONS & NOTIFICATIONS. The State Agent helps in managing large groups better. Further, the State User Agent MAY filter dialog state events & 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 UA's in the BLA group. 6 Example Message Flows 6.1 Subscription Bob and Carol have bridged Line appearances for Alice. Bob and Carol REGISTER for AliceÆs AOR using contacts sip:alicebla@bob.example.com and sip:alicebla@carol.example.com respectively. Alice REGISTERÆs with contact sip:alice@alice.example.com. The State Agent subscribes to dialog states of the DN at the UAÆs for Alice, Bob and Carol. Message exchange between the State Agent, Alice, Bob and Carol are as below. The call flow examples below do not show challenging of subscriptions or Notifications. We chose to use unique contact user parts, when the event agent SUBSCRIBES to various devices for clarity of the call flows. There are no other significant meanings that should be implicitly assumed beyond the same. An Event Agent implementation could choose the same contact user parts for all of its subscriptions. It should be noted that all subscriptions MUST be authorized before the same is accepted for security purposes. Anil Kumar Expires August 2004 6 Internet-Draft Bridged Line Appearance 2/18/2004 Alice Bob Carol State Agent | | | | | | | | |<== State Agent Notified of REGISTER from | | Alice, Bob and Carol ==> | | | | | | | | | | | | SUBSCRIBE(1)| |<-------------+--------------+---------------| |200 OK (SUBSCRIBE)(2) | | |--------------+--------------+-------------->| | NOTIFY(Full dialog state)(3)| | |--------------+--------------+-------------->| | | 200 OK(NOTIFY)(4)| |<-------------+--------------+---------------| | | | | |<===== Alice SUBSCRIBES to State Agent =====>| | | | | |SUBSCRIBE (13)| | | |--------------+--------------+-------------->| | | 200 OK(SUBS)(14) | |<-------------+--------------+---------------| | |NOTIFY (full dialog state)(15)| |<-------------+--------------+---------------| |200 OK (NOTIFY) (16) | | |--------------+--------------+-------------->| | | | | | <==== BobÆs SUBSCRIBE Exchange ====> | | | | | | | | | | | | SUBSCRIBE(5)| | |<-------------+---------------| | |200 OK (SUBSCRIBE) (6) | | |--------------+-------------->| | |NOTIFY (Full dialog state)(7) | | |--------------+-------------->| | | 200 OK(NOTIFY)(8)| | |<-------------+---------------| | | | | |<===== BOB SUBSCRIBES to State Agent =====> | | | | | | |SUBSCRIBE (17)| | | |--------------+-------------->| | | 200 OK(SUBS)(18) | | |<-------------+---------------| | | NOTIFY (full dialog state)(19) | |<-------------+---------------| | |200 OK (NOTIFY) (20) | | |--------------+-------------->| | | | | | | | | | <==== Carols SUBSCRIBE Exchange ====> | | | | | | | | | Anil Kumar Expires August 2004 7 Internet-Draft Bridged Line Appearance 2/18/2004 | | | SUBSCRIBE(9)| | | |<--------------| | | 200 OK (SUB)(10)| | | |-------------->| | | |NOTIFY (11) | | | |-------------->| | | 200 OK(NOTIFY)(12)| | | |<--------------| | | | | |<===== Carol SUBSCRIBES to State Agent ====> | | | | | | | | SUBSCRIBE (21)| | | |-------------->| | | 200 OK(SUBS)(22)| | | |<--------------| | | |NOTIFY (23) | | | |<--------------| | | 200 OK(NOTIFY)(24)| | | |-------------->| 1. Subscriber (State Agent) -> Notifier (Alice's phone) SUBSCRIBE sip:alice@alice.example.com SIP/2.0 From: ;tag=1307882389683999 To: Call-ID: 1-660699082@stateagent.example.com CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1583396174692840 Event: dialog;sla;include-session-description Expires: 3600 Contact: Content-Length: 0 2. Notifier (Alice's phone) -> Subscriber (State Agent) SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1583396174692840 To: ;tag=1b65dc71 From: ;tag=1307882389683999 CSeq: 2 SUBSCRIBE Call-ID: 1-660699082@stateagent.example.com Contact: Expires: 3600 Event: dialog;sla;include-session-description Content-Length: 0 3. Notifier (Alice's phone) -> Subscriber (State Agent) NOTIFY sip:StateAgntAlice@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 To: ;tag=1307882389683999 From: ;tag=1b65dc71 Anil Kumar Expires August 2004 8 Internet-Draft Bridged Line Appearance 2/18/2004 Call-ID: 1-660699082@stateagent.example.com CSeq: 1 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 161 4. Subscriber (State Agent) -> Notifier (Alice's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 1 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 5. Subscriber (State Agent) -> Notifier (Bob's phone) SUBSCRIBE sip:alicebla@bob.example.com SIP/2.0 From: ;tag=1934233137712337 To: Call-ID: 2-1257492286@stateagent.example.com CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk953383972713521 Event: dialog;sla;include-session-description Expires: 3600 Contact: Content-Length: 0 6. Notifier (Bobs's phone) -> Subscriber (State Agent) SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk953383972713521 To: ;tag=7698e8ef From: ;tag=1934233137712337 CSeq: 2 SUBSCRIBE Call-ID: 2-1257492286@stateagent.example.com Contact: Expires: 3600 Event: dialog;sla;include-session-description Anil Kumar Expires August 2004 9 Internet-Draft Bridged Line Appearance 2/18/2004 Content-Length: 0 7. Notifier (Bob's phone) -> Subscriber (State Agent) NOTIFY sip:StateAgntBob@stateagent.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK5717dbd8 To: ;tag=1934233137712337 From: ;tag=7698e8ef Call-ID: 2-1257492286@stateagent.example.com CSeq: 1 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 161 8. Subscriber (State Agent) -> Notifier (Bob's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK5717dbd8 CSeq: 1 NOTIFY Call-ID: 2-1257492286@stateagent.example.com From: ;tag=7698e8ef To: ;tag=1934233137712337 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 9. Subscriber (State Agent) -> Notifier (Carol's phone) SUBSCRIBE sip:alicebla@carol.example.com SIP/2.0 From: ;tag=1307882389683999 To: Call-ID: 1-660699082@stateagent.example.com CSeq: 2 SUBSCRIBE Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1583396174692840 Event: dialog;sla;include-session-description Expires: 3600 Contact: Content-Length: 0 10. Notifier (Carol's phone) -> Subscriber (State Agent) SIP/2.0 200 OK Anil Kumar Expires August 2004 10 Internet-Draft Bridged Line Appearance 2/18/2004 Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1583396174692840 To: ;tag=1b65dc71 From: ;tag=1307882389683999 CSeq: 2 SUBSCRIBE Call-ID: 1-660699082@stateagent.example.com Contact: Expires: 3600 Event: dialog;sla;include-session-description Content-Length: 0 11. Notifier (Carol's phone) -> Subscriber (State Agent) NOTIFY sip:StateAgntCarol@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 To: ;tag=1307882389683999 From: ;tag=1b65dc71 Call-ID: 1-660699082@stateagent.example.com CSeq: 1 NOTIFY Contact: Event: dialog;sla; include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 161 12. Subscriber (State Agent) -> Notifier (Carol's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 1 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 13. Notifier (Alice's phone) -> Subscriber (State Agent) SUBSCRIBE sip:StateAgntAlice@stateagent.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK4ca30b4f To: From: ;tag=33ff9006 Call-ID: 0008101f-0001bd50-000000ab@example.com CSeq: 1 SUBSCRIBE Anil Kumar Expires August 2004 11 Internet-Draft Bridged Line Appearance 2/18/2004 Contact: Max-Forwards: 70 Expires: 3600 Event: dialog;sla; include-session-description Content-Length: 0 14. Subscriber (State Agent) -> Notifier (Alice's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK4ca30b4f CSeq: 1 SUBSCRIBE Call-ID: 0008101f-0001bd50-000000ab@example.com From: ;tag=33ff9006 To:;tag=891300607993 084 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 15. Subscriber (State Agent) -> Notifier (Alice's phone) Single NOTIFY is sent as no calls at DN for Alice NOTIFY sip:alice@alice.example.com SIP/2.0 From:;tag=8913006079 93084 To:;tag=33ff9006 Call-ID: 0008101f-0001bd50-000000ab@example.com CSeq: 2 NOTIFY Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk6299151979913 Max-Forwards: 70 Subscription-State: active Content-Type: application/dialog-info+xml Event: dialog;sla; include-session-description Contact: Content-Length: 159 16. Subscriber (State Agent) -> Notifier (Alice's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk6299151979913 To: ;tag=33ff9006 From:;tag=891300607993084 CSeq: 2 NOTIFY Call-ID: 0008101f-0001bd50-000000ab@example.com Anil Kumar Expires August 2004 12 Internet-Draft Bridged Line Appearance 2/18/2004 Event: dialog;sla; include-session-description Content-Length: 0 17. Notifier (Bob's phone) -> Subscriber (State Agent) SUBSCRIBE sip:StateAgntBob@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK2a258f0b To: From: ;tag=38f4ee0c Call-ID: 0008101f-00026930-000000ac@example.com CSeq: 1 SUBSCRIBE Contact: Max-Forwards: 70 Expires: 3600 Event: dialog;sla; include-session-description Content-Length: 0 18. Subscriber (State Agent) -> Notifier (Bob's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK2a258f0b CSeq: 1 SUBSCRIBE Call-ID: 0008101f-00026930-000000ac@example.com From: ;tag=38f4ee0c To:;tag=76225508648778 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 19. Subscriber (State Agent) -> Notifier (Bob's phone) A NOTIFY is sent as no calls at DN for Alice. NOTIFY sip:alicebla@bob.example.com SIP/2.0 From:;tag=76225508648778 To: ;tag=38f4ee0c Call-ID: 0008101f-00026930-000000ac@example.com CSeq: 2 NOTIFY Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1864726366166251 Max-Forwards: 70 Subscription-State: active Content-Type: application/dialog-info+xml Event: dialog;sla; include-session-description Contact: Content-Length: 159 Anil Kumar Expires August 2004 13 Internet-Draft Bridged Line Appearance 2/18/2004 20. Subscriber (State Agent) -> Notifier (Bob's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 1 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: "State_Agent" ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 21. Notifier (Carol's phone) -> Subscriber (State Agent) SUBSCRIBE sip:StateAgntCarol@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK2a258f0b To: From: ;tag=38f4ee0c Call-ID: 0008101f-00026930-000000ac@example.com CSeq: 1 SUBSCRIBE Contact: Max-Forwards: 70 Expires: 3600 Event: dialog;sla; include-session-description Content-Length: 0 22. Subscriber (State Agent) -> Notifier (Carol's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK2a258f0b CSeq: 1 SUBSCRIBE Call-ID: 0008101f-00026930-000000ac@example.com From: ;tag=38f4ee0c To:;tag=762255086487 78 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 23. Subscriber (State Agent) -> Notifier (Carol's phone) NOTIFY sip:alicebla@carol.example.com SIP/2.0 From:;tag=76225508648778 To: ;tag=38f4ee0c Call-ID: 0008101f-00026930-000000ac@example.com CSeq: 2 NOTIFY Via: SIP/2.0/UDP stateagent.example.com:5060;branch=z9hG4bk1864726366166251 Max-Forwards: 70 Subscription-State: active Content-Type: application/dialog-info+xml Anil Kumar Expires August 2004 14 Internet-Draft Bridged Line Appearance 2/18/2004 Event: dialog;sla; include-session-description Contact: Content-Length: 159 24. Subscriber (State Agent) -> Notifier (Carol's phone) SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 1 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: 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 NOTIFY with event ô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 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 [4], but this MUST be implemented to resolve glare issues. Further, the dialog state draft 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 Event Agent as a single dialog payload in the NOTIFY. Anil Kumar Expires August 2004 15 Internet-Draft Bridged Line Appearance 2/18/2004 User X Proxy Alice Bob Carol Event Agent | | | | | | | | |NOTIFY/200 OK | | | | |(trying) | | | | | |-----------+-----------+------------>| | | | |NOTIFY/200 OK | | | | |(trying) | | | | | |<----------+-------------| | | | | |NOTIFY/200 OK| | | | | |(trying) | | | | | |<------------| | |INVITE | | | | | |<--------| | | | | |100 TRYING | | | | INVITE |-------->| | | | |<-------| | | | | |180 RINGING | | | | |------->| | | | | | |180 RINGING | | | | |-------->| | | | | | | | | | |200 OK | | | | | |------->| | | | | | |200 OK | | | | | |-------->| | | | | | ACK |NOTIFY/200 OK | | | ACK |<--------|(confirmed)| | | |<-------| |-----------+-----------+------------>| | | | |NOTIFY/200 OK | | | | |(confirmed)| | | | | |<----------+-------------| | | | | |NOTIFY/200 OK| | | | | |(confirmed) | | | | | |<------------| |<==== Time Passes. Alice Places call on hold ====>| | | | | | | |INVITE/200/ACK (Hold) | | | |<-------+---------| | | | | | |NOTIFY/200 OK | | | | |(confirmed,local-session-description | | | | SDP=a:sendonly | | | | | | | | | | +------------+----------+------------>| | | | |NOTIFY/200 OK | | | | |(confirmed) | | | | |<---------+-------------| | | | | NOTIFY/200 OK | | | | | (confirmed) | | | | | |<------------| | | | | | | |<==== Time Passes. Bob decides to answer held call ====>| | | | | | | Anil Kumar Expires August 2004 16 Internet-Draft Bridged Line Appearance 2/18/2004 | |INVITE Replaces:Cid=1,from-tag=1000,totag=2000)| | |<--------+------------| | | |INVITE(Cid = 2) | | | | |<-------| | | | | | | | | | | | 200 OK | | 200 OK | | | |------->|---------+----------->|NOTIFY/200 OK | | | | |(confirmed) | | | | |----------+------------>| | | |NOTIFY/200 OK | | | | |(confirmed) | | | | | |<-----------+----------+-------------| | | | | NOTIFY/200 OK | | | | | |(confirmed) | |ACK(Cid 2) | | |<------------| |<-------+---------+------------| | | | BYE/200 OK(Cid 1)| | | | |--------+-------->| NOTIFY/200 OK | | | | |(terminated)| | | | | |------------+----------+------------>| | | | |NOTIFY /200 OK | | | | |(terminated) | | | | |<---------+-------------|_ | | | | NOTIFY/200 OK | | | | | |(terminated) | | | | | |<------------| | | | | | | |<==== Time Passes. Bob Hangs up ====>| |BYE/200 OK (Cid 2)| | | | |<-------+---------+------------| | | | | | |NOTIFY/200 OK | | | | |(terminated) | | | | +----------+------------>| | | | | | | | | |NOTIFY/200 OK | | | | |(terminated)| | | | | |<-----------+----------+-------------| | | | | NOTIFY/200 OK | | | | | |(terminated) | | | | | |<------------| | | | | | | 1. Before sending the INVITE, NOTIFY prior to going off hook: ------------------------------- Notifier -> Subscriber NOTIFY sip:StateAgntAlice@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 To: ;tag=1307882389683999 From: ;tag=1b65dc71 Call-ID: 1-660699082@stateagent.example.com Anil Kumar Expires August 2004 17 Internet-Draft Bridged Line Appearance 2/18/2004 CSeq: 2 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 243 trying 2. The Event Agent NOTIFYÆs Bob and Carol of the same. It does so by forwarding the NOTIFY payload provided by Alice after appropriately changing the dialog ôidö field in the XML payload to a unique value towards each of the entities it is forwarding to (Bob and Carol in this example). 3. Alice gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 2 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 4. Alice sends out INVITE. 5. Alice receives a 100 Trying, 180 ringing (could be from multiple branches). Alice suppresses sending out any NOTIFY's until the dialog transitions to a confirmed state. 6. Alice receives a 200 OK for the INVITE. Alice dialog moves to confirmed state (It should be noted here that, should Alice get a non 200 OK final response, or Alice were to hang up, Alice should send a NOTIFY ôterminatedö event to the Event Agent for this dialog ôidö to close out the FSM at the Event Agent and thus allowing other BLA members in the group to use this line). 7. Alice sends out NOTIFY to the Event Agent. The XML payload is as below: (Sending SDP as part of dialog state info is not mandatory, shown below only for completeness. It should also be noted here that it is possible that Alice receive multiple 200 OKÆs from various user Anil Kumar Expires August 2004 18 Internet-Draft Bridged Line Appearance 2/18/2004 agents. The only requirement as regards this draft is that Alice sends out the dialog identifiers of dialog that was finally accepted by Alice). NOTIFY sip:StateAgntAlice@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 To: ;tag=1307882389683999 From: ;tag=1b65dc71 Call-ID: 1-660699082@stateagent.example.com CSeq: 3 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 818 confirmed v=0 o=- 264257771 264257771 IN IP4 example.com s= c=IN IP4 example.com t=0 0 m=audio 1060 RTP/AVP 0 8 96 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-11 sip:5301@stateagent.example.com 8. Alice gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 3 NOTIFY Call-ID: 1-660699082@stateagent.example.com Anil Kumar Expires August 2004 19 Internet-Draft Bridged Line Appearance 2/18/2004 From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 9. Event Agent NOTIFYÆs Bob & Carol of the same. 10. Alice places call on HOLD. Receives a SUCCESS response for HOLD. (It should be noted that there are call flows like transfers and conference where the UA might place a call on hold temporarily as a part of such feature invokes. Sending a NOTIFY for HOLD in such could result in another user picking up a call and thus disallowing the end user from performing the actual intended feature. Should sending NOTIFY's be suppressed in these scenarios?) 11. Alice sends out a NOTIFY. XML Payload: NOTIFY sip:StateAgntAlice@stateagent.example.com SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 To: ;tag=1307882389683999 From: ;tag=1b65dc71 Call-ID: 1-660699082@stateagent.example.com CSeq: 4 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 830 confirmed v=0 o=- 264257771 264257772 IN IP4 example.com s= c=IN IP4 example.com t=0 0 a=sendonly m=audio 1060 RTP/AVP 0 8 96 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-11 Anil Kumar Expires August 2004 20 Internet-Draft Bridged Line Appearance 2/18/2004 sip:5301@stateagent.example.com 12. Alice gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 4 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 13. Event Agent NOTIFYÆs Bob & Carol. 14. Bob attempts to "pick" this dialog. 15. Bob sends out a new INVITE with Replaces towards the far end. 16. Gets a 200 OK for the INVITE, sends an ACK. 17. Bob sends a NOTIFY with following payload: NOTIFY sip:StateAgntBob@stateagent.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK5717dbd8 To: ;tag=1934233137712337 From: ;tag=7698e8ef Call-ID: 2-1257492286@stateagent.example.com CSeq: 2 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 857 confirmed Anil Kumar Expires August 2004 21 Internet-Draft Bridged Line Appearance 2/18/2004 v=0 o=- 264266143 264266143 IN IP4 38.187.114.10 s= c=IN IP4 example.com t=0 0 m=audio 1062 RTP/AVP 0 8 96 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-11 sip:5301@stateagent.example.com:5075 terminated 22. Alice gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK12a034b1 CSeq: 5 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 23. Event Agent Forwards NOTIFY to Bob & Carol using the dialog identifiers established during subscriptions. 24. Bob sends a BYE to the far end. Gets a 200 OK for the same. 25. Bob sends a NOTIFY to that effect. NOTIFY sip:StateAgntBob@stateagent.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK5717dbd8 To: ;tag=1934233137712337 From: ;tag=7698e8ef Call-ID: 2-1257492286@stateagent.example.com CSeq: 3 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 243 terminated Anil Kumar Expires August 2004 23 Internet-Draft Bridged Line Appearance 2/18/2004 26. Bob gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK5717dbd8 CSeq: 3 NOTIFY Call-ID: 2-1257492286@stateagent.example.com From: ;tag=7698e8ef To: ;tag=1934233137712337 Allow: NOTIFY,SUBSCRIBE Contact: Content-Length: 0 27. Event Agent Forwards NOTIFY to Alice & Carol. 6.3 Call Offered to a BLA Group In the call flow below Bob and Carol have bridged appearances of Alice. ôUser Xö places a call to Alice. All NOTIFYÆs in the call flow below carry ôdialogö events and only dialog states are mentioned for simplicity. User X Proxy Alice Bob Carol Event Agent | | | | | | |(CID 1,frmtag=1000) | | | | | INVITE | | | | | |-------->| | | | | |<--------| | | | | |100 TRYING INVITE | | | | | |----------->| | | | | | | INVITE | | | | |------------+----------->| | | | | | | INVITE | | | |------------+------------+--------->| | | | | | | | | |180 RINGING | | | | | |<-----------| | | | |<--------| | | | | |180 RINGING | | | | | | |180 RINGING | | | | |<-----------+------------| | | |<--------| | | | | |180 RINGING |180 RINGING | | | | |<-----------+------------+----------| | |<--------| | | | | |180 RINGING | | | | | | | | | | | | 200 OK | | | | | 200 OK |<-----------| | | | |<--------| | | | | Anil Kumar Expires August 2004 24 Internet-Draft Bridged Line Appearance 2/18/2004 | |CANCEL/487/ACK | | | | |------------+----------->|CANCEL/487/ACK | | ACK |------------+------------+--------->| | |-------->|ACK | | | | | |----------->| | | | | | | | | | | | |NOTIFY/200 OK | | | | |(confirmed) | | | | | |(CID 1,frmtag=1000, | | | | | totag=2000)| | | | | +------------+----------+----------->| | | | |NOTIFY/200 OK | | | | |(confirmed) | | | | |<---------+------------| | | | | NOTIFY/200 OK| | | | | (confirmed) | | | | | |<-----------| |<==== Message flows same as previous from here on ===>| | | | | | | | | | | | | 1. Call Offered to Alice, Bob and Carol in the BLA group. 2. All of them suppress sending out NOTIFY's for the "Trying". 3. Alice answers the call. Call is established. 4. Alice sends out a NOTIFY with dialog state Payload as: NOTIFY sip:StateAgntAlice@stateagent.example.com:5060;SIP/2.0 Via: SIP/2.0/UDP example.com;branch=z9hG4bK4a8c7531 To: "State_Agent" ;tag=1307882389683999 From: ;tag=1b65dc71 Call-ID: 1-660699082@stateagent.example.com CSeq: 6 NOTIFY Contact: Event: dialog;sla;include-session-description Subscription-State: active Max-Forwards: 70 Content-Type: application/dialog-info+xml Content-Length: 779 confirmed Anil Kumar Expires August 2004 25 Internet-Draft Bridged Line Appearance 2/18/2004 v=0 o=- 264858535 264858535 IN IP4 example.com s= c=IN IP4 example.com t=0 0 a=sendrecv m=audio 1068 RTP/AVP 0 a=rtpmap:0 PCMU/8000 sip:4083695301@example.com 5. Alice gets a 200 OK for the NOTIFY. SIP/2.0 200 OK Via: SIP/2.0/UDP example.com;branch=z9hG4bK4a8c7531 CSeq: 6 NOTIFY Call-ID: 1-660699082@stateagent.example.com From: ;tag=1b65dc71 To: "State_Agent" ;tag=1307882389683999 Allow: NOTIFY,SUBSCRIBE Contact: 6. Event Agent Forwards NOTIFY to Bob & Carol. 7. Alice places call on Hold. (Message flows will be same as those specified from step 10 in previous call origination scenario) 7. New Event Package Parameter The dialog state package defined in [4] defines the set of messages that MAY be provided by a UA to publish state information of dialogs. 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. Further, in order to address the problem of off-hook glare (no two users can simultaneously use a BLA appearance), the solution proposed in the draft (having the UA send a NOTIFY of trying, wait for a 200 OK response before it actually sends out the INVITE) is a deviation from that mentioned in [4]. In order to indicate this preference, this draft proposes a new Event parameter for the ôdialogö package called ôslaö. UAÆs that understand this parameter will only provide dialog state information as detailed in this draft. 8. State Recovery A critical aspect for reliable operation of this feature is the ability for all UA's in the BLA group to recover from network failures caused at a single UA. For example, one of the user agents Anil Kumar Expires August 2004 26 Internet-Draft Bridged Line Appearance 2/18/2004 in the BLA group answered an incoming call, notifies 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 UA's in the BLA group gets notification of this change in dialog state and their BLA appearance could stay out of sync for a long time; depending on when the network is restored, or when the Event Agent attempts to refresh its dialog-state subscription with this UA. To recover from such a failure, the Event Agent MAY SUBSCRIBE with a shorter expiration (expiration interval no 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 UA's that notified it of this information. 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 [4], Multi-party application framework [6], and Event Notification [3], 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. Anil Kumar Expires August 2004 27 Internet-Draft Bridged Line Appearance 2/18/2004 References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol," Request for Comments 3261, Internet Engineering Task Force, June 2002. [3] A.B. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification," Request for Comments 3265, Internet Engineering Task Force, June 2002 [4] J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Dialog State", Internet Draft, Internet Engineering Task Force, April 2004. [5] J. Rosenberg, "A Session Initiation Protocol (SIP) Event Package for Registrations", Internet Draft, Internet Engineering Task Force, April 2003. [6] Mahy, Campbell, Johnston, et al., "A Multi-party Application Framework for SIP," Internet Draft, Internet Engineering Task Force, April 2004. Work in progress. [7] J. Rosenberg, H.Schulzrinne, "An Offer/Answer Model with Session Description Protocol," Request for Comments 3264, Internet Engineering Task Force, June 2002. [8] R. Mahy, B. Biggs, R. Dean, "The Session Initiation Protocol (SIP) Replaces header", Internet Draft, Internet Engineering Task Force, December 2003. Acknowledgements The authors would like to thank Kent Fritz, John Weald, Sunil Veluvali and Mohsen Soroush Nejad, Sylantro Systems, Graeme Dollar Yahoo Inc, Rob Harder and Hong Chen Polycom Inc, John Elwell, J D Smith Siemens, Steve Towlsen, Michael Procter Citel Technologies for their numerous corrections, comments and suggestions during authoring of this draft. Author's Addresses Anil Kumar Email: anil.kumar@sylantro.com Anil Kumar Expires August 2004 28 Internet-Draft Bridged Line Appearance 2/18/2004 sip:anil.kumar@sip.sylantro.com (408) 626 2332 Sylantro Systems Corp. 910 E Hamilton Ave, Campbell, CA 95008 Venkatesh Venkataramanan Email: venkatar@sylantro.com sip:venkatar@sip.sylantro.com (408) 626 3025 Sylantro Systems Corp. 910 E Hamilton Ave, Campbell, CA 95008 Paul Pepper Email: paul.pepper@citel.com Citel Technologies 1420 Fifth Avenue, nd 22 Floor, Seattle WA 98101 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Anil Kumar Expires August 2004 29