Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

[Robin Raymond <[e-mail]>]

Without going into tremendous details (which believe me, I could), I'm
going to summarize the reasons why I believe it's a bad idea to include SDP:

- increases incompatibilities
- support nightmare (whose to blame when the format introduces problems and
features are injected into SDP along the way)
- bad user experience (protocol will be brittle)
- non predictable behavior, i.e. not an API-contract (receiving side can't
predict or control implied logic, behaviours, etc)
- forces SDP to be standard on all future protocols (not advisable or too
dangerous to parse SDP but some will have to in order to send as
alternative format and then reassemble)
- offer / answer actually breaks other concepts of state machines
- offer / answer forces problems that don’t need to exist when done
differently (roll back, simultaneous negation cross over, SSRC clashes,
knowledge of remote party's state)
- does not really solve legacy compatibility (would likely increase legacy
incompatibility IMHO)
- truly is not needed
- initially simpler for some programmers but at the cost of tremendous pain
forever for others
- forever hamper future technologies and burden them with SIP issues
- make browsers much more difficult to innovate
- make new protocols much more difficult to innovate
- will cause the introduction of SBCs to sanitize the SDPs mid point to
correct compatibility issues
- cause rollouts of new browser versions with even the tiniest of SDP
changes to break countless existing devices


I have to strongly reiterate. It's not just the format. It's the concept. I
know there is the argument "we need some data to be exchanged and this is
close to what we need". Absolutely, we need data but it can be at the split
by only what each component actually needs rather than one big monolithic
thing. Many parts of the information are the relationships between media. I
strongly prefer to assemble relationships with code control than with
monolithic blobs.

Again, it's not necessary to have the blob at all. Take CR-RTCWEB for
example, they have objects that each independently take the information for
each component and then you wire the components together. Is it perfect?
No, but that's the kind of API that would make future stuff much more
possible/better. (Not pushing them, just using as an example.)

Would a JSONified version be better? Perhaps. It could be treated as one
big function call with JSONified arguments. The format is certainly nicer.
But I think that will cause a large amount of arguments as to what that
should be and in order to make it flexible. I would be happier I suppose,
especially if it got rid of offer/answer but I don't think all the problems
are truly solved. Perhaps if that's all that we could "win" it might be
better but I'm not sure it won't introduce new problems either.

I completely agree with Erik's suggestion: Expose a lower layer stream API,
without SDP and without offer/answer and then create a library (perhaps
entirely JS) that mimics the behavior of the current drafts on top of the
lower layers. The SIP people get exactly what they want and think they need
and those that need lower to innovate new stuff get what they absolutely
need.

Benefits: Both sides win and nobody loses. This should not be any harder to
make since all that logic is layered internally this way anyway (it must
be). Better still, Microsoft/IE can be brought back into the mix and the
proposals can be reunited. Perhaps I'm an idealist though with rose
coloured glasses.

If we lock into SDP, the long-term implications will be very bad for WebRTC
(IMHO). Ultimately, whatever is imposed, I will adopt and adapt. In our
case, we'll have to make a really tough choice of how we will have to mess
with SDP or make wonky work-arounds for the problems SDP introduces.

If forced to use SDP, are any others willing to work on a common JS library
with us for the sender/receiver that extracts the SDP from the browsers
into informational structures, manipulates the data (completely outside of
the browser APIs which tie it to real streams), and sanitizes/normalizes
the SDP behaviours to make it more contractual/predictable in behaviour? I
really don't like this idea but if we are forced to use SDP then at least
it would be better to have a common library to handle the pain of
manipulating the SDP for those who can't avoid it. I'd prefer not introduce
yet another set of incompatibilities between all of us that will need to do
it.