WebRTC JavaScript Object API Rationale

Versions: 00 01                                                         
Network Working Group                                         R. Raymond
Internet-Draft                                               E. Lagerway
Intended status: Informational                                 Hookflash
Expires: December 28, 2013                               I. Baz Castillo
                                                              R. Shpount
                                                           June 26, 2013

                 WebRTC JavaScript Object API Rationale


   This document describes the reasons why a JavaScript Object API
   approach is a far better solution than using SDP [RFC4566] as a
   surface API for interfacing with WebRTC.  The document outlines the
   issues and pitfalls as well as use cases that are difficult (or
   impossible) with SDP with offer / answer [RFC3264], and explains the
   benefits and goals of an alternative JavaScript Object API approach.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 28, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Raymond, et al.         Expires December 28, 2013               [Page 1]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Issues with a Universal Session Description Format (and Offer
       / Answer) . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Goal of Minimized Requirements  . . . . . . . . . . . . .   6
     2.2.  Offer / Answer State Machine  . . . . . . . . . . . . . .   6
       2.2.1.  Offer / Answer Violations . . . . . . . . . . . . . .   7
     2.3.  Browser to Browser Format Compatibility Issue . . . . . .   8
     2.4.  Browser to JavaScript Compatibility Issues  . . . . . . .   8
     2.5.  SDP as a surface API for JavaScript developers  . . . . .   8
     2.6.  Is SDP allowed to be mangled? . . . . . . . . . . . . . .  10
     2.7.  SDP errata and bugs compatibility issues  . . . . . . . .  10
       2.7.1.  SDP Bugs Become Enshrined . . . . . . . . . . . . . .  11
     2.8.  SIP/SDP compatibility worsened  . . . . . . . . . . . . .  11
     2.9.  Increased surface API . . . . . . . . . . . . . . . . . .  12
     2.10. Impossible API to implement to achieve browser
           compatibility . . . . . . . . . . . . . . . . . . . . . .  12
       2.10.1.  Example Oddities That Need Definition  . . . . . . .  12
     2.11. Plan A, Plan B vs NoPlan  . . . . . . . . . . . . . . . .  13
     2.12. SIP Forking Issue . . . . . . . . . . . . . . . . . . . .  14
   3.  Alternatives to Fixing these Issues Now . . . . . . . . . . .  14
     3.1.  Waiting for WebRTC 2.0  . . . . . . . . . . . . . . . . .  14
       3.1.1.  Cost now to fix versus fixing later . . . . . . . . .  15
       3.1.2.  If starting over, would even SIP people want SDP as a
               surface API?  . . . . . . . . . . . . . . . . . . . .  15
       3.1.3.  Incremental Approach may make Compatibility Worse . .  15
     3.2.  Session Description Format Construction API . . . . . . .  16
   4.  Example Difficult Usage Cases with Current Model  . . . . . .  18
     4.1.  On / off hold example usage case  . . . . . . . . . . . .  18
     4.2.  One-Sided Constraints Negotiation use Case Scenario . . .  19
     4.3.  Meet-me Negotiation Use Case Scenario . . . . . . . . . .  20
     4.4.  Browser to Browser Compatibility Extension Compatibility
           Issue Scenario  . . . . . . . . . . . . . . . . . . . . .  21
     4.5.  Building Interoperability between WebRTC and a SIP
           Service Scenario  . . . . . . . . . . . . . . . . . . . .  21
     4.6.  Bit-rate Change Scenario  . . . . . . . . . . . . . . . .  22
   5.  Proposal: WebRTC JavaScript Object API  . . . . . . . . . . .  23
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  23
     5.2.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . .  23
       5.2.1.  Greater compatibility . . . . . . . . . . . . . . . .  23
       5.2.2.  Easier to extend  . . . . . . . . . . . . . . . . . .  23

Raymond, et al.         Expires December 28, 2013               [Page 2]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

       5.2.3.  Faster Reaction Time To Issues  . . . . . . . . . . .  24
       5.2.4.  Decreased surface API . . . . . . . . . . . . . . . .  24
       5.2.5.  Greater compatibility for SIP . . . . . . . . . . . .  24
       5.2.6.  Alternative formats . . . . . . . . . . . . . . . . .  25
     5.3.  Design Goals and Considerations . . . . . . . . . . . . .  25
       5.3.1.  Objects Model Kept Simple . . . . . . . . . . . . . .  25
       5.3.2.  Simple to Gather Negotiation Information  . . . . . .  25
       5.3.3.  Offer / Answer  . . . . . . . . . . . . . . . . . . .  25
       5.3.4.  Extensions  . . . . . . . . . . . . . . . . . . . . .  25
       5.3.5.  Well Defined Behaviors  . . . . . . . . . . . . . . .  26
       5.3.6.  Data Channel  . . . . . . . . . . . . . . . . . . . .  26
       5.3.7.  Satisfy the expectations of the RTCWEB charter  . . .  26
       5.3.8.  SIP/SDP and current WebRTC API shim compatibility
               statement . . . . . . . . . . . . . . . . . . . . . .  26
       5.3.9.  Greater Separation of RTCWEB Working Group and Other
               Working Groups  . . . . . . . . . . . . . . . . . . .  27
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  27
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   While the IETF RTCWEB WG is not specifically tasked with providing an
   API by the W3C, the group has effectively defined a surface API with
   the mandate to use SDP [RFC4566] with offer / answer [RFC3264].

   SDP is a condensed text based format that typically describes real-
   time media streams, networking properties, codecs, media state and
   media attributes.  SDP is completely extensible and can be used to
   describe absolutely anything so long as it is formatted correctly
   within the few limited constraints.

   The points for mandating SDP with an offer / answer API typically
   boil down to:

   1.  It's really easy to establish communication, especially with SIP

   2.  The decision was already made.

   3.  SDP yields greater compatibility (especially with SIP networks).

   4.  We must have some kind of universal exchange format.

   5.  There is no alternative to this approach except destroying
       everything created and starting from scratch.

Raymond, et al.         Expires December 28, 2013               [Page 3]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   This document will explain why these reasons are insufficient to
   continue with a SDP with offer / answer mandate approach given strong
   logical arguments and reasons with real world scenarios where this
   approach fails and due in no small part to its lasting consequences
   (including negative consequences for SIP).

   The document highlights the benefits and goals for a different
   "JavaScript Object API" approach, which satisfies the RTCWEB
   charter's requirements, yields greater compatibility and offer a
   road-map where future potential extensions can be readily added
   without breaking existing implementations.

   A "JavaScript shim" is described including details on how it can
   offer a wrapped API around a core WebRTC JavaScript Object API.  This
   Shim will provide the same level of "ease of use" as experienced with
   the current SDP WebRTC API.  However, this Shim is not mandatory to
   use for those who do not require an "SDP with offer / answer" model.

2.  Issues with a Universal Session Description Format (and Offer /

   The issue with SDP is not the expressiveness of the format but its
   usage as an arbitrary universal format and an API surface instead of
   providing JavaScript developers an object model they can readily
   understand.  JavaScript could be used to control the plumbing of
   media objects using familiar JavaScript expressive concepts enshrined
   with methods, properties and events.  Today, in many real-world use
   cases, controlling WebRTC requires modifying SDP directly.

   Requiring JavaScript developers serialize their API control requests
   into a text format (via modifications of SDP existing blobs) is only
   one aspect of the many issues the SDP approach creates for
   developers.  Needlessly, an offer / answer state machine is imposed
   on JavaScript developers as well.

   While the currently mandated SDP based API allows developers to
   quickly implement basic calling demos and interoperability with some
   SIP networks, it has many issues that will be explored and explained
   in this document and include (but not limited to):

   1.   Defining a standard universal session description format for use
        with WebRTC that describes all scenarios and behaviors desired
        is especially challenging.

   2.   Every detail, expression, nuance and behavior of a universal
        format will need to be detailed for any browser vendor to
        capable to implement the WebRTC specification.

Raymond, et al.         Expires December 28, 2013               [Page 4]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   3.   The bar for browsers (or other applications with WebRTC engines)
        is raised substantially beyond the basics needed for RTC
        communications, with little to no benefit.

   4.   A universal format built into the browser's API is entirely
        unneeded and goes well beyond the RTCWEB chartered mandate for
        the RTCWEB Working Group.

   5.   A flexible and expendable universal exchange format leads to
        greater interpretations and mistakes in various implementations
        that leads to increased incompatibilities.

   6.   Given the format is entirely flexible and open to
        interpretation, resulting implementations will more likely be
        prone to errors relative to the other truly needed aspects of
        RTC that are relatively limited in behaviors and scope.

   7.   Mistakes in the format won't be fixed until a new browser binary
        updates are released and deployed amongst users.

   8.   Mistakes in implementation of the session description format can
        become enshrined and difficult to deprecate (for the sake of

   9.   Compatibility issues caused by the format will not be limited to
        browsers releases as many hybrid browser-engine based
        applications now exist.

   10.  Using alternative signaling formats will require complete
        understanding of the universal format to be able to translate it
        into other alternatives.

   11.  JavaScript (or proxies) will need to parse and rewrite the
        output session description format with 100% precision.  They
        will also require pre-knowledge of what each browser produces
        and expects, despite the multitude of outputted versions of the
        format by various browsers, on various platforms, and from
        version to version and despite the inability to easily predict
        or detect the variations.

   12.  JavaScript developers trying to control WebRTC features will
        need to manipulate any defined universal format rather than
        interacting with JavaScript objects.

   13.  Offer / answer is mandated and the state machine is required but
        ill defined to the specific rules for use within WebRTC.

Raymond, et al.         Expires December 28, 2013               [Page 5]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   14.  The rules of how a universal format can be modified before being
        delivered to remote parties need to be meticulously defined or
        compatibility issues will arise (including the allowed rules of
        post browser format generation that can be modified and fed back
        into the browser to change its parameters).

   15.  Due to the issues defined above, SIP compatibility will worsen,
        not strengthen.

   An alternative to all the issues caused by a universal format is
   described later in the document.  This alternative allows JavaScript
   to control the behavior of the media engine's plumbing while
   providing extensible and modifiable shims written entirely in
   JavaScript that produce consistent signaling and exchange formats
   specific to the network where those formats operate.

2.1.  Goal of Minimized Requirements

   While the primary goal of WebRTC is to enable browser to browser
   communication, the definition of a "browser" is ever expanding.
   Beyond just traditional hand-held applications, hybrid applications
   that are part HTML-5 and part native code exist.  Servers will become
   as much as part of the WebRTC infrastructure as browsers.  Minimizing
   the requirements to the basic wire compatibility necessary to achieve
   RTC is essential for maximum compatibility, flexibility and varying
   usage scenarios.

   The mandate for the RTCWEB charter is to simply provide basic "on-
   the-wire" compatibility and for any basic security requirements (such
   as enforcing ICE connection agreements).  The RTCWEB charter goals
   have been exceeded by going well beyond that scope by mandating an
   API that works fine for simple SIP interoperability demos but does
   not provide easy compatibility to the basic constructs needed as
   outlined from the charter for use with other on-the-wire signaling
   protocols (other than SIP).  If SIP is the only end goal of the WG,
   then that goal must be specifically stated rather than effectively
   mandated by making alternative signaling approaches unreasonably
   difficult to achieve.

2.2.  Offer / Answer State Machine

   The current SDP approach requires an offer / answer state machine.
   Mandating an offer / answer state machine implies that:

   1.  SDP be generated by browser A and sent to browser B

   2.  Browser B must respond with the offer with an answer

Raymond, et al.         Expires December 28, 2013               [Page 6]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   3.  If either party issues a new offer but the offer is rejected, the
       state must revert to the previous agreed SDP (or fail to none)

   4.  If one side receives an offer while the other side has an
       outstanding offer, a conflict occurs and both sides must reject
       and revert and perform SDP conflict resolution to issue an offer

   5.  The only changes to the media that are allowed happens if both
       sides agree

   6.  Any change required to the SDP requires a network round trip
       where both sides mutually agree

   This offer / answer model is defined as required with the current
   implementation.  Not only do the browser vendors have to enforce the
   rules, all JavaScript authors must also adhere to these rules of
   signaling.  While WebRTC does not dictate the signaling mechanism
   between browsers, effectively it is imposing this signaling state
   machine on all implementations (which need not be mandated as part of
   the RTCWEB Working Group).

   There are other models for signaling other than offer / answer.  For
   example, one-sided constraints based negotiation is an alternative
   model.  This type of negotiation requires each side to determine what
   it wants to receive independent of the other.  This signaling is akin
   to saying "if you plan to send anything, make sure it conforms to the
   following".  Changes to the media may occur without agreement from
   the remote party where each side decides what is acceptable to
   receive without agreement from the other.  The remote side can decide
   if it wants to send within those constraints or not.  There is no
   round trip offer / answer required in this model.

   Offer / answer introduces the unnecessary asynchronism to the API and
   JavaScript implementations.  For example, changing the list of codecs
   expecting to receive or the current sending codec can be done
   immediately without the need for asynchronous calls.

   Offer / answer is not required to achieve RTC wire compatibility but
   it is currently mandated when alternatives could exist.

2.2.1.  Offer / Answer Violations

   The offer / answer SDP state machine is already violated in WebRTC.
   Trickle ICE precludes offer / answer round trips and other proposed
   standards like NoPlan [I-D.ivov-rtcweb-noplan] suggest relaxing the
   offer / answer model even more.  The rules of what offer / answer at
   this point is undefined and in clear violation of the strict previous

Raymond, et al.         Expires December 28, 2013               [Page 7]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   rules without clear direction on what exactly constitutes offer /
   answer anymore and where it should and should not be used.

   A new state for offer / answer called PRANSWER is now defined, which
   did not exist as part of the standard offer / answer state machine.
   Offer rollback is not adequately defined either should an offer /
   answer conflict occur.

   Currently, switching codecs requires an SDP offer / answer round trip
   even though it is not technically need for an RTC engine to change
   codecs.  Should this be another exception to the offer / answer state

2.3.  Browser to Browser Format Compatibility Issue

   SDP is a flexible format many alternative methods to express the same
   meanings.  The smallest change can alter the SDP's meaning.

   This creates a parsing and SDP generation compatibility issues.  If
   the SDP is packaged by JavaScript and delivered to the remote browser
   then each browser must support every single possible variation of SDP
   for every browser version and platform in existence.  They must do
   this without failure.  They also do not know exactly the format that
   is expected by the remote party in advance in order to generate
   compatible SDP (despite not having sufficient knowledge about the
   remote party to provide the correct SDP).

2.4.  Browser to JavaScript Compatibility Issues

   Since WebRTC does not mandate the format on the wire for signaling,
   one supported use case for WebRTC must be allowing the browser
   generated SDP to be converted into alternative on-the-wire formats.
   This SDP conversion may be performed by JavaScript in the browser or
   by an intermediate gateway.  In either case, the converter must be
   entirely aware of all flavors and variations to the SDP possible from
   every browser platform and version, despite browser version detection
   being heavily frowned upon by industry best practices.  Likewise, the
   JavaScript or gateway must know how to generate the correct SDP for
   all browsers and versions before passing the serialize SDP blob into
   the browser.  Generating compatible SDP may be impossible unless the
   exact formats and restrictions are unquestionably clear by all
   implementers of the specification (which is anything but clearly
   described in the current WebRTC SDP based API that developers are
   mandated to use).

2.5.  SDP as a surface API for JavaScript developers

Raymond, et al.         Expires December 28, 2013               [Page 8]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   The current SDP based API is limited to placing a call and answering
   a call and adding media.  To perform common edge cases or to utilize
   RTC features beyond the basic API requires SDP mangling.

   Many of the operations from JavaScript to control or fetch properties
   from RTC will be through serialization to / from the SDP instead of a
   developer using familiar JavaScript language constructs (e.g. object
   methods, properties and events).  The JavaScript developer must learn
   an entirely new protocol called "SDP" and be able to parse and
   generate not only basic SDP but any SDP extensions without
   introducing a single compatibility issue.

   Examples; A JavaScript developer wants to hold / un-hold media
   streams.  The developer must use a widely adopted but hidden feature
   to parse the SDP from the browser, change it to add the appropriate
   "hold" state, send that hold state to the remote side, wait for the
   "answer" to accept the hold, parse the result on the return to see if
   the hold was accepted and feed the result to the browser.

   Worse, a flood of extensions to SDP for WebRTC are being written to
   "enhance" and "extend" the functionality of the browser with new
   features.  Many basic things are not defined in the current SDP based
   API, for example, changing non-negotiated codec parameters, such as
   codec bandwidth.

   There is no facility for JavaScript to detect what SDP the browser is
   currently using or capable of delivering.  The developer has no idea
   of the extensions available, or what SDP will be produced, or what
   SDP is compatible.  The developer's JavaScript code must be able to
   handle everything generated by the browser for any use case beyond
   basic call, answer and hang-up.  This is a heavy burden to place on a
   JavaScript developer who is not familiar with the details of RTC
   concepts as expressed in SDP, and is a challenge even for those who
   are familiar.

   Effective APIs are meant to be contracts between a producer and
   consumer, this SDP methodology offer little in the form of any such

   If SDP is to become standardized for use with WebRTC then JavaScript
   developers must learn SDP to use RTC's available features and build
   new features.

Raymond, et al.         Expires December 28, 2013               [Page 9]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

2.6.  Is SDP allowed to be mangled?

   The choice must be made that SDP may be modified or not.  If
   modifications are the only way to achieve RTC features available then
   what is allowed to be modified must be clearly defined in exact
   detail and the expected behavior of each feature (and modification of
   each feature), as expressed in SDP, must be defined.  Anything short
   of of exact specifications will cause incompatibility.  Again, the
   implication is that Web / JavaScript developers must learn SDP to
   utilize the available RTC features and they must learn the rules of
   modification equally well, which do not exist at all today.

   If the choice is to not allow complete SDP modification at all, then
   the protocol becomes extremely tied to SDP based protocols like SIP.
   Yet, there is no mandate for SIP to be the standardized protocol in
   WebRTC, which presents the argument that SDP manipulation must be

   The SDP mangling issue isn't just an issue when the format is sent
   on-the-wire.  If Browser A sends Browser B an SDP, the current
   philosophy is that the SDP is allowed to be modified.  However, there
   is the possibility of modifying the SDP generated by Browser A and
   giving that modified SDP back to Browser A to change it's options
   before it even creates the offer for Browser B (and likewise when
   Browser B responds with its SDP answer).

   How much of the SDP is allowed to be modified before giving the SDP
   back to the local browser?  SDP is a free-form format so anything can
   theoretically get changed, but should it be allowed?  If not, what
   can and cannot be modified?  CODECS?  SSRC?  SDES?  Fingerprints?
   Transports?  And so on...

   This issue only gets compounded when extensions are factored in as

2.7.  SDP errata and bugs compatibility issues

   With the SDP baked into the browser binary, the only way SDP
   compatibility issues can be fixed is by releasing a new browser
   update and the JavaScript developers must support or work around
   flaws until the browser vendors deliver the fix and the user base
   upgrades their browsers.

   While it could be argued that any bug must be worked around, SDP is a
   unique problem.  SDP is a free-form format.  Being compatible isn't
   as easy as implemented a limited wire protocol for media transport or
   a API contract with defined features and attributes.  The likelihood
   of free-form SDP containing errors is far greater than a typical well

Raymond, et al.         Expires December 28, 2013              [Page 10]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   defined API due to SDPs many flavors, interpretations and lack of
   strong definition.

2.7.1.  SDP Bugs Become Enshrined

   To illustrate a scenario: 1.  Browser Vendor A has a bug 2.  Browser
   Vendor B can't work with A because of the bug so it implements a
   "work around" 3.  Browser Vendor A fixes the bug but implements a
   work around to be compatible with Browser Vendor B's "work around"

   This situation is how browser bugs can become enshrined as there's no
   way to update the SDP produces by the browser binary once it's
   released until the next update release cycle occurs.  This would not
   be true if JavaScript was used via a shim to produce SDP as
   JavaScript can be dynamically updated as needed at any time and a
   service provider can choose to update their JavaScript implementation
   to exacting expectations for their network regardless of the browser

   The lower level RTC wire protocols that need to be mandated by the
   RTCWEB Working Group have limited scopes and well defined behaviors.
   Any mistakes are obvious, likely to present very rapidly, and easy to
   spot which party is doing something wrong and much easier to fix as a
   result.  This is not true with a free form highly descriptive
   language for sessions.  The combinations are limitless and every
   scenario is difficult to test, especially in concert with every other
   browser vendor with every version released.  The session description
   will be the likely place of failure across the browsers when the
   session description is generated inside the browser's binary.

2.8.  SIP/SDP compatibility worsened

   One of the main arguments for using SDP with offer / answer was
   supposed to be easy of compatibility with existing signaling
   networks, like SIP.  Instead, variations in the browser's SDP will
   likely worsen SIP compatibility instead of enhance it.

   A SIP provider must now be compatible with every browser's SDP on
   every platform and version and the browser's SDP must be compatible
   with every SDP from a SIP network.  Alternatively, JavaScript or SBCs
   (Session Border Controller) must be used to re-write any incompatible
   SDP to be compatible.  But this moves the problem from the browser to
   JavaScript or requires SBCs to "fix" the problem.

Raymond, et al.         Expires December 28, 2013              [Page 11]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   Had SDP been entirely generated by JavaScript rather than come from
   the browser engine, the JavaScript could create only SDPs compatible
   with a particular SIP provider under control of their own JavaScript
   and the SIP provider could chose which JavaScript SDP parsing /
   generation code to run, for maximum compatibility.

2.9.  Increased surface API

   By mandating SDP, the requirement for compatibility with WebRTC are
   increased substantially with little benefit.  Instead of just
   supporting basic media RTP [RFC3550], STUN/ICE/TURN [RFC5389]/
   [RFC5245]/[RFC5766], DTLS [RFC6347] and CODECS an additional bar must
   be passed, i.e. a browser or other WebRTC compliant API must support
   SDP with a full offer / answer state machine (or a state machine with
   additional rules to make it flexible for various scenarios).

   With an alternative approach, this entire requirement for SDP could
   be removed without any loss of compatibility or increase in
   complexity while achieving greater compatibility via the JavaScript

2.10.  Impossible API to implement to achieve browser compatibility

   The current mandated SDP based API cannot be implemented as a
   standard by independent browser vendors in its current form.  A list
   of subsequent behaviors regarding the usage, parsing, handling,
   extensions, behaviors, constraints and other such reference documents
   must be meticulously defined for SDP with the modified offer / answer
   state machine or no browser can ever claim to be "compliant".  The
   current definition process is far from complete.

   The current WebRTC SDP based API is far from achieving that goal due
   to the inclusion of free-form SDP with offer / answer and it is
   grounds for removing it as it goes beyond the RTCWEB's charter and
   limited scope.

   Any incremental approach that does not remove the offer / answer
   model requirement yields a road block to achieving alternative WebRTC
   signaling protocols other than SIP.

   An alternative JavaScript approach that does not require sessions to
   be described on the wire embedded inside the browser is being
   proposed as an alternative solution so the RTCWEB charter can
   complete its defined goals in a timely fashion.

2.10.1.  Example Oddities That Need Definition

Raymond, et al.         Expires December 28, 2013              [Page 12]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   There are many oddities in the SDP RFC [RFC4566] and the various
   related extensions.

   For example; will rtp maps be required or not?  They are not required
   for basic CODECs according to the RFC.  However, with all the flavors
   of CODECs being offered, defining a mapping between payload an
   interpretation is critical to compatibility and not just a good idea.

   Another example; should "t=0 0" be respected?  Is that allowed to be
   changed?  Do the browser vendors need to enforce the attribute, or
   should the JavaScript layer enforce it?  Should the streams wait to
   start until the NTP time stamp and close when the NTP time completes?

   These questions must all be completely addressed in detail.  This
   could also cause a cascade of updated references and confusion as to
   which version is to be adhered and what each browser specifically
   support.  Nominally referencing the SDP RFC will not be sufficient,
   and deltas from the established standards will need to be defined
   when the rules change.

2.11.  Plan A, Plan B vs NoPlan

   At the time of authoring this document, three plans on how to handle
   large number of media streams in SDP have emerged currently under
   consideration from the IETF, referred to as PlanA
   [I-D.roach-rtcweb-plan-a], PlanB [I-D.uberti-rtcweb-plan] and NoPlan

   All three of these plans acknowledge that using SDP as it is
   historically defined in SIP is inefficient and problematic for large
   number of media streams, especially factoring in that each media line
   must have its own unique ports.

   All three of these plans are a perfect example of why not to use SDP
   as the basis for WebRTC.  SDP has some arbitrary limitations as a
   description protocol for multiple streams where as no such
   limitations exist at the lower layer transports themselves.  RTP
   allows for multiplexing multiple SSRCs.  In other words, the problem
   is SDP, not the real time transportation technologies.

   These drafts illustrate the limitations of SDP and attempt to solve
   it by introducing either more complex descriptions around SDP and /
   or by "relaxation" of the offer answer model combined with altering
   the description language of SDP.

   None of these drafts address most of the concerns outlined in this
   draft.  If anything they further illustrate how divergent the SDP
   will become as more and more effort is put into working around

Raymond, et al.         Expires December 28, 2013              [Page 13]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   problems inherent to the nature of utilizing SDP (or any universal

   The issue that SDP implementers face should be isolated to those who
   require SDP for their signaling protocols (namely SIP) where they can
   choose the best practices for their networks for interoperability.
   These complex approaches do not have to be forced on other signaling
   protocols that do not have or require such limitations.

   Certainly JavaScript programmers and the W3C should not be impacted
   by such limitations by introducing SDP (or any universal format) into
   the mix when it adds zero value and fails in its primary objectives,
   namely: interoperability with existing SIP vendors & networks.

   This further illustrates why SDP baked into the browser binary is not
   beneficial for SIP vendors either.  They will be forced to upgrade
   their SIP infrastructure to support SDP packets from browsers with
   these kinds of extensions or be forced to utilize a JavaScript SDP
   re-write of SDP approach to "fix" these incompatibilities.

   With an object approach, newer signaling protocols could describe
   multiple media streams with ease and SIP providers could ensure they
   only generate SDP compatible with their networks and agree on their
   best practices and launch new features that incorporate approaches
   like as PlanA, PlanB or NoPlan in a manner they deem fit rather then
   when the browser vendors decide to upgrade the SDP arbitrarily.

2.12.  SIP Forking Issue

   The current SDP based API model does not allow for SIP forking even
   though the RTC engine can allow for demuxing a media stream.  The
   current model does not allow for one offer to be transmitted but
   accept multiple answers, which is legal in SIP.

   A JavaScript object API would not be affected if the upper shim
   supported SDP / SIP style forking in the negotiation or not, so long
   as the basic rules of the RTC media engine is respected.

3.  Alternatives to Fixing these Issues Now

3.1.  Waiting for WebRTC 2.0

   If we don't get WebRTC 1.0 correct, fixing the API in WebRTC 2.0 may
   become even more difficult.

   At this stage, prototypes are underway but to our knowledge there are
   no major commercial services deployed by more that one major vendor
   using the current WebRTC API.  Yet, the argument to even consider an

Raymond, et al.         Expires December 28, 2013              [Page 14]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   alternative is that 'it's too late'.  Imagine trying to arguing
   fixing it after major networks are reliant upon specific browser
   implementation.  Having a good but simple API architecture from the
   start could alleviate a lot of pressure fix a broken 1.0 in a 2.0
   release before APIs become entrenched.

3.1.1.  Cost now to fix versus fixing later

   The cost of fixing the API issues today may pale in comparison to the
   cost of compatibility problems spread across entire sets of
   industries where constant fixes and work around may be required.

3.1.2.  If starting over, would even SIP people want SDP as a surface

   Even SIP providers and vendors have started to realize that baking
   SDP into the browser is not necessarily in their best interests, but
   they do have an interest in a simple API to use since they aren't
   specialized JavaScript developers but SIP integrators.

   If an alternative approach provides them SIP providers a simple
   JavaScript API they desire and achieves greater interoperability
   because of predictable, controllable and tailored SDP for their
   network, would they not prefer such a model over the current "baked
   in the browser" approach?

   If the current WebRTC specification was ever rebooted, the current
   mandated SDP based API would undoubtedly be scrapped in favor of a
   better approach without its inherent design and use case flaws with
   negative long term compatibility consequences.

3.1.3.  Incremental Approach may make Compatibility Worse

   One argument put forward, to keep the current SDP model, proposes the
   current WebRTC SDP-based API must be completed soon and incremental
   improvement approach can be used to gradually move away from these
   obvious problems.

   The trouble with an incremental approach is that may increase
   incompatibility further.  Not all browser vendors will match the
   incremental improvements in unison nor will all customers upgrade
   simultaneously.  This puts the onus on JavaScript developers to
   support multiple versions of the WebRTC API and increase the number
   of APIs they must learn and maintain.  The JavaScript developers must
   still perform all the workarounds required for the current API and
   limit using any additional APIs until all browsers universally
   support the incremental improvements.  This will slow innovation and
   adoption of future improvements.

Raymond, et al.         Expires December 28, 2013              [Page 15]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   This will also create a situation where browser vendors cannot easily
   achieve compliance because they too must support the existing API and
   incremental improvements along the way.

   Having a good solid simple foundation is key to ensuring basic
   compatibility while allowing for innovation to occur for those
   developers who are willing to give new APIs a trial without needing
   to supporting multiple sets of equivalent but incompatible APIs

3.2.  Session Description Format Construction API

   An alternative JavaScript model, other than the model advocated in
   this draft, would be to create a JavaScript session description
   format construction API.  Such an API would use JavaScript objects to
   construct the session description format rather than allowing direct
   control of how media should be plumbed together from JavaScript.

   While using SDP as the chosen format for WebRTC highlights the issues
   described in this draft particularly well, using an alternative
   format like JSON instead of SDP does not remove many of the issues
   presented in this draft.  The issues expressed are not solely caused
   by the lack of expressiveness of the SDP format but the nature of
   creating a universal format to supersede all formats and the
   difficulty in producing and implementing any standardized format.

   A few years ago there was an attempt to create a new "SDP 2.0" format
   with a draft named Session Description and Capability Negotiation
   [I-D.ietf-mmusic-sdpng].  This effort to create the "ultimate" SDP
   format in XML was ultimately abandoned, in no small part because of
   the difficulties in coming up with a single solution that works for
   all scenarios.

   Given the difficulty in creating a universal format that works for
   all scenarios, the idea that creating a JavaScript based API that
   constructs a similar flexible but well defined universal session
   description format using JavaScript objects is highly suspect.  The
   reality is such an effort is complex.

   Even if successful, this format is not necessarily the format that
   will be sent on-the-wire, especially for existing signaling
   protocols.  As such, the format will still need to be transformed
   into a alternative formats by JavaScript (or by a proxy).  If the
   format must be parsed or interpreted by an intermediate then the
   format becomes an interaction point to the browser no matter how
   clever the JavaScript session description construction API
   implementation.  Whatever format is selected, each browser or
   alternative protocol format will have to decide how to convert and

Raymond, et al.         Expires December 28, 2013              [Page 16]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   interpret the output and generate new compatible inputs and deal with
   the variations that will undoubtedly arrive from browser to browser
   and from version to version.

   Even if JavaScript APIs are made available to simplify the
   construction or interpretation of a defined format, this format would
   still becomes a do-everything serialization access point for the
   browser and the defined exchange point the local and remote browser.
   Therefor the format itself must described in meticulous detail.

   The standardization requirements for such an approach would increase
   substantially over the WebRTC JavaScript Object API advocated by this
   draft since not only would such a JavaScript format construction API
   have to be standardized (as any JavaScript API would) but the format
   it outputs from the API has to become standardized in detail as well.

   Every combination of this format possible would needs to be outlined.
   Any slight variations would likely cause JavaScript developers or
   other browsers to break their implementations.  Obtaining 100%
   stability in such an output equally across all browsers, on all
   platforms with all versions is highly doubtful.

   While a JavaScript format construction API is merely hypothetical at
   the time of writing this draft, any proposal will need to be vetted
   to see if it address all the concerns and issues brought up in this

   This hypothetical JavaScript session description construction API
   still puts the emphasis in driving the developer towards building up
   a media signaling exchange format rather than in the logic of how the
   media should be controlled and pipelined.

   The JavaScript Object API model is being proposed as the alternative.
   In a follow-up to this draft the API will describe how the JavaScript
   developer gains control over the stream's pipelining for the
   browser's media/RTC engine and thus free the JavaScript developer to
   express signaling using whatever mechanism desired.  A simplified
   shim implemented entirely in JavaScript will allow easier
   interpretation to any format desired by the JavaScript developer in a
   way that can be updated independent of a browser's binary release.
   Should any changes be needed, a JavaScript shim generated format is
   strictly under the control of the network provider.

Raymond, et al.         Expires December 28, 2013              [Page 17]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

4.  Example Difficult Usage Cases with Current Model

4.1.  On / off hold example usage case

   This is a typical scenario widely adopted SIP technique of an SDP
   attribute to place a stream on / off hold.  This is the accepted
   methodology and performing alternative approaches would deviate from
   the expected practices for use with SIP and its manipulation of SDP.
   Although not officially documented, it is effectively supported in
   WebRTC implementations.  This is a typical use case need by media

   1.  Browser A establishes a connection with Browser B

   2.  Browser A and browser B are streaming media

   3.  JavaScript developer wants Browser A to put "on hold"

   These are the steps that must be performed by a JavaScript developer:

   1.  getUserMedia to obtain the SDP from Browser A

   2.  Parse the SDP

   3.  Change the SDP version number of the SDP (although the internal
       version number in the binary has not changed)

   4.  Add "a=sendonly" or "a=inactive" to all media

   5.  Send the SDP to Browser B

   6.  Receive the answer from Browser B (which should respond with
       a=recvonly if it still wishes media)

   7.  Parse the received SDP and modify with "a=inactive" to ensure the
       local side hold back its media

   8.  Pass the modified SDP back into Browser A

   This also implies that:

   1.  All future getUserMedia events from Browser A must be mangled
       because the SDP version numbers are out of sequence (or allow the
       browser to be receive back an altered version of the SDP before

   2.  All future SDP events received from Browser B must be mangled to
       ensure the "inactive" attribute is maintained while on hold

Raymond, et al.         Expires December 28, 2013              [Page 18]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   3.  All future getUserMedia events from Browser A must be modified to
       ensure the "sendonly" property is maintained

   4.  We need to handle alternative formats to describe hold, e.g.
       "c=" from Browser B which may not utilize the latest SDP
       specifications depending on the remote device / platform

   This is a very basic use case that is extremely complex for a
   JavaScript developer, but it is the only way to perform this
   particular action which is supported by the browsers, except only via
   the "SDP surface API".  Even if this particular use case ends up
   being an exposed JavaScript method to manipulate the SDP by the
   browser, there are countless other scenarios where tweaking a field
   to modify the behavior in the format will only be only available via
   SDP manipulation.

4.2.  One-Sided Constraints Negotiation use Case Scenario

   As WebRTC is a web API and not a SIP API, the API must be capable of
   allowing for alternative signaling methods without enforcing it's own
   signaling aspects (other than basic principles like ensure ICE
   agreement has been achieved for security reasons).

   Consider the following scenario: 1) Browser A and Browser B establish
   a connection 2) Browser A and Browser B use one-sided constraints
   negotiation where each party independently decides what "it expects
   to receive" 3) Browser A decides that it wishes to alter the
   properties of the video it expects to receive

   With the current model: Browser A must be capable of independently
   modifying its expectations without waiting for an answer from the
   remote side (as that's illegal by the nature of the offer / answer
   signaling), unless the rules are relaxed and special exceptions are

   To achieve this a for one-sided negotiation: 1) Browser A's
   JavaScript must respond to every SDP offer with an answer locally
   generated from JavaScript without a round trip, extracting out last
   known expectations from the remote SDP last received as part of the
   answer 2) The JavaScript must update the constraint signaling for the
   remote party 3) Browser B's JavaScript sees the constraints have
   changed from Browser A thus it initiates a fake offer from the remote
   party (generating the intentions of the constraint and generating an
   SDP format) 4) Browser B's JavaScript must examine the answer if any
   constraints of changed, and if so, it may trigger another reverse
   situation where step 1 is repeated, except with Browser A and B's
   role reversed.

Raymond, et al.         Expires December 28, 2013              [Page 19]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   Is this really doable?  Maybe, with a great deal of difficulty and
   SDP mangling but it is unquestionably a hack and a violation of offer
   / answer (and relaxed rules create exceptions and exceptions require
   additional logic to handle).  The offer / answer rules are violated
   because no round trip was performed at the time when the constraints
   were changed.

   This is also fragile because if Browser B failed to accept the fake
   offer there is no way to enforce the constraint nor can the
   JavaScript rollback the expected constraint.  Likewise if the state
   machine in Browser A expected an offer to be generated before a new
   offer would be accepted, the conflict resolution process would be
   extremely difficult and messy.

   This offer / answer state machine is not even required to fulfill the
   mandate of the RTCWEB Working Group charter but it is currently
   mandated because it supposedly makes producing "SIP interoperability"
   easier (which is highly suspect as shown herein).

   A JavaScript shim approach with an object model and without offer /
   answer could achieve the same "SIP interoperability" without breaking
   other stateless negotiation models, such as one-sided negotiation.

4.3.  Meet-me Negotiation Use Case Scenario

   1.  WebRTC client A generates an offer and sends to a server

   2.  WebRTC client B generates an offer and sends to a server

   3.  WebRTC client C generates an offer and sends to a server

   4.  The server returns all the exchanges to each of these clients

   5.  WebRTC client A, B and C interconnect

   Technically, there is no need for independent SDP offer / answer
   negotiation amongst all these peers to achieve a mesh scenario for
   this use case.  Each client has enough information about the other
   clients to establish a peer connection.  The current WebRTC SDP API
   imposes independent round trip negotiations that are not technically

   A JavaScript Object API approach would allow for this kind of
   scenario without independent round trip negotiations for each WebRTC
   client in the mesh.

Raymond, et al.         Expires December 28, 2013              [Page 20]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

4.4.  Browser to Browser Compatibility Extension Compatibility Issue

   Consider the following scenario:

   1.  Browser A has implemented an extension to SDP (which is allowed)

   2.  Browser B has no knowledge of such an extension

   3.  The JavaScript engine running on Browser A has no knowledge of
       the extension

   4.  The JavaScript engine packages up the SDP from Browser A and
       sends it to Browser B

   Under this scenario, what should browser B do?  To reject the offer
   means communication cannot occur.  To accept the offer has ambiguous
   meaning because the answer might have misunderstood the extension's
   intention and does not allow for the appropriate behavior.

   The exact rules of what is allowed in SDP and what is not and how
   extensions are treated must be defined clearly and non ambiguously.
   The current SDP offer / answer API is ambiguous for extensions.

   Assuming that a lack of response to an extension is non-agreement to
   use the extension is not acceptable.  For example, if the extension
   was security related dictating some security precondition to opening
   a stream, the offer must be rejected as the precondition cannot be
   met.  Ignoring the extension would mean the offer was accepted where
   it cannot be accepted.

4.5.  Building Interoperability between WebRTC and a SIP Service

   Consider the following scenario:

   1.  Developer takes SDP produced by browser and send to SIP gateway
       (which is supposed to be SIP "compatible")

   2.  Users happily use this service

   3.  Browser Vendor A updates the browser SDP generator and a slight
       variation in SDP changes

   4.  Users are now broken

   5.  SIP gateway must be updated to handle new SDP (and old SDP)

Raymond, et al.         Expires December 28, 2013              [Page 21]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   6.  Browser Vendor B updates their browser SDP generator (with a
       different SDP variation)

   7.  Users are now broken again

   8.  SIP gateway must be updated to handle another variation of SDP
       (and maintain the old variations)

   9.  Repeat to step 3, but add Browser Vendor C, D and multiple

   This is not an unrealistic scenario by any stretch of the
   imagination.  This currently happens in the SIP world, but at least
   in that world new devices are tested to ensure compatibility before
   roll outs occur on the network so issues can be addressed before the
   user's experience is broken.  Since the SIP provider and gateway
   vendor do not have control over the update cycle of the browsers,
   their users are much more prone to breakage by taking the SDP from
   the browser and sending to their network.

   Whereas this is what happens with a JavaScript Object API model with
   SDP shim written in JavaScript-only:

   1.  Developer uses shim to generate SDP by browser and sends to SIP
       gateway (with SDP that is compatible)

   2.  Users happily use this service

   3.  Browser Vendor A updates the browser with a new RTC feature.

   4.  Repeat to step 2

   The reason why the browser update does not affect the gateway is
   because the SDP is generated entirely in JavaScript and thus updates
   to the browser do not change the SDP generation logic.  The SDP is
   entirely in control of SIP network provider.  Any bugs with SDP
   compatibility can be addressed by the SIP provider without changes in
   the browser's binary.  Bugs, updates and improvements are completely
   within the boundary and control of the SIP network provider.

4.6.  Bit-rate Change Scenario

   Consider the follow scenario:

   1.  User is connected to a conference server

   2.  While user is listening, the user transmits a low bit-rate

Raymond, et al.         Expires December 28, 2013              [Page 22]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   3.  The users starts to communicate and the bit-rate is adjusted to
       maximum quality

   Using the current WebRTC API, this would require an offer / answer
   round trip to perform the change and thus the quality would be
   updated until the answer was acknowledged.  This round trip is
   unnecessary technically since the bit-rate can be dynamically
   adjusted without remote acknowledgment.  Yet, the current SDP API
   model imposes a round trip (unless yet another exception to the SDP
   rules are defined).

5.  Proposal: WebRTC JavaScript Object API

5.1.  Overview

   The browser can expose simple object methods, properties and events
   representing the various RTC components at an abstracted level and
   provide a solid API for controlling how the media should be

   A JavaScript-only shim can be layered on top of this API providing
   easy SDP offer / answer capability for those who want a similar
   "simple" API for use with SIP but on top of the object model (but
   developer can chose not to use this shim if they do not need SDP).
   Likewise the object model could be used to produce alternative
   formats to SDP if the same simplicity is needed but in an alternative
   on-the-wire session description format.

   The API described in the solution will be presented in a follow-up
   draft and referenced once available.  This solution will allow for
   the RTCWEB Working Group to complete its chartered mandate without
   starting from scratch.  Any of the drafts proposed to solve issues in
   expressing SDP for WebRTC can be moved to more appropriate working
   groups.  For example, SDP for SIP issues can be moved to the
   appropriate SIP working groups and multi-party SDP to the MMUSIC
   (e.g. drafts like PlanA, PlanB or NoPlan).

5.2.  Benefits

5.2.1.  Greater compatibility

   By having a JavaScript object API, the exact inputs, outputs,
   properties and events can be well defined as an API and will be
   designed to be a specific contract between browser vendors and
   JavaScript developers.

5.2.2.  Easier to extend

Raymond, et al.         Expires December 28, 2013              [Page 23]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   New objects and methods can be added without breaking existing
   compatibility.  Compliance can be verified with unit tests able to
   test each and every behavior across all browsers versions on every
   platform.  JavaScript developers can expect their version of the API
   contract to remain fixed to expected behaviors and not break (unless
   through well planned deprecation).

   Any extensions added to a JavaScript object model does not change the
   behavior expectation from JavaScript developers when using the
   current version of the API regardless of any extensions.  This is
   unlike SDP where extensions could be silently added into the SDP
   produced by the browsers.  Any component that consumes the SDP may be
   unaware what those additional feature behaviors imply or require as a

5.2.3.  Faster Reaction Time To Issues

   Signaling related bugs produced by the JavaScript shims can easily be
   fixed and updated at any time regardless of the browser's release
   cycle.  If a SIP provider discovers their SIP is not compatible with
   the JavaScript shim, the SIP provider can update the shim code to
   their own needs dynamically without waiting for a browser to be
   patched and updated.

5.2.4.  Decreased surface API

   With a JavaScript API, the features are well defined so the surface
   API is fixed to the agreed contract.  Once agreed, a browser vendor
   only has to ensure their compatibility with well defined limited
   scope unit tests, and need not worry about some free-form protocol
   that may introduce untold compatibility issues after a browser is
   released in real-world scenarios.  This is also true of any non-
   browsers that may with to implement and be compliant to the WebRTC
   API for JavaScript and provide their own JavaScript and WebRTC

5.2.5.  Greater compatibility for SIP

   While SIP is not the main RTCWEB Working Group charter responsibility
   for WebRTC, SIP compatibility is highly desirable.  By exclusively
   generating SDP from a JavaScript shim, the SDP produced will be
   identical across all platforms and all devices with every browser
   version and entire under the control of the SIP provider.  This
   increases compatibility for SIP providers.  The SDP produced from the
   shim can be custom tailored to a SIP network without affecting any
   other SIP vendor or harming compatibility with other utilizing

Raymond, et al.         Expires December 28, 2013              [Page 24]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

5.2.6.  Alternative formats

   With a JavaScript shim approach on top of an object model, the
   information going over the wire can be transformed from the
   JavaScript object properties to alternative formats, including JSON,
   XML or SIP (or anything custom).  As the JavaScript shim to use is
   under control of the service provider and identical regardless of the
   platform, the output from the JavaScript format generation is
   consistent and controllable thus ensuring maximum compatibility with
   the network and signaling utilized.

   The party receiving this format can be sure the format is to exacting
   specification of their choosing rather than relying on whatever
   format is produced by whatever browser vendor.

5.3.  Design Goals and Considerations

5.3.1.  Objects Model Kept Simple

   The JavaScript developer should not need to understand the mechanics
   of RTC other than understanding how to plumb the objects together.
   Those whom need extended properties or events for finer control can
   obtain them with simple method access to an object, but those
   extended attributes should not be required for simple use cases.

5.3.2.  Simple to Gather Negotiation Information

   The objects model should allow a simple method for collecting
   information that will be needed for various alternative negotiation
   models.  One of the targets for negotiation must be SDP and SIP.

5.3.3.  Offer / Answer

   The proposed JavaScript object model should not require the offer /
   answer state machine but should not preclude this state machine being
   built in a layer above.  The offer / answer state machine must be
   possible to implement as a JavaScript shim without any additional
   built-in browser services needing to be implemented.

5.3.4.  Extensions

   Extending the object model for the expected common extension use
   cases without breaking the JavaScript API must be possible.  Such
   possible extension use cases should include items like local mixing
   and data synchronization or extended properties, events or features.

Raymond, et al.         Expires December 28, 2013              [Page 25]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

   As any design, there may be limitations but the design should hold up
   to various realistic scenarios that are likely to happen in the near

5.3.5.  Well Defined Behaviors

   The API must be possible to describe specific API behavior sets to
   the browser vendors so they have the appropriate guidelines for
   implementation, including the mapping to on-the-wire to RTC
   protocols.  The API presented in the follow up draft may be the input
   to a W3C efforts to define specific and exact expected behavior sets
   for an object based JavaScript API for an official WebRTC 1.0

5.3.6.  Data Channel

   The proposed JavaScript Object model will have an API to define the
   basic JavaScript usage of the data channel.

5.3.7.  Satisfy the expectations of the RTCWEB charter

   The API must adhere to the expectations of the RTCWEB charter either
   directly, via extensions that can be defined by the working group on
   top of the object model or possibly via a JavaScript shim written to
   utilize the functionality of the object model but it must not
   preclude the RTCWEB charter from fulfilling its goals.

5.3.8.  SIP/SDP and current WebRTC API shim compatibility statement

   The goal of the object model is to allow for a JavaScript shim that
   provide a simple mechanism for parsing and generating SDP for basic
   compatibility with SIP networks (capable of supporting the WebRTC
   wire protocols).

   The goal of this object based API is not to provide working
   JavaScript shim on top that is a 1-for-1 matching of the current
   WebRTC API as a shim, including all behaviors, features, bugs and
   expectations since the definition of the current API is not defined
   enough to be able to produce that level of compatibility.  This would
   be an impossible goal as a result and would add little value.

   Extensions are beyond the scope of the JavaScript shim, but it is
   possible for others to fork and modify the shim to their own needs
   specific to their own SIP/SDP network infrastructure.

   Compatibility with the SDP used in all SIP networks is not a stated
   goal for the JavaScript shim since not even SIP providers can agree
   on a common agreed definitive standard set of RFCs and drafts.

Raymond, et al.         Expires December 28, 2013              [Page 26]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

5.3.9.  Greater Separation of RTCWEB Working Group and Other Working

   A JavasScript object model would remove much of the need for cross
   IETF working group coordination, which has become common place with
   the current movement because of utilizing SDP.  By limiting the
   RTCWEB technologies used to only those required for Real-Time
   Communication from the browser (e.g. RTP, ICE/STUN/TURN, DTLS), the
   RTCWEB Working Group is freed from tight couplings with other IETF
   working groups, each having their own charters, schedules, agendas
   and interests and thus ensures more rapid progress between RTCWEB
   Working Group the W3C and developers who are to use this technology.

6.  Security Considerations

   While RTCWEB has it's own security considerations for protocols, a
   JavaScript object model has no additional requirements other than
   those already established for use within RTCWEB, e.g. ICE
   connectivity permission check or DTLS fingerprint checks.

   JavaScript as a browser language itself has security consideration
   but nothing inherent to using a JavaScript object model versus a
   JavaScript SDP API model.  Any proposed implementations must have a
   JavaScript API.  The specifics of any API must have their own
   security considerations should any exist.

   Any specific issues for the proposed JavaScript object model will be
   outlined in the separated draft JavaScript Object API draft as needed
   and warranted.

7.  References

7.1.  Normative References

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264, June

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

7.2.  Informative References

              Kutscher, D., Ott, J., and C. Bormann, "Session
              Description and Capability Negotiation", draft-ietf-
              mmusic-sdpng-08 (work in progress), February 2005.

Raymond, et al.         Expires December 28, 2013              [Page 27]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

              Ivov, E., Marocco, E., and P. Thatcher, "No Plan:
              Economical Use of the Offer/Answer Model in WebRTC
              Sessions with Multiple Media Sources", draft-ivov-rtcweb-
              noplan-01 (work in progress), June 2013.

              Roach, A. and M. Thomson, "Using SDP with Large Numbers of
              Media Flows", draft-roach-rtcweb-plan-a-00 (work in
              progress), May 2013.

              Uberti, J., "Plan B: a proposal for signaling multiple
              media sources in WebRTC.", draft-uberti-rtcweb-plan-00
              (work in progress), May 2013.

              Burnett, D., "Media Capture and Streams", May 2013,

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.


Raymond, et al.         Expires December 28, 2013              [Page 28]

Internet-Draft   WebRTC JavaScript Object API Rationale        June 2013

              Bergkvist, A., "WebRTC 1.0 Real-time Communication Between
              Browsers", August 2012,

Authors' Addresses

   Robin Raymond
   436, 3553 31 St. NW
   Calgary, Alberta  T2L 2K7

   Email: robin@hookflash.com

   Erik Lagerway
   436, 3553 31 St. NW
   Calgary, Alberta  T2L 2K7

   Email: erik@hookflash.com

   Inaki Baz Castillo
   Basque Country

   Email: ibc@aliax.net

   Roman Shpount
   4905 Del Ray Ave Suite 300
   Bethesda, MD  20814

   Email: rshpount@turbobridge.com

Raymond, et al.         Expires December 28, 2013              [Page 29]