the future of sip and presence jonathan rosenberg chief scientist
Post on 21-Dec-2015
213 views
TRANSCRIPT
SIP 2003 2
A Brief IETF History
March 1998 IETF begins investigating IM and presence in the PIPR BoF.
August 1998 Idea of SIP for Presence is first proposed to PIPR.
March 1999 IMPP group chartered to do requirements.
February 2000 RFC2778 (Model for IM and Presence) and RFC2779 (Requirements for IM and Presence Protocol)appear.
March 2000 IMPP goes dormant, can’t make progress on a single protocol. IESG requests complete proposals by June.
June 2000 Nine protocols are submitted to IETF, including SIP for presence, jointly proposed by folks from dynamicsoft, Microsoft, Columbia U., Cisco.
August 2000 Nine distill to three camps. IESG considers forming three working groups.
December 2000 SIMPLE BoF meets.
March 2001 SIMPLE working group formed.
SIP 2003 3
Where Are We Now?
SIP for Instant Messaging (aka the MESSAGE Method) Completed RFC3428 issued December 2002
SIP for Presence Specifications Completed in May 2002 and Submitted to IESG for Approval Baseline presence spec
(draft-ietf-simple-presence) Watcherinfo spec
(draft-ietf-simple-winfo-package) Watcherinfo XML format
(draft-ietf-simple-winfo-format)
Instant Messaging Sessions Making Progress Could not agree on a transport for
a long time (almost 9 months) Finally agreed on CPIM/TCP Work is progressing well on
details
“Buddy List Package” Subscribe to a list of users Has received continuous attention
for a year but had not stabilized Finally stabilized on a satisfactory
approach
SIP 2003 4
Where Are We Going?
The Main Goal Is to Develop a Set of Component Capabilities for Building a Variety of Presence-based Systems
Guiding Principles Presence will drive many applications, not just IM Presence will be used as an integral part of any communications system Wireless is a key customer
Main Activities in 2003 Application configuration data manipulation Generic IM features
isTyping Delivery status notification
Presence filtering Presence document enhancements Completion of buddy list package, messaging sessions BCP for IM systems
SIP 2003 5
Data Manipulation
Presence and IM Systems Make Significant Use of Application Configuration Data (ACD)
The buddy list White/black lists, authorization policy
ACD Is Read and Written by End Users
ACD Is Read and Written by Network Applications
Example: Buddy List User adds Joe to Buddy List using
ACD manipulation protocol ACD server stores new list User subscribes to their buddy list Presence server fetches the buddy list
from the ACD server Presence server fans out subscriptions
SUBSCRIBE toBuddylist
Add Joe toBuddy List
Get Buddy List
Fanned OutSubscriptions
ACDServer
SIP 2003 6
ACD Needs
ACD Is Needed in Other Areas in the SIP Universe Conferencing policies
Who can and cannot join Who can be moderator Creating conferences
Group calling Network speed dials
All ACD Usages Share Common Requirements Manipulation by end user clients Usage by a single user across
multiple devices General editing – add elements,
remove elements, change elements, list elements
Synchronization with end device End user authentication Extensive authorization support
Only Joe can write his own buddy list, but his department can read it
ACID (Atomicity, Consistency, Isolation, Durability)
Support lots of clients Work for wireless devices
SIP 2003 7
Approaches for ACD
Two Approaches Vertical protocols General protocol
Vertical Protocols Design a specific protocol for
managing the specific data for each application
This is the Wireless Village, PRIM, XMPP approaches
Easy to design a specific protocol BUT, network complexity is horrible
when you get multiple applications Hard to share data Expensive to add new applications Needs tie in to customer care,
operations, etc.
General Protocol and Server Single protocol and server for
managing ACD for all applications Server itself is schema
independent and ignorant Protocol is schema independent Hard to design generically BUT, works famously for
multi-application networks Easier to share data across
applications Easy to add new applications (no
server changes – just publish a new schema, used only by the application)
Easy to tie in to customer care, operations
SIP 2003 8
What Are the Challenges?
The Data Model Generic enough to support a broad
set of applications Simple enough to be implementable
in a wide variety of devices Example data models
Structure of Managed Information (SMI) from SNMP
ACAP data model SQL relational Database
Authorization Who is allowed to
Read Write Search Delete Create
Are user groups needed?
Extensibility Making sure future applications
can be supported without requiring server or database changes
Synchronization Handling the case of multiple
clients each updating the same data
Need a notification mechanism to indicate changes in data
SIP 2003 9
isTyping
What Is It? Existing IM feature that lets users know
whether the other user is typing a reply Very useful in non-streaming interactive
applications
Solution Possibilities SIP Events – SUBSCRIBE to it, get notified
when the typing state changes Hard to work with page mode Hard to sequence with the actual
messages
MESSAGE body type Works with page and session mode Will work through CPIM gateways In same sequence space as actual
messages Use SDP to signal capability to use it
Generalization “Typing” represents non-
streaming interactive text There are other media types –
voice, video Would like to generalize isTyping
to general composition of non-streaming media
Useful for voice IM, for example
SIP 2003 10
Delivery Status Notifications
DSNs Indicate That a Message Was Ultimately Received or Failed
Common in Email (RFC 1894)
Several Uses in IM In Session Mode, used to indicate
whether message is received by the endpoint or fails
In session or page mode, handles delivery through gateways (SMS gateway) where final status is unknown at time of sending
In page mode, handles delivery when recipient is not online, and logs on later to retrieve their IM
RFC 1894 Is Almost Perfect, but Not Quite Specific to email DSNs are quite large, would
like something smaller for wireless
Work Will Be in Determining the Level of Reuse of RFC 1894 for IM
SIP 2003 11
Presence Filtering
Presence Is All About POLICY
There Are Three Players Who Have Policy Inputs
The watcher The presentity The administrator
A Complete System Needs to Allow All Three Parties to Express Their Policy Requirements
Presentity Policy Through ACD manipulation – set specific policies
Administrator Policy Through operational and provisioning interfaces,
usually not standardized
But, How Does the Watcher Indicate Their Policies?
OverallPolicy
WatcherPolicy
PresentityPolicy
AdminPolicy
SIP 2003 12
Presence Filtering
Examples of Watcher Policies Send me only geoloc information Send me presence updates only when
the status goes from offline to online Don’t send me notifications faster
than once per minute
RFC 3265 Leaves a Space for This Problem SUBSCRIBE bodies contain policy
document, called a “filter” No documents currently defined
Main Issue: Presence Specific or Generic for All SIP-events Conclusion: most of it is package specific
Task Is to Specify a Document Format for Presence Policy
Main Challenge: Scope Potentially unbounded:
“Send me only geoloc information when the basic status changes from online to offline if there are four tuples but only if one of those tuples supports IM and at least one of the remaining three indicates a SIP URI”
Two Axes of Filtering On what state changes are
notifications sent What is the content of the
notifications that get sent
SIP 2003 13
Presence Document Enhancements
Current PIDF Document Is Minimalistic
OPEN/CLOSED status Multiple tuples, each with its own
address, status and display note That’s it
Several Potential Areas of Extension
Tuple naming extensions Device capabilities General status Static content
Tuple Naming Extensions Need a way to refer to a tuple for
policy reasons Example: “send me only the PC tuple”
Device Capabilities SIP Caller Preferences extension
allows a device to indicate its capabilities
Media types Codecs SIP Methods
Would like to reflect this information in presence documents
Indicate that tuple 1 supports audio and video
General Status Busy, in a meeting, out to lunch, etc. Do these need to be standardized, or
does a textual note suffice? Main issue: what is needed for an
automata to process
Static Content vCard, Image Thumbnail, recording of
my name Indirection or inline content
SIP 2003 14
Putting It All Together
The Challenge: Build a Consumer-grade IM/buddylist Application Using IETF Protocols, Comparable to Yahoo, AOL, MSN in Features
SIMPLE to Generate a Document Explaining How
Serves Several Purposes Verify that we have all the pieces
standardized to do so Instruct operators on how to fit all the
pieces together
Makes Use of Many Protocols SIP for presence MESSAGE method, messaging sessions Data manipulation IMAP (IM message store) HTTP (content indirection) Whois++ (profile searches) HTML (emoticons) SIP (PC to phone, webcams) SIP Conferencing (IM conferences) Floor control protocols (IM conferences) Content Indirection (file sharing)
Will Provide Guidelines on How to Use Some of These Protocols
System Integration Is the Hardest Part
SIP 2003 15
Resources
SIMPLE Charter: http://www.ietf.org/html.charters/simple-charter.html
Advanced IM Requirements: http://www.ietf.org/internet-drafts/draft-rosenberg-simple-messaging-requirements-00.txt
SIMPLE Components Model: http://www.jdrosen.net/papers/draft-rosenberg-simple-components-00.txt