idnits 2.17.1 draft-partha-rtcweb-signaling-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 : ---------------------------------------------------------------------------- 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 date (October 3, 2011) is 4560 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) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-02 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-00 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-00 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RTCWeb working group Parthasarathi. Ravindran 2 Internet-Draft Sonus Networks, Inc. 3 Intended status: Standards Track October 3, 2011 4 Expires: April 5, 2012 6 RTCWeb standard signaling protocol 7 draft-partha-rtcweb-signaling-00 9 Abstract 11 The standardization of Real time communication between browsers is to 12 provide the infrastructure for audio, video, text communication using 13 standard interface so that interoperable communication can be 14 established between any compatible browsers. RTCWeb specific 15 Javascript API will be provided by browsers for developing real-time 16 web application. It is possible to develop signaling protocol like 17 Session Initiation Protocol (SIP) or Jingle or websocket extension or 18 custom-made signaling protocol in Javascript. There are lots of 19 issues in Javascript based signaling protocol. This document list 20 the need for standard signaling protocol between RTCWeb client 21 (browser) and RTCWeb server and possible signaling protocol for the 22 same. 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 5, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Issues without RTCWeb standard signaling protocol . . . . . . . 4 61 4. Standard RTCWeb signaling protocol advantages . . . . . . . . . 5 62 5. RTCWeb Protocol requirement and design consideration . . . . . 5 63 6. Possible RTCWeb signaling protocols . . . . . . . . . . . . . . 6 64 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11. Informative References . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The standardization of Real time communication between browsers is to 74 provide the infrastructure for audio, video, text communication using 75 standard interface so that interoperable communication can be 76 established between any compatible browsers. The detail overview of 77 RTCweb is available at [I-D.ietf-rtcweb-overview], RTCWeb usecase and 78 requirements are illustrated in 79 [I-D.ietf-rtcweb-use-cases-and-requirements], RTP usage for RTCWeb is 80 explained at [I-D.ietf-rtcweb-rtp-usage] and security consideration 81 is mentioned in [I-D.ietf-rtcweb-security] 83 RTCWeb specific Javascript API will be provided by browsers for 84 developing real-time web application. It is possible to develop 85 signaling protocol like Session Initiation Protocol (SIP) [RFC3261] 86 or Jingle [Jingle] or Websocket [I-D.ietf-hybi-thewebsocketprotocol] 87 extension or HTTP [RFC2616] custom-made signaling protocol in 88 Javascript. 90 Having said that, this document provides insight about the limitation 91 of custom made RTCWeb signaling protocol, need for standard RTCWeb 92 signaling protocol and the possible solutions for the same. 94 2. Architecture 96 RTCWeb signaling protocol architecture is as follows: 98 +-----------+ +-----------+ 99 | RTCWeb | Federation | RTCWeb | 100 | | Signaling | | 101 | |-------------| | 102 | Server | protocol | Server | 103 | | | | 104 +-----------+ +-----------+ 105 / \ 106 / \ RTCWeb 107 / \ Signaling 108 / \ 109 / RTCWeb \ 110 / Signaling \ 111 / \ 112 +-----------+ +-----------+ 113 | | | | 114 | | | | 115 | Browser | ------------------------- | Browser | 116 | | Media path | | 117 | | | | 118 +-----------+ +-----------+ 119 +-----------+ +-----------+ 120 |JS/HTML/CSS| |JS/HTML/CSS| 121 +-----------+ +-----------+ 123 Fig 1: RTCWeb signaling protocol architecture 125 In the above mentioned architecture, this document focus on 126 standardizing RTCWeb signaling between browser and RTCWeb server 128 3. Issues without RTCWeb standard signaling protocol 130 The issues in creating non standard RTCWeb sigaling protocol are 132 o Without RTCWeb standard signaling protocol, each website developer 133 has to understand the complication of signaling protocol for 134 making the real-time communication. 135 o Downloading the complete RTCWeb signaling protocol Javascript is 136 inefficient as it impact performance and setup delay of real-time 137 communication. The caching of Javascript shall avoid downloading 138 the signaling protocol in each time RTCWeb server is accessed. 139 But the Javascript cache is possible to be removed often which 140 leads to the impact. 141 o Also, browser has to download each website signaling protocol 142 indepentely 144 o Plugin is efficient as standard signaling protocol but defeat the 145 purpose of RTCWeb charter 147 4. Standard RTCWeb signaling protocol advantages 149 The defining signaling protocol is not a hindrance for any innovative 150 RTCWeb signaling protocol development as it is complementary 151 solution. The issues mentioned in non-existence of RTCWeb signaling 152 protocol is overcome by having standard RTCWeb signaling protocol. 153 The other advantages related to standard RTCWeb sigaling protocol are 154 as follows: 156 o RTCWeb developer has no need to know the intricacies of signaling 157 protocol for developing RTCWeb application. The effort involved 158 in making voice or video chat by each web developer shall be 159 overcome by providing standard signaling in RTCWeb client 160 o Gateway for RTCWeb server and legacy signaling protocol is easy in 161 case standard RTCweb signaling protocol is used. 162 o More efficient in case of browser having native RTCWeb signaling 163 protocol in browser 165 5. RTCWeb Protocol requirement and design consideration 167 Some of the RTCWeb signaling protocol requirement and design 168 considerations are as follows 170 o The mechanism has to create two way communications between RTCWeb 171 server and RTCweb client 172 o The mechanism has to provide the way to pass description about the 173 media transmission between two RTCweb clients 174 o The mechanism has to support the secure transmission of signaling 175 information 176 o The authentication between RTCweb client and RTCweb server has to 177 be supported 179 TBD: Complete list has to be mentioned. 181 The following criteria has to discussed in detail for the protocol 182 selection 184 o Signaling routing intelligence in RTCWeb client or only in RTCWeb 185 server 186 o RTCWeb client has to maintain the state of the communication or 187 not (intelligent vs. dumb) 189 o SDP [RFC4566] has to be used for media description or not 190 o Offer/answer [RFC3264] mechanism has to be supported in RTCWeb 191 client or not 192 o Signaling protocol has to address only basic two party 193 communication or more scenarios has to be taken into account 194 o User Identity has to be managed in RTCWeb client or not 195 o TBD: ??? 197 6. Possible RTCWeb signaling protocols 199 The following Signaling protocols will qualify for becoming standard 200 RTCWeb signaling protocol 202 1. Jingle 203 2. Websocket with SDP offer/answer 204 3. SIP 205 4. SIPLite [I-D.cbran-rtcweb-protocols] 206 5. Websocket with custom XML 207 6. Megaco [RFC5125] 208 7. Websocket with SIP [I-D.ibc-rtcweb-sip-websocket] 209 8. HTTP with custom XML 210 9. ??? 212 TBD: Pros and cons for each of the signaling mechanism has to be 213 added 215 7. Conclusion 217 The collection of more signaling requirements & design consideration, 218 analysis of those constraints with the list of possible RTCWeb 219 signaling protocol will lead to the selection of best signaling 220 protocol for RTCweb 222 8. Security Considerations 224 The selected RTCWeb signaling protocol has to meet all the security 225 consideration in [I-D.ietf-rtcweb-security]. There is no specific 226 security consideration associated with this draft. 228 9. IANA Considerations 230 This is no IANA consideration for this specification 232 10. Acknowledgement 234 TBD 236 11. Informative References 238 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 239 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 240 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 242 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 243 A., Peterson, J., Sparks, R., Handley, M., and E. 244 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 245 June 2002. 247 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 248 with Session Description Protocol (SDP)", RFC 3264, 249 June 2002. 251 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 252 Description Protocol", RFC 4566, July 2006. 254 [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", 255 RFC 5125, February 2008. 257 [I-D.ietf-rtcweb-overview] 258 Alvestrand, H., "Overview: Real Time Protocols for Brower- 259 based Applications", draft-ietf-rtcweb-overview-02 (work 260 in progress), September 2011. 262 [I-D.ietf-rtcweb-security] 263 Rescorla, E., "Security Considerations for RTC-Web", 264 draft-ietf-rtcweb-security-00 (work in progress), 265 September 2011. 267 [I-D.ietf-rtcweb-rtp-usage] 268 Perkins, C., Westerlund, M., and J. Ott, "RTP Requirements 269 for RTC-Web", draft-ietf-rtcweb-rtp-usage-00 (work in 270 progress), September 2011. 272 [I-D.ietf-rtcweb-use-cases-and-requirements] 273 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 274 Time Communication Use-cases and Requirements", 275 draft-ietf-rtcweb-use-cases-and-requirements-05 (work in 276 progress), September 2011. 278 [I-D.ietf-hybi-thewebsocketprotocol] 279 Fette, I. and A. Melnikov, "The WebSocket protocol", 280 draft-ietf-hybi-thewebsocketprotocol-17 (work in 281 progress), September 2011. 283 [I-D.ibc-rtcweb-sip-websocket] 284 Castillo, I., Millan, J., and V. Pascual, "WebSocket 285 Transport for Session Initiation Protocol (SIP)", 286 draft-ibc-rtcweb-sip-websocket-00 (work in progress), 287 September 2011. 289 [I-D.cbran-rtcweb-protocols] 290 Bran, C. and C. Jennings, "RTC-Web Communications 291 Protocols", draft-cbran-rtcweb-protocols-00 (work in 292 progress), June 2011. 294 [Jingle] "XEP-0166: Jingle", 295 . 297 Author's Address 299 Parthasarathi Ravindran 300 Sonus Networks, Inc. 301 Prestige Shantiniketan - Business Precinct 302 Whitefield Road 303 Bangalore, Karnataka 560066 304 India 306 Email: pravindran@sonusnet.com