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

[Eric Rescorla <[e-mail]>]

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