IMPP Update: SIP

Spring 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

Spring PIM 2001 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 doesnt work well Multi-party conferencing doesnt work well No way to know when messaging session is over First IM Second IM

Spring PIM 2001 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?

Spring PIM 2001 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 IM Second IM INVITE

Spring PIM 2001 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/2.0 From: Subject: Lets chat To: Eric Sumner Via: SIP/2.0/UDP pc13.dynamicsoft.com Call-ID: Content-type: application/sdp CSeq: 4711 INVITE Content-Length: 187 v=0 o=jdrosen IN IP s= c=IN IP t=0 0 m=audio 3456 RTP/AVP 0 m=message 5060 SIP

Spring PIM 2001 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

Spring PIM 2001 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

Spring PIM 2001 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 IM Conference Server SIP Calls IM Stream

Spring PIM 2001 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 Bs laptop and Bs 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

Spring PIM 2001 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?

Spring PIM 2001 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

Spring PIM 2001 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

Spring PIM 2001 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 B A Server SUBSCRIBE B 202 Accepted 200 OK NOTIFY 200 OK HTTP POST

Spring PIM 2001 IMPP Update Benefits Clean separation between Who can REGISTER for B Who can subscribe to Bs watcherinfo Who can upload policy for Bs subscriptions Many entities can subscribe to Bs 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

Spring PIM 2001 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 Rosenberg