Instantmessagingprotocols

Collaboration: Instant Messaging

Real Time Interactive Content Delivery

Sanjoy Sanyal:www.itforintelligentfolks.blogspot.c

om

Reference Model for Instant MessagingPresence Service

Instant Message Service

Presentity Watcher

Presence UA Watcher UA

Instant Inbox

Inbox UASender UA

Sender

Principal A Principal B

Based on RFC 2778

Sanjoy Sanyal:www.itforintelligentfolks.blogspot.com

Understanding the Model – Agents & Rules

• The Principal interacts thru agents:– Presence UA– Watcher UA– Sender UA– Inbox UA

• Rules:– Access rules determines how presence information is made available to

watchers – Visibility rules determine how watcher information is made available – Delivery rules allow the receiving principal to decide how instant messages are

filtered from the instant inbox


Understanding the model – Presence ServiceComponent 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)


Understanding– Instant Message Service

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


Understanding the Model – Agents & Rules

• The Principal interacts thru agents:– Presence UA– Watcher UA– Sender UA– Inbox UA

• Rules:– Access rules determines how presence information is made available to

watchers – Visibility rules determine how watcher information is made available – Delivery rules allow the receiving principal to decide how instant messages are

filtered from the instant inbox


Common Profile for Presence

Defines common semantics and data formats for presenceSubscribe

(request from a watcher to a presence service to subscribe to the presence information about a particular presentity)

Watcher – specified by a URITarget - the presentity specified by a URIDuration – maximum number of seconds a subcription should be active (set to zero for a one time fetcher)Subscription IDTransaction ID – used to correlate with response

Response

(response from presence service to watcher on receiving subscription request)

Status – success/failureTransactionID - same used in subscribe requestDuration – 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)

WatcherTargetTransID


Presence Information Data Format (PIDF)

Defines the XML based format used for expressing presence information

Presence element <presence> <entity> - presentity URI <xmlns> - namespace declarationPresence 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)


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 URIDestination - specified by a URIMaxForwards – 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 messageStatus


CPIM message format

• A mime type common message format which is used by any CPIM-compliant transport protocol.

• This achieves the following:– internetworking diverse set of instant messaging protocols – meeting security needs so that end to end- to end signatures and encryption


A slide on MIME

• Multipurpose Internet Mail Extensions

• Extends the format of e-mail to support:– text in character sets other than US-ASCII; – non-text attachments; (images, sounds, movies, and computer programs)– multi-part message bodies; and – header information in non-ASCII character sets.

• Fundamental component of HTTP:– which requires that data be transmitted in the context of e-mail-like messages


Internet based Instant Messaging

• Two main IETF based open standards:

– SIMPLE – XMPP


SIMPLE

• Session Initiation Protocol – Application layer control and signaling protocol for creating, modifying and

terminating sessions with multiple participants – These sessions can be diverse: multimedia sharing/conference, VoIP

• SIMPLE– SIP for Instant Messaging and Presence Leverage

The full scope of SIP is beyond the session – we will learn some basics


SIP Protocol - Basics

• SIP:– Runs on a variety of transport protocols notably TCP and UDP– Is independent of transport protocol, type of media and type of session

• SIP ‘s similarities with HTTP:– Based on a request-response transaction medel– SIP requests invoke a method on the server that carries out a function

• SIP Proxy Servers – route requests to each users current locations – Authenticates users

• User agents – Agree on session characteristics that will best allow them to communicate


SIP methods

• Invite – Signaling messages used to invite users to participate in sessions – Carry session descriptors to agree on media types and specific encoding

• Register – Allow users to announce current locations to systems

• Subscribe – Allow watchers to get presence information

• Notify– Allow watchers to receive presence information


SIP Session : Call Set Up

INVITE INVITE INVITE1 2 4

Bejing.com proxy Barcelona.com proxy

100 Trying3

Tracy Durga

100 Trying5

180 Ringing6

180 Ringing7

180 Ringing8

200 OK9

200 OK10

200 OK11

ACK

12

Media Session (independent of SIP

BYE13

OK

14

This is a very simple call set up. The SIP protocol acomodates much more complex situations including security and conferencing


SIP Call Session - explained1 – 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 Tracy4- The barcelona.com proxy receives the INVITE and forwards it to the IP address of Durga’s SIP phone5 – 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 ringback9- Durga decides to answer the call. As she picks it up his SIP phone sends a 200 OK message10- The 200 OK message is forwarded to the beijing.com proxy11. 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.


SIP invite message

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc33.beijing.com;branch=z9xchk777656ssdheMax-Forwards: 70To: Durga <sip:[email protected]>From Tracy <sip:[email protected]>; tag=1987634Call-ID: a06545bnf667pc33.beijing.comCseq:342356 INVITEContact: <sip: [email protected]>Content-Type:application/sdpContent Length: 142

INVITE method Durga’s SIP URI Protocol IdentifierUnique 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


sip:[email protected]



mailto:[email protected]

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


Durga’s Cell PhoneDurga’s Wireless PDA

Durga’s Home PC

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


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 AgentAccepts 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.


1

2

3

4

5

6

SIMPLE - generate Presence Information


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

SIMPLE – implement instant messaging service

• Pager mode – Exchanging a small number of short messages without the overhead of

creating a SIP dialog

• Message mode– Exchanging longer messages and first creates a SIP dialog


Definition: SIP dialogPeer to peer SIP relationship between two user agents that persists for some time

SIMPLE Pager mode


Sender UA (UAC)

Tracy

SIP Proxies

Inbox UA (UAS)

MESSAGE

OK

OK

12

3

4

Durga

MESSAGE

SIMPLE Pager mode - explained


1 – The UAC for Tracy begins the session by sending a MESSAGE method to the local SIP proxy. The actual message is sent along in MIME format

The instant inbox is identified by a SIP URI

2 – The proxy recognizes the domain specified by the SIP URI & looks up Durga in the location server and forwards it to the UAS acting as the instant inbox.

3 A OK response is generated by the UAS and sent back to proxy

4. The OK response is forwarded by the proxy to Tracy

Definitions:MESSAGE method: allows transfer of instant messages in MIME formatUser Agent Client (UAC) – creates and sends new requestUser Agent Server (UAS) – generates a response to a SIP request

SIMPLE: Message mode


Application Layer

Transport Layer

Network Layer

SDP

SIPMSRP

TCP

IP

Uses Session Description Protocol (SDP) over SIP to describe the session Message Session Relay Protocol (MSRP) over TCP to transmit the messages

Session Description Protocol

• Describes multimedia sessions • Purely a format for describing a session and it can be used

over a variety of transport protocols


Information used in SDP

The session name and purpose Times the session is active (start/stop, recurring times)Media used for the session

Type of media Type of media format Transport protocol used

Communications information needed to receive those media (network addresses, ports, formats)Optional information (bandwidth, contact information)

Message Session Relay Protocol (MSRP)

• MSRP supports conferencing, third party call control, call transfer, quality of service integration and privacy

• MSRP uses the following two methods:– SEND delivers a complete message or a portion of a complete message – REPORT sends a report on the status of an earlier SEND request

• MSRP uses the SIP INVITE method to initialize a conversation


IM with MSRP, SDP over SIP


TracySender UA, Sender

DurgaInbox UA, Receiver

SDP/SIP INVITE

SDP/SIP 200 OK

SIP ACK

MSRP SEND

1

2

3

4

MSRP 200 OK5

MSRP 200 OK

6 MSRP SEND7

SIP BYE3

SIP 200 OK3

IM with MSRP, SDP over SIP - exaplained


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

XMPP and Jabber

• XMPP is the standardised version of Jabber (www.jabber.org)

• Extensible Messaging and Presence Protocol (XMPP) – Streaming XML elements in near real time between any two network

endpoints– Provides a generalized extensible framework for exchanging XML data – Used mainly for the purpose of IM

• Google Talk uses the XMPP protocol


http://www.jabber.org/

XMPP Network Architecture Elements

• Clients• Servers

– Manage connections and sessions – Route XML elements over TCP among network elements – Stores persistent data such as contact lists used by clients – Typiclly intercommunicate using TCP on port 5269

• Jabber Identifier (JID)– Unique identifier for each network endpoint– JIDs identify IM users , servers and the particular client device (resource)

• Gatways – Translate XMPP into the protocol used by a non-XMPP messaging system

• Foreign networks – Messaging system which does not use XMPP

(IRC,SMS,SIMPLE,SMTP,AIM,ICQ,MSN,Yahoo)


XMPP network architecture

Server 1

Server 2

Gateway


Durga’s Cell Phone Client

Durga’s Wireless PDA Client

Durga’s PC clientTracy’s PC client

Brian’s PC client

Foreign network

Foreign network

XAMPP uses XML Streams and Stanzas

• XML stream: Container for exchanging XML elements between any two network entities

• XML stanza: a unit of information sent over an XML stream


Basic XMPP instant message session


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>

Basic XMPP instant message session - explained


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.

XMPP based presence services


<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>

Other XMPP features

• Allows users to manage contact lists called rosters – User’s roster is stored on the server – can be accessed by the client from any device

• Provides blocking lists

• Includes several security features. Can be used over:– Transport Layer Security (TLS) – Simple Authentication and Security Layer (SASL)


Summary

• Oops …this was long. You need to IM your friends and go out tonight for a few tequila shots

• You need to know who is present (Presence)

• You need to message them (Instant Messaging service)

• Two main general standards: SIMPLE and XMPP to do that.


Business

Instantmessagingprotocols