idnits 2.17.1 draft-li-rtcweb-jsep-xmpp-mapping-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([XEP-0166]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 30, 2012) is 4289 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) == Unused Reference: 'I-D.jennings-rtcweb-signaling' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 366, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0166' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb K. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track July 30, 2012 5 Expires: January 31, 2013 7 RTCWeb JSEP XMPP/Jingle Mapping 8 draft-li-rtcweb-jsep-xmpp-mapping-00 10 Abstract 12 This document proposes mapping message representations between RTCWeb 13 Javascript Session Establishment Protocol(JSEP) scheme and XMPP/ 14 Jingle [XEP-0166] messaging scheme. Such a signaling mapping is 15 intended to enable Javascript to use XMPP/Jingle to establish a 16 session between two RTCWeb enabled browsers. 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 January 31, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Media Setup Overview . . . . . . . . . . . . . . . . . . . 3 56 2.1. Initiating the Session . . . . . . . . . . . . . . . . . . 4 57 2.2. Exchange the ICE . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.1. Transport Information . . . . . . . . . . . . . . . . . . . 4 59 2.3. Receiving the Session . . . . . . . . . . . . . . . . . . . 5 60 2.3.1. Accept the Session . . . . . . . . . . . . . . . . . . . . 5 61 2.3.2. Terminate the Session . . . . . . . . . . . . . . . . . . . 5 62 2.4. Updates to the Session . . . . . . . . . . . . . . . . . . 5 63 2.4.1. Add Media . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.4.2. Modify Media . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4.3. Remove Media . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4.4. Accept Media . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4.5. Reject Media . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.4.6. Description Information . . . . . . . . . . . . . . . . . . 6 69 2.4.7. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.4.8. Error . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.5. Other Actions . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Example Message Flows . . . . . . . . . . . . . . . . . . . 6 74 3.1. Exchange Candidates . . . . . . . . . . . . . . . . . . . . 6 75 3.2. Add Contents . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3. Exchange Description Information . . . . . . . . . . . . . 8 78 4. Security Considerations . . . . . . . . . . . . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 84 7. Normative References . . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 In draft [I-D.ietf-rtcweb-jsep], it is mentioned that there are 91 several options for the signalling mechanisms: ROAP, SIP or XMPP/ 92 Jingle. 94 This document focuses on XMPP/Jingle and tries to explain how to use 95 JSEP and XMPP/Jingle to exchange session descriptions. 97 1.1. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Media Setup Overview 105 The example here shows a typical call setup using the JSEP model. We 106 assume the following architecture in this example, where UA is 107 synonymous with "browser", and JS is synonymous with "web 108 application". 110 In Figure 1, it shows the overall mapping architecture. 112 +----------------------+ 113 | Web | 114 | | 115 | Server | 116 +----------------------+ 117 / \ 118 / \ 119 Jingle / \ Jingle 120 / \ 121 / \ 122 / \ 123 +-------------+ +--------------+ 124 | Web | | Web | 125 | Application | | Application | 126 + ----------- + + ------------ + 127 ^ ^ 128 | SDP | SDP 129 | | 130 V (JSEP) V (JSEP) 131 +-------------+ +--------------+ 132 | Caller | | Callee | 133 | | <====== Media =======> | | 134 | Browser | | Browser | 135 +-------------+ +--------------+ 137 Figure 1: JSEP-XMPP/Jingle Mapping Architecture 139 2.1. Initiating the Session 141 To initiate a session, the Caller can send the offer to the Callee by 142 using Jingle "session-initiate" action. 144 CallerJS->CalleeJS: . 146 2.2. Exchange the ICE 148 2.2.1. Transport Information 150 To perform the ICE process, the Caller can exchange the ICE 151 candidates with the Callee by using Jingle "transport-info" action. 153 CallerJS->CalleeJS: . 155 CalleeJS->CallerJS: . 157 2.3. Receiving the Session 159 2.3.1. Accept the Session 161 If the Callee accepts a session, it can send back the answer by using 162 Jingle "session-accept" action. 164 CalleeJS->CallerJS: . 166 2.3.2. Terminate the Session 168 To terminate a session, the Caller can send the offer to the Callee 169 by using Jingle "session-terminate" action. 171 CallerJS->CalleeJS: . 173 2.4. Updates to the Session 175 2.4.1. Add Media 177 To add media (e.g.video) to an existing session, the Caller can use 178 Jingle "content-add" action. 180 CallerJS->CalleeJS: . 182 2.4.2. Modify Media 184 To modify media (e.g.change audio to video) to an existing session, 185 the Caller can use Jingle "content-modify" action. 187 CallerJS->CalleeJS: . 189 2.4.3. Remove Media 191 To remove media (e.g.video) to an existing session, the Caller can 192 use Jingle "content-remove" action. 194 CallerJS->CalleeJS: . 196 2.4.4. Accept Media 198 If the Callee accepts the "content-add" action to an existing session 199 from the Caller, Callee can send back answer by using Jingle 200 "content-accept" action. 202 CalleeJS->CallerJS: . 204 2.4.5. Reject Media 206 If the Callee rejects the "content-add" action to an existing session 207 from the Caller, Callee can send back answer by using Jingle 208 "content-reject" action. 210 CalleeJS->CallerJS: . 212 2.4.6. Description Information 214 To send informational hints about parameters related to an existing 215 session, for example, add new video sources to a call that already 216 has video, the Caller can indicate that by using Jingle "description- 217 info" action. 219 CallerJS->CalleeJS: . 221 2.4.7. Result 223 To acknowledge the description information to an existing session 224 from the Caller, Callee can send back answer by using IQ stanza of 225 "result" type. See [RFC6120]. 227 CalleeJS->CallerJS: . 229 2.4.8. Error 231 If there are errors occurred during an existing session, the Callee 232 can send back answer by using IQ stanza of "error" type. See 233 [RFC6120]. 235 CalleeJS->CallerJS: . 237 2.5. Other Actions 239 TBD 1: do we have usage for the following actions: "security-info", 240 "session-info"? 242 TBD 2: do we need to redefine a transport method? If yes, we can use 243 "transport-replace", "transport-accept", "transport-reject". 245 3. Example Message Flows 247 3.1. Exchange Candidates 249 In Figure 2, CallerJS uses Jingle "session-initiate" action to 250 initiate a session with CalleeJS, and uses Jingle "transport-info" to 251 exchange ICE candidates with CalleeJS. Then CalleeJS accepts the 252 session using Jingle "session-accept" action. After the media 253 session, CallerJS uses "session-terminate" action to terminate the 254 session, and CalleeJS acknowledges with IQ stanza of "result" type. 256 Caller JS Callee JS 257 | | 258 | | 259 |-------------------------------------->| 260 | | 261 | | 262 |-------------------------------------->| 263 | | 264 | | 265 |<--------------------------------------| 266 | | 267 | | 268 |<--------------------------------------| 269 | | 270 | Media Session | 271 |<=====================================>| 272 | | 273 | | 274 |-------------------------------------->| 275 | | 276 | | 277 |<--------------------------------------| 278 | | 280 Figure 2: Exchange Candidates 282 Message details go here... 284 3.2. Add Contents 286 In Figure 3, CallerJS uses Jingle "content-add" action to add video 287 media to an existing session. CalleeJS accepts that by using Jingle 288 "content-accept" action. For simplicity, candidate exchange is not 289 shown. 291 Caller JS Callee JS 292 | | 293 | | 294 |-------------------------------------->| 295 | | 296 | | 297 |<--------------------------------------| 298 | | 299 | Media Session | 300 |<=====================================>| 301 | | 303 Figure 3: Add Contents 305 Message details go here... 307 3.3. Exchange Description Information 309 In Figure 4, CallerJS uses Jingle "description-info" action to add 310 new video sources at the same time to a call that already has video. 311 CalleeJS also uses Jingle "description-info" action to indicate the 312 new sources to the remote side. After that, they uses IQ stanza of 313 "result" type to acknowledge each other. 315 Caller JS Callee JS 316 | | 317 | | 318 |-------------------------------------->| 319 | | 320 | | 321 |<--------------------------------------| 322 | | 323 | | 324 |-------------------------------------->| 325 | | 326 | | 327 |<--------------------------------------| 328 | | 329 | Media Session | 330 |<=====================================>| 331 | | 333 Figure 4: Exchange Description Information 335 Message details go here... 337 4. Security Considerations 339 TBD. 341 5. IANA Considerations 343 This document requires no actions from IANA. 345 6. Acknowledgements 347 The author would like to thank Kiran Kumar and Bert greevenbosch for 348 the reviews and feedbacks. 350 7. Normative References 352 [I-D.ietf-rtcweb-jsep] 353 Uberti, J. and C. Jennings, "Javascript Session 354 Establishment Protocol", draft-ietf-rtcweb-jsep-01 (work 355 in progress), June 2012. 357 [I-D.jennings-rtcweb-signaling] 358 Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ 359 Answer Protocol (ROAP)", 360 draft-jennings-rtcweb-signaling-01 (work in progress), 361 October 2011. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, March 1997. 366 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 367 with Session Description Protocol (SDP)", RFC 3264, 368 June 2002. 370 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 371 Protocol (XMPP): Core", RFC 6120, March 2011. 373 [XEP-0166] 374 XMPP Standards Foundation, "Jingle", Dec 2009. 376 Author's Address 378 Kepeng Li 379 Huawei Technologies 380 Huawei Base, Bantian, Longgang District 381 Shenzhen, Guangdong 518129 382 P. R. China 384 Phone: +86-755-28971807 385 Email: likepeng@huawei.com