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

[Christer Holmberg <[e-mail]>]

(As co-chair)

Hi Albrecht,

Thanks for your review!

Regards,

Christer

From: straw [mailto:[e-mail]] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Tuesday, February 11, 2014 5:20 PM
To: Bernard Aboba; Lorenzo Miniero
Cc: [e-mail]; Campos, Simao; [e-mail]; [e-mail]; Colin Perkins
Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00


Dear All,

like to provide further review comments:



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]<mailto:[e-mail]>; Colin Perkins; [e-mail]<mailto:[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