W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Teleco Integrators vs Web Developers vs Browser Implementers

From: Roman Shpount <roman@telurix.com>
Date: Fri, 28 Jun 2013 19:16:45 -0400
Message-ID: <CAD5OKxtsfp_7OrQMJakwYsmYPkrp5jxNx9K=0jLEwsPPMpKUiA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: "piranna@gmail.com" <piranna@gmail.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, public-webrtc <public-webrtc@w3.org>
On Fri, Jun 28, 2013 at 7:00 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>   A quick answer regarding why the user is exposed to an opaque blob: the
> specification makes a conscience decision to omit the bootstrap process
> (aka signaling). WebRTC generates some blob and it is up to you to somehow
> transfer it from one peer to another in order to establish the connection.
> If the bootstrap process was handled by WebRTC then obviously you wouldn't
> see this blob at all.
>     Why does the specification omit the bootstrap process? I'm sure there
> is a good reason for it, but until we see their list of use-cases we won't
> know.
I know exactly why specification omit the bootstrap process -- because it
can already be implemented using existing tools available in JavaScript.
This is the same reason I think offer/answer and SDP blog should be omitted
-- they provide no useful functionality and can be implemented in
JavaScript using considerably simpler and easier to manage concepts. We did
provide use cases in draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00
and on this mailing list. But to outline this to you again:

1. Current API is not compatible with existing offer answer implementation
(no support for SIP forking, pranswer is new and has nothing that
corresponds to in SIP, UPDATE during call setup are not supported etc)

2. Current API is not compatible with non-SIP offer/answer based exchanges
(cannot implement other types of offer collisions, cannot work with
constraints based negotiation systems, cannot work with non-SDP based
system without the blob being parsed).

3. Current API cannot become a standard until a lot more work is put
into standardizing the SDP blob. If bundling is still a goal I would
estimate we are about 1-2 years away from completion. At the same time we
can implement a javascript media stream demux now.

4. Current API is undebugable without parsing the SDP blob.

And there is probably a lot more.
Roman Shpount
Received on Friday, 28 June 2013 23:17:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC