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

Harald Alvestrand <harald@alvestrand.no> Tue, 12 February 2013 07:38 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6321F8BE8 for <rtcweb@ietfa.amsl.com>; Mon, 11 Feb 2013 23:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.351
X-Spam-Level:
X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwcjZ5AOV2Ii for <rtcweb@ietfa.amsl.com>; Mon, 11 Feb 2013 23:38:01 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4521F8BDB for <rtcweb@ietf.org>; Mon, 11 Feb 2013 23:38:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A188839E1BB for <rtcweb@ietf.org>; Tue, 12 Feb 2013 08:37:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Q6QKsMkjZ5 for <rtcweb@ietf.org>; Tue, 12 Feb 2013 08:37:57 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:906d:d465:2b80:5d1d] (unknown [IPv6:2001:470:de0a:27:906d:d465:2b80:5d1d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B198939E0A7 for <rtcweb@ietf.org>; Tue, 12 Feb 2013 08:37:57 +0100 (CET)
Message-ID: <5119F155.8090303@alvestrand.no>
Date: Tue, 12 Feb 2013 08:37:57 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CABcZeBO105HXWoRAbaAR0fGTCLtDmAyjt-DOM=aKy80sg2SG_Q@mail.gmail.com> <51140038.3040001@ericsson.com> <CABcZeBP_-ce-JT-oDkpkDoRKjrZo+m7NLTcifCOsRBM_qKPTmg@mail.gmail.com> <511407AA.1040501@ericsson.com> <CABcZeBO0oSYw-M-1wVujftiYdBtJ67SBfMp4k5gSm45HFhZ+=A@mail.gmail.com> <92B7E61ADAC1BB4F941F943788C0882804788D71@xmb-aln-x08.cisco.com> <51157034.3020800@alvestrand.no> <51164AFC.80700@ericsson.com> <51165FCA.2040707@alvestrand.no> <511796C6.3050601@ericsson.com> <511820F9.5080806@alvestrand.no> <5118EDC1.2000809@ericsson.com>
In-Reply-To: <5118EDC1.2000809@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2013 07:38:04 -0000

On 02/11/2013 02:10 PM, Stefan Håkansson LK wrote:
>>> If this is indeed a problem, then there must be other ways. A setting
>>> "privacy=on" on PeerConnection, or do not expose CNAME to the app (do
>>> we really need to signal it?; and [1] indicates you can use other
>>> CNAME's than those signaled).
>> What I'd like to have is to have no statement that forces (even at
>> SHOULD level) all local sources to have the same CNAME, and perhaps even
>> an explicit statement that the sender can use different CNAMEs for local
>> sources if it wants to (for whatever reason it wants to do so), as long
>> as they are in different tracks.
>
> The problem I have with this is that it makes it impossible for 
> someone building a service to know whether streams will be synced (and 
> I mean in situations when syncing makes sense - not when the video is 
> delayed by 500ms) or not. This is fully up to the browser - it may be 
> that sometimes they are and sometimes not.

I don't understand what the problem is here. I may be dumb.
If syncing is important to the guy writing the service, (he can't live 
with them being unsynchronized), he should put them in the same stream.

Under your suggestion, it would be impossible to generate two 
MediaStreams that have local content and are *not* synced - I don't see 
a reason to outlaw that.

The practical issue I can think of would be a source that had its own 
clock, not the system clock, but is otherwise a local source. Having the 
same CNAME would require resynchronizing that source. I don't know if 
any such sources exist in practice, but again, I don't want to outlaw them.


>
> I would prefer that all streams used the same CNAME (if it is signaled 
> or not is another question). If this is a privacy issue I think we 
> should solve that instead of having the browser use, or not use, the 
> same CNAMEs at its own will. 

CNAMEs are signaled in RTCP SRs. We don't have the option of leaving 
them out.