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

[Peter Thatcher <[e-mail]>]

A question for all of you in the "please don't make us use SDP as an
API forever" crowd (and I include myself): Would it be acceptable to
you to have an intermediate step where we keep createOffeer,
setRemoteDescription and setLocalDescription as-is, but allow a JSON
argument?  It seems to be that such a thing could provide all the same
low-level of control as any other setup of methods, but may be much
more likely to be accepted by the group as a whole.  And, it would
still be a lot more pleasant for application developers, and leave
more flexibility for a future where low-level methods might be added.

As both an application developer and a browser implementor, I think a
good SessionDescription JSON format would be easy to implement,
pleasant to use, a small incremental step from what we currently have,
and would relieve the standards body of so much fighting over what the
SDP should look like.

I know it wouldn't be exactly what you're looking for, but I think it
would be achievable and much better than what we have.

If you're interested in such a thing, let me know.  I might be able to
provide something a little more concrete idea as to what such a format
could be.

On Thu, Mar 7, 2013 at 10:23 AM, Peter Thatcher <[e-mail]> wrote:
> Hadriel,
>
> That email is great.  Thank you for preserving it and for bringing it
> to our attention.  I am especially sympathetic to the argument that
> it's undesirable to have the W3C tied to MMUSIC for all time.
>
>
>
>
> On Thu, Mar 7, 2013 at 8:50 AM, Hadriel Kaplan <[e-mail]> wrote:
>>
>> I knew there was a reason for posting an email for the archive machine to store for eternity... see this:
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01256.html
>>
>> -hadriel
>>
>>
>> On Mar 6, 2013, at 6:45 PM, Robin Raymond <[e-mail]> wrote:
>>
>>>
>>> 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/
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb