Re: Update of RTCRtpSender "doohickey" proposal

On Tue, Apr 29, 2014 at 12:52 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 04/29/2014 04:19 AM, Martin Thomson wrote:
>
>> On 28 April 2014 16:51, Justin Uberti <juberti@google.com> wrote:
>>
>>> I thought about it a bit, and I don't really see an issue with making it
>>> arbitrary. This will put the track to be in the specified MS at the other
>>> side, but I don't see a need to force the tracks to be bagged up on the
>>> send
>>> side.
>>>
>> Why not just put the stream in, not its identifier and avoid the issue?
>>
>
> Putting its identifier in rather than the stream object has some
> advantages. In particular for the case where you have been sending a
> stream, but for some reason have thrown it away, and want to connect a
> different stream on the sender side to the old stream on the receiver side.
> This would make "rehydration" simpler, I think.


In this case, you need to also be able to set the track id as well, which
we don't currently have a mechanism for.

>
>
>
>> As for the null case, generate a new stream on the remote side for
>> every track that is added that way.
>>
>>  If the stream object is null, the receiver can choose to add the track
> to an existing stream or to create a stream for it.
>
> If the stream object is an auto-generated stream, the receiver can choose
> to add the track to an existing stream or to use the stream it's handed; in
> the former case, the auto-generated stream will eventually be
> garbage-collected.
>
> In practice, there seems very little difference between the two
> alternatives, but auto-generating a stream lets the receiver skip testing
> whether there's a stream there or not, so I think I like that.
>

Indeed, this makes life simpler for the receiver.