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

[Robin Raymond <[e-mail]>]

                   
                   
                   
                   
Do we need SDP "blob" format in the exchange in the first place? All media
can be done without SDP given an intelligent stream API. An API already
exists to create these streams (albeit somewhat lacking if we remove the
SDP 'blob'). This API helps "simplify" creating this blob for later
exchange. But the blob is truly not needed. Each side could in fact create
the desired streams, pass in the appropriate media information such as
codecs and ICE candidates and chose the socket pair to multiplex upon.
Yes, it's a bit more low level but it certainly can be done (and cleanly).

https://datatracker.ietf.org/doc/draft-jennings-rtcweb-plan/

Nothing wrong with the draft in an SDP/SIP mindset but I'm going to take
it from a totally different non-SDP angle. I have to say, the ideas
presented are very good. I appreciate FEC, and synchronizing streams is
cool. But SDP isn¹t needed to do it. Let me as the programmer worry about
how to manage streams and the features on the streams and associations
between the streams via an API only.

Point 4, 5 and 6 in the specification all have to do with the complexities
of having to describe the intentions of mixing in SDP. So no comment
beyond ³don¹t use SDP².

As for 7.1 ­ ³this is because the sender choses the SSRC² ­ only true
because we are forced to use SDP and the assumptions is that it¹s SIP. We
could have the receiver dictate what the sender should use in advance of
any media. In our case, we establish in advance what we want from all
parties before even ³ringing² the other party. We do not have SSRC
collisions as we reversed the scenario allowing the receiver to pick the
expected SSRC. Coordinating the streams is a problem with SIP because of
how they do forking/conferencing. This specification forces this issue on
those not using SIP. If SIP has problems with streams arriving early to
their stateful offer/answer then let them worry about ³how² they intend to
match the streams at a higher SDP layer and get this draft out of the
RTCWEB track on the SIP track. To be clear, the proposal seems entirely
reasonable and intelligent for SIP/SDP. But it¹s way to SIP centric for
general use.

On that note, what I do need in the API is an ability to dictate the SSRC
when I create an RTP stream for sending (should I care to do that).

7.2 Multiple render

Again this is an issue of SIP/SDP. We can control the SSRCs to split them
out to allow multiplexing easily on the same RTP ports with multiple
parties/sources. If given the primitives to control the streams just, this
specification could be used to dictate how to negotiate issues in their
space.

7.2.1 I¹m feeling the pain. How about just giving me an API where I can
indicate what streams are FEC associated.

7.3 Give me API to give crypto keys to RTP layer. Let me handle the
fingerprint and security myself beyond that.

8. Let's just say politely that I would not want to be the developer
assigned to programming around all this stuff.

Again, a perfect illustration why I don¹t want SDP.

Media is complicated for good reason as there are many untold use cases.
The entire IETF/W3C discussion around video constraints illustrates some
of the complexities and competing desires for just one single media type.
If we tie ourselves to SDP we are limiting ourselves big time, and some of
the cool future stuff will be horribly hampered by it.

My issues with SDP can be summarized as:

- unneeded - much too high level an API
- arcane format - legacy and problematic
- offer/answer
- incompatibilities
- lack of API contact
- doesn't truly solve goal of interoperability with legacy systems (eg.
SIP)

Regret that I did not have time for feedback earlier. As you can tell, I
am not at all happy with where we sit today wrt requiring SDP. IMHO we
need a lower level API if we are going to insist on using SDP.


You can read my entire (long) rant against SDP here
http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/