On Fri, Jul 19, 2013 at 10:09 AM, Adam Roach <adam@nostrum.com> wrote: > On 7/19/13 11:54, Martin Thomson wrote: > >> As it turns out, "does not need to be solved" doesn't go to 100%. >> Some problems are deferred to applications. Intentionally. Because >> a) they are better at that than we are, clearly, and b) they don't >> necessarily want our crappy solutions. >> >> How long have we talked about BUNDLE? How long do you think that it >> would take someone with a functioning RTP library to build something >> that multiplexes and demultiplexes RTP streams? >> > > Are you proposing that Firefox come up with its own multiplexing mechanism > for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a > fifth? And then we just kind of pray that five proprietary solutions > developed in a vacuum miraculously work together? I mean, yeah, if we can > rely on miracle interop for independently-developed proprietary solutions, > I guess that works. > > Again, you are conflating signalling and API surface. We could define a simple API that leaves the control up the application, and different applications can signal different multiplexing techniques in different ways. > Or are you envisioning a WebRTC API that requires javascript applications > to supply their own RTP stacks? SDP != RTP. It is possible to have an RTP stack without an SDP stack. You realize this, right? > > > /a > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb> >
Received on Friday, 19 July 2013 17:25:08 UTC