idnits 2.17.1 draft-sipdoc-rtcweb-open-wire-protocol-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2011) is 4559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-jennings-rtcweb-signaling-00 == Outdated reference: A later version (-04) exists of draft-moffitt-xmpp-over-websocket-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Baz Castillo 3 Internet-Draft XtraTelecom S.A. 4 Intended status: Informational S. Ibarra Corretge 5 Expires: April 27, 2012 AG Projects 6 J. Millan Villegas 7 XtraTelecom S.A. 8 October 25, 2011 10 Open In-The-Wire Protocol for RTC-Web 11 draft-sipdoc-rtcweb-open-wire-protocol-00 13 Abstract 15 RTC-Web clients communicate with a server in order to request or 16 manage realtime communications with other users. This document 17 exposes four hypothetical and different RTC-Web scenarios and 18 analyzes the requirements of the in-the-wire protocol in each of 19 them. 21 The aim of this document is to make RTC-Web properly fit in the 22 nature of the Web. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 27, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Overview of an RTC-Web Communication . . . . . . . . . . . . . 7 62 5. More Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. RTC-Web in Facebook . . . . . . . . . . . . . . . . . . . 12 64 5.2. SIP over WebSocket . . . . . . . . . . . . . . . . . . . . 14 65 5.3. Poker Game . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 7. New Requirements for RTC-Web . . . . . . . . . . . . . . . . . 18 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 75 1. Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 In contrast to protocols such as SIP [RFC3261] or XMPP [RFC6120], 84 RTC-Web [RTC-Web] does not define a protocol for establishing media 85 sessions between peers. Instead RTC-Web defines the media protocols 86 (RTP/SRTP/ICE) to be used by web browsers. It also states how the 87 web browser natively handles media streams (including media security 88 and validation concerns), defines the requirements for the 89 communication between the RTC-Web stack in the browser and the web 90 application (via a JavaScript API to be defined by W3C) and MAY 91 suggest some kind of media negotiation protocol to be carried in-the- 92 wire between RTC-Web clients and servers. 94 That said, RTC-Web does not mandate any user identifier syntax (in 95 the way SIP defines the SIP URI), nor an authentication mechanism, 96 in-the-wire messages format or the way messages are exchanged between 97 RTC-Web clients and servers. There are many different ways by which 98 those targets can be achieved nowadays on the Web. 100 All this flexibility makes the whole picture of an RTC-Web scenario 101 and the scope in which RTC-Web is involved hard to understand. This 102 document tries to identify each component in the RTC-Web architecture 103 and clarify which components can be left up to web developers and 104 which others should be mandated by RTC-Web specifications. 106 3. Definitions 108 The following terms have special significance in the context of RTC- 109 Web. 111 JavaScript WebRTC API: This is the communication layer between the 112 native RTC-Web stack in the browser and JavaScript. It 113 includes JavaScript functions to manage media sessions along 114 with JavaScript callbacks which will be called by the RTC-Web 115 stack when some media related event takes place. This API MUST 116 be exposed by every RTC-Web compliant browser. It's being 117 defined by W3C. 119 RTC-Web Server: The server that RTC-Web clients communicate with for 120 initiating and managing media sessions with remote peers. This 121 is usually an HTTP [RFC2616] server or a WebSocket 122 [I-D.ietf-hybi-thewebsocketprotocol] server behaving as a 123 centralized point for signaling messages exchanged between 124 peers (and MAY accomplish other tasks such as authentication, 125 authorization, peer lookup procedures and protocol conversion). 126 A given RTC-Web server will implement the In-The-Wire Protocol 127 (defined below) chosen by the website developer. 129 In-The-Wire Protocol: This is the communication layer between users' 130 web browser and the RTC-Web Server. It involves a signaling 131 protocol to be carried over HTTP or WebSocket (the protocols 132 JavaScript can interact with). The messages exchanged over 133 this protocol contain call control information and media 134 negotiation information (both Call Control Protocol and Media 135 Negotiation Protocol explained next). 137 Call Control Protocol: This involves the format and semantics of the 138 messages exchanged between the RTC-Web client (web browser) and 139 the RTC-Web Server for routing and other purposes such as 140 authorization, authentication, registration and others. 141 Examples of a Call Control Protocol could be SIP or XMPP 142 carried over HTTP or WebSocket, whose messages contain 143 information about the originator and recipient of the message, 144 credentials, type of message, etc. However any other custom 145 protocol (such as HTTP POST or some JSON-based protocol over 146 WebSocket) can accomplish this task. Call Control Protocol 147 messages MAY carry media negotiation information (in the same 148 way a SIP INVITE request contains an SDP body). 150 Media Negotiation Protocol: When a RTC-Web client wants to establish 151 a media session with a remote peer, it sends a Call Control 152 Protocol request over the wire to the RTC-Web Server indicating 153 the destination of the request (along with other fields). Such 154 a request also carries media information exposed by the 155 originator. In the SIP protocol example, the Media Negotiation 156 Protocol is represented by the SDP offer/answer body conveyed 157 by INVITE and 200 OK messages (simplified). In the case of 158 RTC-Web, such media negotiation MAY be carried as ROAP 159 [I-D.jennings-rtcweb-signaling] Offer/Answer JSON objects. 161 JavaScript RTC-Web Library: This is a website-agnostic JavaScript 162 library. Web developers (end-users) can include it within 163 their websites. The library defines a custom In-The-Wire 164 Protocol by providing an API with functions for generating 165 requests and responses (to be sent in-the-wire) along with 166 callbacks for processing incoming request/responses and state 167 change notifications. This JavaScript library is coded by an 168 RTC-Web expert and is supposed to hide the complexity of the 169 JavaScript WebRTC API and the management of the In-The-Wire 170 Signaling to the end-user. This is the API the end-user should 171 use and care about (and here is where the famous term "20 lines 172 of code" applies). 174 JavaScript WebSite Library: This is the custom JavaScript library 175 that a web developer (the end-user) provides in his website. 176 In the context of RTC-Web, this custom library is supposed to 177 make usage of functions and features present in a JavaScript 178 RTC-Web Library (defined above). This is the library in which 179 the end-user writes "20 lines of code" for integrating RTC-Web 180 capabilities within his website. 182 4. Overview of an RTC-Web Communication 184 Here a hypothetical and very simple RTC-Web scenario is described: 186 o A user visits a web page "mysite.com" using his browser and 187 logs-in the web by introducing his username (Bob) and password. 188 The authentication is achieved by sending an HTTP POST request 189 with the user's credentials. The web server validates the 190 credentials and replies with a HTTP 200 response containing a 191 Cookie "kj87kjsdhf" to be used within the same session. The user 192 is redirected to a new page from which the browser retrieves two 193 JavaScript libraries: 195 rtcquery.js (a JavaScript RTC-Web Library): This is a GPL 196 JavaScript library implementing a custom In-The-Wire 197 Protocol for RTC-Web based on JSON and WebSocket. This 198 library is becoming the most successful and extended RTC-Web 199 library and there are O'Reilly books about it. 201 mysite.js (a JavaScript WebSite Library): This is the JavaScript 202 code created by the web developer of "mysite.com". It 203 includes website specific functions and makes use of the 204 "rtcquery.js" library to incorporate RTC-Web capabilities to 205 the web page (by adding "20 lines of code"). 207 o Once all the JavaScript code (both "rtcquery.js" and "mysite.js") 208 is loaded by the browser, it opens a WebSocket connection with the 209 web server, which is also a WebSocket server listening on the same 210 port (it could be a different server though). 212 o The web developer of "mysite.com" has implemented the In-The-Wire 213 Protocol defined in "rtcquery.js" into his WebSocket server using 214 PHP. For this task, the developer has studied the documentation 215 available in the website of the rtcQuery.js project. 217 o The custom In-The-Wire Protocol states that each request sent over 218 the WebSocket connection is a JSON object containing: 220 A mandatory Call Control Protocol section: This includes fields 221 such as "call-id" (a common string for all the requests/ 222 responses within the same call), "transaction-id" (an 223 integer for correlating a request and its associated 224 responses), "request-type" (for example "call"), "source- 225 user" (current user), "destination-user" (the remote peer), 226 "subject" (some description of the call) and "cookie" (the 227 Cookie sent by web server, which is used by the client to 228 identify itself and get authorization by the WebSocket 229 server). 231 An optional Media Negotiation Protocol section: This is conveyed 232 by attaching a ROAP [I-D.jennings-rtcweb-signaling] Offer or 233 OK JSON object. 235 o In-The-Wire Protocol responses are similar to the requests, but 236 instead of "request-type" and "subject", they contain a "status" 237 field indicating the nature of the response (which can be 238 "accepted", "rejected" or "not-online") and instead of a ROAP 239 Offer they MAY contain a ROAP Answer. 241 o The new page rendered by the browser includes a big section with 242 "online" users (those that are available for audio/video 243 sessions). The user wants to make an audio call with Alice (who 244 is online) and clicks a "Call" button next to Alice's buddy. 246 o Then the JavaScript code makes a call (using the JavaScript WebRTC 247 API) to the browser RTC-Web stack in order to ask for a ROAP Offer 248 object with just "audio" capability (note: PeerConnection stuff 249 ommited for brevity). The RTC-Web stack performs some internal 250 operations to discover the browser IP, gets some available UDP 251 port for sending RTP, chooses an audio codec from the list of 252 available codecs in the browser, and returns the ROAP Offer JSON 253 object. 255 o After that, the JavaScript code constructs an In-The-Wire Protocol 256 request (a JSON object) as follows: 258 { 259 "request": { 260 "call-id": "0skilqwp", 261 "transaction-id": 1001, 262 "request-type": "call", 263 "source-user": "Bob", 264 "destination-user": "Alice", 265 "subject": null, 266 "cookie": "kj87kjsdhf", 267 "media": _ROAP_OFFER_OBJECT_ 268 } 269 } 271 o The JavaScript code sends the request to the web server via the 272 existing WebSocket connection. 274 o The server inspects the "cookie" and the "source-user" fields, and 275 authorizes the request since such Cookie value is associated to an 276 existing web session owned by Bob. 278 o Then the server checks for Alice's status. Alice is online and 279 connected via WebSocket to the server, so using such connection 280 the server delivers the request to Alice (previously removing the 281 "cookie" field). 283 o Alice's browser receives the request and some JavaScript callback 284 (defined by the JavaScript code when a WebSocket messsage is 285 received) is called. Alice is prompted to accept or reject the 286 incoming call request from Bob. Alice presses "Accept". 288 o The JavaScript code in Alice's browser makes a call (using the 289 JavaScript WebRTC API) to the browser RTC-Web stack and gets a 290 ROAP Answer object with just "audio" capability. Then it 291 constructs an In-The-Wire Protocol response as follows (note that 292 it includes her Cookie) and sends it to the server via the 293 WebSocket connection: 295 { 296 "response": { 297 "call-id": "0skilqwp", 298 "transaction-id": 1001, 299 "status": "accepted", 300 "source-user": "Alice", 301 "destination-user": "Bob", 302 "cookie": "t112mnkszz", 303 "media": _ROAP_ANSWER_OBJECT_ 304 } 305 } 307 o The server inspects the "cookie" and "source-user" and validates 308 the response. Then it inspects the "destination-user" and routes 309 the response object to Bob. 311 o Upon receipt of the response, the JavaScript code in Bob's browser 312 automatically sends a request acknowledging the response to the 313 server: 315 { 316 "request": { 317 "call-id": "0skilqwp", 318 "transaction-id": 1001, 319 "request-type": "ack", 320 "source-user": "Bob", 321 "destination-user": "Alice", 322 "cookie": "kj87kjsdhf", 323 "media": _ROAP_OK_MESSAGE_ 324 } 325 } 327 o The request is routed to Alice's browser and its ROAP OK message 328 automatically delivered to the RTC-Web stack by the JavaScript 329 code. 331 o At this point, both Bob and Alice's browsers perform ICE 332 connectivity checks and finally establish a RTP audio session. 333 The success of the media session establishment is notified to the 334 users via some JavaScript pop-up. 336 o After a while Alice decides to terminate the call by pressing a 337 "Hangup" button. The JavaScript code asks the RTC-Web stack in 338 the browser to finish sending RTP and sends a JSON request to Bob 339 via the WebSocket connection: 341 { 342 "request": { 343 "call-id": "0skilqwp", 344 "transaction-id": 1002, 345 "request-type": "hangup", 346 "source-user": "Alice", 347 "destination-user": "Bob", 348 "cookie": "t112mnkszz" 349 } 350 } 352 o Bob receives the request. His JavaScript code calls the RTC-Web 353 stack to finish the media session (by passing it some "session-id" 354 identifier retrieved from the initial ROAP Offer). 356 o Session is now terminated. Bob did not get a date with Alice, but 357 has been enjoying a RTC experience so he is satisfied. 359 Lets inspect the RTC-Web components as defined by this document in 360 the given scenario: 362 RTC-Web Server: A WebSocket server running in the same port as the 363 web server. 365 In-The-Wire Protocol: Custom JSON messages over WebSocket transport. 367 Call Control Protocol: All the fields in the JSON message (but the 368 "media" field). 370 Media Negotiation Protocol: The media information is located in the 371 "media" parameter of the JSON message. It's carried as ROAP 372 Offer/Answer JSON object. 374 JavaScript RTC-Web Library: "rtcquery.js" library made GPL by the 375 rtcQuery.js project. 377 JavaScript WebSite Library: "mysite.js" custom library (makes use of 378 "rtcquery.js"). 380 5. More Use Cases 382 5.1. RTC-Web in Facebook 384 Facebook integrates IM (instant messaging) into its web application. 385 For that the JavaScript code performs HTTP long polling for 386 retrieving incoming IM messages in realtime, and sends an HTTP POST 387 request when a user sends a message to another user. Such HTTP POST 388 requests look as follows: 390 POST /ajax/chat/send.php?__a=1 HTTP/1.1 391 Host: www.facebook.com 392 Connection: keep-alive 393 X-SVN-Rev: 460802 394 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 395 Referer: http://www.facebook.com/?sfrm=1 396 Content-Length: XXX 397 Cookie: datr=ZjyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2; 398 lu=RgQytVtJJBoSvWUNOYzs0oQg; sct=1319153603; 399 xs=60%3A1c179a7dfb7f08278477b20e778bd391; p=112; 400 presence=631L212REp_5f1B08654409875F4EriF0CEstateFDutF131910363 \ 401 96EvisF1HsndF1ODiFA21B02609687525A2C_5dEfFA21B02602687525A2Euct \ 402 319103618FD55F1G318103604PEuoFD1B02602687525FDexpF1319103680370 \ 403 lF_5b1_5dEolF0CCEalFD1B02602687525FDiF0umF0CCCC; 404 wd=1366x675 405 Pragma: no-cache 406 Cache-Control: no-cache 408 msg_id=1319103647568%3A3629978310&client_time=1319103646048& 409 to=100002772687525&num_tabs=1&pvs_time&msg_text=hello& 410 to_offline=false&to_idle=false&window_id=2877189837& 411 sidebar_launched=true&sidebar_enabled=true&sidebar_capable=true& 412 sidebar_should_show=false&sidebar_visible=false& 413 post_form_id=449eb730c851e127f21d8a88b6a00667&fb_dtsg=AQC3StlW&lsd& 414 post_form_id_source=AsyncRequest&__user=100002624409995 416 The above request contains some parameters in both the Cookie header 417 and the body. The Cookie header seems to contain information about 418 the identity of the user sending the IM message. The Cookie value is 419 probably also used for authentication in the server. The "msg_text" 420 parameter in the body contains the IM text message itself while the 421 "to" parameter in the body seems to contain the destination user (a 422 long integer probably representing the user ID). The meaning of 423 other parameters in both the Cookie and the body are up to Facebook, 424 this is, they are specific to the application. It seems obvious that 425 it's not possible to standarize all these parameters. 427 Assuming that Facebook is willing to integrate RTC-Web within the web 428 application, it makes sense that Facebook would be interested in 429 reusing the same protocol and message format it's already using for 430 IM (which is also realtime communication). So when a user clicks 431 some "Call" button within his Facebook contact list, it is expected 432 that the JavaScript code could generate an HTTP POST as follows: 434 POST /ajax/call/call.php?__a=1 HTTP/1.1 435 Host: www.facebook.com 436 Connection: keep-alive 437 X-SVN-Rev: 460802 438 Content-Type: application/x-www-form-urlencoded; charset=UTF-8 439 Referer: http://www.facebook.com/?sfrm=1 440 Content-Length: XXX 441 Cookie: datr=ZjyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2; 442 lu=RgQytVtJJBoSvWUNOYzs0oQg; sct=1319153603; 443 xs=60%3A1c179a7dfb7f08278477b20e778bd391; p=112; 444 presence=631L212REp_5f1B08654409875F4EriF0CEstateFDutF131910363 \ 445 96EvisF1HsndF1ODiFA21B02609687525A2C_5dEfFA21B02602687525A2Euct \ 446 319103618FD55F1G318103604PEuoFD1B02602687525FDexpF1319103680370 \ 447 lF_5b1_5dEolF0CCEalFD1B02602687525FDiF0umF0CCCC; 448 wd=1366x675 449 Pragma: no-cache 450 Cache-Control: no-cache 452 call_id=1319103647568%3A3629978310&client_time=1319103646048& 453 to=100002772687525&num_tabs=1&pvs_time&to_offline=false& 454 to_idle=false&window_id=2877189837&sidebar_launched=true& 455 sidebar_enabled=true&sidebar_capable=true& 456 sidebar_should_show=false&sidebar_visible=false& 457 post_form_id=449eb730c851e127f21d8a88b6a00667&fb_dtsg=AQC3StlW& 458 lsd&post_form_id_source=AsyncRequest&__user=100002624409995& 459 media=_ROAP_OFFER_OBJECT_ 461 The new HTTP POST request differs in the request URI (which now 462 points to "/ajax/call/call.php"). The body includes a "media" 463 parameter whose value is a ROAP Offer JSON object (properly encoded 464 if necessary). 466 Given this HTTP POST request, lets inspect the RTC-Web components as 467 defined by this document: 469 RTC-Web Server: Facebook uses their HTTP servers as RTC-Web servers. 471 In-The-Wire Protocol: Facebook uses HTTP protocol and a common HTTP 472 POST request. 474 Call Control Protocol: The information about the call originator is 475 mainly included in the Cookie header, while other topics as the 476 destination user of the call are located in the body (the "to" 477 parameter). 479 Media Negotiation Protocol: The media information is located in the 480 "media" parameter of the body. In this case Facebook uses a 481 ROAP Offer JSON object for carrying such media information. 483 JavaScript RTC-Web Library: It is expected to be an advanced 484 JavaScript library designed by Facebook which also includes 485 other functions unrelated to RTC-Web. 487 JavaScript WebSite Library: Merged with the JavaScript RTC-Web 488 Library into a single JavaScript file. 490 If Facebook would desire to interoperate (federate) with a SIP 491 network it is clear that it would need a signaling protocol gateway 492 which converts the HTTP POST information into a SIP request, and the 493 ROAP Offer into a SDP body. 495 5.2. SIP over WebSocket 497 This is an optimal solution for interoperating with SIP without 498 requiring a protocol gateway. In this scenario the web user 499 downloads a JavaScript code from the website and the JavaScript code 500 establishes a WebSocket connection with a SIP proxy (the RTC-Web 501 server) implementing the WebSocket transport 502 [I-D.ibc-rtcweb-sip-websocket] (along with other common SIP 503 transports as UDP and TCP). The messages exchanged between the RTC- 504 Web client and server over the WebSocket connection are pure SIP 505 requests and responses, with no modifications (others than the new 506 "WS" transport identificator in the Via header). 508 When the user makes a call from the web it generates a SIP INVITE to 509 be sent over the WebSocket connection, which looks as follows: 511 INVITE sip:bob@example.org SIP/2.0 512 Via: SIP/2.0/WS invalid.domain;branch=z9hG4bK56sdasks 513 From: sip:alice@example.org;tag=asdyka899 514 To: sip:bob@example.org 515 Call-ID: asidkj3ss 516 CSeq: 1 INVITE 517 Max-Forwards: 70 518 Contact: 519 Supported: path, outbound 520 Content-Type: application/sdp 521 _SDP_ 523 For this to work, the JavaScript code must map the ROAP Offer 524 retrieved via the JavaScript WebRTC API into a normal SDP (it's not 525 the aim of this documment to discuss about the complexity such 526 mapping could involve). 528 When the INVITE arrives to the RTC-Web Server (which behaves as a 529 pure SIP proxy) it just performs standard SIP routing procedures (the 530 same as if the request would have arrived via UDP or TCP transports), 531 so there is no need for a protocol gateway when interoperating with a 532 pure SIP network out there. 534 Given this INVITE request, lets inspect the RTC-Web components as 535 defined by this document: 537 RTC-Web Server: A SIP proxy that also implements the WebSocket 538 transport. 540 In-The-Wire Protocol: Pure SIP protocol. 542 Call Control Protocol: Contained in the headers of the SIP request 543 (From, request URI, Contact, Authorization...). 545 Media Negotiation Protocol: The session description (SDP) carried in 546 the SIP request body. 548 JavaScript RTC-Web Library: It could be a GPL "jssip.js" library 549 implementing SIP over WebSocket and a SIP stack in JavaScript. 551 JavaScript WebSite Library: Website specific. It would make use of 552 the "jssip.js" library for adding RTC-Web capabilities "in 20 553 lines of code". 555 5.3. Poker Game 557 A website "www.poker-game.info" makes use of HTTP Comet technology 558 for carrying realtime information about the game to each participant. 559 The messages exchanged via HTTP Comet between participants and the 560 web server are XML documents conveying updates and actions happening 561 during the game. 563 Now that website wants to integrate RTC-Web capabilities and enter 564 each participant into an audio multiconference in which every user 565 listens to all the participants and can speak to them. 567 To accomplish this architecture and still reuse the existing design, 568 once the user logs-in the web his browser receives an incoming audio 569 call from the conference server. Such call request is carried over 570 the HTTP connection (HTTP Comet) as a new XML document which looks as 571 follows: 573 574 575 call 576 _ROAP_OFFER_XML_ 577 579 The ROAP Offer is generated by the conference server, which satisfies 580 all the media requirements of RTC-Web (ICE, SRTP). 582 The JavaScript code in the client side answers the call (once the 583 user accepted it) and sends a similar XML containing a ROAP Answer 584 via the existing HTTP connection. 586 Given the above XML document, lets inspect the RTC-Web components as 587 defined by this document: 589 RTC-Web Server: The web server of "www.poker-game.info". 591 In-The-Wire Protocol: Custom XML document through HTTP Comet. 593 Call Control Protocol: It's minimal. There is no information about 594 the originator or recipient of the call (not needed in this 595 scenario). The XML contains an "action" field whose value 596 "call" means "incoming call request from the website". 598 Media Negotiation Protocol: A ROAP Offer/Answer in XML format. 600 JavaScript RTC-Web Library: A library created by the developer of 601 "www.poker-game.info". It implements the In-The-Wire Protocol 602 as stated above. 604 JavaScript WebSite Library: It is merged with the JavaScript RTC-Web 605 Library, so there is a single JavaScript file. 607 6. Conclusions 609 This document has shown four hypothetical scenarios of RTC-Web. Each 610 scenario uses its own In-The-Wire Protocol (JSON over WebSocket, HTTP 611 POST, SIP over WebSocket and XML over HTTP Comet) and it's hard to 612 expect that all these scenarios could be constrained to use the same 613 protocol and message format in-the-wire. The needs of each scenario 614 are not the same, neither the custom fields carried in-the-wire (see 615 for example the ammount of custom parameters Facebook includes within 616 the HTTP POST request). 618 In the Web each website decides how to accomplish the features and 619 capabilities it wants to provide to its users. Mandating the message 620 format in-the-wire seems not to be an option given the nature of the 621 Web. Mandating it would also make RTC-Web integration very hard into 622 existing websites which already implement their custom signaling 623 protocol and message format for realtime communications (as instant 624 messaging), their authentication mechanisms, etc. 626 RTC-Web will bridge the gap between realtime communication services 627 such as VoIP and the Web, so it must play by the rules present on the 628 Web. These rules include the freedom by which the web developer 629 chooses his preferred option to innovate and offer new services to 630 users. That is the key to success of the Web and should be 631 respected. 633 7. New Requirements for RTC-Web 635 Given the conclusions in the previous section, this document states 636 some new requirements for RTC-Web: 638 1. It MUST be possible for a website developer to design his own In- 639 The-Wire Protocol (including the messages format and transport 640 used for carrying such messages). 642 2. It MUST be possible for a website developer to choose his 643 favourite JavaScript RTC-Web Library and adapt his web 644 application to make use of it. 646 3. It MUST be possible for a website developer to design a Media 647 Negotiation Protocol in which the media information is not 648 carried as ROAP Offer/Answer objects (by letting the developer 649 implement the ROAP mapping in JavaScript). 651 NOTE: This text is written assuming that ROAP 652 [I-D.jennings-rtcweb-signaling] becomes a standard in RTC-Web. 654 4. It MUST be possible for a website developer to make his RTC-Web 655 scenario to interoperate with a pure SIP or XMPP/Jingle network 656 without requiring a signaling protocol gateway (by using SIP over 657 WebSocket [I-D.ibc-rtcweb-sip-websocket] or XMPP over WebSocket 658 [I-D.moffitt-xmpp-over-websocket]). 660 This would be indeed feasible if previous bullets are 661 satisfied. 663 8. Security Considerations 665 Not applicable. 667 9. IANA Considerations 669 Not applicable. 671 10. References 673 10.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, March 1997. 678 10.2. Informative References 680 [I-D.ibc-rtcweb-sip-websocket] 681 Castillo, I., Millan, J., and V. Pascual, "WebSocket 682 Transport for Session Initiation Protocol (SIP)", 683 draft-ibc-rtcweb-sip-websocket-00 (work in progress), 684 September 2011. 686 [I-D.ietf-hybi-thewebsocketprotocol] 687 Fette, I. and A. Melnikov, "The WebSocket protocol", 688 draft-ietf-hybi-thewebsocketprotocol-17 (work in 689 progress), September 2011. 691 [I-D.jennings-rtcweb-signaling] 692 Jennings, C. and J. Rosenberg, "RTCWeb Offer/Answer 693 Protocol (ROAP)", draft-jennings-rtcweb-signaling-00 (work 694 in progress), October 2011. 696 [I-D.moffitt-xmpp-over-websocket] 697 Moffitt, J. and E. Cestari, "An XMPP Sub-protocol for 698 WebSocket", draft-moffitt-xmpp-over-websocket-00 (work in 699 progress), December 2010. 701 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 702 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 703 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 705 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 706 A., Peterson, J., Sparks, R., Handley, M., and E. 707 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 708 June 2002. 710 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 711 Protocol (XMPP): Core", RFC 6120, March 2011. 713 [RTC-Web] IETF and W3C, "Real Time Collaboration on the World Wide 714 Web", October 2010. 716 Authors' Addresses 718 Inaki Baz Castillo 719 XtraTelecom S.A. 720 Barakaldo, Basque Country 721 Spain 723 Email: ibc@aliax.net 725 Saul Ibarra Corretge 726 AG Projects 727 Amsterdam, 728 Netherlands 730 Email: saul@ag-projects.com 732 Jose Luis Millan Villegas 733 XtraTelecom S.A. 734 Bilbao, Basque Country 735 Spain 737 Email: jmillan@aliax.net