Re: [rtcweb] A compromise for SDES

[Peter Thatcher <[e-mail]>]

On Sat, Jul 13, 2013 at 2:02 PM, Bernard Aboba <[e-mail]>wrote:

> Hadriel --
>
> I think you've brought up a critical point, which is very worth keeping in
> mind throughout the discussions in IETF RTCWEB.  That is that WebRTC is
> really two distinct innovations -- one, a profile of "RAI 2.0"
> functionality, defining a core set of RTP functionality developed over the
> last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and
> the other, a set of Javascript APIs for Web browsers defined by the W3C.   IMHO,
>  the "RAI 2.0" aspect is likely to prove more important (and long-lived)
> than the W3C WEBRTC API aspect.
>
> Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to
> live on way beyond the useful life of the W3C WEBRTC APIs, it is critical
> that the protocol profiles not be distorted so as to cater to API concerns
> that will be difficult to justify, let alone remember, a decade from now.
> If the damage brought about by an SDP-based API could be restricted
> solely to Web browsers without reflecting itself in expected "on the wire"
> behavior, I would care a lot less about it.  After all, the Internet
> knows how to deal with bad designs -  it just "treats them as damage and
> routes around them".    So to the extent that IETF RTCWEB can contain the
> SDP API swamp we'll all be better off -- and the swamp will be that much
> easier to drain down the road once it becomes clear to all that nobody
> really wants to live in that part of town anyway.
>
>



> As you state, the vast majority of customers I talk to are interested
> primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at
> all, in the W3C JS APIs.  Given the displacement of feature phones by
> smartphones, the growth in availability of wireless data as well as the
> increasing availability of connectivity that can support interactive video
> (all areas of very rapid growth over the next few years), the focus of
> realtime communications app developers I talk to is not on browser, but on
> the development of native applications.  And unless HTML5-based approaches
> such as Firefox OS gain traction, that focus is likely to remain.
>
> Given this, the most frequent request I hear is for a usable mobile SDK
> that can offer protocol compatibility with WebRTC implementations on
> browsers.  To succeed, that mobile SDK had better not look anything like
> the W3C WEBRTC API, and it also better support extensibility.
>

Chrome's implementation of WebRTC, which can be found at webrtc.org, has a
mobile SDK that can be used to build mobile apps (Android and iOS, at
least).  Some well-known and popular RTC mobile apps are in large part
built on that code and can interop to a degree with browsers.  So in some
sense, you already have what you want.

The big problem is that the high-level API offered by that SDK exactly
matches the one in the browser, which means it's the gross SDP-based one.
 And none of the mobile apps I know, beyond an example app, use that API,
or have plans to, precisely because it's gross.  Instead, as far as I know,
they dig deeper into the code and avoid that part. (why jam everything
through SDP if you don't have to?).

I think the optimal scenario for us to target is to define a good API that
is the same between mobile and web browsers.  I think that would help
developers the most.  Making such a "web and mobile" API is probably out of
scope for any WG, but I think that if we defined a good (non SDP-based) API
for the browser, it could easily be exposed as a native SDK (just like it
is now), but be much less gross and more usable.

I don't know if such a thing (a good API for both mobile and web) can
realistically ever happen, but in the meantime, you can at least pick up
the code at webrtc.org and make a mobile app.  It's open source, too, so if
you want to make a better API than what's there, go ahead and write one :).





In reality, all that the IETF RTCWEB profile defines is the core set of
> functionality -- that set of features that MUST be supported to enable
> interoperability.  However, there is a lot more that a developer might want
> to have available for their particular application.  That might include a
> codec (such as AMR-NB) or a security variant such as SDES/SRTP.   Since as
> you note many developers aren't going to be using the W3C WEBRTC APIs
> anyway, whether those additional functions are supported in the W3C APIs is
> largely irrelevant - and so are discussions about whether this or that
> additional feature needs to be a "SHOULD" or a "MAY".
>

FYI, the code at webrtc.org supports SDES/SRTP, and while it doesn't have
support for AMR-NB (as far as I know), it does have a system for adding new
codecs, so you could theoretically take an implementation of AMR-NB and
compile it in yourself to make a mobile app.  It may not be very easy, but
it is possible.


>
>
> > So given that background, I was planning to propose that the security
> doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a
> statement that web-based application frameworks SHOULD also support SDES.
> (with text about why and how, etc.)
> >
> > I don't think this is too controversial, because web-based frameworks
> are never beholden to following browser behavior anyway - they're used to
> build a native application, and native applications have a very different
> security/threat model in practice. They're written for a specific purpose,
> and installed by users from known sources for that known purpose.
> Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have
> any requirements/mandates for native applications anyway - an app maker
> would just ignore something they don't think applies to them - but I think
> web-based frameworks do generally try to follow W3C models for Javascript
> APIs, and will likely read the IETF RFCs for the media-layer stuff too. So
> I think having this SHOULD statement would be beneficial.
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>