- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Sun, 16 Feb 2014 07:13:49 +0000
- To: "public-orca@w3.org" <public-orca@w3.org>
- CC: Martin Thomson <martin.thomson@gmail.com>
- Message-ID: <2272D478-BD6A-4EB3-93C0-7978B5ADB176@microsoft.com>
I am assuming the event would fire once if an RTP stream is received on a configured address/port but *isn't* processed by an RTCRtpReceiver (see below). So that could happen if the PT was unrecognized or PT was recognized but there was no configured recv-appId or SSRC. If the address/port wasn't configured, my assumption is that the stream is dropped with no event. And yes, I would assume only very modest buffering. On Feb 15, 2014, at 4:47 PM, Martin Thomson <notifications@github.com<mailto:notifications@github.com>> wrote: I assume that you only want to fire this once for a given stream, but what are the uniqueness properties that you want to key on? Just SSRC? SSRC + PT? All three attributes on the event? I found that it helps to buffer a couple of packets, particularly if this is video inbound. Since this event isn't synchronous, the time it takes to fire and process the event is all you need to cover. Might want to recommend that a tiny number of packets or small number of bytes be kept. 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.
Received on Sunday, 16 February 2014 07:14:20 UTC