idnits 2.17.1 draft-kaplan-rtcweb-api-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 31, 2011) is 4559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Kaplan 3 Internet Draft Acme Packet 4 Intended status: Informational D. Burnett 5 Expires: April 31, 2012 Voxeo 6 N. Stratford 7 Voxeo 8 Tim Panton 9 PhoneFromHere.com 10 October 31, 2011 12 API Requirements for WebRTC-enabled Browsers 14 draft-kaplan-rtcweb-api-reqs-01 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with 19 the provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 31, 2011. 39 Copyright and License Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the BSD License. 54 Abstract 56 This document discusses the advantages and disadvantages of several 57 proposed approaches to what type of API and architectural model 58 WebRTC Browsers should expose and use. The document then defines 59 the requirements for an API that treats the Browser as a library and 60 interface as opposed to a self-contained application agent. 62 Table of Contents 64 1. Terminology...................................................2 65 2. Introduction..................................................2 66 3. Defining a WebRTC Protocol in the Browser.....................4 67 4. Leaving Logic to Web Developers...............................6 68 5. API Requirements..............................................8 69 5.1. Browser User-Interface Requirements......................8 70 5.2. Media Properties.........................................9 71 5.3. RTP/RTCP Properties.....................................10 72 5.4. Data-stream Properties..................................11 73 5.5. IP and ICE Properties...................................11 74 5.6. API Design Recommendations..............................12 75 6. Security Considerations......................................12 76 7. IANA Considerations..........................................12 77 8. Acknowledgments..............................................12 78 9. References...................................................12 79 9.1. Informative References..................................12 80 Authors' Addresses...............................................12 82 1. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119. The 87 terminology in this document conforms to RFC 2828, "Internet 88 Security Glossary". 90 2. Introduction 92 There has been a long discussion in the RTCWEB Working Group mailing 93 list concerning whether any "signaling" or protocol should be 94 standardized between the Browser and its Server, other Browsers, or 95 the JavaScript it runs. 97 Within the context of the WebRTC Browser architecture, shown in 98 Figure 1 below, the discussion is centered on how much intelligence, 99 logic, state, and decisions are built into the Browser, vs. provided 100 by Javascript. 102 +------------------------+ On-the-wire 103 | | Protocols 104 | Servers |---------> 105 | | 106 | | 107 +------------------------+ 108 ^ 109 | 110 | 111 | HTTP/ 112 | Websockets 113 | 114 | 115 +----------------------------+ 116 | Javascript/HTML/CSS | 117 +----------------------------+ 118 Other ^ ^WebRTC 119 APIs | |API 120 +---|-----------------|------+ 121 | | | | 122 | +---------+| 123 | | Browser || On-the-wire 124 | Browser | RTC || Protocols 125 | | Function|-----------> 126 | | || 127 | | || 128 | +---------+| 129 +---------------------|------+ 130 | 131 V 132 Native OS Services 134 Figure 1: Browser Model 136 There has been some discussion that the protocol running over the 137 HTTP/Websockets connection between the Javascript and the Server be 138 standardized, which will be discussed in this document. 140 There has also been discussion that the interface between the 141 Javascript and Browser be a protocol, rather than an API, such that 142 the JavaScript could pass the protocol's messages as opaque blobs 143 between two Browsers to establish the media-plane characteristics. 145 An example of such a protocol interface is described in [draft- 146 roap]. That will also be discussed in this document. 148 The conclusion of the discussion in this document concerning those 149 designs is that they are detrimental to the applications enabled 150 with WebRTC, and contrary to the Web Application model in general. 151 Therefore, this document defines the beginning list of requirements 152 for an API that we feel is more appropriate for Browsers to expose. 154 3. Defining a WebRTC Protocol in the Browser 156 Proposals have been made for integrating an entire session signaling 157 protocol into the Browser, in [draft-signaling], and for integrating 158 an SDP offer/answer protocol in the Browser, in [draft-roap]. This 159 section discusses the benefits and drawbacks of doing such things in 160 Browsers. 162 1) For a session signaling mechanism to work, it is not sufficient 163 to just implement something in the browser. The Server also has 164 to have be involved in the protocol, in order to forward the 165 protocol messages between the appropriate Browsers. Minimally, 166 this requires identity and location services, such as a user 167 database and which Browser connections are which user, etc. Often 168 it involves authentication and authorization decisions as well. 169 In SIP, for example, this would be the role of a Proxy and 170 Registrar. In Web applications, such things are typically handled 171 in an application-specific way based on the needs and architecture 172 of the specific Web application. For example, a gaming website 173 already knows who its users are and where they are as part of 174 their game application, while Facebook already knows who its users 175 are and where they are in its specific application. There is no 176 need to standardize this in any way, and attempting to do so would 177 be fruitless since it would have to make assumptions about the 178 applications that could not possibly be known in advance, and thus 179 not usable in practice. 180 2) For either session signaling or SDP offer/answer protocols, 181 integrating the protocols into the Browser means more logic and 182 state is in the Browser, and ultimately more code. This leads to 183 the following properties: 184 a. It is easier for simple Web-application developers to 185 initially deploy, if the code they need was built-in to the 186 Browser the way they needed it to be. 187 b. But, the more logic is placed into the Browser, the more 188 need there is to extend/enhance/fix that logic in the future, 189 and Web-application developers have little control over users 190 to upgrade their Browsers. 191 c. History has shown that the more complex the interface is 192 between two implementations, the more interoperability 193 problems occur. Ultimately the best way to provide 194 interoperability is to run the same actual source-code; short 195 of that, the less logic placed into it, the better the odds 196 of interoperability. 197 3) For the SDP offer/answer protocol proposal, a benefit is that for 198 some very simple applications it makes deployment easier, if the 199 simple application does not need to know anything about the SDP 200 content or offer/answer semantics. If an application needs 201 control at the media layer, then it could create a fake 202 shim/interface from some real SDP in Javascript, to the SDP 203 offer/answer protocol in the Browser. Thus it trades off 204 additional simplicity for simple applications, against additional 205 complexity for advanced applications. If the goal of WebRTC is 206 purely simplicity, this might seem a reasonable trade-off; if the 207 goal is innovation, however, then making it harder for advanced 208 uses means making it harder to innovate. 209 4) For the SDP offer/answer protocol proposal, an argument has been 210 made that the logic/state required for media already has to exist 211 in the Browser itself, and thus splitting the domain of 212 responsibility between the Browser and Javascript is more 213 difficult than keeping it all in the Browser. We believe this 214 conclusion is drawn from an implicit assumption that the Browser 215 should be dealing with SDP to begin with. Unfortunately, SDP is 216 not just about media characteristics. There are numerous 217 attributes in SDP that are actually properties of a higher layer 218 than RTP and codecs. For example, the following IANA-registered 219 SDP attributes would be unknown to a media library in the browser 220 and only known to the Javascript: cat, keywds, tool, type, 221 charset, lang, setup, connection, confid, userid, floorid, and 222 probably a bunch more (we haven't investigated them all). The 223 point is that it is NOT true that "all the SDP information needs 224 to be handled by the Browser, so why not put offer/answer in it 225 too?". 226 5) Building the SDP offer/answer model into the Browser restricts 227 the Web application to only being able to do things that can be 228 encoded and communicated with the SDP offer/answer model. As an 229 example of something that cannot be accomplished because of this: 230 imagine a Web-application that allows the Browser to communicate 231 with a TelePresence (TP) system. TP systems have multiple 232 cameras, screen displays, microphones, and speakers. A PC-based 233 Browser typically only has a single microphone and camera, but can 234 display multiple video feeds separately and can render-mix the 235 incoming audio streams. Thus, a Browser to TP system would 236 produce an asymmetric media stream model: multiple video streams 237 from the TP system to the Browser, and one video stream from the 238 Browser to the TP system, and the same for audio. Each TP stream 239 is an independent RTP session and has unique attributes to 240 indicate position (left/center/right). Encoding that is currently 241 not possible with SDP offer/answer; not only because the SDP 242 attributes aren't yet defined, but because the offer/answer model 243 assumes a symmetric number of media-lines (m= lines), and also 244 that attributes represent media-receiving characteristics as 245 opposed to media-sending capabilities. Clearly if and when SDP is 246 changed to handle TelePresence cases, Browsers could be upgraded 247 to handle it as well sometime after; but they wouldn't need to if 248 the Browser hadn't been involved in SDP to begin with. SDP 249 information isn't strictly that of an RTP library layer; it's not 250 a one-to-one correlation. 251 6) Some Web application developers may prefer to make the decision 252 of which codecs/media-properties to use in the Server, and command 253 all the Browsers in a given session to do so. In some respects 254 this is the very simplest model possible; but with SDP 255 offer/answer model being forced on the developer it becomes much 256 more complicated to achieve. 257 7) Since SDP offer/answer mechanism is a protocol, involving both 258 state machines and encoding schemes, interoperability between 259 different vendor implementations is not guaranteed. In fact, 260 real-world SIP deployments have experienced interoperability 261 problems with both SDP and the offer/answer model. 262 8) For both session signaling and SDP offer/answer, troubleshooting 263 and debugging become difficult for the web-app provider if a 264 problem occurs in the protocol built in the Browser. Even if the 265 Javascript snoops on SIP or ROAP message exchanges and pushes back 266 copies to the server in case of failure, the developer has to 267 guess what the cause of an error response is. In other words, 268 it's the difference between having only Wireshark traces to debug 269 with vs. also having internal logs from code procedures. 270 9) Using the SDP offer/answer model provides a more rigid API 271 interaction model, enabling Browser vendors to perform less 272 testing and provide more robust implementations than exposing all 273 discrete components to a Javascript API would. 274 10) Using a higher-level API model, such as would be done with an 275 SDP offer/answer model, means the cross-browser vendor-specific 276 variances would be reduced. Exposing a lower-level API would 277 inevitably lead to some differences in different browsers due to 278 differences in their architectures/implementation. 280 4. Leaving Logic to Web Developers 282 The alternative to embedding protocols in the Browser, is to leave 283 the work up to Javascript, for whatever "work" might be required for 284 the particular application. After all, the actual knowledge of what 285 the specific Web application does, wants, how it encodes it, etc. is 286 only fully known by the Web developer for that application, and thus 287 by the Javascript+Server-code combination employed (i.e., the 288 application "source-code"). 290 Clearly the Browser needs to perform quite a bit of "logic": for 291 implementing codec rendering/encoding, RTP/RTCP protocols, SRTP, and 292 ICE. That is unavoidable, and not in question. The question is who 293 should be in control, where any additional logic should be placed, 294 and what the API model should be. 296 There has been discussion that WebRTC should strive to enable media 297 communication session with about "20 lines of code". We assert the 298 only means of achieving that goal in a production-deployment manner 299 is to use Javascript, and in particular Javascript libraries. 300 Javascript libraries are used by a huge number of Web applications, 301 and they work. Some of the libraries are so popular, reference 302 books have been published for them. Yes, there are a lot of 303 libraries, but that's a *good thing*. 305 The properties of using Javascript, and Javascript libraries, are as 306 follows: 307 1) The logic is under the control of the Web developer. This means: 308 a. If something is broken, the Web developer can generate log- 309 type debug information within the javascript and push it back 310 to the server or log collector, and determine what is broken 311 and when to fix it; they do not need to rely on asking for 312 the user to provide Browser logs, rely on the Browser to 313 generate useful logs, understand the logs, nor rely on 314 Browser manufacturers to prioritize fixing them. 315 b. If an enhancement can be made, the Web developer can decide 316 if and when to do so; they do not need to rely on Browser 317 manufacturer decisions and timescales. 318 2) All the Browsers using a given application site run the same 319 literal Javascript source-code provided for that application. 320 There is no greater means of achieving interoperability than that. 321 3) If specific Browsers enable something proprietary, or some new 322 media extension, the Web developer can decide whether to use it or 323 not, when, and how. And the mechanism can be made flexibly; for 324 example, new codecs do not need new Javascript code to be used, 325 unless the Javascript wishes to follow a model where they do need 326 new Javascript to be used. (see API section on this) In other 327 words, the Web-application developer can be as conservative or 328 liberal as he/she wishes. There are already known use-cases where 329 a Web-app will never want to use new codecs or capabilities 330 introduced into Browser RTP libraries, and there are known use- 331 cases for the opposite. Let the Web-app developer make that 332 choice. 333 4) The Javascript code does need to be downloaded (although Browser 334 caching does exist), and clearly the larger the Javascript, the 335 longer it takes to download. BUT, popular Javascript libraries 336 are so necessary in modern Web applications, that they are often 337 available for free and fast downloading by local delivery 338 networks. 340 5) There are properties of the media library API that Javascript may 341 need to access that cannot and should not be expressed in SDP. 342 Some of these are described in the "Hints" and "Stats" section of 343 [draft-roap]. These will need a true API rather than an SDP 344 offer/answer protocol to learn, yet they are tied to the 345 information in the SDP regarding the media streams and codecs. 346 Therefore, it is not the case that the Javascript does not need to 347 understand SDP and could treat it as an opaque blob. 348 6) There are settings of the media library API that Javascript may 349 want to set that cannot be expressed in SDP. For example, setting 350 which local audio or video sources to fork to two or more remote 351 parties. Another example is local Javascript setting the media 352 library to use audio only even if an incoming session's remote 353 peer Browser indicates both audio and video, because the local 354 user only wants to use audio right now (e.g., they pressed some 355 Javascript-provided button which meant "audio-only" because 356 they're not wearing proper attire for this particular session). 357 These types of decisions and logic are not the domain of the 358 Browser, but rather the Javascript, yet they are also integral to 359 the SDP offer/answer. 360 7) For the Browser manufacturers, testing every discrete API 361 setting, in every possible permutation, and in all possible timing 362 sequences that a Javascript could invoke is extremely time- 363 consuming and error-prone. 365 5. API Requirements 367 Some requirements for an API are already documented in [draft-use- 368 cases-and-requirements]. This section expands upon those in further 369 detail, and adds new ones. In all cases, the term "Application" 370 means the Javascript, and "Web API" refers to the Javascript <-> 371 Browser API. 373 It is not the goal of this document to define the actual API - 374 that's W3C's job. [Note: this is a strawman list] 376 5.1. Browser User-Interface Requirements 378 REQ-ID DESCRIPTION 379 ---------------------------------------------------------------- 380 A1-1 The Web API MUST provide a means for the 381 application to ask the browser for permission 382 to use cameras and microphones as input devices. 383 ---------------------------------------------------------------- 384 A1-2 The Web API MUST provide a means for the 385 application to ask the browser for permission 386 to the screen, a certain area on the screen 387 or what a certain application displays on the 388 screen as input to streams, and which stream. 390 ---------------------------------------------------------------- 391 A1-3 The Web API MUST provide a means for the 392 application to disable/enable the microphone and 393 camera inputs. [Note: this does NOT mean 394 disabling RTP transmission] 395 ---------------------------------------------------------------- 396 A1-4 The Web API MUST provide a means for the 397 application to disable/enable the rendering of 398 received audio and video, per stream. 399 ---------------------------------------------------------------- 401 5.2. Media Properties 403 REQ-ID DESCRIPTION 404 ---------------------------------------------------------------- 405 A2-1 The Web API MUST provide a means for the 406 application to learn what codecs and codec 407 properties the Browser supports 408 ---------------------------------------------------------------- 409 A2-2 The Web API MUST provide a means for the 410 Browser to indicate codecs and codec properties 411 such that the application does not need to know 412 about the specific codec type in advance 413 ---------------------------------------------------------------- 414 A2-3 The Web API MUST provide a means for the 415 Browser to indicate codecs and codec properties 416 such that the application can use them in SDP, 417 for example by providing the IANA-registered 418 encoding name for the payload format, and the 419 format specific parameters as strings, such that 420 they could be used in the 'a=rtpmap' and 'a=fmtp' 421 lines of SDP should the Javascript wish to 422 create SDP containing codecs unknown to it. 423 ---------------------------------------------------------------- 424 A2-4 The Web API MUST provide means for the 425 application to get the following media codec 426 properties: bandwidth, clock rate, number of 427 channels, type (audio vs. video) 428 ---------------------------------------------------------------- 429 A2-5 The Web API MUST provide a means for the 430 application to get the bandwidth values for 431 codecs which support multiple levels, and set 432 it for codecs which can be controlled/primed. 433 ---------------------------------------------------------------- 434 A2-6 The Web API MUST provide a means for the 435 application to set whether to use silence 436 suppression or not, for codecs which support it. 437 ---------------------------------------------------------------- 438 A2-7 The Web API MUST provide a means for the 439 Browser to notify the application when a used 440 codec falls below a given quality threshold 441 [Note: it is TBD what "quality" means] 442 ---------------------------------------------------------------- 443 A2-8 The Web API MUST provide a means for the web 444 application to detect the level in audio 445 streams. 446 ---------------------------------------------------------------- 447 A2-9 The Web API MUST provide a means for the web 448 application to adjust the level in audio 449 streams. 450 ---------------------------------------------------------------- 452 5.3. RTP/RTCP Properties 454 REQ-ID DESCRIPTION 455 ---------------------------------------------------------------- 456 A3-1 The Web API MUST provide a means for the 457 application to get and set the SSRC value(s) 458 ---------------------------------------------------------------- 459 A3-2 The Web API MUST provide a means for the 460 application to get and set the CNAME value(s) 461 ---------------------------------------------------------------- 462 A3-3 The Web API MUST provide a means for the 463 application to get and set the Payload Type 464 value(s) for each of the codecs 465 ---------------------------------------------------------------- 466 A3-4 The Web API MUST provide a means for the 467 application to set the audio and video codecs 468 to be used for each stream, for both rendering 469 and generating separately, at any time. 470 ---------------------------------------------------------------- 471 A3-5 The Web API MUST provide means for the 472 application to set whether to use SRTP, its 473 encryption algorithm and key length, with or 474 without authentication 475 ---------------------------------------------------------------- 476 A3-6 The Web API MUST provide a means for the 477 application to set whether to use SRTP or not, 478 and which key exchange type to use 479 [Note: this is TBD pending SRTP decisions of WG] 480 ---------------------------------------------------------------- 481 A3-7 The Web API MUST provide a means for the 482 application to set the SRTP master key value(s) 483 ---------------------------------------------------------------- 484 A3-8 The Web API MUST provide a means for the 485 application to get DTLS-SRTP fingerprint value(s) 487 ---------------------------------------------------------------- 488 A3-10 The Web API MUST provide a means for the 489 application to enable/disable generating RTP per 490 stream [Note: this does not disable RTCP] 491 ---------------------------------------------------------------- 492 A3-11 The Web API MUST provide a means for the 493 application to be notified by the Browser if 494 RTCP is no longer being received from the far-end 495 ---------------------------------------------------------------- 497 5.4. Data-stream Properties 499 This section will detail requirements for the API for the client-to- 500 client data connection stream. 502 [TBD, since no other document has proposed anything for this yet 503 either] 505 5.5. IP and ICE Properties 507 ---------------------------------------------------------------- 508 A5-1 The Web API MUST provide a means for the 509 application to get IPv4/v6 addresses and ports 510 for receiving ICE/RTP/RTCP on, per stream 511 ---------------------------------------------------------------- 512 A5-2 The Web API MUST provide a means for the 513 application to set a list of the remote IPv4/v6 514 addresses and ports to send to, per stream 515 ---------------------------------------------------------------- 516 A5-3 The Web API MUST provide a means for the 517 application to set a list of TURN servers to use, 518 including passwords 519 ---------------------------------------------------------------- 520 A5-4 The Web API MUST provide a means for the 521 application to set a list of STUN servers to use 522 ---------------------------------------------------------------- 523 A5-5 The Web API MUST provide a means for the 524 application to set the local ICE username and 525 password 526 ---------------------------------------------------------------- 527 A5-6 The Web API MUST provide a means for the 528 application to set the remote ICE username and 529 password to perform connectivity checks with 530 ---------------------------------------------------------------- 531 A5-7 The Web API MUST provide a means for the 532 application to set the remote IP Addresses and 533 ports to perform connectivity checks with 534 ---------------------------------------------------------------- 535 A5-8 The Web API MUST provide a means for the 536 application to get any IP Addresses and ports 537 learned by the Browser from STUN, TURN, or other 538 methods (such as UPnP, NAT-PMP, PCP), including 539 their candidate-type, foundation, etc. 540 ---------------------------------------------------------------- 541 A5-9 The Web API MUST provide a means for the 542 application to be notified by the Browser for 543 ICE event state changes 544 ---------------------------------------------------------------- 545 A5-10 The Web API MUST provide a means for the 546 application to be notified by the Browser if 547 the local in-use IP address changes or becomes 548 inactive (e.g., link loss) 549 ---------------------------------------------------------------- 551 5.6. API Design Recommendations 553 Technically the API design is the role of the W3C. That hasn't 554 stopped people in the IETF RTCWEB mailing list from discussing it ad 555 nauseum, however, and even defining a protocol for it. This 556 document therefore recommends the following to W3C: 557 1) That the API setters/getters function-arguments use 558 separate/discrete values, instead of one long string of separate 559 tokens in a pseudo-arbitrary order with weak and complex encoding 560 rules. 561 2) That when the Javascript calls an API setter function to the 562 Browser, that it be treated as a *command*, not a protocol 563 negotiation. 564 3) *IF* any "blob" of information should be passed from the Browser 565 to the Javascript and vice-versa, for use in such things as SDP, 566 that it be something for which there would not likely be any use 567 to a Javascript programmer and for which future extensions/changes 568 would require Browser changes only but would not be easily 569 representable in discrete fields. The most likely candidate for 570 such a need for a "blob" would be ICE-specific SDP attributes. 571 4) That when a IETF documents start telling you how to build 572 Javascript APIs, you should run far away... quickly. :) 574 6. Security Considerations 576 There are no security implications for this document, yet - this is 577 just a strawman document. 579 7. IANA Considerations 581 This document makes no request of IANA. 583 8. Acknowledgments 585 Many of the topics discussed in this document came from numerous 586 email posts and threads on the IETF RTCWEB mailing list over the 587 past couple months, so we will likely forget to recognize some 588 people who have had their input written herein. We believe, though, 589 that the following folks have possibly emailed something we've 590 stolen^M^M borrowed: Matthew Kaufman, Roman Shpount, Inaki Baz 591 Castillo, Albert Einstein, Saul Ibarra Corretge, Victor Pascual, 592 Henry Sinnreich, and Bernard Aboba. 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA). 597 9. References 599 9.1. Informative References 601 TBD 603 Authors' Addresses 605 Hadriel Kaplan 606 Acme Packet 607 Email: hkaplan@acmepacket.com 609 Dan Burnett 610 Voxeo 611 Email: dburnett@voxeo.com 613 Neil Stratford 614 Voxeo 615 Email: nstratford@voxeo.com 617 Tim Panton 618 PhoneFromHere.com 619 Email: tim@phonefromhere.com