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

sgtm


On Mon, Apr 14, 2014 at 7:39 PM, Emil Ivov <emcho@jitsi.org> wrote:

> +1 for one-time use.
>
> --sent from my mobile
> On 14 Apr 2014 7:28 PM, "Robin Raymond" <robin@hookflash.com> wrote:
>
>>
>> [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 <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
>>
>>
>>