Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03

Thomas Schierl <schierl@hhi.fhg.de> Mon, 19 October 2009 12:16 UTC

Return-Path: <schierl@hhi.fhg.de>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C753A68BB for <mmusic@core3.amsl.com>; Mon, 19 Oct 2009 05:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.637
X-Spam-Level:
X-Spam-Status: No, score=-4.637 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KIDIVdgDjaN for <mmusic@core3.amsl.com>; Mon, 19 Oct 2009 05:16:26 -0700 (PDT)
Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 3FE5B3A69CD for <mmusic@ietf.org>; Mon, 19 Oct 2009 05:16:26 -0700 (PDT)
Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 2FF1F1D89026; Mon, 19 Oct 2009 14:16:30 +0200 (CEST)
Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 751F4150041; Mon, 19 Oct 2009 14:16:30 +0200 (CEST)
Received: from [130.149.228.125] (unknown [130.149.228.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Thomas Schierl", Issuer "Fraunhofer-Gesellschaft Root-CA v2" (not verified)) by mail.hhi.fraunhofer.de (Postfix) with ESMTP id 962E21D88F51; Mon, 19 Oct 2009 14:16:29 +0200 (CEST)
Message-ID: <4ADC589D.8000306@hhi.fhg.de>
Date: Mon, 19 Oct 2009 14:16:29 +0200
From: Thomas Schierl <schierl@hhi.fhg.de>
Organization: Fraunhofer HHI
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Jean-Francois Mule <jf.mule@cablelabs.com>
References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEC0C@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEC0C@srvxchg3.cablelabs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-alterMIME: Yes
Cc: mmusic@ietf.org, Joerg Ott <jo@netlab.tkk.fi>, draft-ietf-mmusic-rfc4756bis@tools.ietf.org
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4756bis-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 19 Oct 2009 12:16:28 -0000

Dear Ali,

I am not sure if the SDP signaling is covering all cases. What is about 
the case of having a SVC or any other layered media, where one session 
SB contains the base layer and another session SE contains the 
enhancement layer. Let us assume session SB is protected by  repair flow 
RB. Furthermore, session SB and SE are jointly protected by repair flow 
RB+E. Additionally, RB+E is additive to RB. The only way expressing this 
with the current draft seems to be:

        a=group:FEC-XR SB RB
        a=group:FEC-XR SB SE RB RB+E

I would expect that the grouping can signal that RB can be used 
separately for SB, but RB and RB+E can be also jointly used for the 
combination of SB and SE. Would the above grouping be in line with the 
current draft? I wonder if this may be somehow contrary to definition in 
section 4.1:

"Repair flows that are in different FEC groups are non-
   additive.".

If the signaling in the example above is in line with the intention of 
the draft, I would make the following modifications:

- You may add an "...exclusively in different FEC groups..." to the 
sentence of section 4.1 above.
- Further, I would add the following text to section 4.1 to make it clearer:

"In order to express multiple relations between source and repair flows, 
source and repair flows may appear in more than one FEC group."

I think the same should be valid for the FEC-SSRC grouping.

Best regards,
Thomas


-- 
Thomas Schierl
--------------
Fraunhofer HHI



Jean-Francois Mule wrote:
> This is to start a 2-week working group last call on draft
> draft-ietf-mmusic-rfc4756bis-03,
> http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-03.  The comment
> period will end on Wednesday October 28.
>
> Please send your comments to the mmusic list and the authors.
>
> Thank you,
> Jean-Francois.
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>