| < draft-veikkolainen-sip-xmpp-coex-reqs-01.txt | draft-veikkolainen-sip-xmpp-coex-reqs-02.txt > | |||
|---|---|---|---|---|
| DISPATCH WG S. Veikkolainen | DISPATCH WG S. Veikkolainen | |||
| Internet-Draft M. Isomaki | Internet-Draft M. Isomaki | |||
| Intended status: Standards Track Nokia | Intended status: Standards Track Nokia | |||
| Expires: February 23, 2011 August 22, 2010 | Expires: July 30, 2011 January 26, 2011 | |||
| Requirements and Use Cases for Combining SIP Based Real-time Media | Requirements and Use Cases for Combining SIP Based Real-time Media | |||
| Sessions With XMPP Based Instant Messaging and Presence Service. | Sessions With XMPP Based Instant Messaging and Presence Service. | |||
| draft-veikkolainen-sip-xmpp-coex-reqs-01 | draft-veikkolainen-sip-xmpp-coex-reqs-02 | |||
| Abstract | Abstract | |||
| This memo defines use cases and requirements for combining Session | This memo defines use cases and requirements for combining Session | |||
| Initiation Protocol (SIP) based real-time media sessions with | Initiation Protocol (SIP) based real-time media sessions with | |||
| Extensible Messaging and Presence Protocol (XMPP) based instant | Extensible Messaging and Presence Protocol (XMPP) based instant | |||
| messaging and presence services in a seamless manner. | messaging and presence services in a seamless manner. | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on February 23, 2011. | This Internet-Draft will expire on July 30, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| skipping to change at page 5, line 49 ¶ | skipping to change at page 5, line 49 ¶ | |||
| populate her address book further use. For instance watcher's UI | populate her address book further use. For instance watcher's UI | |||
| can now for certain show that the user on her roster is capable of | can now for certain show that the user on her roster is capable of | |||
| receiving multimedia calls. (Note that the watcher initially only | receiving multimedia calls. (Note that the watcher initially only | |||
| needs to know the other user's XMPP user id.) | needs to know the other user's XMPP user id.) | |||
| A user who has obtained another user's SIP URI is able to discover | A user who has obtained another user's SIP URI is able to discover | |||
| the other user's XMPP URI so that she can send the other user XMPP | the other user's XMPP URI so that she can send the other user XMPP | |||
| IM or subscribe to the other user's presence, or just populate her | IM or subscribe to the other user's presence, or just populate her | |||
| address book for futher use. The user is able to do this without | address book for futher use. The user is able to do this without | |||
| bothering the other user, provided the other user has pre- | bothering the other user, provided the other user has pre- | |||
| authorized the operation. but | authorized the operation. | |||
| From the use cases, we can derive the following protocol | From the use cases, we can derive the following protocol | |||
| requirements: | requirements: | |||
| REQ-1: When endpoint A sends an XMPP message to endpoint B, it must | REQ-1: When endpoint A sends an XMPP message to endpoint B, it must | |||
| be able to include its SIP contact and correlation | be able to include its SIP address and correlation | |||
| information in the message, so that endpoint B can initiate a | information in the message, so that endpoint B can initiate a | |||
| SIP real-time media session with endpoint A. The SIP session | SIP real-time media session with endpoint A. The SIP session | |||
| initiation must be able to carry information that allows | initiation must be able to carry information that allows | |||
| endpoint A to to correlate the session with the XMPP message | endpoint A to to correlate the session with the XMPP message | |||
| it sent earlier. | it sent earlier. | |||
| As including the same information in every XMPP message | As including the same information in every XMPP message | |||
| would create some overhead, it is desirable to be able to | would create some overhead, it is desirable to be able to | |||
| convey the SIP contact and correlation only once per IM | convey the SIP contact and correlation only once per IM | |||
| conversation/thread. | conversation/thread. | |||
| REQ-2: When endpoints A and B establish a real-time media session | REQ-2: When endpoints A and B establish a real-time media session | |||
| with SIP, they must during the session initiation be able to | with SIP, they must during the session initiation be able to | |||
| exchange their XMPP contact and correlation information so | exchange their XMPP contact and correlation information so | |||
| that either endpoint can send an XMPP message to the other | that either endpoint can send an XMPP message to the other | |||
| endpoint. That XMPP message must be able to carry | endpoint. That XMPP message must be able to carry | |||
| information which allows its recipient to correlate it with | information which allows its recipient to correlate it with | |||
| the SIP session. | the SIP session. | |||
| REQ-3: It must be possible to include SIP real-time media related | REQ-3: It must be possible to include SIP address and status | |||
| contact and status in XMPP presence information. The | information in XMPP presence. The information must contain | |||
| information must contain at least SIP contact address to | at least a SIP contact address to identify a user or a user | |||
| identify a user or a user agent instance, media capabilities | agent instance, media capabilities and general availability | |||
| and general availability status. | status. | |||
| REQ-4: It must be possible for a user, who only knows another user's | REQ-4: It must be possible for a user, who only knows another user's | |||
| SIP URI, to learn the other user's XMPP URI. | SIP URI, to learn the other user's XMPP URI. | |||
| OPEN ISSUE: Should we define requirements related to error or | OPEN ISSUE: Should we define requirements related to error or | |||
| corner cases here. For instance what happens to communication | corner cases here. For instance what happens to communication | |||
| attempts after the other party has closed the conversation | attempts after the other party has closed the conversation | |||
| context, e.g. a correlated XMPP message that is sent after the | context, e.g. a correlated XMPP message that is sent after the | |||
| related SIP session is terminated. Or a SIP INVITE that appears | related SIP session is terminated. Or a SIP INVITE that appears | |||
| two days after the XMPP IM conversation was ended. | two days after the XMPP IM conversation was ended. | |||
| End of changes. 7 change blocks. | ||||
| 11 lines changed or deleted | 11 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||