Re: [ortc] Proposal: RtpListener for unsignalled ssrcs (#32)

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.