The document discusses reference models and protocols for instant messaging and presence services. It describes: - The reference model for presence services and instant messaging, including components like presence and instant message services, presentities, watchers, senders, and inboxes. - Protocols like SIP, SIMPLE, XMPP, PIDF, and MSRP that are used to implement presence services and instant messaging. These protocols handle presence information, subscriptions, messaging, and media delivery. - How presence information is generated and distributed using SIP methods like SUBSCRIBE, NOTIFY, and protocols like PIDF. Instant messages are sent using SIP MESSAGE or by establishing SIP dialogs and using MSRP.

2. Reference Model for Instant Messaging Presence Service Instant Message Service Presentity Watcher Presence UA Watcher UA Instant Inbox Inbox UA Sender UA Sender Principal A Principal B Based on RFC 2778 Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

4. Understanding the model – Presence Service Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Component Function Principal User – human or program Presence Service “ I am here” Presentity Provides information about the principal to the presence service Watcher Receives information from the presence service. Can be a fetcher (requests presence information) or a subscriber (sent notifications). Fetcher that periodically requests information is a poller. Presence Protocol Carries precise information between the presentities , the presence service and the watchers Presence Tuples Combines to form presence information. Each tupple includes: - status information (open/closed – ready/not ready to receive messages) - communication address (includes communication means and contact address)

5. Understanding– Instant Message Service Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Component Function IM Service Delivers Instant Messages to the correct instant inbox Sender Provides instant messages for delivery Instant Inbox Receives intsant messages from the service Instant Message Protocol Carries instant messages from the sender thru the service to the instant inbox

7. Common Profile for Presence Defines common semantics and data formats for presence Subscribe (request from a watcher to a presence service to subscribe to the presence information about a particular presentity) Watcher – specified by a URI Target - the presentity specified by a URI Duration – maximum number of seconds a subcription should be active (set to zero for a one time fetcher) Subscription ID Transaction ID – used to correlate with response Response (response from presence service to watcher on receiving subscription request) Status – success/failure TransactionID - same used in subscribe request Duration – the number of seconds the subcription will be active (may differ from request) e Notify (response from presence service to watcher to communicate the presence information) Watcher Target TransID Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

8. Presence Information Data Format (PIDF) Defines the XML based format used for expressing presence information Presence element <presence> <entity> - presentity URI <xmlns> - namespace declaration Presence Tuples <identifier> <status> - <open> or <closed> <communication address> <communication means> <contact address> - optional <relative priority> - optional of this address relative to other addresses <timestamp> - optional time of status change <note> - presentity human readable comment a free text memo (optional) Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

9. Common Profile for instant messaging (CPIM) Provides a means for preserving end to end features (especially security) as messages pass thru instant messaging interoperability gateways Also provides recommendations for IM document formats Message (to send a message to an instant inbox) Source – originator specified by a URI Destination - specified by a URI MaxForwards – a hop counter to avoid loops. Counter decremented by each IM gaeway Transaction ID – used to correlate with response Content Response (on receipt of a message) Transaction ID – same as in message Status Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

16. SIP Session : Call Set Up INVITE INVITE INVITE 1 2 4 Bejing.com proxy Barcelona.com proxy 100 Trying 3 Tracy Durga 100 Trying 5 180 Ringing 6 180 Ringing 7 180 Ringing 8 200 OK 9 200 OK 10 200 OK 11 ACK 12 Media Session (independent of SIP BYE 13 OK 14 This is a very simple call set up. The SIP protocol acomodates much more complex situations including security and conferencing Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

17. SIP Call Session - explained 1 – Tracy invites Durga by addressing her by her SIP identifier. Tracy’s invitation is sent to the local SIP proxy at Beijing. 2- The beijing.com proxy on receipt of the INVITE determines the IP addresses of barcelona.com and forwards it 3- The beijing.com proxy also sends a code 100 Trying message to Tracy 4- The barcelona.com proxy receives the INVITE and forwards it to the IP address of Durga’s SIP phone 5 – The barcelona.com proxy also sends a 100 Trying message to the beijing.com proxy 6- Durga’s phone responds with a 180 Ringing message to the barcelona.com proxy 7- The 180 Ringing message is forwarded to the beijing.com proxy where 8 - The 180 Ringing message is forwarded to Tracy’s phone where it can be used to initiate ringback 9- Durga decides to answer the call. As she picks it up his SIP phone sends a 200 OK message 10- The 200 OK message is forwarded to the beijing.com proxy 11. The 200 OK message is forwaded to Tracy’s phone which stops the ringback 12 Tracy’s SIP phone sends an ACK (acknowledgement) message directly to Durga’s SIP phone and thwe media session proceeds between the two endpoints without involving the SIP proxies. 13. Durga decides to end the call and when she hangs up a BYE message is sent to Tracy 14. Tracy responds with OK and the session is terminated. Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

18. SIP invite message INVITE sip:durga@barcelona. com SIP/2.0 Via: SIP/2.0/UDP pc33.beijing.com;branch=z9xchk777656ssdhe Max-Forwards: 70 To: Durga < sip:durga@barcelona.com > From Tracy < sip:tracy@beijing.com >; tag=1987634 Call-ID: a06545bnf667pc33.beijing.com Cseq:342356 INVITE Contact: <sip: [email_address] > Content-Type:application/sdp Content Length: 142 INVITE method Durga’s SIP URI Protocol Identifier Unique Transaction Identifier Decremented on Each SIP proxy hop Address to respond to sender Identifying Tag Command Sequence incremented for each new dialog request A SIP URI providing a direct route to contact Tracy without requiring SIP proxy servers Session Descriptor Protocol (explained later) The type of message content Globally Unique Call Identifier Durga and Tracy’s diplay name and SIP URI Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

19. SIP registration method How is the correct IP address of Durga’s SIP phone identified in Step 4 ? REGISTER REGISTER REGISTER Registration Server Location Server Beijing.com proxy Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Durga’s Cell Phone Durga’s Wireless PDA Durga’s Home PC

20. SIP Registration method - explained User (Durga) has three phones that she uses in SIP sessions Each of her phones sends REGISTER messages to the SIP registration server The registration server is addressed within the beijing.com domain but need not be co-located with the beijing.com proxy Each REGISTER message associates the IP address of her phone with the SIP URI The association between the IP address and the SIP URI is stored by the Location Server and is accessible by the SIP Proxy Durga may have: - a single URI in which case the most recent phone to be activated will be bound to that URI - several SIP URIs allowing her to maintain association between each of her URIs and phones The signaling protocol allows for serial or parallel forking where her several devices can be alerted sequentially or simultaneously Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

21. Getting Back to IM How can SIP be used to generate presence information? Watcher (subscriber) Presence Agent Presence UA SIP Proxies Presence Server SUBSCRIBE 200 OK NOTIFY+ PIDF 200 OK NOTIFY+ PIDF 200 OK Presence Status Presence Status Change Definition: Presence Agent Accepts subscriptions, stores subscription requests and generates notifications when there are changes in presence information. The presence agent knows the presence state of each presentity within its scope. Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com 1 2 3 4 5 6

22. SIMPLE - generate Presence Information Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com 1 – Subscriber (watcher) creates a SUBSCRIBE request identifying the presentity. The SUBSCRIBE request is carried along by SIP proxies and arrives at the presence server which forwards it to the presence gent serving the identified presentity 2 -If authorized by presence agent a 200 OK response is returned. 3 – A NOTIFY message is also sent containing presence information in PIDF format. 4 – The watcher acknowledges receipt of the NOTIFY message with a 200 OK message 5 – After some time when the presentity state changes, the presence agent uses a NOTIFY method to send updated presence information in PIDF format 6 – The watcher acknowledges receipt of the notify message with a 200 OK

24. SIMPLE Pager mode Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Sender UA (UAC) Tracy SIP Proxies Inbox UA (UAS) MESSAGE OK OK 1 2 3 4 Durga MESSAGE

26. SIMPLE: Message mode Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com SDP SIP MSRP TCP IP Uses Session Description Protocol (SDP) over SIP to describe the session Message Session Relay Protocol (MSRP) over TCP to transmit the messages Application Layer Transport Layer Network Layer

29. IM with MSRP, SDP over SIP Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Tracy Sender UA, Sender Durga Inbox UA, Receiver SDP/SIP INVITE SDP/SIP 200 OK SIP ACK MSRP SEND 1 2 3 4 MSRP 200 OK 5 MSRP 200 OK 6 MSRP SEND 7 SIP BYE 3 SIP 200 OK 3

30. IM with MSRP, SDP over SIP - exaplained Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com 1- Tracy sends a SIP INVITE message with SDP embedded 2- Durga sends a SIP OK and includes the negotiated SDP parmeters 3- Tracy replies with a SIP ACK At this point the connection to the endpoints is established 4- Tracy opens a connection to Durga and uses the MSRP SEND to transmit her first text message 5 –Durga sends a MSRP OK message 6. Now Durga send a text message using MSRP SEND 7. Tracy acknowledges receipt with MSRP OK message 8. Tracy send a SIP BYE to terminate 9. Durga responds with a SIP 200 OK and terminates the session

33. XMPP network architecture Server 1 Server 2 Gateway Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Durga’s Cell Phone Client Durga’s Wireless PDA Client Durga’s PC client Tracy’s PC client Brian’s PC client Foreign network

35. Basic XMPP instant message session Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com Tracy’s PC Client Server 1 <stream> 1 3 4 Durga’s PC Client Server 2 <stream> 2 <message> </stream/stream> 5 6 <message> </stream/stream>

36. Basic XMPP instant message session - explained Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com 1 – Tracy initiates a <stream> towards her XMPP server by opening a TCP connection 2- Her server responds by opening a stream towards Tracy. 3 – Tracy sends a <message> to Durga. She sends the <message stanza> over the connection to her local server including her JID in the “from field” and Durga’s JID in the “to field”. She includes her message inside the <body> element of the stanza 4 – Durga sends her own <message> stanza to her local server including her JID in the from field and Tracy’s JID in the to field. Her server forwards it to Tracy’s server which in turn forwards it to Tracy 5 – Tracy terminates her session by sending </stream:stream> to her local server. 6 – Her local server terminates the stream by sending </stream:stream> to her.

37. XMPP based presence services Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com <presence> stanzas are used to implement presence services <presence> <type> - describes the client’s presence status <show> - supplements the presence information <status> - contains text and allows presence info to be read by humans <priority> - guide stanza routing to preferred devices </presence>