Presence & IM Use Cases

1. Presence & IM Use Cases draft-ietf-speermint-consolidates-presence-im-usecases-00 Avshalom Houri – IBM Edwin Aoki – AOL LLC Sriram Parameswar - Microsoft IETF 68 – SPEERMINT WG

2. Real Time Collaboration • VOIP use cases are discussed in a different draft • This draft concentrates on use cases for real time collaboration and presence and IM in particular • Real time collaboration are services as instant messaging, N-way chat, file transfer, collaborative editing and more IETF 68 – SPEERMINT WG

3. Presence • Presence is a key enabler for many services including voice • Peering domains will need presence in order to have a better enablement • Deployments of domain to domain presence and IM systems already exist IETF 68 – SPEERMINT WG

4. Presence Use Cases • Simple presence subscription – A user subscribes to another user on another domain • Resource list subscription – A user subscribes to a list of users on another domain while using a single URL as the resource list identifier • Authorization migration – Enable the other server to handle the privacy of users from another domain, will enable sending consolidated notifications IETF 68 – SPEERMINT WG

5. IM use cases • Page mode IM – Send a singleton message from a user in one domain to a user in another domain • Session mode IM • Create an MSRP session between a user in one domain and a user in another domain • Usage of MSRP relays where the IMs are going via different route then the signaling, actually creating media stream… IETF 68 – SPEERMINT WG

6. Other Real Time Collaboration Use Cases • Chat rooms – A text based chat that is conducted between users from multiple domains • File transfer – Transferring a file from a user at one domain to a user in another domain • Application sharing – Enable seeing and working on the same application together • Many more to come… IETF 68 – SPEERMINT WG

7. General Requirements • Connectivity – learn connectivity settings including NAT/FW • Security – Making sure that the connection is authenticated, encrypted etc. • Services – Discovery of services available on the other side • Overload control - Making sure that the other domains are not overloading each other • Federation of domains (AKA clearing house) as defined in SPEERMINT terminology draft should be enabled for presence and real time collaboration services IETF 68 – SPEERMINT WG

8. Specific Requirements • Mapping of presence documents – Domains may have different statuses for user (e.g. busy, in a meeting), in some cases there is a need for a mapping function of these statuses and other presence information between the domains • Mapping of users – A domain may support users in multiple domain names, when a domain connects to many domains there is a need to know how to map user URIs to specific domains • Consolidates subscriptions – Enable consolidated subscription between domains while retaining privacy of users, will enable consolidated notifications IETF 68 – SPEERMINT WG

9. VOIP and RTC – Commonalities and Differences • Both are based mainly on session creation • In VOIP the session is always between users in RTC the session may be to a server like a presence server or a conference focus • In VOIP after the session is created, the media will go via different path. In RTC many messages will go via the SIP control path (e.g. NOTIFY) • RTC and esp. presence is extremely privacy sensitive. It is less so in VOIP IETF 68 – SPEERMINT WG