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

[Lorenzo Miniero <[e-mail]>]

Il giorno Tue, 11 Feb 2014 16:20:24 +0000
"Schwarz, Albrecht (Albrecht)" <[e-mail]> ha
scritto:

> Dear All,
> 
> like to provide further review comments:
> 
> 


Thanks for your detailed comments, Albrecht!
We'll definitely address them in the next version of the draft.

Lorenzo


> 
> 1.  Terminology:
> [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC
> 7092.
> 
> 
> 2.  Media plane B2BUA vs RTP topologies:
> RFC 7092 differentiates precisely between the signalling (SIP) B2BUA
> and media plane B2BUA part. Hence, this draft is just focusing on the
> media plane B2BUA entity with scope on RTP/RTCP traffic handling
> only. And the "RTP/RTCP B2BUA" behaviour is actually the concept
> related to "RTP topologies" (RFC 5117). Conclusions:
> 
> a.  this draft
> must refer to a) [RFC 5117] and
> should refer to b) [draft-ietf-avtcore-rtp-topologies-update]
> 
> b.  Terms "media relay", "media-aware relay" & "media-terminator"
> could and should be linked (or even replaced) by concrete RTP
> topology types (here, I guess: RTP transport translator, RTP media
> translator and RTP endsystem)
> 
> 
> 3.  Why reference to "RTP topology" concept?
> Because "RTCP handling" is (loosely / tightly) coupled to "RTP
> topologies" (see above references). Thus, the "RTCP B2BUA" behaviour
> is essentially determined firstly by the RTP topology ... (being
> aware that above RTP topology references could still add more
> detailed RTCP handling behaviour ... and this is one purpose of
> avtcore-rtp-topologies-update in our understanding)
> 
> 
> 4.  Call type: 2-party vs multiparty
> => this subject would be inherently addressed as well when referring
> to RTP topologies (e.g., RTCP handling by RTP topology "RTP mixer"
> etc etc)
> 
> 
> 5.  B2BUAs in integrated and decomposed SBCs:
> Fig.1 isn't specific on that aspect, but looks like an integrated SBC
> (but signalling isn't indicated), hence could be also just the media
> plane B2BUA instance (=> would change the Fig. title). Concerning
> decomposed SBCs, following reference might be beneficial: [ITU-T
> H.248.88] Gateway control protocol: RTP topology dependent RTCP
> handling by ITU-T H.248 media gateways with IP terminations
> 
> Background: H.248.88 defines the media plane B2BUA behaviour
> concerning RTCP handling in case of decomposed SBCs following the
> H.248 gateway model. H.248.88 is tightly coupled to the RTP topology
> concept.
> 
> 
> 6.  Principal challenge for "RTCP B2BUA" behaviour: guess you got
> already the feeling that it is fairly difficult to define unambiguous
> RTCP handling for the entire plethora of "media plane B2BUA" types
> (RTP topologies). This problem could be solved by introducing a "RTCP
> service" concept. E.g., H.248.88 uses following service model: a)
> basic RTCP service = RTCP capabilities according "core RTP" (i.e.,
> RFC 3550) b) RTP profile dependent RTCP services = RFCs 3551 | 3711 |
> 4585 | 5124 | .... c) supplementary RTCP services = e.g., RTCP XR
> (RFC 3611), RFC 5760, RFC 6051
> 
> Now, H.248.88 makes the assumption that RTCP service categories (a &
> b) are tightly coupled to the RTP topology, but category (c) could be
> independent of the applied RTP topology. Such a proceeding is
> drastically simplifying the complexity space ... and may be also
> motivated/justified from network operational point.
> 
> Example: a performance monitoring service (RTCP XR based) as an
> network overlay on top of the variety of RTP node types (RTP
> transport translator, RTP mixer, etc).
> 
> 
> 
> Regards,
> 
> Albrecht
> 
> 
> PS
> 
> [ITU-T H.248.88]
> 
> is just PRE-PUBLISHED, but the freely available document is expected
> to be published soon at the ITU-T web site.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: straw [mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: Dienstag, 4. Februar 2014 16:25
> To: Lorenzo Miniero
> Cc: [e-mail]; Colin Perkins; [e-mail]
> Subject: Re: [straw] STRAW WG document review request:
> draft-ietf-straw-b2bua-rtcp-00
> 
> 
> 
> I do not believe that the document even accurately describes a two
> person video call intermediated by a MANE/SFU.
> 
> 
> 
> > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero"
> > <[e-mail]<mailto:[e-mail]>> wrote:
> 
> >
> 
> > 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
> 
> > <[e-mail]<mailto:[e-mail]>> 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:[e-mail]]
> 
> >>> Sent: 3. helmikuuta 2014 12:32
> 
> >>> To: Christer Holmberg
> 
> >>> Cc: [e-mail]<mailto:[e-mail]>
> 
> >>> 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
> 
> >>> <[e-mail]<mailto:[e-mail]>>
> >>> 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
> >>>> [e-mail]<mailto:[e-mail]>
> 
> >>>> https://www.ietf.org/mailman/listinfo/avt
> 
> >>>
> 
> >>>
> 
> >>>
> 
> >>> --
> 
> >>> Colin Perkins
> 
> >>> http://csperkins.org/
> 
> >>>
> 
> >>>
> 
> >>>
> 
> >>> _______________________________________________
> 
> >>> Audio/Video Transport Core Maintenance
> >>> [e-mail]<mailto:[e-mail]>
> 
> >>> https://www.ietf.org/mailman/listinfo/avt
> 
> >>
> 
> _______________________________________________
> 
> straw mailing list
> 
> [e-mail]<mailto:[e-mail]>
> 
> https://www.ietf.org/mailman/listinfo/straw