[MMUSIC] Comments on draft-begen-mmusic-redundancy-grouping-01
Magnus Westerlund <magnus.westerlund@ericsson.com> Sat, 23 July 2011 10:58 UTC
Return-Path: <magnus.westerlund@ericsson.com>
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 38B8B21F86EA; Sat, 23 Jul 2011 03:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.034
X-Spam-Level:
X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, 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 93msG5jGEt7v; Sat, 23 Jul 2011 03:58:31 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3026E21F86C0; Sat, 23 Jul 2011 03:58:31 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-f1-4e2aa9552167
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.CA.20773.559AA2E4; Sat, 23 Jul 2011 12:58:29 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 23 Jul 2011 12:58:28 +0200
Message-ID: <4E296F64.70500@ericsson.com>
Date: Fri, 22 Jul 2011 14:39:00 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "mmusic (E-mail)" <mmusic@ietf.org>, IETF AVTCore WG <avt@ietf.org>
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Subject: [MMUSIC] Comments on draft-begen-mmusic-redundancy-grouping-01
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, 23 Jul 2011 10:58:32 -0000
Hi, (Primarily as individual, but the WG home question is as WG chair) I have reviewed this draft and some comments on it. 1. If this solution proposal is to be taken forward I think it needs to be discussed in AVTCORE. The reason is that it has several RTP details that needs to be figured out to make stream duplication issue free in a general usage. I will take up a few of these issues in the below comments. 2. One aspect this document has is a relation to what is discussed in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream duplication both results in a certain form of multi-stream and also has a similar but slightly different semantics to simulcast in that the streams are two representations of a single original media source. In this case they are clones, but not true duplicates due to that RTP doesn't handle try duplicates well. 3. Another issue that also the authors has identified is the question of what one do when one has multiple media streams from the same end-point. And in a general case one can't use the CNAME to separate the sources. The reason is that two media sources that has a common timing (synchronization) context do needs to indicate that by having the same CNAME. Thus there are need for some additional mechanism to ensure that SSRC carrying RTP media streams that are duplicates of each other do in fact be labeled explicitly. I also note that a SDP based solution is not sufficient to resolve this issue. I think we need something in RTP, so that SSRC collisions can be handled. 4. In addition there is a few questions how this duplication really should set some RTP fields. Is the duplication only working on Sequence number level? There seem to be additional questions, for example in the need to have RTP timestamp considerations between the streams. They need to point identically into the joint timeline. Otherwise outages, or receiver taking synch from one and not the other stream can end up with different synchronizations. Becomes especially interesting to discuss when the time shifted transmission. 5. The draft also discussed Payload Type differences and have them in the SDP examples. I don't see how that is appropriate. If the streams are true encoding duplicates then they should use the same payload type configuration, and thus a single payload type should be sufficient and in fact recommended, unless the source encoding truly changes. 6. I think it is worth discussing also the benefits of SSRC multiplexed versus the session multiplexed. In multicast context there is clear benefits from a control and congestion perspective to have session multiplexed versions and these mapped onto different multicast groups enabling a receiver to choose one or both streams. 7. Thus I think the signalling aspects of this is the minor part. Although there clearly are some aspects of this needing discussion. For example clearer offer/answer rules for handling these. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [MMUSIC] Comments on draft-begen-mmusic-redundanc… Magnus Westerlund
- Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mm… Ali C. Begen (abegen)
- Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mm… Magnus Westerlund
- Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mm… David R Oran
- Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mm… Ali C. Begen (abegen)
- Re: [MMUSIC] [AVTCORE] Comments on draft-begen-mm… Magnus Westerlund