SIMPLE S. Sinha Internet-Draft Cisco Systems, Inc. Intended status: BCP A. Houri Expires: April 18, 2009 IBM October 15, 2008 Intradomain Presence and IM Federation Call Flow Examples draft-sinha-simple-intradomain-federation-callflow-00 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2009. Abstract This document gives call flow examples and relevant message details at the interface of two federating server that have implemented intradomain federation using the model described in Models for Intra- Domain Presence and Instant Messaging (IM) Federation, [I-D.ietf-simple-intradomain-federation]. Sinha & Houri Expires April 18, 2009 [Page 1] Internet-Draft Intradomain Call Flows October 2008 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. General Assumption for message Flows . . . . . . . . . . . . . 3 3.1. Partitioned Federation . . . . . . . . . . . . . . . . . . 4 3.2. Unioned Federation . . . . . . . . . . . . . . . . . . . . 5 3.3. Routing Assumptions . . . . . . . . . . . . . . . . . . . 6 4. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Partitioned Call flows . . . . . . . . . . . . . . . . . . 7 4.1.1. Alice adds Bob to her Buddy List . . . . . . . . . . . 8 4.1.1.1. Message Details . . . . . . . . . . . . . . . . . 9 4.1.2. Bob changes his Presence state to Away on IM client . 11 4.1.2.1. Message Details . . . . . . . . . . . . . . . . . 11 4.1.3. Bob sets his state to Do Not Disturb . . . . . . . . . 13 4.1.3.1. Message Details . . . . . . . . . . . . . . . . . 13 4.1.4. Alice initiates Instant Messaging (IM) with Bob . . . 15 4.1.4.1. Message Details . . . . . . . . . . . . . . . . . 16 4.2. Unioned Call Flows . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Hierarchical Model . . . . . . . . . . . . . . . . . . 18 4.2.1.1. Alice logs into her client . . . . . . . . . . . . 19 4.2.1.2. Bob adds Alice to her Buddy list . . . . . . . . . 24 4.2.1.3. Alice dials in a meeting from phone . . . . . . . 26 4.2.1.4. Bob sends an Instant Message to Alice . . . . . . 30 4.2.2. Peer Model . . . . . . . . . . . . . . . . . . . . . . 38 4.2.2.1. Bob adds Alice to her Buddy list . . . . . . . . . 38 4.2.2.2. Alice sets her status to Do Not Disturb(DND) . . . 43 4.2.2.3. Bob sends an Instant Message to Alice . . . . . . 46 5. Security Considerations . . . . . . . . . . . . . . . . . . . 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 8. Informative References . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . . . . 55 Sinha & Houri Expires April 18, 2009 [Page 2] Internet-Draft Intradomain Call Flows October 2008 1. Terminology 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 [RFC2119] 2. Introduction Models for Intra-Domain Presence and Instant Messaging (IM) Federation, [I-D.ietf-simple-intradomain-federation], explains the models for intra-domain federation between two or more presence servers from different vendors. This document captures flows of message exchange at the federation interface between the presence servers. It is the hope of the authors that this document will be useful for SIP implementers and designers, when Presence and IM federation is desired between servers from different vendors, in that it will improve interoperability between the servers. Call flows in this document are based on the two models described in Models for Intra-Domain Presence and Instant Messaging (IM) Federation 3. General Assumption for message Flows These call flows are based on the two models for Presence and IM federation described in [I-D.ietf-simple-intradomain-federation]. The models are: o Partitioned : users are divided between federating servers o Exclusive : User is served by more than presence server, but the user is using only one system at one time. If the user is using one system at a given time, and then if it starts using another system, without logging out from the other system, then the user is automatically logged out from the other system. o Union : in which a given user is served by more than one server. Call flows in this document do not cover Exclusive Federation model In partitioned case, server the user belongs to, has it's buddylist and is authoritative in determining presence composition for the user. In union case, since the user is served by more than one server and hence has client on more than one server and possibly can add buddies from either client and set allow,block and preferred lists from each client, keeping the buddylist and policy sync is key for union federation. For simplicity, the call flows in this document makes these assumptions: Sinha & Houri Expires April 18, 2009 [Page 3] Internet-Draft Intradomain Call Flows October 2008 o IM and Presence functionality is co-located in same federating server. o Buddylist database of the user is co-located with the federating presence and IM server. o For union case, there is no policy and buddylist synchronisation between servers is not covered in these call flows. As in any server to server communication, presence and IM messages are exchanged over a mutually authenticated TLS connection. There is no user authentication across the federation link. It is expected that originating server has authenticated the user and the identity of authenticated user is conveyed in P-Asserted-Id header in all dialog forming or non-dialog requests across the federated interface. All of the call flows show only the interactions between the federating servers and some relevant protocol flows within each network. User input and user presentation events which drive the interface messaging are shown as part of the flow. The flows also show, inline, key SIP header fields. When needed, the text following the flow example includes message fragment examples. This is typically needed for presence documents and IM content. Messages are identified in the Figures as F1, F2, etc. This references the message details in the table that follows the Figure. Actors and the devices that they use, are listed below for each federation model. The domain in these message flows is example.com 3.1. Partitioned Federation The prototypical example for partitioned federation is shown in Figure 1. An user Alice (alice@example.com), is using Presence server from vendor A. She wishes to communicate with Bob, who is using Presence server from a different vendor, vendor B. Alice's device is an IM client, and Bob has a deskphone and an IM client. Bob's deskphone does not have IM capability. Alice's buddylist is stored on Presence server A and the IM client running on her computer logs into server A to retrieve it's buddy information, subscribe for buddylist and self and Publishes it's status to server A. Presence server A does presence composition for Alice. Similarly Bob's buddylist is stored on server B and his devices, IM device and phone, Publish their status to presence server B, which aggregates the presence composition sends notification to it's client(s) and his watchers. Sinha & Houri Expires April 18, 2009 [Page 4] Internet-Draft Intradomain Call Flows October 2008 ................................................................... . . . ........................... .......................... . . . alice@example.com . . bob@example.com . . . . +------------+ SUB . . +------------+ . . . . | | Bob . . | | . . . . | Presence |------------------->| Presence | . . . . | Server | . . | Server | . . . . | (Vendor A) | . . | (Vendor B)| . . . . | |<-------------------| | . . . . | | NOTIFY . | | . . . . +------------+ . . +------------+ . . . . ^ | . . ^ . . . . SUB | | . . |PUBLISH . . . . Buddy | |NOTIFY . . | . . . . List | | . . | . . . . | | . . |---------------| . . . . +-------+ . . +-----+ +-----+ . . . . | | . . | | | | . . . . | | . . | | | | . . . . | | . . +-----+ +-----+ . . . . +-------+ . . . . . . . . . . . . Alice's . . Bob's Bob's . . . . PC . . PC phone . . . . . . . . . ........................... ........................... . . . ................................................................... Partitioned Federation 3.2. Unioned Federation The prototypical example for unioned federation is shown in Figure 2. In this model, user Alice (alice@example.com) has a PC client in Vendor X's network and a mobile client in other Vendor, Vendor Y's network. She communicates with Bob, having a PC Client and DeskPhone in Vendor Y's network. Alice's buddylist is stored on server A and it's IM device Publishes it's status to server A. Her phone is from vendor B and publishes it's status to server B. While composing Alice's presence, server A sends a backend subscription to server B to gather phone status and combines it with IM status to compose her overall presence. This is Sinha & Houri Expires April 18, 2009 [Page 5] Internet-Draft Intradomain Call Flows October 2008 one of the options in composing Alice's overall presence. Other options are that server B routes the Publish from phone to server A. Call flows assume that Bob's phone is a mobile device having IM capability, in addition to voice capability. ................................................................... . . . ........................... .......................... . . . . . . . . . +------------+ SUB . . +------------+ . . . . | | . . | | . . . . | Presence |------------------->| Presence | . . . . | Server | . . | Server | . . . . | (Vendor A) | . . | (Vendor B) | . . . . | |<-------------------| | . . . . | | NOTIFY . | | . . . . +------------+ . . +------------+ . . . . ^ | . . ^ ^ ^ . . . . SUB | | . . | | | . . . . Buddy | |NOTIFY . . | | | . . . . List | | . . | PUBLISH | . . . . | | . . | | | . . . . | V . . | | | . . . . +-------+ . . +-----+ | +-----+ . . . . | | . . |Bob's| | |Bob's| . . . . | | . . | PC | | |phone| . . . . | | . . +-----+ | +-----+ . . . . +-------+ . . | . . . . . . +-----+ . . . . Alice's . . |Alice| . . . . PC . . |phone| . . . . . . +-----+ . . . ........................... ........................... . . . ................................................................... Unioned Federation 3.3. Routing Assumptions The example call flows in this document are for Server to Server federation. Models for Intra-Domain Presence and Instant Messaging (IM) Federation, [I-D.ietf-simple-intradomain-federation] mentions six routing options: Sinha & Houri Expires April 18, 2009 [Page 6] Internet-Draft Intradomain Call Flows October 2008 o Centralized Database o Routing Proxy o Subdomaining o Peer-to-Peer o Forking o Provisioned Routing These call flows assume Centralized Database model for Routing. So clients route the Presence & IM requests to the server they are connected to. The servers either sync enduser data from the centralized database server or consult the database server to find out which server is the destination user responsible for and then it routes the request to that server, which then routes it to the client. These call flows and the associated Message Details assume these addresses: o Alice's computer IM client: alicepc.example.com o Alice's phone: 64.102.224.56 o Bob's computer IM client: bobpc.example.com o Bob's phone: 64.102.193.98 o Presence Server A: 1.2.3.4 o Presence Server B: 10.10.10.4 4. Call Flows 4.1. Partitioned Call flows Sinha & Houri Expires April 18, 2009 [Page 7] Internet-Draft Intradomain Call Flows October 2008 4.1.1. Alice adds Bob to her Buddy List Alice (PC) Server A Server B | | | | | | | | | | | | +-------+ | | |Alice | | | |adds | | | |to BL | | | +-------+ | | | | | | F1 SUBSCRIBE | | |------------------>| | | | F2 SUBSCRIBE | | F3 200 OK |----------------------->| |<------------------| | | | +--------+ | | |Bob's | | | |Policy | | | |approves| | | +--------+ | | | | | F4 200 OK | | |<----------------------| | | | | | | | | F5 NOTIFY | | |<----------------------| | F6 NOTIFY | | |<------------------| | | | | | | | | F7 200 OK | | |------------------>| | | | F8 200 OK | | |---------------------->| | | | Alice Adds Bob to Buddy List Alice adds Bob to her Buddy list. This causes a presence Subscribe request to be sent across the federation interface. Bob's presence Sinha & Houri Expires April 18, 2009 [Page 8] Internet-Draft Intradomain Call Flows October 2008 server queries Bob's policy to make sure that Alice is in the Allowed list. If it is in the allowed list, it accepts the subscription by sending a 200 OK response to the originating server. Then it sends a NOTIFY with the presence document in pidf format with rich presence information. 4.1.1.1. Message Details F1 SUBSCRIBE Alice PC -> Server A SUBSCRIBE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP serverA.example.com:5060;branch=z9hG4bKa From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxk3uxtm8tn@example.com CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 F2 SUBSCRIBE Server A -> Server B SUBSCRIBE sip:bob@10.10.10.4 SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKa ... From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxk3uxtm8tn@example.com CSeq: 1 SUBSCRIBE Record-Route: Contact: P-Asserted-Identity: Content-Length: 0 F5 NOTIFY Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 9] Internet-Draft Intradomain Call Flows October 2008 NOTIFY sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn864968gds7 To: ;tag=a73kszlfl From: ;tag=gred45 Call-ID: 1j9FpLxkxtm8tn@example.com CSeq: 1 NOTIFY Route: Contact: P-Asserted-Identity: Content-Length:567 I am Active sip:bob@example.com true text/plain open open true sip:89991234@64.102.193.98 Sinha & Houri Expires April 18, 2009 [Page 10] Internet-Draft Intradomain Call Flows October 2008 4.1.2. Bob changes his Presence state to Away on IM client Alice(PC) Server A Server B Bob(PC) | | | | | | | | | | | | | | | +-------+ | | | |Bob | | | | |changes| | | | | his | | | | | state | | | | |to away| | | | +-------+ | | | | | | | F1 PUBLISH | | | |<--------------| | | | | | | | | | | | F2 200 OK | | | |-------------->| | | F3 NOTIFY | | | |<---------------| | | F4 NOTIFY | | | |<--------------| F5 200 OK | | | |--------------->| | | | | | | F6 200 OK | | | |-------------->| | | | | | | | | | | Bob changes his Presence State to Awaay Bob changes his state to Away and this causes a NOTIFY to be sent from Server B to Server A 4.1.2.1. Message Details F3 NOTIFY Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 11] Internet-Draft Intradomain Call Flows October 2008 NOTIFY sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn864968gds7 To: ;tag=a73kszlfl From: ;tag=gred45 Call-ID: 1j9FpLxkxtm8tn@example.com Route: CSeq: 2 NOTIFY Contact: P-Asserted-Identity: Content-Length:567 I am Away from my computer now sip:bob@example.com true text/plain open open true sip:89991234@64.102.193.98 Sinha & Houri Expires April 18, 2009 [Page 12] Internet-Draft Intradomain Call Flows October 2008 4.1.3. Bob sets his state to Do Not Disturb Alice(PC) Server A Server B Bob(PC) | | | | | | | | | | | | | | | +-------+ | | | |Bob | | | | |changes| | | | | his | | | | | state | | | | |to DND | | | | +-------+ | | | | | | | F1 PUBLISH | | | |<--------------| | | | | | | | | | | | F2 200 OK | | | |-------------->| | | F3 NOTIFY | | | |<---------------| | | F4 NOTIFY | | | |<--------------| F5 200 OK | | | |--------------->| | | | | | | F6 200 OK | | | |-------------->| | | | | | | | | | | Bob changes his State to Do Not Disturb Bob changes his state to Do Not Disturb (DND) and this causes a NOTIFY to be sent from Server B to Server A. Bob's presence server treats DND state to mean that devices are not available for communication. 4.1.3.1. Message Details F1 NOTIFY Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 13] Internet-Draft Intradomain Call Flows October 2008 NOTIFY sip:alice@1.2.3.4 SIP/2.0 Via: SIP/2.0/TCP serverB.example.com:5060;branch=z9hG4bKn8as3268gds7 To: ;tag=a73kszlfl From: ;tag=gred45 Call-ID: 1j9FpLxkxtm8tn@example.com CSeq: 3 NOTIFY Contact: P-Asserted-Identity: Content-Length:567 I am Away from my computer now sip:bob@example.com true text/plain closed closed true sip:89991234@64.102.193.98 Sinha & Houri Expires April 18, 2009 [Page 14] Internet-Draft Intradomain Call Flows October 2008 4.1.4. Alice initiates Instant Messaging (IM) with Bob In this call flow Alice initiates an IM session with Bob. Her IM client sends the Invite to it's presence server A which then routes it to server B. MSRP session in SDP of Invite has Alice's IM client's address. Server B routes the request to Bob's IM client. Bob's IM client responds with 200 OK with MSRP session of it's client address. Server B forwards 200 OK to Server A, which then sends it to Alice's IM client. MSRP session is then established between Alice & Bob's endpoints. Alice(PC) Server A Server B Bob (PC) | | | | | | | | | F1 INVITE | | | |----------->| | | | | F2 INVITE | | | |-------------------->| | | | +--------+ | | | | Bob's | | | | | Policy | | | | |approves| | | | +--------+ | | | | | | | | F3 INVITE | | | |------------->| | | | | | | | | | | | F4 200 OK | | | |<-------------| | | | | | | F5 200 OK | | | |<--------------------| | | F6 200 OK | | | |<-----------| | | | | | | | F7 ACK | | | |----------->| | | | | F8 ACK | | | |-------------------->| F9 ACK | | | |------------->| | | | | | | | | | | F10 (MSRP) SEND | | Sinha & Houri Expires April 18, 2009 [Page 15] Internet-Draft Intradomain Call Flows October 2008 |------------------------------------------------>| | | | | | | F11 (MSRP) 200 OK | | |<------------------------------------------------| | | | | | | F12 (MSRP) SEND | | |<------------------------------------------------| | | | | | | F13 (MSRP) 200 OK | | |------------------------------------------------>| . . . . . . . . |F14 (SIP)BYE| | | |----------->| | | | | F15 (SIP) BYE | | | |-------------------->| F16 (SIP) BYE| | | |------------->| | | | | | | | | | | |F17 200 OK | | | |<-------------| | | F18 200 OK | | | F19 200 OK|<--------------------| | |<-----------| | | Alice initiates IM with Bob 4.1.4.1. Message Details F1 INVITE Alice (PC) -> Server A Sinha & Houri Expires April 18, 2009 [Page 16] Internet-Draft Intradomain Call Flows October 2008 INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP alicepc.example.com:5060;branch=z9hG4bKn8as3bgterds7 From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp v=0 o=alice 28908457 2890844559 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:5555/iau39soe2843z;tcp F2 INVITE Server A -> Server B INVITE sip:bob@10.10.10.4 SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060; branch=z9hG4bKlkkdsj Via: SIP/2.0/TCP alicepc.example.com:5060;branch=z9hG4bKn8as3bgterds7 From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com CSeq: 1 INVITE Record-Route: Contact: P-Asserted-Identity: Content-Type: application/sdp v=0 o=alice 28908457 2890844559 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:5555/iau39soe2843z;tcp F5 200 OK Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 17] Internet-Draft Intradomain Call Flows October 2008 SIP/2.0 200 OK Via: SIP/2.0/TCP 1.2.3.4:5060; branch=z9hG4bKlkkdsj Via: SIP/2.0/TCP serverA.example.com:5060;branch=z9hG4bKn8as3bgterds7 From: ;tag=a73kszlfl To: ;tag=087js Call-ID: 1j9FpLxkxtm8tn@example.com CSeq: 1 INVITE Record-Route: Contact: Content-Type: application/sdp v=0 o=bob 2890844612 2890844616 IN IP4 bobpc.example.com s= - c=IN IP4 bobpc.example.com t= 0 0 m=message 8888 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:12763/kjhd37s2s20w2a;tcp F10 Alice (PC) -> Bob (PC) MSRP SEND MSRP gd3kswtf SEND To-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp From-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp Message-ID: 5551234tyu Byte-Range: 1-16/16 Content-Type: text/plain Are you there! -------gd3kswtf$ F11 Bob (PC) -> Alice (PC) MSRP gd3kswtf 200 OK To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp From-Path: msrp://bobpc.example.com:8888/9di4eae923wzd;tcp -------gd3kswtf$ 4.2. Unioned Call Flows 4.2.1. Hierarchical Model In hierarchical model, one server acts as the root and all presence subscriptions and IM requests for the target are always routed to it. In the case of presence, the root server has the final say on the structure of the presence document delivered to watchers. It Sinha & Houri Expires April 18, 2009 [Page 18] Internet-Draft Intradomain Call Flows October 2008 collects presence data from its child presence servers, through notification from backend subscriptions, and composes them into the final presence document. In the case of IM, the root applies IM policy on session initiating request and then passes the IM onto the children for delivery. It is assumed that it does not acts as a MSRP relay or B2BUA. The MSRP session is between the endpoint that initiates and the one that responds. In the call flows below, it is assumed that Server A is the root server. 4.2.1.1. Alice logs into her client This call flow is about Alice logging into her IM client. Her phone Publishes it's state to server B. In this call flow, server A, through directory lookup or some configuration, figures out that Alice also has a phone device on server B. Server A does backend subscription (BE) to server B to get the phone device presence information. An alternate mechanism will be that server B will route the Publish request to server A. The drawback of Publish routing is that it will be for all user devices on server B, whereas the backend subscription is on-demand, when the user logs in. So backend subscription can scale better compared to Publish routing. Alice (PC) Server A (Root) Server B Alice (Phone) | | | | | | | F1 PUBLISH | | | |<-------------| | | | | | | | F2 200 OK | | | |------------->| | | | | +-------+ | | | |Alice | | | | |logs in| | | | +-------- | | | | | | | | F2 PUBLISH | | | |----------------->| | | | | | | | F3 200 OK | | | |<-----------------| | | | | | | | | | | |F4 SUBSCRIBE(self)| | | |----------------->| | | | | | | Sinha & Houri Expires April 18, 2009 [Page 19] Internet-Draft Intradomain Call Flows October 2008 | F5 200 OK | | | |<-----------------| | | | | | | | | F6 SUBSCRIBE (BE) | | | |------------------->| | | | | | | | | | | | F7 200 OK | | | |<-------------------| | | | | | | | | | | | F8 NOTIFY | | | |<-------------------| | | | | | | | F9 200 OK | | | |------------------->| | | | | | | +--------+ | | | |compose | | | | |presence| | | | +--------+ | | | | | | | F10 NOTIFY | | | |<-----------------| | | | | | | | F11 200 OK | | | |----------------->| | | | | | | Alice logs into her Client 4.2.1.1.1. Message Details F1 PUBLISH Alice (Phone) -> Server B Sinha & Houri Expires April 18, 2009 [Page 20] Internet-Draft Intradomain Call Flows October 2008 PUBLISH sip:alice@serverB.example.com SIP/2.0 Via: SIP/2.0/TCP 64.102.224.56:5060;branch=z9hG4bKodqzc5 To: ;tag=a737fqaz From: Call-ID: 8038tr5dsfjk@example.com Event: presence .. open true sip:85551234@64.102.224.56 open true text/plain sip:alice@example.com F2 PUBLISH Alice (PC) -> Server A Sinha & Houri Expires April 18, 2009 [Page 21] Internet-Draft Intradomain Call Flows October 2008 PUBLISH sip:alice@serverA.example.com SIP/2.0 ... Event: presence sip:alice@cisco.com true text/plain active open F10 NOTIFY Server A -> Alice (PC) NOTIFY sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKa873 .... .... I am Active Sinha & Houri Expires April 18, 2009 [Page 22] Internet-Draft Intradomain Call Flows October 2008 open true text/plain active sip:alice@example.com open true text/plain sip:alice@example.com open true sip:85551234@64.102.229.56 Sinha & Houri Expires April 18, 2009 [Page 23] Internet-Draft Intradomain Call Flows October 2008 4.2.1.2. Bob adds Alice to her Buddy list Bob(PC) Server B Server A (Root) | | | | | | | | | +--------+ | | |Bob adds| | | |Alice to| | | |his BL, | | | +--------+ | | | F1 SUBSCRIBE | | |------------------>| | | | F2 SUBSCRIBE | | |------------------>| | | | | | +--------+ | | | Alice's| | | |Policy | | | |approves| | | +--------+ | | F3 200 OK | | F4 200 OK |<------------------| |<------------------| | | | | | | +-------------+ | | |sends Alice's| | | |composed pidf| | | +-------------+ | | | | | F5 NOTIFY | | |<------------------| | F6 NOTIFY | | |<------------------| | | | | | | | | F7 200 OK | | |------------------>| F8 200 OK | | |------------------>| Bob adds Alice to her Buddy list Sinha & Houri Expires April 18, 2009 [Page 24] Internet-Draft Intradomain Call Flows October 2008 4.2.1.2.1. Message Details F5 NOTIFY Server A -> Server B NOTIFY sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKtgf Call-ID: 1j9FpLxk3uxtm8tn@example.com Route: .. Content-Length: 568 I am Active open true text/plain active sip:alice@example.com open true text/plain sip:alice@example.com Sinha & Houri Expires April 18, 2009 [Page 25] Internet-Draft Intradomain Call Flows October 2008 open true sip:85551234@64.102.224.56 4.2.1.3. Alice dials in a meeting from phone Alice has a meeting scheduled in the calendar and she dials into the meeting from her desk phone. Phone sends a Publish that it is busy. Server B relays the changed phone status to Server A (the root server).Server A also gets meeting notification from calendaring server. Server B sends changed presence notifications to Bob Sinha & Houri Expires April 18, 2009 [Page 26] Internet-Draft Intradomain Call Flows October 2008 Calendaring Server A(Root) Server B Alice(Ph) Bob(PC) |F1 Meeting | | | | |-----------| | | | | | F3 NOTIFY | | | | F2 Resp |--------------->| F4 NOTIFY | |<----------| |------------------------>| | | F5 200 OK | | | | |<---------------| F6 200 OK | | | |<------------------------| | | | | | | | | | | | | | F7 PUBLISH | | | | |<------------| | | | | | | | | | F8 200 OK | | | | F9 NOTIFY |------------>| | | |<---------------| | | | | | | | | | F10 200 OK | | | | |--------------->| | | | | | | | | | | | | | | F11 NOTIFY | | | | |--------------->| | | | | | F13 NOTIFY | | | F12 200 OK |------------------------>| | |<---------------| | | | | | F14 200 OK | | | |<------------------------| | | | | | Alice dials in a meeting from phone 4.2.1.3.1. Message Details F3 NOTIFY Server A -> Server B Sinha & Houri Expires April 18, 2009 [Page 27] Internet-Draft Intradomain Call Flows October 2008 NOTIFY sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP serverA.exmaple.com;branch=z9hg4bkgtrfw Call-ID: ssdfhsgt@example.com Route: .. Event: presence I am in a Meeting calendar open true text/plain sip:alice@example.com F11 NOTIFY Server A -> Server B NOTIFY sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP serverA.example.com:5060;branch=z9hG4bKvbf Call-ID: 1j9FpLxk3uxtm8tn@example.com Route: .. Event: presence I am in a Meeting open true text/plain sip:alice@example.com closed true sip:85551234@64.102.229.37 open true text/plain sip:alice@example.com Sinha & Houri Expires April 18, 2009 [Page 29] Internet-Draft Intradomain Call Flows October 2008 4.2.1.4. Bob sends an Instant Message to Alice Bob initiates an IM session with Alice. Since Bob's IM client is logged into server B, it will get the session establishing INVITE request. Server B knows that Server A is the root, so it routes that request to server A. Server A acts like a forking proxy and forks the request to Alice's PC client and also to server B, which Alice's phone uses as it's presence and IM server. SIP early media RFC 3960 [RFC3960] technique is used to establish a preliminary session with both devices so that the initial message(s) are displayed on each endpoint. When Alice responds from any endpoint, lets assume her PC client, then after that subsequent messages will be delivered only to the PC client and the phone leg will be canceled. Note: In the call flows below, for offer and answer, the labels are as follows, because of lack of real estate: o Initial Offer: o o Offer in Invite forked to endpoint 1: o1 o Answer from forked endpoint 1: a1 o Early offer from forked endpoint 1: eo1 o Early-answer from originator: ea1 o Offer in Invite forked to endpoint 2: o2 o Answer from forked endpoint 2: a2 o Early offer from forked endpoint 2: eo2 o Early-answer from originator: ea2 Bob(PC) Alice(Ph) Server B Server A(Root) Alice(PC) | | | | | | F1 INVITE (o) | | | |----------------------->| F2 INVITE (o) | | | | |------------------>| | | | | | | | | | +--------+ | | | | |Policy | | | | | |Approves| | | | | +--------+ | | | | | | | | | F3 INVITE(o1) | | | | |<------------------| | | |F5 INVITE (o1)| | F4 INVITE (o2)| | |<-------------| |-------------->| | | | | | | |F7 183(a1,eo1)| |F6 183 (a2,eo2)| | |------------->| F8 183 (a1,eo1) |<--------------| | | |------------------>| | Sinha & Houri Expires April 18, 2009 [Page 30] Internet-Draft Intradomain Call Flows October 2008 | | | | | | | | F9 183 (a2, eo2) | | | | |<------------------| | | | | | | | F10 183(a2, eo2) | | | |<--------|--------------| | | | | | | | | F11 PRACK(ea2) | | | |--------- ------------->| F12 PRACK (ea2) | | | | |------------------>| F13 PRACK(ea2)| | | | |-------------->| | | | | | | | | | F14 200 OK | | | | |<--------------| | | |F15 200 OK (PRACK) | | | | F16 200 OK |<------------------| | |<-----------------------| | | | | | | | |<=========== Early MSRP Session (R u there) ==============>| | | | | | | | | F17 183 (a1, eo1) | | | | |<------------------| | | F18 183 (a1, eo1) | | | |<--------|--------------| | | | | | | | | F19 PRACK (ea1) | | | |--------- ------------->| | | | | | F20 PRACK (ea1) | | | | |------------------>| | | | | | | | | | F21 (PRACK (ea1) | | | | |<------------------| | | |F22 PRACK(ea1)| | | | |<-------------| | | | | | | | | | F23 200 OK | | | | |------------->| F24 200 OK | | | | |------------------>| | | | | | | | | | | | | | | F25 200 OK | | | | |<------------------| | | F26 200 OK (PRACK) | | | |<-----------------------| | | | | | | | |R u there| | | | |<= MSRP=>| | | | | | | | +--------+ Sinha & Houri Expires April 18, 2009 [Page 31] Internet-Draft Intradomain Call Flows October 2008 | | | | |Alice | | | | | |responds| | | | | +--------+ | | | |F27 200 OK(Inv)| | | | F28 200 OK(Inv) |<--------------| | F29 200 OK(Inv) |<------------------| | |<-----------------------| | | | | F30 ACK | | | |--------- ------------->| F31 ACK | | | | |------------------>| F32 ACK | | | | |-------------->| | | | | | |<============== MSRP Session Established =================>| | | | | | | | | F33 Cancel | | | | F34 Cancel |<------------------| | | |<-------------| | | | | | | | | | F35 200 OK | | | | |------------->| | | | | | F36 200 OK | | | | |------------------>| | | | F37 487 | | | | |------------->| F38 487 | | | | |------------------>| | | | | | | | | | F39 ACK | | | | F40 ACK |<------------------| | | |<-------------| | | Bob sends an Instant Message to Alice 4.2.1.4.1. Message Details F2 INVITE Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 32] Internet-Draft Intradomain Call Flows October 2008 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn8as37 From: ;tag=a73kszlfl To: Route: Call-ID: 1j9FpLxkxtm8tn@example.com ... Supported: early-session Content-Type: application/sdp Content-Disposition: session v=0 o=bob 28908457 2890844559 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/iau39soe2843z;tcp F3 INVITE Server A -> Server B INVITE sip:alice@10.10.10.4 SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKn7sCZGa Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn8as37 From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: ... Supported: early-session Content-Type: application/sdp Content-Disposition: session v=0 o=bob 28908457 2890844559 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/iau39soe2843z;tcp F4 INVITE Server A -> Alice (PC) Sinha & Houri Expires April 18, 2009 [Page 33] Internet-Draft Intradomain Call Flows October 2008 INVITE sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKn7sdfhs From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: ... Supported: early-session Content-Type: application/sdp Content-Disposition: session v=0 o=bob 28908457 2890844559 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/iau39soe2843z;tcp F9 183 Session Progress Server A -> Server B Sinha & Houri Expires April 18, 2009 [Page 34] Internet-Draft Intradomain Call Flows October 2008 183 Session Progress Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKsdfhs From: ;tag=a73kszlfl To: ;tag=dsakjhf Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: Contact: ... Content-Type: multipart/mixed; boundary="boundary1" --boundary1 Content-Type: application/sdp Content-Disposition: session v=0 o=alice 2890844612 2890844616 IN IP4 alice.example.com s= - c=IN IP4 alicepc.example.com t= 0 0 m=message 8888 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:12763/kjhd37s2s20w2a;tcp --boundary1 Content-Type: application/sdp Content-Disposition: early-session v=0 o=alice 2890844612 2890844616 IN IP4 alice.example.com s= - c=IN IP4 alicepc.example.com t= 0 0 m=message 8890 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:12763/safhafd0w2a;tcp F12 PRACK Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 35] Internet-Draft Intradomain Call Flows October 2008 PRACK sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKhkjahfs Route: ... Content-Type: application/sdp Content-Disposition: early-session v=0 o=bob 28908107 2890844739 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7779 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/izcqazx843z;tcp F17 183 Session Progress Server A -> Server B Sinha & Houri Expires April 18, 2009 [Page 36] Internet-Draft Intradomain Call Flows October 2008 183 Session Progress Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKn7sCZGa Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn8as37 From: ;tag=a73kszlfl To: ;tag=mkiopw Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: Contact: ... Content-Type: multipart/mixed; boundary="boundary1" --boundary1 Content-Type: application/sdp Content-Disposition: session v=0 o=alice 289121212 2890824141 IN IP4 alice.example.com s= - c=IN IP4 64.102.224.56 t= 0 0 m=message 5555 TCP/MSRP * a=accept-types:text/plain a=path:msrp://64.102.224.56:13934/edcfrv;tcp --boundary1 Content-Type: application/sdp Content-Disposition: early-session v=0 o=alice 28973213 289023912 IN IP4 alice.example.com s= - c=IN IP4 64.102.224.56 t= 0 0 m=message 5577 TCP/MSRP * a=accept-types:text/plain a=path:msrp://64.102.224.56:13832/uhtyrfyt;tcp F20 PRACK Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 37] Internet-Draft Intradomain Call Flows October 2008 PRACK sip:alice@64.102.224.56 SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKhkjahfs Route: To: ;tag=a73kszlfl From: ;tag=mkiopw ... Content-Type: application/sdp Content-Disposition: early-session v=0 o=bob 2893231133 289084329 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7779 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/ijnhtred;tcp 4.2.2. Peer Model In the peer model, neither server is configured explicitly as a root server. When a watcher subscribes to a presentity, that subscription is processed first by the server to which the watcher is connected (the server in this case, effectively acting as the root). Through some configuration mechanism, either static, or through directory lookup, that server discovers that the presentity has additional device capabilities. The server then gathers state of those other devices through backend subscription to that device presence server. Similarly for IM, when a client sends an IM, the IM is processed first by the server associated with the sender (effectively acting as the root) and then the IM is routed to other servers, which act as a child node. 4.2.2.1. Bob adds Alice to her Buddy list In the following call flow, watcher Bob has his buddylist on server B. Bob adds Alice to his buddylist and server B gets the presence subscription. It gets presentity's phone device information internally from PUBLISH sent by phone, which is not shown in this call flow for brevity. Through some static configuration mechanism or by directory lookup, server B discovers that Alice has an PC IM device status on server A. Server B then sends a backend subscription to server A to get that information. Sinha & Houri Expires April 18, 2009 [Page 38] Internet-Draft Intradomain Call Flows October 2008 Bob Server B Server A | | | +------+ | | | Bob | | | | adds | | | |Alice | | | +------+ | | | | | | F1 SUBSCRIBE | | |----------------->| | | | | | +--------+ | | |Policy | | | |Approves| | | +--------+ | | | F3 SUBSCRIBE (BE) | | F2 200 OK |------------------->| |<-----------------| | | | F4 200 OK | | |<-------------------| | | | | | | | | F5 NOTIFY | | |<-------------------| | | | | +--------+ | | |Compose | | | |Presence| | | +--------+ | |F7 NOTIFY | | |<-----------------| F6 200 OK | | |------------------->| | F8 200 OK | | |----------------->| | Bob adds Alice to her Buddy list 4.2.2.1.1. Message Details F1 SUBSCRIBE Bob -> Server B Sinha & Houri Expires April 18, 2009 [Page 39] Internet-Draft Intradomain Call Flows October 2008 SUBSCRIBE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKasafd From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxk3uxtm8tn@example.com CSeq: 1 SUBSCRIBE Contact: Content-Length: 0 F3 SUBSCRIBE Server B -> Server A SUBSCRIBE sip:alice@serverA.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKghgh From: ;tag=a737fqaz To: Call-ID: 8038tr5dsfjk@example.com CSeq: 1 SUBSCRIBE P-Asserted-Identity: sip:alice@example.com Contact: Content-Length: 0 F5 NOTIFY Server A -> Server B Sinha & Houri Expires April 18, 2009 [Page 40] Internet-Draft Intradomain Call Flows October 2008 NOTIFY sip:alice@10.10.10.4 SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKuhb To: ;tag=a737fqaz From: ;tag=98utw Call-ID: 8038tr5dsfjk@example.com .. I am Active open true text/plain sip:alice@example.com F7 NOTIFY Server B -> Bob NOTIFY sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKtgf To: ;tag=8wqrzsc From: ;tag=a73kszlfl Call-ID: 1j9FpLxk3uxtm8tn@example.com .. Content-Length: 568 I am Active open true text/plain sip:alice@example.com open true sip:85551234@64.102.224.56 open true text/plain sip:alice@example.com Sinha & Houri Expires April 18, 2009 [Page 42] Internet-Draft Intradomain Call Flows October 2008 4.2.2.2. Alice sets her status to Do Not Disturb(DND) In this call flow, Alice sets her status to DND on the IM device. There is a PUBLISH from the client to server A, for this changed state which is not shown in this call flow for brevity. This causes a Notify on the backend subscription dialog from server B to server A to be sent out, reflecting Alice's IM device status in the presence document. Typically, the DND status will be reflected on Alice's Desktop phone also, such that it is also set to DND and depending on local policy, then incoming voice calls will be diverted to a voicemail without alerting Alice. The flow below assumes that Alice's phone is also set to DND when she sets it on her IM client. Server B composes overall presence documents and notifies it to watchers and to her IM device, for self presence. Bob Server B Server A | | | | | +----------+ | | |Alice sets| | | |status to | | | | DND | | | +----------+ | | | | | F1 NOTIFY | | |<-------------------| | | | | +---------+ | | |set phone| | | |status | | | +---------+ | | | F2 200 OK | | |------------------->| | | | | +---------+ | | | compose | | | | presence| | | +---------+ | | | | | | | | F3 NOTIFY | | |<-----------------| F4 NOTIFY (self) | | |------------------->| | | | | F5 200 OK | | |----------------->| F6 200 OK | Sinha & Houri Expires April 18, 2009 [Page 43] Internet-Draft Intradomain Call Flows October 2008 | |<-------------------| Alice changes her Status to Do Not Disturb (DND) 4.2.2.2.1. Message Details F1 NOTIFY Server A -> Server B NOTIFY sip:alice@serverB.example.com Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKodqzc5 To: ;tag=a737fqaz From: ;tag=98utw Call-ID: 8038tr5dsfjk@example.com .. Busy fixing critical defect closed true text/plain sip:alice@example.com F3 NOTIFY Server B -> Bob NOTIFY sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKtgf To: ;tag=8wqrzsc Sinha & Houri Expires April 18, 2009 [Page 44] Internet-Draft Intradomain Call Flows October 2008 From: ;tag=a73kszlfl Call-ID: 1j9FpLxk3uxtm8tn@example.com .. Content-Length: 568 Busy Fixing critical defects closed true text/plain sip:alice@example.com closed true sip:85551234@64.102.224.56 closed true text/plain Sinha & Houri Expires April 18, 2009 [Page 45] Internet-Draft Intradomain Call Flows October 2008 sip:alice@example.com 4.2.2.3. Bob sends an Instant Message to Alice Bob initiates an IM session with Alice. Since Bob's PC client is logged into Server B, it will get the session establishing INVITE request. It acts as root from Alice's composed presence state figures out, that Alice has an IM capable phone device on same server and an IM device on Server A. So it acts as a forking proxy and forks the request to both locations, phone device and server A. SIP early media RFC 3960 [RFC3960] technique is used to establish a preliminary session with both devices so that the initial message(s) are displayed on each endpoint. When Alice responds from any endpoint, lets assume her PC IM client, then after that subsequent messages will be delivered only to the IM client and the phone leg will be canceled. Note: In the call flows below, for offer and answer, the labels are as follows, because of lack of real estate: o Initial Offer: o o Offer in Invite forked to endpoint 1: o1 o Answer from forked endpoint 1: a1 o Early offer from forked endpoint 1: eo1 o Early-answer from originator: ea1 o Offer in Invite forked to endpoint 2: o2 o Answer from forked endpoint 2: a2 o Early offer from forked endpoint 2: eo2 o Early-answer from originator: ea2 Bob Alice(Ph) Server B Server A Alice(PC) | | | | | | | F1 INVITE (o) | | | |------------------------------->| | | | | | | | | | +--------+ | | | | |Policy | | | | | |Approves| | | | | +--------+ | | | | | F2 INVITE (o) | | | | |---------------->| | | | F3 INVITE (o2)| |F4 INVITE(o1)| Sinha & Houri Expires April 18, 2009 [Page 46] Internet-Draft Intradomain Call Flows October 2008 | |<---------------| |------------>| | | | | | | |F6 183 (a2, eo2)| |F5183(a1,eo1)| | |--------------->| F7 183 (a1,eo1)|<------------| | | |<----------------| | | F8 183 (a1, eo1) | | | |<-------------------------------| | | | | | | | | | F9 PRACK(ea1) | | | |------------------------------->| F10 PRACK (ea1)| | | | |---------------->|F11 PRACK(ea1) | | | |------------>| | | | | | | | | | F12 200 OK | | | | |<------------| | | | F13 200 OK | | | | F14 200 OK |<----------------| | |<-------------------------------| | | | | | | | |<================ Early MSRP Session (R u there) =============>| | | | | | | | | | | | | | | | | |F16 183 (a2,eo2)| | | |<--------------|----------------| | | | | | | | | |F17 PRACK (ea2) | | | |------------------------------->| | | | | | | | | | F18 PRACK (ea2)| | | | |<---------------| | | | | | | | | | F19 200 OK | | | | |--------------->| | | | | | | | | F20 200 OK (PRACK) | | | |<-------------------------------| | | | | | | | | R u there | | | | |<= Early MSRP=>| | | | | | | | +--------+ | | | | |Alice | | | | | |responds| | | | | +--------+ | | | | | | | | |F21 200 OK | | | | F22 200 OK(Inv)|<------------| | F23 200 OK(Inv) |<----------------| | Sinha & Houri Expires April 18, 2009 [Page 47] Internet-Draft Intradomain Call Flows October 2008 |<-------------------------------| | | | | F24 ACK | | | |------------------------------->| F25 ACK | | | | |---------------->| F26 ACK | | | | |------------>| | | | | | |<================ MSRP Session Established ===================>| | | | | | | | | | | | | F27 Cancel | | | | |<---------------| | | | | | | | | | F28 200 OK | | | | |--------------->| | | | | | | | | | F29 487 | | | | |--------------->| | | | | | | | | | F30 ACK | | | | |<---------------| | | Bob sends an Instant Message to Alice 4.2.2.3.1. Message Details F2 INVITE Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 48] Internet-Draft Intradomain Call Flows October 2008 INVITE sip:alice@serverA.example.com SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKn8as37 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKbvqwa From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com Contact: Record-Route: ... Supported: early-session Content-Type: application/sdp Content-Disposition: session v=0 o=bob 28908457 2890844559 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/iau39soe2843z;tcp F3 INVITE Server B -> Alice Phone IM device INVITE sip:alice@64.102.224.56 SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn8as37 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKbvqwa From: ;tag=a73kszlfl To: Call-ID: 1j9FpLxkxtm8tn@example.com Contact: Record-Route: ... Supported: early-session Content-Type: application/sdp Content-Disposition: session v=0 o=bob 28908457 2890844559 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7777 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/iau39soe2843z;tcp Sinha & Houri Expires April 18, 2009 [Page 49] Internet-Draft Intradomain Call Flows October 2008 F7 183 Session Progress Server A -> Server B 183 Session Progress Via: SIP/2.0/TCP serverB.example.com:5060;branch=z9hG4bKn8as37 Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKbvqwa From: ;tag=a73kszlfl To: ;tag=dsakjhf Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: Record-Route: Contact: ... Content-Type: multipart/mixed; boundary="boundary1" --boundary1 Content-Type: application/sdp Content-Disposition: session v=0 o=alice 2890844612 2890844616 IN IP4 alice.example.com s= - c=IN IP4 alicepc.example.com t= 0 0 m=message 8888 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:12763/kjhd37s2s20w2a;tcp --boundary1 Content-Type: application/sdp Content-Disposition: early-session v=0 o=alice 2890844612 2890844616 IN IP4 alice.example.com s= - c=IN IP4 alicepc.example.com t= 0 0 m=message 8890 TCP/MSRP * a=accept-types:text/plain a=path:msrp://alicepc.example.com:12763/safhafd0w2a;tcp F10 PRACK Server B -> Server A Sinha & Houri Expires April 18, 2009 [Page 50] Internet-Draft Intradomain Call Flows October 2008 PRACK sip:alice@alicepc.example.com SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKhkjahfs Route: ... Content-Type: application/sdp Content-Disposition: early-session v=0 o=bob 28908107 2890844739 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7779 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/izcqazx843z;tcp F16 183 Session Progress Server B -> Bob Sinha & Houri Expires April 18, 2009 [Page 51] Internet-Draft Intradomain Call Flows October 2008 183 Session Progress Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKn7sCZGa Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKn8as37 From: ;tag=a73kszlfl To: ;tag=rwi093258 Call-ID: 1j9FpLxkxtm8tn@example.com Record-Route: Contact: ... Content-Type: multipart/mixed; boundary="boundary1" --boundary1 Content-Type: application/sdp Content-Disposition: session v=0 o=alice 289121212 2890824141 IN IP4 alice.example.com s= - c=IN IP4 64.102.224.56 t= 0 0 m=message 5555 TCP/MSRP * a=accept-types:text/plain a=path:msrp://64.102.224.56:13934/edcfrv;tcp --boundary1 Content-Type: application/sdp Content-Disposition: early-session v=0 o=alice 28973213 289023912 IN IP4 alice.example.com s= - c=IN IP4 64.102.224.56 t= 0 0 m=message 5577 TCP/MSRP * a=accept-types:text/plain a=path:msrp://64.102.224.56:13832/uhtyrfyt;tcp F18 PRACK Server B -> Alice Phone IM device Sinha & Houri Expires April 18, 2009 [Page 52] Internet-Draft Intradomain Call Flows October 2008 PRACK sip:alice@64.102.224.56 SIP/2.0 Via: SIP/2.0/TCP 10.10.10.4:5060;branch=z9hG4bKhkjahfs To: ;tag=a73kszlfl From: ;tag=rwi093258 ... Content-Type: application/sdp Content-Disposition: early-session v=0 o=bob 2893231133 289084329 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 7779 TCP/MSRP * a=accept-types:text/plain a=path:msrp://bobpc.example.com:5555/ijnhtred;tcp 5. Security Considerations Two main considerations are user identity between the federating servers and for unioned federation, the fact that user experience is same with privacy setting. For user identity, the server which has user's buddylist authenticates the user and adds asserted identity in form of P-Asserted-Identity header to messages on the federation interface. Servers will treat each other as authorized hosts and authentication will not be done on the federated link. TLS is used to encrypt signaling. For consistent user privacies, services of a centralized Policy Decision Point (PDP) model described in Models for Intra-Domain Presence and Instant Messaging (IM) Federation can be used. 6. IANA Considerations None 7. Acknowledgments Many thanks to Paul Kyzivat for review and excellent comments on the draft and help with XML. 8. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Sinha & Houri Expires April 18, 2009 [Page 53] Internet-Draft Intradomain Call Flows October 2008 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004. [I-D.ietf-simple-intradomain-federation] Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra- Domain Presence and Instant Messaging (IM) Federation", draft-ietf-simple-intradomain-federation-01 (work in progress), July 2008. Authors' Addresses Sanjay Sinha Cisco Systems, Inc. 7100-9 Kit Creek Road RTP, NC 27709 USA Email: sanjsinh@cisco.com Avshalom Houri IBM Science Park Rehovot Israel Email: avshalom@il.ibm.com Sinha & Houri Expires April 18, 2009 [Page 54] Internet-Draft Intradomain Call Flows October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Sinha & Houri Expires April 18, 2009 [Page 55]