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