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

On Mon, Feb 17, 2014 at 11:58 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> 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.
>
​
I think we have two options:

1.  Fire the event once for each (SSRC, PT) pair, triggered when a packet
is ignored because it doesn't have a corresponding RtpReceiver to be
delivered to.  One event for two scenarios (unknown SSRC and unknown PT).

2.  Fire the event once for each SSRC, triggered when a packet is ignored
because it doesn't have a corresponding RtpReceiver to be delivered to.
 And also add an event on the RtpReceiver, such as
RtpReceiver.onunhandledrtp which is fired when the SSRC is configured with
that RtpReceiver, but the PT is not.  Two events for two scenarios.


I think I'm more in favor of #2.


​As for the receiverId, we should certainly include it in the event, but
the question I have is:  if you configure an RtpReceiver to expect a
receiverId, and packets are received with that receiverId,  so the packets
are routed to the correct RtpReceiver, but then later packets are received
with the same SSRC, but not the receiverId header extension, is the packet
routed to the RtpReceiver (ie is the ssrc auto-configured for that
RtpReceiver) or is onunhadledrtp fired, or both?



> Buffering amount is secondary.
>

For video and key frames, it's very desirable.
​​

>
> 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.
> >
> >
>