Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

On Fri, Jul 19, 2013 at 12:37 PM, Adam Roach <adam@nostrum.com> wrote:

> I think this is a hopelessly naïve interpretation of the facts on the
> ground. Simply discarding SDP doesn't magically make the underlying issues
> go away. We would still need to settle a vast number of issues around
> things like simulcast, FEC, codec parameters, indication of supported
> codecs, correlation of RTP streams with MediaStreamTracks, attempts by both
> parties to operate on the same stream simultaneously [1], etc. Basically,
> with very rare exception, the same set of problems that we need to solve if
> we *don't* throw SDP out the window.
>

I would argue that we are not as naïve as you think.

First of all, a lot of the issues you are talking about are not yet solved.
At the same time we have something already working and useful with current
browser implementation. So, what we want is to have these features released
as version 1.0. The problem that we face, that when you implement all the
above mentioned features, even though the API will stay the same, SDP that
it will produce will change, and that will require all, except the simplest
application, and all external components interfacing WebRTC clients to
change. And then when more features are implemented and more different
versions are in use more and more interop for applications and external
components will be required. What we want is an API that is not based on
blob with unpredictable data.

Second, offer/answer and SDP introduce a number of negotiation constraints
that really should not be there. They cause unrelated things to be
negotiated together. It should be possible to negotiate a data connection
and then add and remove media streams without renegotiating the underlying
data connection. To force selection of single codec you need to do two
offer/answer exchanges, which caused by no other reason then framework
limitations. Resolution of glare is restricted to offer back off.
Furthermore, even from the point of view of offer/answer the current API is
broken. It does not allow forking. It introduces a new PRANSWER which is
not a part of normal offer/answer specification. It does not allow change
send media parameters (ie change send codec or send codec parameters)
without doing an offer/answer exchange, which is not necessary with normal
offer/answer framework.

So, what we are proposing is to map exiting implemented browser
functionality to API and get rid of SDP. Ideally we should get rid of
offer/answer as well but if it is too much work we can leave with it for
version 1.0. This way we get predictable behavior based on predictable
input. If we miss some of the future capabilities and they would require
API modification to implement, we can deal with it in 2.0. In API, unlike
network protocols, predictability and testability counts more then ability
for future extension.
_____________
Roman Shpount