IETF Logo Mail Archive

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

Thomas Schierl <schierl@hhi.fhg.de> Mon, 19 October 2009 15:33 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 A9CDE3A68C0 for <mmusic@core3.amsl.com>; Mon, 19 Oct 2009 08:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level:
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, MIME_HTML_ONLY=1.457, 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 S2DP6WACiETh for <mmusic@core3.amsl.com>; Mon, 19 Oct 2009 08:33:40 -0700 (PDT)
Received: from mail.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 609A53A6778 for <mmusic@ietf.org>; Mon, 19 Oct 2009 08:33:40 -0700 (PDT)
Received: by mail.hhi.fraunhofer.de (Postfix, from userid 65534) id 7094A1D8903E; Mon, 19 Oct 2009 17:33:45 +0200 (CEST)
Received: from imsva.hhi.de (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2CAD9150036; Mon, 19 Oct 2009 17:33:45 +0200 (CEST)
Received: from [10.8.0.10] (unknown [10.8.0.10]) (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 ED9D31D88F51; Mon, 19 Oct 2009 17:33:44 +0200 (CEST)
Message-ID: <4ADC86D7.9030307@hhi.fhg.de>
Date: Mon, 19 Oct 2009 17:33:43 +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: "Ali C. Begen (abegen)" <abegen@cisco.com>
References: <9AAEDF491EF7CA48AB587781B8F5D7C6024FEC0C@srvxchg3.cablelabs.com> <4ADC589D.8000306@hhi.fhg.de> <04CAD96D4C5A3D48B1919248A8FE0D540A6E779B@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A6E779B@xmb-sjc-215.amer.cisco.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-alterMIME: Yes
Cc: Jean-Francois Mule <jf.mule@cablelabs.com>, 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 15:33:41 -0000

Hi  Ali,

Ali C. Begen (abegen) wrote: 
Now, this sounds different than the first scenario you described above, IMO. And, this leads to the original SDP you gave:

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

You are right, RB and RB+E are meant to be additive with respect to SB+SE.


  

    
section 4.1:

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

  

  
Why would it be contrary? Here, RB and RB+E are in the same line and that is enough to state their additivity. But, in this scenario, their joint decoding helps the group of SB+SE. The above SDP says if the source consists of SB only, then just use RB only since RB+E would not help with decoding.
 
  

  

    
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.
    

  

  
We can add this to make it stronger. But, I believe if two repair flows are additive in a group, it does not mean that they will also be additive in any other group where one of the source flows they protect is listed.
  





I think this makes the text clearer, at least to me.





  
Agree?

  

  

    
- 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 believe this was clear, but it is a good suggestion.
  





Good





  
 
  

  

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

  

  
Sure.

Thanks for the review. Let me know if you agree with the above.
  





Thanks for the clarifications. I am ok with the changes and the
resulting draft.



Thomas





  
Cheers, acbegen.

 
  

  

    
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" rel="nofollow">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" rel="nofollow">https://www.ietf.org/mailman/listinfo/mmusic



      

    

    

    

  

  

  






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












      
    

    

      
    


 




             


      

        
      

          
    
 

    


 

    



    






    

    


    
  
    
  

      
v2.23.0 | Report a Bug | By Email