Re: [ortc] Undefined RTCRtpListener behavior (#48)

[RR]
Yes. Good summary.

One fundamental design decision should be made... Are the RtcRtpReceiver 
objects one-time use and then disposable once used? In other words, when 
the RtcRtpReceiver locks/latches onto an RTP stream, the lock is final 
and there is no RTP stream that can become relatched to the same 
RtcRtpReceiver instance.

I tried to outline the behaviour that would be required if the 
RtcRtpReceiver  instance supported relatching to a new RTP stream. It 
has much more complex rules than if we made the object a one time use. 
The downside is that you'll need to create a new instance of an 
RtcRtpReceiver every time a switch to a new stream occurs since 
relatching isn't supported. The benefit is that the rules are much 
simpler, and it's it's not overly hard to prepare a new RtcRtpReceiver 
object that is ready to accept a changed RTP stream once it arrives so 
in my mind supporting relatching is not vital.

I prefer to not support re-latching and make the RtcRtpReceiver instance 
a one-time-use for each incoming RTP stream.
[/RR]

> Emil Ivov <mailto:emcho@jitsi.org>
> April 14, 2014 at 12:36 PM
>
> [...]
>
> Also, kind of a side/clarifying question:
>
> If I understand correctly that filtering logic is necessary for two 
> cases:
>
> 1. The app wants to create RTPReceivers before it starts getting media 
> (for whatever reason) so these rules help make sure that when media 
> actually starts arriving it would flow to the right receivers. 
> Pre-defining such rules is not mandatory however and apps can very 
> well create receivers on the fly as they get unhandled events.
>
> 2. RTPReceiver-s have already been created (either "pro" or "re" 
> actively) and these rules try to guarantee that media would continue 
> flowing to the right receiver with as little intervention from the 
> application as possible.
>
> Are the above statements correct?
>
> Emil
>
>