IMPP Update: SIP. Spring PIM 2001 IMPP Update SIMPLE Group SIMPLE = SIP for Instant Messaging Leveraging Extensions BoF Session Held

IMPP Update: SIP

www.dynamicsoft.comSpring PIM 2001

IMPP Update

SIMPLE Group SIMPLE = SIP for Instant Messaging Leveraging Extensions

BoF Session Held at IETF 49 December 00 Chaired by Jon Peterson, Level(3) Clear consensus to move forward

Officially approved as a working group on Feb 25, 2001 Robert Sparks, dynamicsoft, and Jon Peterson, Level(3), to chair

Charter Encompasses SIP for presence specification

Built off of CPIM and SIP event framework April 01

SIP for IM specification March 01


IMPP Update

Original IM Proposal MESSAGE defined as a new SIP

method

MESSAGE like INVITE First one sets up a “session” Can be record-routed Carried over SIP proxies

Drawbacks Large messages over regular

proxy networks in many cases Forking doesn’t work well Multi-party conferencing doesn’t

work well No way to know when “messaging

session” is over

First IMSecond

IM


IMPP Update

Thoughts on IM IM has a dual-nature

IM as a “page” Single message at a time No correlation between messages Generally very short SMS

IM as a “media session” IM is part of a conversation between users Many messages Correlation between messages Can be long AIM, Yahoo messenger, etc.

Question: how to structure protocol to service both needs easily?


IMPP Update

IM Proposal Proposed at IETF 50

Agreement on list since then

MESSAGE is a “page” Not record-routed Does not establish a session Much like SIP OPTIONS

To set up a chat, create an IM session with INVITE/BYE Send INVITE to desired recipient One of media streams is a

message stream Message stream is a series of

MESSAGE requests

First IMSecond

IMINVITE


IMPP Update

IM Proposal IM Message stream

described in SDP, like other streams

IM “address” is a SIP URL Allows for IM to contain

Route headers (firewall traversal)

Allows for IM to contain different Call-ID than INVITE (third party call control)

Allows for IM to follow same route as INVITE if needed

Each side provides its own IM “address” in SDP Just like media stream

INVITE sip:[email protected] SIP/2.0From: sip:[email protected]: Lets chatTo: Eric Sumner <sip:[email protected]>Via: SIP/2.0/UDP pc13.dynamicsoft.comCall-ID: [email protected]: application/sdpCSeq: 4711 INVITEContent-Length: 187

v=0o=jdrosen 536557 235368 IN IP4 122.3.44.12s= [email protected]=IN IP4 122.3.44.12t=0 0m=audio 3456 RTP/AVP 0m=message 5060 SIP sip:[email protected]


IMPP Update

Benefits of this Approach IM can take many paths

Route header embedded in SIP URL can specify a path

Many possible paths Directly, using UDP or TCP Through a third party provider Through the same path the

INVITE took

IM becomes part of a broader communications exchange Easily add audio, video, games as

additional streams

Easy to determine when session ends BYE or timeout using existing SIP

techniques

Can reuse SIP techniques for Third party call control Multiparty conferencing Session keepalives

Can use TCP for large messages, directly between participants

Reduce traffic through proxies


IMPP Update

Multiparty Conferencing Example User 1 INVITEs User 2

User 2 accepts They IM

User 1 decides to add user 3

User 1 connects himself to IM conference server

User 1 reconnects IM stream with user 2 to conference server

User 1 calls user 3 and connects their IM stream to conference server

INV

200

ACK

INV

200

ACK

INV w/o SDP

200

INV

200

ACK w/ SDP

ACK

INV w/o SDP

200

INV

200

ACK

ACK w/ SDP

User 1 User 2 User 3 IM Conf. Srvr


IMPP Update

Multiparty Conferencing Scenario End Result

User 1, 2 and 3 send messages to conference server, conference server reflects them back

User 1 and User 2 have a SIP call User 1 and User 3 have a SIP call User 1 has three calls to the

conference server

Standard third party call control techniques used in SIP

Additional Benefits Can use separate servers for IM

conferencing, voice conferencing and video conferencing

User 1

User 1

User 1

IMConference

Server

SIP Calls

IM Stream


IMPP Update

Forking IM “Forking” is a SIP concept

whereby a session invitation can “ring” many phones at the same time First one to answer wins If multiple answer at the same

time, multiple calls are set up

Forking works now for IM also! A sends IM to B Arrives at B’s laptop and B’s PC Both accept A is now in two IM sessions – one

is with B at laptop, one is with B on PC

B can type on either laptop or PC, and A gets messages and can see each as a separate conversation

A

B PC

B Laptop


IMPP Update

New Topic: Presence Authorization Problem Statement

When A SUBSCRIBEs to B, we need to determine if this subscription is allowed

Many ways B pre-approved or pre-rejected A from a web form Provider for B has a “black list” that gets applied, using backend AAA

server B is queried, and approves or rejects the subscription

If B is not online, the query is made when B logs in

How to handle query scenario?


IMPP Update

Old Approach: QAUTH Defined a new method – QAUTH

Query for Authorization Sent from Presence Server to

client If client responds with 200 OK,

subscription is approved

Presence Server determined where to send QAUTH from registration Client would REGISTER and

indicate support for QAUTH

SUBSCRIBE

QAUTH

200 OK


IMPP Update

Issues with QAUTH mechanism Tied ability to approve subscriptions with ability to REGISTER

Possible security issues if these are not same

Forking QAUTH was bad So long as any one of recipients approved, subscription would be

approved Might not be desired result

User timeout If presentity is not around when QAUTH arrives, transaction may

timeout Presence server needs to ping to get authorization

Offline authorization was brittle Presence server sends QAUTH when client comes online and registers If registration fails, or QAUTH not answered, no way to authorize


IMPP Update

Proposal: WatcherInfo Each presentity has a set of active

and pending subscriptions Call this set “watcherinfo”

Watcherinfo changes as subscriptions arrive

Can consider watcherinfo as another type of presentity

Entities can SUBSCRIBE to it When it changes, they get NOTIFYd

Approach Presentity B subscribes to its own

watcherinfo A SUBSCRIBEs to B B gets notification of pending

subscription B uploads an authorization document

to approve/reject

SUBSCRIBE winfo

BA Server

SUBSCRIBE B

202 Accepted

200 OK

NOTIFY

200 OK

HTTP POST


IMPP Update

Benefits Clean separation between

Who can REGISTER for B Who can subscribe to B’s

watcherinfo Who can upload policy for B’s

subscriptions

Many entities can subscribe to B’s watcherinfo B at many locations – cell phone,

PDA, laptop Administrators Third parties (e.g., secretary)

Uploading of policy is unified Triggered by subscription At any point in time

Policy document is orthogonal Can be simple list of yes/no Needs to support incremental

uploads

Offline subscriptions are easy Presentity SUBSCRIBEs to its

watcherinfo when logging in Results in a fetch of watcherinfo Prompt user

No transaction in progress yet Can wait arbitrarily long for

user input Upload policy documents for

accept/rejects

Merging of policy at discretion of server


IMPP Update

What will be specified SIP event “package” for watcherinfo

Provides details on generic SUBSCRIBE/NOTIFY for this application

Watcherinfo document format Carried in NOTIFYs for watcherinfo Indicates set of active and pending subscribers for a presentity

Authorization policy document format Who is accepted/rejected

Policy document upload mechanism Either HTTP based or SIP based

Information Resource Jonathan [email protected]

Documents

IMPP Update: SIP. Spring PIM 2001 IMPP Update SIMPLE Group SIMPLE = SIP for Instant Messaging Leveraging Extensions BoF Session Held