idnits 2.17.1 draft-veikkolainen-sip-xmpp-coex-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 26, 2011) is 4810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-saintandre-sip-xmpp-core-01 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH WG S. Veikkolainen 3 Internet-Draft M. Isomaki 4 Intended status: Standards Track Nokia 5 Expires: July 30, 2011 January 26, 2011 7 Requirements and Use Cases for Combining SIP Based Real-time Media 8 Sessions With XMPP Based Instant Messaging and Presence Service. 9 draft-veikkolainen-sip-xmpp-coex-reqs-02 11 Abstract 13 This memo defines use cases and requirements for combining Session 14 Initiation Protocol (SIP) based real-time media sessions with 15 Extensible Messaging and Presence Protocol (XMPP) based instant 16 messaging and presence services in a seamless manner. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 30, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 54 3. Intended scope and deployment scenarios . . . . . . . . . . . . 3 55 4. Use cases and requirements . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 Currently most standards-based Voice over IP (VoIP) deployments use 67 Session Initiation Protocol (SIP) [RFC3261]. In addition to 68 providing basic voice service SIP has an extensive support for more 69 advanced telephony features including interworking with the 70 traditional Public Switched Telephone Network (PSTN). SIP is also 71 gaining popularity in the field of video communication. 73 At the same time, the Extensible Messaging and Presence Protocol 74 (XMPP; [RFC3920] and [RFC3921]) is enjoying widespread usage in 75 instant messaging and presence services. An interesting scenario 76 arises when a SIP based voice and video service is combined together 77 with an XMPP based instant messaging and presence service. 79 This memo presents a set of use cases and requirements for an 80 integrated SIP User Agent and XMPP client that aims to offer a 81 seamless user experience combining SIP based voice and video with 82 XMPP based instant messaging and presence. 84 The main issues that need to be addressed when offering such combined 85 services are identities and addressing. SIP and XMPP both use a 86 similar addressing scheme (based on "user@domain" structure) to 87 identify users and endpoints but there are some subtle differences as 88 well. We do not assume any algorithmic correlation or translation 89 between SIP and XMPP Universal Resource Identifiers (URI), even when 90 they identify the "same" user or endpoint. New protocol mechanisms 91 are needed to tie together communication contexts that are based on 92 the two protocols. 94 The document structure is as follows: Section 2 presents the document 95 conventions and definitions, Section 3 defines the scope and presents 96 deployment scenarios, and Section 4 describes use cases and 97 requirements. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119] and indicate requirement levels for compliant 105 implementations. 107 3. Intended scope and deployment scenarios 109 This section presents the intended scope of the work and the 110 assumptions that are made about SIP and XMPP deployments with respect 111 to endpoints and server infrastructure. 113 This work is about combined use of SIP and XMPP in a single 114 integrated endpoint. Protocol translation through a gateway between 115 SIP and XMPP is out of scope; that is the subject of other work, see 116 for example [I-D.saintandre-sip-xmpp-core]. 118 The initial focus is on one-to-one communication only. Multiparty 119 use cases such as combining SIP voice conference with XMPP IM group 120 chat are beyond the scope. This maybe subject of later work. 122 SIP is able to offer Presence and IM services via the SIP IM and 123 Presence Leveraging Extensions (SIMPLE)(see e.g. [RFC3428] and 124 [RFC3856]). XMPP is able to offer voice and video services via the 125 Jingle extension [XEP-0166]. Offering overlapping services (e.g. 126 presence) via both SIP and XMPP is out of scope of this document. 127 However, it is expected that such scenarios will exist, and 128 guidelines for developers and service providers may be given in other 129 documents. 131 It is assumed that combining SIP based real-time services with XMPP 132 based presence and IM service can be accomplished purely in the 133 endpoints; no support is needed in the service infrastructure. The 134 intent is that the combined SIP and XMPP endpoints can use already 135 existing SIP and XMPP services, which makes deployment much easier. 136 In general the SIP and XMPP service infrastructures can be totally 137 independent from each other. It is possible to achieve seamless 138 integration even when SIP and XMPP services are offered by different 139 service providers. It is of course possible (and likely) that the 140 same provider offers both SIP and XMPP service, but that does not 141 affect how endpoints use the protocols between each other. 143 We assume that the user initially only needs to know the contact 144 address of the other user in one protocol space. The contact address 145 for the other protocol must be learned by some means. 147 We consider only cases where two integrated endpoints interact. When 148 an integrated endpoint communicates with a separated endpoint, normal 149 SIP and XMPP procedures apply and no extensions defined in this memo 150 are used. 152 4. Use cases and requirements 154 In this section we enumerate the actual use cases that the combined 155 service must accommodate for, and define the protol requirements that 156 stem from these use cases. 158 The use cases are as follows: 160 o Two users who both use an integrated endpoint start an (XMPP) IM 161 conversation. After the exchange of initial messages, their UIs 162 show that the other party is capable of (SIP) voice and/or video 163 in addition to IM. Either user can at any point add voice and/or 164 video component to the conversation in such a way that at the 165 other user's end it arrives at the same endpoint and conversation 166 context where the IM exchange is already taking place. (Note that 167 for this use case the conversation initiator initially only needs 168 to know the other user's XMPP user id.) 170 o Two users who both use an integrated endpoint start a (SIP) voice 171 and/or video call. As the call is established, their UIs show 172 that the other party is capable for (XMPP) IM. Either user can at 173 any point add an IM component to the conversation in such a way 174 that at the other user's end it arrives at the same endpoint and 175 conversation context where the voice and/or video call is already 176 taking place. (Note that for this use case the caller initially 177 only needs to know the other user's SIP user id.) 179 It is possible to vary the two cases above so that one of the 180 users initiates a "multimedia call" to the other one, i.e. SIP 181 voice and/or video and XMPP IM are all active from the start. 182 Technically this may happen according to the two-phased 183 approach above, and it invisible from the end-user. 185 o A user of an integrated endpoint is able to publish her SIP voice 186 and video related presence status as part of her XMPP presence. 187 The status includes information such as user's SIP contact address 188 (for the integrated endpoint), media capability and availability 189 and whether the user is currently "on the phone". Another user of 190 an integrated endpoint can see the presence status (assuming she 191 is authorized for that) and based on that initiate calls or 192 populate her address book further use. For instance watcher's UI 193 can now for certain show that the user on her roster is capable of 194 receiving multimedia calls. (Note that the watcher initially only 195 needs to know the other user's XMPP user id.) 197 A user who has obtained another user's SIP URI is able to discover 198 the other user's XMPP URI so that she can send the other user XMPP 199 IM or subscribe to the other user's presence, or just populate her 200 address book for futher use. The user is able to do this without 201 bothering the other user, provided the other user has pre- 202 authorized the operation. 204 From the use cases, we can derive the following protocol 205 requirements: 207 REQ-1: When endpoint A sends an XMPP message to endpoint B, it must 208 be able to include its SIP address and correlation 209 information in the message, so that endpoint B can initiate a 210 SIP real-time media session with endpoint A. The SIP session 211 initiation must be able to carry information that allows 212 endpoint A to to correlate the session with the XMPP message 213 it sent earlier. 215 As including the same information in every XMPP message 216 would create some overhead, it is desirable to be able to 217 convey the SIP contact and correlation only once per IM 218 conversation/thread. 220 REQ-2: When endpoints A and B establish a real-time media session 221 with SIP, they must during the session initiation be able to 222 exchange their XMPP contact and correlation information so 223 that either endpoint can send an XMPP message to the other 224 endpoint. That XMPP message must be able to carry 225 information which allows its recipient to correlate it with 226 the SIP session. 228 REQ-3: It must be possible to include SIP address and status 229 information in XMPP presence. The information must contain 230 at least a SIP contact address to identify a user or a user 231 agent instance, media capabilities and general availability 232 status. 234 REQ-4: It must be possible for a user, who only knows another user's 235 SIP URI, to learn the other user's XMPP URI. 237 OPEN ISSUE: Should we define requirements related to error or 238 corner cases here. For instance what happens to communication 239 attempts after the other party has closed the conversation 240 context, e.g. a correlated XMPP message that is sent after the 241 related SIP session is terminated. Or a SIP INVITE that appears 242 two days after the XMPP IM conversation was ended. 244 NOTE: There is also an implicit requirement that we must take 245 Session Border Controllers into account when defining how SIP User 246 Agents are able to identify an existing session between them in a 247 common manner. 249 5. IANA Considerations 251 This document contains no IANA considerations. 253 6. Security Considerations 255 The contact and correlation information is sensitive and we need to 256 prevent connection hijacking and impersonation. If the contact 257 information that is sent over one protocol is forged, the identity 258 verification mechanism in the other no longer help as an attacker is 259 able to assert the false identity. 261 7. Acknowledgments 263 TBD 265 8. References 267 8.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 8.2. Informative References 274 [I-D.saintandre-sip-xmpp-core] 275 Saint-Andre, P., Houri, A., and J. Hildebrand, 276 "Interworking between the Session Initiation Protocol 277 (SIP) and the Extensible Messaging and Presence Protocol 278 (XMPP): Core", draft-saintandre-sip-xmpp-core-01 (work in 279 progress), March 2009. 281 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 282 A., Peterson, J., Sparks, R., Handley, M., and E. 283 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 284 June 2002. 286 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 287 and D. Gurle, "Session Initiation Protocol (SIP) Extension 288 for Instant Messaging", RFC 3428, December 2002. 290 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 291 Initiation Protocol (SIP)", RFC 3856, August 2004. 293 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 294 Protocol (XMPP): Core", RFC 3920, October 2004. 296 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 297 Protocol (XMPP): Instant Messaging and Presence", 298 RFC 3921, October 2004. 300 [XEP-0166] 301 Ludwig, S., Beda, J., Saint-Andre, P., McQueen, R., Egan, 302 S., and J. Hildebrand, "Jingle", December 2009, 303 . 305 Authors' Addresses 307 Simo Veikkolainen 308 Nokia 309 P.O. Box 407 310 NOKIA GROUP, FI 00045 311 Finland 313 Phone: +358 50 486 4463 314 Email: simo.veikkolainen@nokia.com 316 Markus Isomaki 317 Nokia 318 P.O. Box 100 319 NOKIA GROUP, FI 00045 320 Finland 322 Phone: +358 50 522 5984 323 Email: markus.isomaki@nokia.com