WebRTC JavaScript Object API Rationale
draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Robin Raymond, Erik Lagerway, Inaki Baz Castillo , Roman Shpount | ||
| Last updated | 2013-06-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
Network Working Group R. Raymond
Internet-Draft E. Lagerway
Intended status: Informational Hookflash
Expires: December 28, 2013 I. Baz Castillo
Versatica
R. Shpount
TurboBridge
June 26, 2013
WebRTC JavaScript Object API Rationale
draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
Abstract
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
[RFC3261].
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 /
Answer)
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
compatibility).
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
again
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
machine?
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
contract.
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
allowed.
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
well.
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
version.
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
shim.
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
[I-D.ivov-rtcweb-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
format).
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
API?
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
simultaneously.
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
draft.
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
application:
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
exchanging)
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=0.0.0.0" 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
made.
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
simultaneously
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
necessary.
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
Scenario
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
Scenario
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
platforms
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
pipelined.
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
result.
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
engines.
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
WebRTC.
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
future.
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
release.
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
Groups
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
2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
7.2. Informative References
[I-D.ietf-mmusic-sdpng]
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
[I-D.ivov-rtcweb-noplan]
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.
[I-D.roach-rtcweb-plan-a]
Roach, A. and M. Thomson, "Using SDP with Large Numbers of
Media Flows", draft-roach-rtcweb-plan-a-00 (work in
progress), May 2013.
[I-D.uberti-rtcweb-plan]
Uberti, J., "Plan B: a proposal for signaling multiple
media sources in WebRTC.", draft-uberti-rtcweb-plan-00
(work in progress), May 2013.
[MediaCapture]
Burnett, D., "Media Capture and Streams", May 2013,
<http://dev.w3.org/2011/webrtc/editor/getusermedia.html>.
[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
2010.
[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.
[WebRTC10]
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,
<http://www.w3.org/TR/2012/WD-webrtc-20120821/>.
Authors' Addresses
Robin Raymond
Hookflash
436, 3553 31 St. NW
Calgary, Alberta T2L 2K7
Email: robin@hookflash.com
Erik Lagerway
Hookflash
436, 3553 31 St. NW
Calgary, Alberta T2L 2K7
Canada
Email: erik@hookflash.com
Inaki Baz Castillo
Versatica
Barakaldo
Basque Country
Spain
Email: ibc@aliax.net
Roman Shpount
TurboBridge
4905 Del Ray Ave Suite 300
Bethesda, MD 20814
USA
Email: rshpount@turbobridge.com
Raymond, et al. Expires December 28, 2013 [Page 29]