The Future of SIP and Presence Jonathan Rosenberg Chief Scientist.

The Future of SIP and Presence

Jonathan RosenbergChief Scientist

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

Information Resource

Jonathan RosenbergChief Scientist+1 [email protected]