Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization

[Harald Alvestrand <[e-mail]>]

On 02/07/2013 09:08 PM, Charles Eckel (eckelcu) wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Eric Rescorla
>> Sent: Thursday, February 07, 2013 3:03 PM
>> To: Stefan Hakansson LK
>> Cc: [e-mail]
>> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for
>> synchronization
>>
>>
>>
>> On Thu, Feb 7, 2013 at 11:59 AM, Stefan Hakansson LK
>> <[e-mail]> wrote:
>>
>>
>> 	On 02/07/2013 08:43 PM, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>
>> 		    My question is basically: what if the sender creates two
>> 		    MediaStreams for which all tracks have local sources
>> (cam's,
>> 		    mike's), sends them to a peer, will the RTP streams for
>> both
>> 		    MediaStreams have the same or different CNAME?
>>
>> 		    I argued for that they should have the same.
>>
>>
>> 		Yes, I think this is a separate (and fraught) question. :)
>>
>>
>>
>> 	Separate question, but I think the answer should be documented
>> (regardless on if it is "same", "different" or "implementers choice").
>>
>>
>>
>> Agreed.
> I think SHOULD is the correct thing to document. I can imagine there will be cases in which the sender will be a somewhat distributed app that does not really know that the media source should be synchronized, so it will assign a different CNAME.
> The rest of the proposal sounded good as well.
>
>
SHOULD often makes me unhappy, because it can lead easily to something 
being true so much of the time, people forget to check for whether it is 
true or not.

I think "all the streams have local sources" is a property that we 
shouldn't require that one end of a PeerConnection reveals to the other end.

(Parenthesis: In the discussion, the question was raised of what it 
meant to send out two tracks in one MediaStream that were not 
originallly synchronized - one local and one remote, for instance. The 
best answer I heard was that they would have to be synchronized 
(re-clocked if necessary) in such a way that when played out at the 
recipient, they would give the same experience as when played out 
locally at the sender - same relative timing for the playout.)