- From: Emil Ivov <emcho@jitsi.org>
- Date: Thu, 13 Feb 2014 23:07:33 +0100
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "public-orca@w3.org" <public-orca@w3.org>
I haven't been following the work here as closely as I would have liked so I might be missing something obvious. What I don't understand is: what is an app supposed to do with an RTP event? I would expect it to be able to either somehow convert it to a new render-able stream or attach it to an existing one as some sort of a layer. How would these work? On Thu, Feb 13, 2014 at 8:23 PM, Peter Thatcher <pthatcher@google.com> wrote: > With the move to RtpSender/RtpReceiver, we have one thing we're missing from > RTP that can't be put in either of them: an event for unsignalled ssrcs. We > want such an event, but right now we don't have a clear place to put it. I > propose we add a class called RtpListener which, like RtpReceiver, wraps a > DtlsTransport, and fires events for RTP received. Unlike RtpReceiver, which > handles the RTP for a given set of ssrcs, the RtpListener can listen to all > RTP and fire an event if a packet is already process by an existing > RtpReceiver. Here's how I propose RtpListener should look: > > > [Constructor(RTCDtlsTransport)] > interface RTCRtpListener { > readonly attribute RTCDtlsTransport transport; > // fires RTCRtpUnhandledRtpEvent; > attribute EventHandler? onunhandledrtp; > } > > interface RTCRtpUnhandledRtpEvent : Event { > readonly attribute unsigned int ssrc; > readonly attribute unsigned byte payloadType; > // AKA "AppID" header extension > readonly attribute DOMString? receiverId; > } > > > That's it :). It's simple, but it grants a lot more flexibility to the > application to signal things (or not signal things) how it wants. > > -- https://jitsi.org
Received on Thursday, 13 February 2014 22:08:21 UTC