Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Peter Thatcher <[e-mail]>]

I like your comparison to the data channels.  As I just pointed out in
another email, I think it was good that we "contained the SDP monster", as
you put it, with createDataChannel.  One of the purposes of
createLocalStream/createRemoteStream is to allow a JS app, if it chooses,
to "contain the SDP monster" when adding media streams.  It would still be
needed for setting up the PeerConnection's transport (a monster container
for a future day perhaps), but that's still significant progress in my
book, and it does so with simple additions to the PeerConnection that don't
attempt to blow up the WG.


On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba <[e-mail]>wrote:

>
>
>
> 2) Dissadvantages of using SDP in WebRTC.
>
>
> Roman said:
> "An unmanageable monster was created which currently stays in the way of
> developing new functionality (bundle), building applications (does not
> provide obvious ways to implement obvious tasks, like adding an extra
> stream without re-negotiating all the existing ones) and even interop with
> existing SIP endpoints (which was the original but now is complicated since
> it would require a non trivial set of constraints and subsequent SDP
> manipulation)."
>
> [BA] Hard to argue with this, but I would point out that by far the
> ugliest part of the monster is the video hindquarters.  While one could
> argue that we have been living with the warts of SDP for audio and
> therefore know the workarounds, with video there are substantial
> interoperability issues, *even among vendors who utilize the same
> codec*, sometimes even in relatively basic scenarios (e.g. P2P video call
> with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist
> yet (at least, based on standards).
>
> So as I see it, it does represent progress that we have contained the SDP
> monster's impact on the  the data channel, and I welcome Peter's effort to
> enable applications who don't care about SDP to minimize its usage even if
> it is not eliminated entirely.
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>