Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 04 February 2014 10:01 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB66A1A03D4 for <avt@ietfa.amsl.com>; Tue, 4 Feb 2014 02:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.02
X-Spam-Level:
X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgR9WBpNpwCQ for <avt@ietfa.amsl.com>; Tue, 4 Feb 2014 02:01:36 -0800 (PST)
Received: from smtpdg1.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id 1617D1A03B8 for <avt@ietf.org>; Tue, 4 Feb 2014 02:01:35 -0800 (PST)
Received: from lminiero ([143.225.229.166]) by smtpcmd01.ad.aruba.it with bizsmtp id NA1Y1n01F3c3Lvj01A1Ytj; Tue, 04 Feb 2014 11:01:33 +0100
Date: Tue, 04 Feb 2014 11:01:32 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Message-ID: <20140204110132.0edc1a1b@lminiero>
In-Reply-To: <BLU181-W54813B81203A593F5D9D2D93AB0@phx.gbl>
References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <D13C6CDA-5BD0-43A4-951C-E35B41DDD29E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> <BLU181-W54813B81203A593F5D9D2D93AB0@phx.gbl>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 04 Feb 2014 15:39:00 -0800
Cc: "straw@ietf.org" <straw@ietf.org>, Colin Perkins <csp@csperkins.org>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Feb 2014 10:01:39 -0000

Colin, Bernard,

thanks for this feedback, this is exactly what we were waiting for!

I agree the draft is pretty rough and simple right now. We started this
way to gather some feedback on whether or not we were heading the right
direction in the first place, before delving in some more complex use
cases and scenarios.

Just as a clarification, it is indeed focused on the simpler two-person
case right now, but not only audio, actually: the same principles
described in the draft can be effectively used for a video call between
two people as well (I'm using them in some implementations as well),
or at least they should. If you feel this is unclear right now, we can
try and fix the text to make this clearer.

We'll definitely address the scenarios you both mentioned in the next
versions of the draft.

Thanks,
Lorenzo


Il giorno Mon, 3 Feb 2014 08:39:39 -0800
Bernard Aboba <bernard_aboba@hotmail.com> ha scritto:

> I agree with Colin that this draft appears focused on a single use
> case:  a two-person voice call. It does not appear to apply to video
> use cases, such as those involving a  MANE or Selective Forwarding
> Unit. For example, the advice in Section 3.2 on processing of
> feedback messages would not necessarily apply for the case of a
> MANE/SFU. For example, the MANE/SFU might consume feedback messages
> sent from a client and not forward them on to the source, instead
> choosing to address the feedback itself.  For example, in the case
> where the client reports loss, a MANE may respond by reducing
> bandwidth going to the client, by for example, dropping one or more
> extension layers in SVC, or switching to a lower resolution simulcast
> stream.  
> > -----Original Message-----
> > From: Colin Perkins [mailto:csp@csperkins.org] 
> > Sent: 3. helmikuuta 2014 12:32
> > To: Christer Holmberg
> > Cc: avt@ietf.org
> > Subject: Re: [AVTCORE] STRAW WG document review request:
> > draft-ietf-straw-b2bua-rtcp-00
> > 
> > Christer,
> > 
> > From a quick glance, this draft looks okay as far as it goes,
> > although it seems to assume the B2BUA is processing a call with
> > only two parties and a single media flow. For example, Section 3.2
> > has several mentions of "the SSRC" for packets that can contain
> > multiple SSRCs. With RTCWEB and CLUE both supporting multiparty
> > calls with multiple media flows, I would suggest that this draft
> > needs to consider those use cases more fully. 
> > 
> > I see no mention of the rewriting the CSRC list, which is straight
> > forward but necessary if an RTP mixer is in use.
> > 
> > The list of RTCP packet types in Section 3.2 is incomplete. The
> > draft should certainly discuss rewriting RTCP XR packets, and
> > should probably consider the other RTCP packet types registered
> > with IANA (even if only to explicitly list them as being for future
> > specification).
> > 
> > There are several cases where that draft says to "properly replace"
> > a changed sequence number. It might be helpful to be specific what
> > that means. If the goal is that the B2BUA forwards all packets, but
> > rewrites the RTP sequence number, then the modifications are
> > straight forward. If the B2BUA discards, combines, or splits RTP
> > packets, then the modifications needed get much more complex, and
> > are not obvious in many cases. Defining the scope clearly, and
> > explaining what modifications are possible and what need more
> > complex rules than described, is important here.
> > 
> > Some of the discussion in the topologies draft is relevant, but
> > that draft isn't cited. 
> > 
> > There's no mention of media path security (SRTP, etc.), keying, and
> > how this impacts B2BUAs operating on the media traffic. 
> > 
> > Regards,
> > Colin
> > 
> > 
> > 
> > On 29 Jan 2014, at 12:27, Christer Holmberg
> > <christer.holmberg@ericsson.com> wrote:
> > > Hi,
> > >  
> > > In the STRAW WG we are working on the following document:
> > >  
> > > http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00
> > >  
> > > The STRAW WG chairs think it would be very useful, and we would
> > > deeply appreciate, if some people from the AVTCORE community
> > > would have some time and interest in reviewing and providing
> > > comments on the document (on the STRAW list). Please let me know
> > > if you are willing to do such review :) Thanks!
> > >  
> > > Regards,
> > >  
> > > Christer
> > > STRAW WG co-chair
> > > _______________________________________________
> > > Audio/Video Transport Core Maintenance avt@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/avt
> > 
> > 
> > 
> > -- 
> > Colin Perkins
> > http://csperkins.org/
> > 
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>