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

I think that the question is whether you want the event for the first
packet on an SSRC, the first packet of any given type on an SSRC, and
whether you want to include the receiver-id in this.

Buffering amount is secondary.

On 15 February 2014 23:13, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 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>
> 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 Monday, 17 February 2014 19:59:24 UTC