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: <sip:alice@example.com>;tag=a73kszlfl
To: <sip:bob@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:alice@alicepc.example.com>
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: <sip:alice@example.com>;tag=a73kszlfl
To: <sip:bob@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@example.com
CSeq: 1 SUBSCRIBE
Record-Route: <sip:serverA.example.com;maddr=1.2.3.4;lr>
Contact: <sip:alice@alicepc.example.com>
P-Asserted-Identity: <sip:alice@example.com>
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: <sip:alice@example.com>;tag=a73kszlfl
From: <sip:bob@example.com>;tag=gred45
Call-ID: 1j9FpLxkxtm8tn@example.com
CSeq: 1 NOTIFY
Route: <sip:serverA.example.com>
Contact: <sip:bob@10.10.10.4>
P-Asserted-Identity: <sip:bob@example.com>
Content-Length:567
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:bob@example.com">
<dm:person id="bob">
<rpid:activities>
<rpid:available/>
<rpid:note>I am Active </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<contact priority="0.5">sip:bob@example.com</contact>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<status>
<basic>open</basic>
</status>
</tuple>
<tuple id="fahsaf-hfes-89saf">
<status>
<basic>open</basic>
</status>
<sc:servcaps>
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.4">sip:89991234@64.102.193.98</contact>
</tuple>
</presence>
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: <sip:alice@example.com>;tag=a73kszlfl
From: <sip:bob@example.com>;tag=gred45
Call-ID: 1j9FpLxkxtm8tn@example.com
Route: <sip:serverA.example.com>
CSeq: 2 NOTIFY
Contact: <sip:bob@10.10.10.4>
P-Asserted-Identity: <sip:bob@example.com>
Content-Length:567
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:bob@example.com">
<dm:person id="bob">
<rpid:activities>
<rpid:away/>
<rpid:note>I am Away from my computer now</rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<contact priority="0.5">sip:bob@example.com</contact>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<status>
<basic>open</basic>
</status>
</tuple>
<tuple id="fahsaf-hfes-89saf">
<status>
<basic>open</basic>
</status>
<sc:servcaps>
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.4">sip:89991234@64.102.193.98</contact>
</tuple>
</presence>
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: <sip:alice@example.com>;tag=a73kszlfl
From: <sip:bob@example.com>;tag=gred45
Call-ID: 1j9FpLxkxtm8tn@example.com
CSeq: 3 NOTIFY
Contact: <sip:bob@10.10.10.4>
P-Asserted-Identity: <sip:bob@example.com>
Content-Length:567
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:bob@example.com">
<dm:person id="bob">
<rpid:activities>
<rpid:away/>
<rpid:note>I am Away from my computer now</rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<contact priority="0.5">sip:bob@example.com</contact>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<status>
<basic>closed</basic>
</status>
</tuple>
<tuple id="fahsaf-hfes-89saf">
<status>
<basic>closed</basic>
</status>
<sc:servcaps>
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.4">sip:89991234@64.102.193.98</contact>
</tuple>
</presence>
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: <sip:alice@example.com>;tag=a73kszlfl
To: <sip:bob@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
CSeq: 1 INVITE
Contact: <sip:alice@alicepc.example.com>
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: <sip:alice@example.com>;tag=a73kszlfl
To: <sip:bob@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
CSeq: 1 INVITE
Record-Route: <sip:serverA.example.com;maddr=1.2.3.4;lr>
Contact: <sip:alice@alicepc.example.com>
P-Asserted-Identity: <sip:alice@example.com>
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: <sip:alice@example.com>;tag=a73kszlfl
To: <sip:bob@example.com>;tag=087js
Call-ID: 1j9FpLxkxtm8tn@example.com
CSeq: 1 INVITE
Record-Route: <sip:serverA.example.com;maddr=1.2.3.4;lr>
Contact: <sip:bob@10.10.10.4>
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: <sip:alice@example.com>;tag=a737fqaz
From: <sip:alice@example.com>
Call-ID: 8038tr5dsfjk@example.com
Event: presence
..
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<tuple id="fabfa341">
<status>
<basic>open</basic>
</status>
<sc:servcaps>
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.224.56</contact>
</tuple>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<available/>
</rpid:activities>
</dm:person>
<tuple id="0983wqh">
<contact priority="0.5">sip:alice@cisco.com</contact>
<sc:servcaps>
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<user-input>active</user-input>
<status>
<basic>open</basic>
</status>
</tuple>
</presence>
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
....
....
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:available/>
<rpid:note>I am Active </rpid:note>
</rpid:activities>
Sinha & Houri Expires April 18, 2009 [Page 22]
Internet-Draft Intradomain Call Flows October 2008
</dm:person>
<tuple id="0983wqh">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<user-input>active</user-input>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="fabfa341">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.229.56</contact>
</tuple>
</presence>
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: <sip:serverB.example.com>
..
Content-Length: 568
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:available/>
<rpid:note>I am Active </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="0983wqh">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<user-input>active</user-input>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
Sinha & Houri Expires April 18, 2009 [Page 25]
Internet-Draft Intradomain Call Flows October 2008
</tuple>
<tuple id="fabfa341">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.224.56</contact>
</tuple>
</presence>
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: <sip:serverB.example.com>
..
Event: presence
<?xml version="1.0" encoding="UTF-8">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:busy/>
<rpid:note>I am in a Meeting </rpid:note>
</rpid:activities>
<rpid:class>calendar</rpid:class>
</dm:person>
<tuple id="0983wqh">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:serverB.example.com>
..
Event: presence
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
Sinha & Houri Expires April 18, 2009 [Page 28]
Internet-Draft Intradomain Call Flows October 2008
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:busy/>
<rpid:note>I am in a Meeting </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="0983wqh">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="ghgyyr">
<status>
<basic>closed</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.229.37</contact>
</tuple>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Route: <sip:severA.example.com>
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverA.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
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverA.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
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>;tag=dsakjhf
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverA.example.com;lr>
Contact: <sip:alice@alicepc.example.com>
...
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: <sip:serverA.example.com>
...
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>;tag=mkiopw
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverA.example.com;lr>
Contact: <sip:alice@64.102.224.56>
...
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: <sip:serverA.example.com>
To: <sip:bob@example.com>;tag=a73kszlfl
From: <sip:alice@example.com>;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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Call-ID: 1j9FpLxk3uxtm8tn@example.com
CSeq: 1 SUBSCRIBE
Contact: <sip:bob@bobpc.example.com>
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: <sip:alice@serverB.example.com>;tag=a737fqaz
To: <sip:alice@example.com>
Call-ID: 8038tr5dsfjk@example.com
CSeq: 1 SUBSCRIBE
P-Asserted-Identity: sip:alice@example.com
Contact: <sip:alice@10.10.10.4>
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: <sip:alice@serverB.example.com>;tag=a737fqaz
From: <sip:alice@example.com>;tag=98utw
Call-ID: 8038tr5dsfjk@example.com
..
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:available/>
<rpid:note>I am Active </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:bob@example.com>;tag=8wqrzsc
From: <sip:alice@example.com>;tag=a73kszlfl
Call-ID: 1j9FpLxk3uxtm8tn@example.com
..
Content-Length: 568
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
Sinha & Houri Expires April 18, 2009 [Page 41]
Internet-Draft Intradomain Call Flows October 2008
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:available/>
<rpid:note>I am Active </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="ghgyyr">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.224.56</contact>
</tuple>
<tuple id="0983wqh">
<status>
<basic>open</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:alice@serverB.example.com>;tag=a737fqaz
From: <sip:alice@example.com>;tag=98utw
Call-ID: 8038tr5dsfjk@example.com
..
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:do-not-disturb/>
<rpid:note> Busy fixing critical defect </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="frh78">
<status>
<basic>closed</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:bob@example.com>;tag=8wqrzsc
Sinha & Houri Expires April 18, 2009 [Page 44]
Internet-Draft Intradomain Call Flows October 2008
From: <sip:alice@example.com>;tag=a73kszlfl
Call-ID: 1j9FpLxk3uxtm8tn@example.com
..
Content-Length: 568
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
entity="sip:alice@example.com">
<dm:person id="alice">
<rpid:activities>
<rpid:do-not-disturb/>
<rpid:note>Busy Fixing critical defects </rpid:note>
</rpid:activities>
</dm:person>
<tuple id="9tred">
<status>
<basic>closed</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
<tuple id="1gtlp">
<status>
<basic>closed</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:audio>true</sc:audio>
</sc:servcaps>
<contact priority="0.8">sip:85551234@64.102.224.56</contact>
</tuple>
<tuple id="0983wqh">
<status>
<basic>closed</basic>
</status>
<sc:servcaps xmlns:sc="urn:ietf:params:xml:ns:pidf:servcaps">
<sc:text>true</sc:text>
<sc:type>text/plain</sc:type>
</sc:servcaps>
Sinha & Houri Expires April 18, 2009 [Page 45]
Internet-Draft Intradomain Call Flows October 2008
<contact priority="0.5">sip:alice@example.com</contact>
</tuple>
</presence>
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
Contact: <sip:bob@bobpc.example.com>
Record-Route: <sip:serverB.example.com;lr>
...
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>
Call-ID: 1j9FpLxkxtm8tn@example.com
Contact: <sip:bob@bobpc.example.com>
Record-Route: <sip:serverB.example.com;lr>
...
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>;tag=dsakjhf
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverA.example.com;lr>
Record-Route: <sip:serverB.example.com;lr>
Contact: <sip:alice@alicepc.example.com>
...
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: <sip:serverA.example.com>
...
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: <sip:bob@example.com>;tag=a73kszlfl
To: <sip:alice@example.com>;tag=rwi093258
Call-ID: 1j9FpLxkxtm8tn@example.com
Record-Route: <sip:serverB.example.com;lr>
Contact: <sip:alice@64.102.224.56>
...
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: <sip:bob@example.com>;tag=a73kszlfl
From: <sip:alice@example.com>;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]