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

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