Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 11:01:20 +0200

Hi Stefan,

2013/7/1 Stefan Håkansson LK <[email-masked]>:
> 4.5: This really underlines the need to specify in detail what the
> allowed SDP variations are (or, if we remove SDP, to specify any other
> mechanism to exchange the things needed to set up RTP and other things
> going on the wire).

The draft http://www.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt
clearly proposes that NO media description format is required in the
wire. This is not about SDP vs SDP+XML vs SDP-NG.

The draft explains (in section 5) why it is not needed to mandate how
media info must be sent in the wire. Instead, let the developer to
retrieve the media/transport information from the API and send it in
the wire in the way it wants.

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 1 Jul 2013 14:11:30 +0000

> the wire in the way it wants.

I still think my point is valid. If the app i browser A retrieves this 
media/transport info using the API, and sends it to the peer app in 
another browser B, it must still mean the same for both browsers.

True, we're struggling with this part for SDP. But removing it and only 
have API calls does not get us away from defining exactly what those 
calls mean.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 16:28:15 +0200

> have API calls does not get us away from defining exactly what those

Stefan, the media/transport info will be sent from browser A to
browser B using the custom format the developer of the website chose,
period. I don't understand why you think that the format of the
media/transport info must be constant/fixed for any website using
WebRTC. It makes no sense IMHO. That is up to the website developer.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Jul 2013 08:59:14 -0700

On Mon, Jul 1, 2013 at 7:28 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> WebRTC.

Because ultimately the media is sent via transports set up by the browser.
If the browser must understand every custom format, the system cannot
scale.

regards,

Ted Hardie

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 18:05:52 +0200

2013/7/1 Ted Hardie <[email-masked]>:
> If the browser must understand every custom format, the system cannot scale.

Ted, the media can be *perfectly* sent in-the-wire with any custom
format the web developer builts (JSON, XML, plain SDP or whatever).
The receiver JS app parses the information (i.e. converts from JSON to
an Object), extracts the media/transport fields and pass them to the
PeerConnection via API methods.

It is really so hard? this is how WWW works (in contrast to how SIP works).

If it is possible, please take a look to
http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 1 Jul 2013 17:05:18 +0000

> format the web developer builts (JSON, XML, plain SDP or whatever).

I had the impression that we had consensus for using (S)RTP for the media.

> PeerConnection via API methods.

My point is that when the app passes the fields to the PeerConnection, 
it must be specified exactly what those fields mean (so that the RTP 
send by one browser can be used by another browser receiving it). And 
that requirement is the same regardless of if we use SDP generated and 
consumed by the browser to describe it or something else.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 19:10:10 +0200

> I had the impression that we had consensus for using (S)RTP for the media.

I meant "SDP". Of course the browser sends RTP. What I mean is that we
DO NOT need to play with a SDP blob to transmit media/transport info
between browsers and between JS and WebRTC API.

> consumed by the browser to describe it or something else.

Sure. The point is that we don't need (and don't want) SDP since it
becomes a barrier for innovation. All the details in the draft:

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Jul 2013 10:13:52 -0700

> format the web developer builts (JSON, XML, plain SDP or whatever).

I'm sorry, I think I must misunderstand you.  You are planning to take
media from a source  and encode it using json, xml, or SDP and send that
over the wire?  Or you mean the media *signalling* can use json, xml, or
SDP and go over the wire?

As has been repeatedly mentioned, you have a peer communication here that
has to be implemented by the browser.  That means the downloaded javascript
application must tell a browser what transports it needs so that it can
create the appropriate connections.  If it is using RTP/UDP, it ends up
needing to tell the browser what enough detail to construct the RTP/UPD
streams.  What payload format, for example, is needed.  As I said before,
that means that having no standard format across the API between the JS
application and the browser has very poor scaling characteristics.  You
might replace SDP as the interface between them, but not specifying
anything there doesn't seem to work, at least in my personal opinion.

regards,

Ted Hardie

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 19:22:24 +0200

2013/7/1 Ted Hardie <[email-masked]>:
> I'm sorry, I think I must misunderstand you.  You are planning to take media
> from a source  and encode it using json, xml, or SDP and send that over the
> wire?  Or you mean the media *signalling* can use json, xml, or SDP and go
> over the wire?

Of course, I mean "the media signaling". But that is not just about
"in-the-wire". Current WebRTC specs mandate that the information unit
exchanged between the JS app and the WebRTC stack must be a SDP blob.

What I mean is:

- The JS app uses the WebRTC API to retrieve a JS Object (or Objects)
with transport and media info.

- The JS app serializes such a information in any custom way defined
by the website developer (this can be a JSON body, XML, SDP! or
whatever).

- The JS app sends the information to the remote peer.

- The JS app of the remote peer decodes the information (since it is a
JS app designed by the same domain/website) and extracts all the
transport/media fields.

- The JS app of the remote peer creates a local PC and makes calls to
API methods of PC for passing those transport/media fields.

- ...and remove O/A mandate.

But honestly, all of this is really well described and exposed in the draft:

http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00

> might replace SDP as the interface between them, but not specifying anything
> there doesn't seem to work, at least in my personal opinion.

I invite you to read the draft which describes how your concerns can
be perfectly accomplished without mandating SDP or any other format:

http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 1 Jul 2013 17:33:33 +0000

> - ...and remove O/A mandate.

What if first browser generated a JS Object that said (for this example 
we assume one single audio track) it preferred to send audio using 
Opus2.0 but could also do Opus and G.711. If the second browser (which 
has not yet been upgraded) could only decode Opus and G.711, would it 
not have to tell the first browser about this?

Are you perhaps assuming a capability exchange of some sort before any 
media can be set up?

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Jul 2013 11:17:49 -0700

On Mon, Jul 1, 2013 at 10:22 AM, Iñaki Baz Castillo <[email-masked]> wrote:

Preface:  I have read the document you refer to, and I find it personally a
lot less clear than you do.  While I would welcome specific pointers when I
ask questions, more elucidation is needed for me.  Thanks for understanding.

More questions in-line.

> with transport and media info.
Retrieve from where?  Does the browser generate these at the direction of
the JS application,
or do you believe it generates them when media sources are connected.  How
are data sources
created?

> http://tools.ietf.org/html/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
None of the above appears to touch on the API which uses SDP in the current
design; that's between the JS and the browser.

> anything
Honestly, I have read it and I don't see how you avoid mandating some
standard
interface between the JS and browser.  That needn't be SDP, but if it is
causing the
two sides to negotiate candidate transports and emit RTP, it's going to be
hard going
to avoid it being SDPNG.

Ted

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Jul 2013 14:24:24 -0400

> Are you perhaps assuming a capability exchange of some sort before any
Any API that we propose would include methods to expose browser
capabilities (ie list of available codecs, with default payload type,
payload name, clock rate, number of channels, and preferred codec
parameters). Generation of SDP c line, rtpmap, and fmtp lines from this
would be trivial, as well as generation of other media descriptions for
XMPP or other negotiation protocols.

In other words, we are not removing the need for negotiation. All we want
is to unbundle it from single offer/answer exchange with single string blob
into separate methods where transport negotiation (ie DTLS, SRTP, and ICE
candidates), mapping transport to streams (ie any sort of bundle related
mapping remote address, SSRC, payload or others), and media
encoding/decoding (ie send and receive codecs, codec parameters, payload
times, etc) are all negotiated separately and independently. This is what
is happening with the API anyway with trickle ICE and no-plan proposal
adding ability to update transport and media parameters once the initial
connection is established. All we want is to extend the same logic to the
initial connection establishment,
_____________
Roman Shpount

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 1 Jul 2013 12:22:01 -0700

> Honestly, I have read it and I don't see how you avoid mandating some standard
> interface between the JS and browser.  That needn't be SDP, but if it is causing the
> two sides to negotiate candidate transports and emit RTP, it's going to be hard going
> to avoid it being SDPNG.

This lack of imagination among people designing the APIs we are supposed to use is disturbing.

Have you read, just as an example, the CU-RTCWEB API? It achieves a browser API without resorting to SDP or anything like it.

If you insist on Offer/Answer *and* "opaque" blobs (that we all know people will modify anyway), then sure, SDP looks attractive... But that's just a failure to imagine a world where VoIP isn't based on SIP and SDP O/A.

Matthew Kaufman

(Sent from my iPhone)

---

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Jul 2013 13:11:23 -0700

On Mon, Jul 1, 2013 at 12:22 PM, Matthew Kaufman <[email-masked]> wrote:

> Have you read, just as an example, the CU-RTCWEB API? It achieves a
> browser API without resorting to SDP or anything like it.
>
>
I have read it, though I see from the date on it that it has been updated
since the last time I did so.  You are right that this does not look
anything like SDP, and it is therefore not clear to apply the moniker SDPNG
to it.  But CU-RTCWEB also contains elements that are standardized to meet
similar requirements, which I believe Iñaki is arguing is not needed.  To
put it in CU-RTCWEB terms, I don't see how not having a standardized
version of something like RtpStreamDescription,  RtpExtension, or
CodecDescription scales, since the result is that browser must understand
whatever approach the JS application chooses to use for those.

To restate this:  having the JS application to JS application API surface
not be standardized works because the private agreements can be expressed
in the application; having the JS application to browser interface be not
be standardized doesn't seem to me to work at scale. It could be done by
having an independent browser extension for every site that wants to use a
specialized API, but that hardly seems to meet the goals of the group.

Once again, no hats or company swag on,

Ted

If you insist on Offer/Answer *and* "opaque" blobs (that we all know people
> will modify anyway), then sure, SDP looks attractive... But that's just a
> failure to imagine a world where VoIP isn't based on SIP and SDP O/A.
>
> Matthew Kaufman
>
> (Sent from my iPhone)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 22:37:54 +0200

> Are you perhaps assuming a capability exchange of some sort before any

The fact that a capability exchange or media signaling negotiation
exists does not mean that it must be based on a opaque blob which is
unmanageable at JS level. The JS app should be able to understand
*what* exactly it is sending in-the-wire, and for that purpose a
opaque blob is not a ellegant solution. Instead a JS Object based API
(like *any* WWW API) makes sense. And then the JS app can decide how
to encode/serialize/whatever such a media information in-the-wire (and
yes, it can be into a SDP, but a SDP created by the JS library because
the author chose it, while others can use whatever format or send the
information "splitted" into different requests or whatever.

Of couse the SDP O/A model is a valid model, and of course SIP is a
valid model (which carries the SDP exchange), but that is not the only
one. IMHO the IETF/W3C should not mandate like-SIP-models for every
future RTC applications running in the web.

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 22:59:18 +0200

> ask questions, more elucidation is needed for me.  Thanks for understanding.

Sure Ted, and thanks a lot for reading the draft.

> Retrieve from where?

I don't want to design an API in a few lines because I may be 100%
wrong, but (very) basically:

The JS app:
- Calls getUserMedia().
- Creates a PC instance.
- Provides the PC with the MediaTracks obtained from getUserMedia().
- Calls to some API method*s* in PC to retrieve ICE transport
information (which is obtained as JS Object, with attributes
representing the corresponding fields of a ICE "line").
- Calls to some other API method*s* in PC to get the list of supported
codecs and tells the PC, via another PC API method, the preference
order.
- Calls to some other API method*s* in PC to get local MediaStream
and/or MediaTracks instances (i.e. to render local video).
- Calls to some other API method*s* in PC to get crypto/DTLS
information (an Object with the appropriate attributes fully defining
such an information).
- ...and so on.

And the the JS app serializes all the retrieved information and
encodes/serializes/whatever it into a JSON body, XML, etc etc, and
sends it in-the-wire (or splittes it into various chunks of
information to be send separately).

> Does the browser generate these at the direction of
> the JS application,

I don't understand the question. In the current SDP-based model you
get all the media/transport information when you get the SDP
(SessionDescription instance) from the PC, right? and then you send it
in-the-wire and ICE stuff starts.

Some here, but instead of passing a horrile opaque blob, let's use JS Objects.

NOTE: This is just one of the various changes/improvements the draft
describes. It is not all about the interface between the JS layer and
the WebRTC stack in the browser.

> design; that's between the JS and the browser.

In fact the proposed API between the JS and the browser is what
encourages that the JS app can send whatever it wants in-the-wire.

Anyhow I don't fully understand what you mean with "the API which uses
SDP in the current design". Do you mean setLocalDescription (which is
provided with an opaque blob) and getLocalDescription (which provides
an opaque blob)?

> interface between the JS and browser.  That needn't be SDP,

Of course we need a standard interface (this is: API) between the JS
and browser. That's why we are proposing a "JS Object API rationale".
But we need a *real* JS API (which means functions that returns JS
Objects and are provided with JS Objects) rather than the current API
that just works by passing an opaque/unmanageable blob between JS and
browser (in both directions).

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 1 Jul 2013 23:01:28 +0200

2013/7/1 Ted Hardie <[email-masked]>:
> You are right that this does not look anything like SDP, and it is therefore
> not clear to apply the moniker SDPNG to it.  But CU-RTCWEB also contains
> elements that are standardized to meet similar requirements, which I believe
> Iñaki is arguing is not needed.

May be I explained it wrong, but as said in my previous mail, of
course some kind of *REAL* JS Object-based API is required to
interface between JS and browser.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 2 Jul 2013 07:21:17 +0000

On 2013-07-01 20:24, Roman Shpount wrote:
> On Mon, Jul 1, 2013 at 1:33 PM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> In other words, we are not removing the need for negotiation. All we
> want is to unbundle it from single offer/answer exchange with single
> string blob into separate methods where transport negotiation (ie DTLS,
> SRTP, and ICE candidates), mapping transport to streams (ie any sort of
> bundle related mapping remote address, SSRC, payload or others), and
> media encoding/decoding (ie send and receive codecs, codec parameters,
> payload times, etc) are all negotiated separately and independently.

Roman, thanks for clarifying. Personally (wearing no hat) I think 
splitting things up makes a lot of sense. In fact, our first prototype 
browser (back in early 2011) was sort of implemented this way: each 
MediaStream was described and negotiated separately. We used SDPs for 
the purpose though (each addStream lead to a separate SDP O/A setting up 
that unidirectional MediaStream with its tracks).

But I think we should not underestimate the work needed to describe all 
the nitty gritty details using another "language" than SDP.

> This is what is happening with the API anyway with trickle ICE and
> no-plan proposal adding ability to update transport and media parameters
> once the initial connection is established. All we want is to extend the
> same logic to the initial connection establishment,
> _____________
> Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 2 Jul 2013 10:01:45 +0200

Hi Stefan,

As said multiple times we are not proposing a replacement for SDP.
Passing an opaque blob string between browser and WebRTC is not the
only solution, even more, I don't consider that an "API".

If after reading the draft you have understood that we are proposing a
replacement for SDP then we've done something wrong.

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Tim Panton <[email-masked]>
Date: Tue, 2 Jul 2013 09:31:26 +0100

> the nitty gritty details using another "language" than SDP.

Conversely we shouldn't underestimate (again) the difficulty of describing all the
nitty gritty details in SDP. 

I have the sense that we may have pushed the flexibility of SDP beyond it's elastic limit.

I think that over the last year we have discovered that a dynamically programmable browser
is a fundamentally different beast from a deskphone and that what suits one may well not suit the other.

Tim.

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Tue, 2 Jul 2013 10:44:03 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Inline [RRR]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Panton
Sent: Tuesday, July 02, 2013 4:31 AM
To: Stefan Håkansson LK
Cc: [email-masked]
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model

	But I think we should not underestimate the work needed to describe
all 
	the nitty gritty details using another "language" than SDP.

Conversely we shouldn't underestimate (again) the difficulty of describing
all the nitty gritty details in SDP. 

I have the sense that we may have pushed the flexibility of SDP beyond it's
elastic limit.

[<RRR] SDP has been and is basically a session "description" protocol, not a
session "negotiation" protocol unless and until a new method like UPDATE and
O/A have added to increase SDP's "elasticity" to perform a crude type of
negotiations with one dimensional intelligence. [</RRR>]

I think that over the last year we have discovered that a dynamically
programmable browser is a fundamentally different beast from a deskphone and
that what suits one may well not suit the other.

Tim.

Classification: UNCLASSIFIED
Caveats: NONE

---

From: Robin Raymond <[email-masked]>
Date: Tue, 02 Jul 2013 08:22:58 -0400

You are absolutely, there are  a lot of details. But splitting the 
details into logical separate components reduces the overall complexity 
greatly. Plus many of those details are only needed because of a lack 
ability to properly describe the concept of "streams" at the lower level 
RTP layer (which really only supports tracks at best, and lacks 
sufficient details to coordinate any information between them to 
reassembly remotely as a "stream"). So we are left in a situation where 
the high layers must coordinate a lot of information to be capable of 
reassembling the streams when they really should be just negotiating the 
capabilities of the RTP layer itself.

For example, the only thing that should be needed is a flag that says 
FEC is available in the signaling for the the RTP layer. If it is set 
then that would imply the engine supports this feature and thus FEC 
streams may be created by the sending party. Alas, because RTP lacks 
sufficient depth for such concepts like FEC, you have to signal it. RTP 
doesn't even have enough information to reassemble tracks into stream, 
let allow do things like FEC between them.

Having said that, by making a scoped object that understands there is 
some definition of what a stream means needs to be describes, but 
perhaps that the "future' may not require such crazy definitions like 
all the stream/ssrc/track mappings, it allows for a short/long-term 
temporary situation where stream definitions are passed until we are 
able move to a model where that is no longer needed. When a theoretical 
next-gen RTP transport is capable of sending entire streams and 
reassembling them without explicit signaling from an upper layer, we can 
stop defining all that mapping stuff in signaling and remove that 
complexity.

Basically, it's about scoping the objects, and limiting the requirements 
needed to exchange per object, and defining exactly what is 
expected/required in those definitions and allowing for future 
alternative objects that could replace current ones (if they should 
become available). The other important aspect is removing the definition 
how this information must be coordinated and exchanged to allow for a 
variety of signaling scenarios and alternative state machines. And 
keeping it relatively simple is important for the simple use cases too 
so the burden is low. We are well on our way to producing such a draft 
in short order that does exactly that.

All we ask is that people keep an open mind. We have no desire to 
prevent SDP or offer/answer, just not mandate its usage as an API model.

Make sense?

-Robin

> Tim Panton <mailto:[email-masked]>
> 2 July, 2013 4:31 AM
>
> programmable browser
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bossiel thioriguel <[email-masked]>
Date: Tue, 2 Jul 2013 22:36:32 +0100 (BST)

You have said: "For example, the only thing that should be needed is a flag that says FEC is available in the signaling for the the RTP layer. "

I don't really think and this is why I already said the job is MUCH harder than you think.
- You also need to say which king of FEC you want to use. Let's say it's ulpfec (RFC 5109)
If we are using ulpfec:
A- It is allowed to send FEC packets in the same stream as the protected one or not.
B- When FEC uses different stream then, it is possible to secure it or not regardless the protect stream is secure or not. (e.g SRTP/FEC and RTP/Protected stream). All combinations are possible. When both are encrypted they even could use different keys (if different channels).
C- FEC could be bundled with RED or not
D- When FEC use different channel then, it could use different rate than the protected stream if bundled with RED
E- Say which media (audio, video, application...) and stream you want to protect
F-Whether only one level of protection will be used ("onelevelonly" parameter)
G- etc etc...

SDP already allow all these use-cases. Depending on the  implementations, signalling [A-F] could be mandatory.

Good luck...

________________________________
 De : Robin Raymond <[email-masked]>
À : Tim Panton <[email-masked]> 
Cc : "[email-masked]" <[email-masked]> 
Envoyé le : Mardi 2 juillet 2013 14h22
Objet : Re: [rtcweb] New Draft - WebRTC JS Object API Model

Make sense?

-Robin

Tim Panton
>Conversely we 
shouldn't underestimate (again) the difficulty of describing all the
>I have the sense that 
we may have pushed the flexibility of SDP beyond it's elastic limit.
programmable browser
>rtcweb
 mailing list

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Jul 2013 17:43:16 -0400

You might also want to cite some of the reasons noted in this old draft:
http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01

-hadriel

On Jun 26, 2013, at 12:37 AM, Robin Raymond <[email-masked]> wrote:

> 
> According
>  to many, real adoption of WebRTC will not happen if we continue to 
> force everyone to use this SDP Offer/Answer methodology.  It is clearly 
> blocking our way forward and the amount of specification documentation 
> remaining needed for the browser vendors to produce a compatible SDP 
> based WebRTC engine in a browser is much more daunting than most are 
> willing to admit.
> 
> 
> The
>  draft rationale behind a JavaScript Object API model:
> 
> http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt
> 
>  
> 
> Whereas:
> The
>  WebRTC JavaScript Object API & Shim document will be along shortly.
> 
> 
> We
>  wanted to get this initial rationale draft informational document out 
> right away. Everyone that has any interest should review the reasons and
>  concepts and comment before we get too far along on the details of an 
> actual API, the initial API will follow in the coming days.
> 
> 
> Best
>  regards,
> 
> Robin
>  Raymond
>  
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Jul 2013 15:07:45 -0700

> http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01

Yes. This is an excellent draft that covers a lot of the same issues.
I especially like:

   4) That when a IETF documents start telling you how to build
     Javascript APIs, you should run far away... quickly.  :)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Jul 2013 00:20:26 +0200

> http://tools.ietf.org/html/draft-kaplan-rtcweb-api-reqs-01

Well, section "3. Defining a WebRTC Protocol in the Browser" says:

   9) Using the SDP offer/answer model provides a more rigid API
     interaction model, enabling Browser vendors to perform less
     testing and provide more robust implementations than exposing all
     discrete components to a Javascript API would.

   10)   Using a higher-level API model, such as would be done with an
     SDP offer/answer model, means the cross-browser vendor-specific
     variances would be reduced.  Exposing a lower-level API would
     inevitably lead to some differences in different browsers due to
     differences in their architectures/implementation.

Time to reconsider those assertions? ;)

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 6 Jul 2013 20:59:49 +1000

An interesting read. It makes me wonder if there is a full description
available of the SDP that browsers (Chrome, Firefox) currently
support.

Looking forward to your proposal (I assume it will be on the W3C list?).

Cheers,
Silvia.

On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond <[email-masked]> wrote:
>
> According to many, real adoption of WebRTC will not happen if we continue to
> remaining needed for the browser vendors to produce a compatible SDP based
> WebRTC engine in a browser is much more daunting than most are willing to
> admit.
>
>
> The draft rationale behind a JavaScript Object API model:
>
> The WebRTC JavaScript Object API & Shim document will be along shortly.
>
>
> We wanted to get this initial rationale draft informational document out
> concepts and comment before we get too far along on the details of an actual
> API, the initial API will follow in the coming days.
>
>
> Best regards,
>
> Robin Raymond
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 6 Jul 2013 10:58:32 -0400

Well in our defense, #9 wasn't our argument - that was the argument the browser makers themselves raised two years ago on the deciding conference call for why the browsers should be doing SDP rather than a real API.  In fact if I recall right, I think that was the main deciding argument for why browsers shouldn't offer a lower-level API.

-hadriel

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 08:00:41 -0700

> available of the SDP that browsers (Chrome, Firefox) currently

Here's the description for Chrome:

https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc

:)

> based
> actual

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 08:30:16 -0700

> Time to reconsider those assertions? ;)
These assertions assume we have only two choices:  1.  A high level
SDP-based API or 2.   A low-level API that "[exposes] all discrete
components".

Was a "middle ground" API ever considered?  One which  doesn't require
everything go through SDP, and also doesn't expose "all discrete
components"?   A sort of "best of both worlds" approach?   I'd be
interested to know if such an ideas was proposed and rejected or simply
never proposed.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Mon, 8 Jul 2013 16:02:48 +0000

Some of us work for browser vendors who cannot follow that link, you know.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: Monday, July 8, 2013 8:01 AM
To: Silvia Pfeiffer
Cc: [email-masked]
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model

On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer <[email-masked]<mailto:[email-masked]>> wrote:
An interesting read. It makes me wonder if there is a full description
available of the SDP that browsers (Chrome, Firefox) currently
support.

:)

Cheers,
Silvia.

On Wed, Jun 26, 2013 at 2:37 PM, Robin Raymond <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 12 Jul 2013 12:00:32 -0700

I wasn't aware of that.  Thanks for letting me know.

On Mon, Jul 8, 2013 at 9:02 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  Some of us work for browser vendors who cannot follow that link, you
> know.****
>
> ** **
>
> Matthew Kaufman****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Peter Thatcher
> *Sent:* Monday, July 8, 2013 8:01 AM
> *To:* Silvia Pfeiffer
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] New Draft - WebRTC JS Object API Model****
>
> ** **
>
> ** **
>
> ** **
>
> On Sat, Jul 6, 2013 at 3:59 AM, Silvia Pfeiffer <[email-masked]>
> wrote:****
>
> support.****
>  ** **
> Here's the description for Chrome:****
>
> ** **
>
>
> ****
> ** **
> :)****
>  ****
> Silvia.****
> >****
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
>  ** **
>