Re: [MMUSIC] Updated MSID draft

Harald Alvestrand <harald@alvestrand.no> Sat, 02 November 2013 22:11 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974FF11E824B for <mmusic@ietfa.amsl.com>; Sat, 2 Nov 2013 15:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.255
X-Spam-Level:
X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiK2ZzGGWYWC for <mmusic@ietfa.amsl.com>; Sat, 2 Nov 2013 15:11:22 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CB7B321E8122 for <mmusic@ietf.org>; Sat, 2 Nov 2013 15:11:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D43139E070; Sat, 2 Nov 2013 23:11:19 +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 K0ju2TUSDrXh; Sat, 2 Nov 2013 23:11:18 +0100 (CET)
Received: from [192.168.235.121] (unknown [69.164.171.170]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id AF9A939E0C8; Sat, 2 Nov 2013 23:11:02 +0100 (CET)
Message-ID: <5275394F.1040901@alvestrand.no>
Date: Sat, 02 Nov 2013 18:41:35 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, mmusic <mmusic@ietf.org>
References: <5270B191.9030603@alvestrand.no> <5273ACB5.2020201@ericsson.com>
In-Reply-To: <5273ACB5.2020201@ericsson.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [MMUSIC] Updated MSID draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2013 22:11:28 -0000

On 11/01/2013 02:29 PM, Magnus Westerlund wrote:
> Can you clarify how synchronized playback of multiple different media
> streams, that on RTP level shares CNAME can be achieved in the context
> of WebRTC.

In the context of the WebRTC API spec, there exist no guarantees about
synchronization between different MediaStreams. The UA is free to play
them out synchronized or unsynchronized; of course synchronized playback
is also in accordance with the specification.

>  If that is not an issue with separate MediaStreams then I am
> fine with this. If the main way of achieving synchronized playback is to
> put the MediaStreamTracks in the same MediaStream then we have an issue.
> I see a point in that each endpoitn (CNAME) should have its SSRCs with
> source packet streams result in MediaStreamTracks in the same
> MediaStream. But, as you write that either introduces delay into adding
> a MediaStreamTrack until RTCP info has been received or otherwise a lot
> of change events as one makes one assumption and then have to correct it
> as more data comes in.

I think I see what you mean now; this is an issue with compatibility
with non-WMS systems that rely on CNAME for signalling that
synchronization should occur.

I see two solutions for compatibility:

- Add all tracks with the same CNAME to the same MediaStream. Do not
signal the addstream or addtrack events until the CNAME is known. This
delays playout start, but is compatible with preexisting usage.

- Generate separate MediaStreams as in the current spec, but put in a
note that if these are played out locally, they SHOULD be synchronized.

In the latter case, Javascript will have no way of telling that the
tracks are in fact synchronized, but they will play out correctly.





-- 
Surveillance is pervasive. Go Dark.