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

[Peter Thatcher <[e-mail]>]

Having a JSON-based SessionDescription that's a 1:1 mapping to SDP
semantically seems like a bad idea to me.  We want something better
than SDP, not just a different syntax for SDP.  Trying to map all of
SDP would be a near-impossible task anyway.


I think you're combining two separate questions:
a.  Should the Browser<->JS API have SessionDescriptions at all, or
should it have just low-level methods?
b.  Should the SessionDescription be representable as SDP or as
something else or both?

So far, we have two camps that combine the two questions:
Pro-SDP camp: methods=createOffer/setLocal/setRemote   and  format=SDP
Anti-SDP camp: methods=low-level methods   and   format=none

I'm suggesting that there might value in a third possibility:
Compromise: methods=createOffer/setLocal/setRemote  and  format=JSON


The Pro-SDP camp will tell the Anti-SDP camp, "don't blow up the
world".  The Anti-SDP camp will tell the Pro-SDP camp, "SDP is a
horrible API surface".  I think they are both right.   And I hope that
an alternative format for a SessionDescription would be a sufficiently
good compromise.


I don't think of it as a fork of SDP, but rather as a much better way
to describe sessions than SDP.  I've personally worked with 6
different kinds of session descriptions (SDP, Jingle, libjingle
internals, and a few different Google internal representations), and
SDP is by far the worst, not just in syntax but in semantics also.  I
think a JSON one could be much better syntax and semantics, without
quite "blowing up the world".

At least, that's my hope.













On Thu, Mar 7, 2013 at 10:45 AM, Eric Rescorla <[e-mail]> wrote:
>
>
> On Thu, Mar 7, 2013 at 10:33 AM, Peter Thatcher <[e-mail]>
> wrote:
>>
>> 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.
>
>
> II don't understand how this changes anything meaningful. The point
> of using SDP isn't the crufty line-based encoding, it's being committed
> to the SDP offer/answer semantics. So, when you talk about having
> JSON, you're talking about one of two things:
>
> 1. Having a format which is semantically equivalent to SDP.
> 2. Having a format which is semantically distinct (or perhaps a superset)
> of SDP.
>
> In case 1, I don't see what this bought you, other than programming
> convenience. It's not like it would be difficult to build code to
> mechanically
> dissect the SDP encoding.
>
> In case 2, you have forked SDP, and largely obviated the point of
> using SDP in the first place.
>
> -Ekr
>
>