Upload
adrian-nolan
View
219
Download
1
Embed Size (px)
Citation preview
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
www.dynamicsoft.comSpring 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 doesn’t work well Multi-party conferencing doesn’t
work well No way to know when “messaging
session” is over
First IMSecond
IM
www.dynamicsoft.comSpring 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?
www.dynamicsoft.comSpring 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 IMSecond
IMINVITE
www.dynamicsoft.comSpring 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:[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]
www.dynamicsoft.comSpring 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
www.dynamicsoft.comSpring 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
www.dynamicsoft.comSpring 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
User 1
User 1
IMConference
Server
SIP Calls
IM Stream
www.dynamicsoft.comSpring 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 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
www.dynamicsoft.comSpring 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?
www.dynamicsoft.comSpring 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
www.dynamicsoft.comSpring 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
www.dynamicsoft.comSpring 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
BA Server
SUBSCRIBE B
202 Accepted
200 OK
NOTIFY
200 OK
HTTP POST
www.dynamicsoft.comSpring PIM 2001
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
www.dynamicsoft.comSpring 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 [email protected]