From albrecht.schwarz@alcatel-lucent.com Tue Feb 11 08:20:46 2014 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9B1A0630; Tue, 11 Feb 2014 08:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 D_OcXfH0guwi; Tue, 11 Feb 2014 08:20:41 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC91A0623; Tue, 11 Feb 2014 08:20:40 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1BGKP8E024305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Feb 2014 10:20:27 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1BGKPL9020162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 17:20:25 +0100 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.192]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 11 Feb 2014 17:20:25 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Bernard Aboba , Lorenzo Miniero Thread-Topic: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 Thread-Index: AQHPJ0UrlbOPbn5ppEusJxSoCnPQqg== Date: Tue, 11 Feb 2014 16:20:24 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> <20140204110132.0edc1a1b@lminiero> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_" MIME-Version: 1.0 Cc: "megaco@ietf.org" , "Campos, Simao" , "straw@ietf.org" , "avt@ietf.org" , Colin Perkins Subject: Re: [Megaco] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:20:46 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 me= dia 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 det= ermined firstly by the RTP topology ... (being aware that above RTP topolog= y 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 =3D> this subject would be inherently addressed as well when referring to R= TP 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 (=3D> 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 hand= ling by ITU-T H.248 media gateways with IP terminations Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P 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 t= he 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 =3D RTCP capabilities according "core RTP" (i.e., RFC= 3550) b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= .... c) supplementary RTCP services =3D 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 m= ay be also motivated/justified from network operational point. Example: a performance monitoring service (RTCP XR based) as an network ove= rlay 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:straw-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Dienstag, 4. Februar 2014 16:25 To: Lorenzo Miniero Cc: straw@ietf.org; Colin Perkins; avt@ietf.org Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00 I do not believe that the document even accurately describes a two person v= ideo call intermediated by a MANE/SFU. > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" > 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 > > 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 >>> >= 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 >> _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw --_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 me= dia 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 rela= ted 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 link= ed (or even replaced) by concrete RTP topology types (here, I guess: RTP tr= ansport translator, RTP media translator and RTP endsystem)

3.  Why reference to “RTP topology” concept= ?
Because “RTCP handling” is (loosely / tightly) coupled to ̶= 0;RTP topologies” (see above references). Thus, the “RTCP B2BUA= ” behaviour is essentially determined firstly by the RTP topology = 230; (being aware that above RTP topology references could still add more detailed RTCP handling behaviour … and this is one purpose of avtcor= e-rtp-topologies-update in our understanding)

4.  Call type: 2-party vs multiparty
=3D> this subject would be inherently addressed as well when referring t= o RTP topologies (e.g., RTCP handling by RTP topology “RTP mixer̶= 1; 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 (=3D> 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 hand= ling by ITU-T H.248 media gateways with IP terminations

Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P 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” be= haviour: guess you got already the feeling that it is fairly difficult to d= efine unambiguous RTCP handling for the entire plethora of “media pla= ne B2BUA” types (RTP topologies).
This problem could be solved by introducing a “RTCP service” co= ncept. E.g., H.248.88 uses following service model:
a) basic RTCP service =3D RTCP capabilities according “core RTP”= ; (i.e., RFC 3550)
b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= ….
c) supplementary RTCP services =3D 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 indepen= dent of the applied RTP topology.
Such a proceeding is drastically simplifying the complexity space … a= nd may be also motivated/justified from network operational point.

Example: a performance monitoring service (RTCP XR based) as an network ove= rlay 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 d= ocument is expected to be published soon at the ITU-T web site.<= /p>

 

 

-----Original Message----- From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Dienstag, 4. Februar 2014 16:25
To: Lorenzo Miniero
Cc: straw@ietf.org; Colin Perkins; avt@ietf.org
Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00

 

I do not believe that the document even accuratel= y describes a two person video call intermediated by a MANE/SFU.

 

> On Feb 4, 2014, at 2:01 AM, "Lorenzo Mi= niero" <lorenzo@meetecho.com> wrot= e:

>

> Colin, Bernard,

>

> thanks for this feedback, this is exactly wh= at 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 d= elving in some more

> complex use cases and scenarios.<= /p>

>

> Just as a clarification, it is indeed focuse= d on the simpler

> two-person case right now, but not only audi= o, actually: the same

> principles described in the draft can be eff= ectively used for a video

> call between two people as well (I'm using t= hem in some

> implementations as well), or at least they s= hould. If you feel this is

> unclear right now, we can try and fix the te= xt to make this clearer.

>

> We'll definitely address the scenarios you b= oth mentioned in the next

> versions of the draft.

>

> Thanks,

> Lorenzo

>

>

> Il giorno Mon, 3 Feb 2014 08:39:39 -0800 Ber= nard Aboba

> <bernard_aboba@ho= tmail.com> ha scritto:

>

>> I agree with Colin that this draft appea= rs 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&nbs= p; 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 migh= t 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 ma= y respond by reducing

>> bandwidth going to the client, by for ex= ample, 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<= /o:p>

>>> To: Christer Holmberg

>>> Cc: = avt@ietf.org

>>> Subject: Re: [AVTCORE] STRAW WG docu= ment review request:

>>> draft-ietf-straw-b2bua-rtcp-00<= /o:p>

>>>

>>> Christer,

>>>

>>> From a quick glance, this draft look= s okay as far as it goes,

>>> although it seems to assume the B2BU= A is processing a call with only

>>> two parties and a single media flow.= For example, Section 3.2 has

>>> several mentions of "the SSRC&q= uot; for packets that can contain multiple

>>> SSRCs. With RTCWEB and CLUE both sup= porting multiparty calls with

>>> multiple media flows, I would sugges= t that this draft needs to

>>> consider those use cases more fully.=

>>>

>>> I see no mention of the rewriting th= e CSRC list, which is straight

>>> forward but necessary if an RTP mixe= r is in use.

>>>

>>> The list of RTCP packet types in Sec= tion 3.2 is incomplete. The

>>> draft should certainly discuss rewri= ting RTCP XR packets, and should

>>> probably consider the other RTCP pac= ket types registered with IANA

>>> (even if only to explicitly list the= m as being for future

>>> specification).

>>>

>>> There are several cases where that d= raft 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, th= en the modifications are

>>> straight forward. If the B2BUA disca= rds, combines, or splits RTP

>>> packets, then the modifications need= ed get much more complex, and

>>> are not obvious in many cases. Defin= ing the scope clearly, and

>>> explaining what modifications are po= ssible and what need more

>>> complex rules than described, is imp= ortant here.

>>>

>>> Some of the discussion in the topolo= gies draft is relevant, but that

>>> draft isn't cited.

>>>

>>> There's no mention of media path sec= urity (SRTP, etc.), keying, and

>>> how this impacts B2BUAs operating on= the media traffic.

>>>

>>> Regards,

>>> Colin

>>>

>>>

>>>

>>> On 29 Jan 2014, at 12:27, Christer H= olmberg

>>> <chr= ister.holmberg@ericsson.com> wrote:

>>>> Hi,

>>>>

>>>> In the STRAW WG we are working o= n the following document:

>>>>

>>>> http://tools.ietf.org= /html/draft-ietf-straw-b2bua-rtcp-00

>>>>

>>>> The STRAW WG chairs think it wou= ld be very useful, and we would

>>>> deeply appreciate, if some peopl= e from the AVTCORE community would

>>>> have some time and interest in r= eviewing and providing comments on

>>>> the document (on the STRAW list)= . Please let me know if you are

>>>> willing to do such review :) Tha= nks!

>>>>

>>>> Regards,

>>>>

>>>> Christer

>>>> STRAW WG co-chair

>>>> ________________________________= _______________

>>>> Audio/Video Transport Core Maint= enance avt@ietf.org

>>>> https://www.ietf.org/= mailman/listinfo/avt

>>>

>>>

>>>

>>> --

>>> Colin Perkins

>>> http://csperkins.org/

>>>

>>>

>>>

>>> ____________________________________= ___________

>>> Audio/Video Transport Core Maintenan= ce avt@ietf.org

>>> htt= ps://www.ietf.org/mailman/listinfo/avt

>>       = ;            &n= bsp;    

_______________________________________________

straw mailing list

straw@ietf.org=

https://www.ie= tf.org/mailman/listinfo/straw

--_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_-- From christer.holmberg@ericsson.com Tue Feb 11 08:26:34 2014 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7091A01FD; Tue, 11 Feb 2014 08:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SSOydtYkKveV; Tue, 11 Feb 2014 08:26:28 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 626671A01A8; Tue, 11 Feb 2014 08:26:24 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-98-52fa4f2e0279 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CB.AA.04249.E2F4AF25; Tue, 11 Feb 2014 17:26:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0387.000; Tue, 11 Feb 2014 17:26:22 +0100 From: Christer Holmberg To: "'Schwarz, Albrecht (Albrecht)'" , Bernard Aboba , Lorenzo Miniero Thread-Topic: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 Thread-Index: AQHPJ0VBJSWyPYunbkqIhZ9bKb/t1ZqwPV3Q Date: Tue, 11 Feb 2014 16:26:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16B527@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> <20140204110132.0edc1a1b@lminiero> <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvja6+/68gg6YWbos/rb8YLV72rGS3 2L/kMrPF8pcnGC22b1nAZHH3ywomiwWdO9gtbjU/ZnXg8Gh9tpfVY9r9+2wej3vOsHksWfKT yePb/GUsHh0P77MHsEVx2aSk5mSWpRbp2yVwZVz8dJel4O1+pop7PXOZGhhXTWfqYuTkkBAw kfh//AojhC0mceHeerYuRi4OIYEjjBIb/h6HchYDOSuvMXcxcnCwCVhIdP/TBmkQEVjIKNF9 TASkhllgB6PEhe97mUESwgLhEp2zj7CB1IsIREhM3FIPUW8k8eVSOwuIzSKgKrHt7Uo2EJtX wFei9+NGqF0LmSXa+4+DJTgFoiWObm5kB7EZga77fmoN2NXMAuISt57Mh/pAQGLJnvPMELao xMvH/1ghbCWJHxsusUDU50vcOzKLHWKZoMTJmU9YJjCKzkIyahaSsllIyiDiOhILdn9ig7C1 JZYtfM0MY5858JgJWXwBI/sqRo7i1OKk3HQjg02MwPg9uOW3xQ7Gy39tDjFKc7AoifN+fOsc JCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHxUG304aJvskWiGT2Xi8/Mvc556KtXjm6ZS8jb NWsrzx4+tuborzhj2QOXGqrufBU7afDd+/68yRomagce33y/O7O/LTfF88K9kgevp+w539V1 813N/C9sTLGPTkp+Kmg4LyR6OWhO3rMDHD/3n27I+yudaXfv/eJL37bUqZZtSmeVu2jzabll rBJLcUaioRZzUXEiABnA3lOtAgAA X-Mailman-Approved-At: Wed, 12 Feb 2014 08:03:08 -0800 Cc: Colin Perkins , "megaco@ietf.org" , "Campos, Simao" , "avt@ietf.org" , "straw@ietf.org" Subject: Re: [Megaco] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:26:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi Albrecht, Thanks for your review! Regards, Christer From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Schwarz, Albrecht = (Albrecht) Sent: Tuesday, February 11, 2014 5:20 PM To: Bernard Aboba; Lorenzo Miniero Cc: megaco@ietf.org; Campos, Simao; straw@ietf.org; avt@ietf.org; Colin Per= kins Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-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 me= dia 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 det= ermined firstly by the RTP topology ... (being aware that above RTP topolog= y 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 =3D> this subject would be inherently addressed as well when referring to R= TP 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 (=3D> 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 hand= ling by ITU-T H.248 media gateways with IP terminations Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P 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 t= he 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 =3D RTCP capabilities according "core RTP" (i.e., RFC= 3550) b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= .... c) supplementary RTCP services =3D 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 m= ay be also motivated/justified from network operational point. Example: a performance monitoring service (RTCP XR based) as an network ove= rlay 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:straw-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Dienstag, 4. Februar 2014 16:25 To: Lorenzo Miniero Cc: straw@ietf.org; Colin Perkins; avt@ietf.org Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00 I do not believe that the document even accurately describes a two person v= ideo call intermediated by a MANE/SFU. > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" > 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 > > 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 >>> >= 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 >> _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi Albrecht,

 

Thanks for your review= !

 

Regards,

 

Christer

 

From: straw [m= ailto:straw-bounces@ietf.org] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: Tuesday, February 11, 2014 5:20 PM
To: Bernard Aboba; Lorenzo Miniero
Cc: megaco@ietf.org; Campos, Simao; straw@ietf.org; avt@ietf.org; Co= lin Perkins
Subject: Re: [straw] STRAW WG document review request: draft-ietf-st= raw-b2bua-rtcp-00

 

Dear All,<= /p>

like to provide further revi= ew comments:

 

1= .  Terminology:
[I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC 7092.

2= .  Media plane B2BUA vs RT= P topologies:
RFC 7092 differentiates precisely between the signalling (SIP) B2BUA and me= dia 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 rela= ted 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 rela= y”, “media-aware relay” & “media-terminatorR= 21; could and should be linked (or even replaced) by concrete RTP topology = types (here, I guess: RTP transport translator, RTP media translator and RT= P endsystem)

3= .  Why reference to “= ;RTP topology” concept?
Because “RTCP handling” is (loosely / tightly) coupled to ̶= 0;RTP topologies” (see above references). Thus, the “RTCP B2BUA= ” behaviour is essentially determined firstly by the RTP topology = 230; (being aware that above RTP topology references could still add more detailed RTCP handling behaviour … and this is one purpose of avtcor= e-rtp-topologies-update in our understanding)

4= .  Call type: 2-party vs m= ultiparty
=3D> this subject would be inherently addressed as well when referring t= o RTP topologies (e.g., RTCP handling by RTP topology “RTP mixer̶= 1; etc etc)

5= .  B2BUAs in integrated an= d 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 (=3D> 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 hand= ling by ITU-T H.248 media gateways with IP terminations

Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P 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” co= ncept. E.g., H.248.88 uses following service model:
a) basic RTCP service =3D RTCP capabilities according “core RTP”= ; (i.e., RFC 3550)
b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= ….
c) supplementary RTCP services =3D 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 indepen= dent of the applied RTP topology.
Such a proceeding is drastically simplifying the complexity space … a= nd may be also motivated/justified from network operational point.

Example: a performance monitoring service (RTCP XR based) as an network ove= rlay on top of the variety of RTP node types (RTP transport translator, RTP= mixer, etc).

<= o:p> 

Regards,

Albrecht

PS

[ITU-T H.248.88]<= /span>

is just PRE-PUBLISHED, but t= he freely available document is expected to be published soon at the ITU-T = web site.

 

 

-----Original Message-----
From: straw [mailto:straw-bounces= @ietf.org] On Behalf Of Bernard Aboba
Sent: Dienstag, 4. Februar 2014 16:25
To: Lorenzo Miniero
Cc: straw@ietf.org; Colin Perkins; avt@ietf.org
Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00

 

I do not believe that the do= cument even accurately describes a two person video call intermediated by a= MANE/SFU.

 

> On Feb 4, 2014, at 2:01= AM, "Lorenzo Miniero" <lorenzo@meetecho.co= m> wrote:

>

> Colin, Bernard,

>

> thanks for this feedbac= k, this is exactly what we were waiting for!

>

> I agree the draft is pr= etty 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 s= cenarios.

>

> Just as a clarification= , it is indeed focused on the simpler

> two-person case right n= ow, 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 c= an try and fix the text to make this clearer.

>

> We'll definitely addres= s the scenarios you both mentioned in the next

> versions of the draft.<= o:p>

>

> Thanks,

> Lorenzo

>

>

> Il giorno Mon, 3 Feb 20= 14 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-p= erson 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 w= ould not necessarily apply for the case of a

>> MANE/SFU. For examp= le, 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 re= ports 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.<= /span>

>>> -----Original M= essage-----

>>> From: Colin Per= kins [mailto:csp@csperkins.org]

>>> Sent: 3. helmik= uuta 2014 12:32

>>> To: Christer Ho= lmberg

>>> Cc: avt@ietf.org

>>> Subject: Re: [A= VTCORE] STRAW WG document review request:

>>> draft-ietf-stra= w-b2bua-rtcp-00

>>>

>>> Christer,<= /o:p>

>>>

>>> From a quick gl= ance, this draft looks okay as far as it goes,

>>> although it see= ms to assume the B2BUA is processing a call with only

>>> two parties and= a single media flow. For example, Section 3.2 has

>>> several mention= s of "the SSRC" for packets that can contain multiple

>>> SSRCs. With RTC= WEB 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 mentio= n of the rewriting the CSRC list, which is straight

>>> forward but nec= essary if an RTP mixer is in use.

>>>

>>> The list of RTC= P packet types in Section 3.2 is incomplete. The

>>> draft should ce= rtainly discuss rewriting RTCP XR packets, and should

>>> probably consid= er the other RTCP packet types registered with IANA

>>> (even if only t= o explicitly list them as being for future

>>> specification).=

>>>

>>> There are sever= al cases where that draft says to "properly replace"

>>> a changed seque= nce number. It might be helpful to be specific what

>>> that means. If = the goal is that the B2BUA forwards all packets, but

>>> rewrites the RT= P sequence number, then the modifications are

>>> straight forwar= d. If the B2BUA discards, combines, or splits RTP

>>> packets, then t= he 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 t= han described, is important here.

>>>

>>> Some of the dis= cussion in the topologies draft is relevant, but that

>>> draft isn't cit= ed.

>>>

>>> There's no ment= ion of media path security (SRTP, etc.), keying, and

>>> how this impact= s 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 STRA= W WG we are working on the following document:

>>>> =

>>>> http://tools.ietf.org= /html/draft-ietf-straw-b2bua-rtcp-00

>>>> =

>>>> The STRAW W= G chairs think it would be very useful, and we would

>>>> deeply appr= eciate, if some people from the AVTCORE community would

>>>> have some t= ime and interest in reviewing and providing comments on

>>>> the documen= t (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

>>> ht= tp://csperkins.org/

>>>

>>>

>>>

>>> _______________= ________________________________

>>> Audio/Video Tra= nsport Core Maintenance avt@ietf.org

>>> https://www.ietf.org/= mailman/listinfo/avt

>>   &n= bsp;            = ;        

____________________________= ___________________

straw mailing list

straw@ietf.org<= /span>

https://www.ietf.org/mailman/listinfo/straw

--_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_-- From lorenzo@meetecho.com Wed Feb 12 01:12:35 2014 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442E31A08C6 for ; Wed, 12 Feb 2014 01:12:35 -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 b-kqa0QCVrAN for ; Wed, 12 Feb 2014 01:12:32 -0800 (PST) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id BFF111A08C1 for ; Wed, 12 Feb 2014 01:12:31 -0800 (PST) Received: from lminiero ([82.53.47.146]) by smtpcmd01.ad.aruba.it with bizsmtp id RMCQ1n01f39EUiy01MCRBS; Wed, 12 Feb 2014 10:12:29 +0100 Date: Wed, 12 Feb 2014 10:12:24 +0100 From: Lorenzo Miniero To: "Schwarz, Albrecht (Albrecht)" Message-ID: <20140212101224.1d889904@lminiero> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> <20140204110132.0edc1a1b@lminiero> <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> 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: Wed, 12 Feb 2014 08:03:07 -0800 Cc: Bernard Aboba , "megaco@ietf.org" , "avt@ietf.org" , "straw@ietf.org" , "Campos, Simao" , Colin Perkins Subject: Re: [Megaco] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:12:35 -0000 Il giorno Tue, 11 Feb 2014 16:20:24 +0000 "Schwarz, Albrecht (Albrecht)" 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:straw-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Dienstag, 4. Februar 2014 16:25 > To: Lorenzo Miniero > Cc: straw@ietf.org; Colin Perkins; avt@ietf.org > 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" > > > 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 > > > > 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 > > >>> > > >>> 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 > > >> > > _______________________________________________ > > straw mailing list > > straw@ietf.org > > https://www.ietf.org/mailman/listinfo/straw From simao.campos@itu.int Wed Feb 12 02:07:07 2014 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B201A090B; Wed, 12 Feb 2014 02:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 J6AAndcV_zEM; Wed, 12 Feb 2014 02:07:03 -0800 (PST) Received: from itu2out.svc.unicc.org (itu2out.svc.unicc.org [192.91.247.110]) by ietfa.amsl.com (Postfix) with ESMTP id AB8B81A0906; Wed, 12 Feb 2014 02:07:02 -0800 (PST) Received: from TUCM02.TUECSP.UNICC.ORG (unknown [10.81.6.71]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by iccpfxor02.svc.unicc.org (Postfix) with ESMTPS id DAE0E60C7C; Wed, 12 Feb 2014 10:07:00 +0000 (UTC) Received: from TUCM03.TUECSP.UNICC.ORG (10.81.38.70) by TUCM02.TUECSP.UNICC.ORG (10.81.6.71) with Microsoft SMTP Server (TLS) id 15.0.775.38; Wed, 12 Feb 2014 10:07:00 +0000 Received: from TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) by TUCM03.TUECSP.UNICC.ORG ([10.81.38.70]) with mapi id 15.00.0775.031; Wed, 12 Feb 2014 10:07:00 +0000 From: "Campos, Simao" To: "'lorenzo@meetecho.com'" , "'albrecht.schwarz@alcatel-lucent.com'" Thread-Topic: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 Thread-Index: AQHPJ0UrlbOPbn5ppEusJxSoCnPQqpqxVooAgAAPQGE= Date: Wed, 12 Feb 2014 10:06:59 +0000 Message-ID: <822350f472df49bfac3bde182429c228@TUCM03.TUECSP.UNICC.ORG> In-Reply-To: <20140212101224.1d889904@lminiero> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.102] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 12 Feb 2014 08:03:08 -0800 Cc: "'bernard_aboba@hotmail.com'" , "'csp@csperkins.org'" , "'megaco@ietf.org'" , "'straw@ietf.org'" , "'avt@ietf.org'" Subject: Re: [Megaco] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 10:07:07 -0000 For information, final publication online of H.248.88 is expected before th= e end of March 2014.=20 Simao --- Terse message composed in a mobile phone ----- Original Message ----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] Sent: Wednesday, February 12, 2014 10:12 AM=0A= To: Schwarz, Albrecht (Albrecht) Cc: Bernard Aboba ; megaco@ietf.org ; Campos, Simao; straw@ietf.org ; avt@ietf.org ; Colin Perkins Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00 Il giorno Tue, 11 Feb 2014 16:20:24 +0000 "Schwarz, Albrecht (Albrecht)" ha scritto: > Dear All, >=20 > like to provide further review comments: >=20 >=20 Thanks for your detailed comments, Albrecht! We'll definitely address them in the next version of the draft. Lorenzo >=20 > 1. Terminology: > [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC > 7092. >=20 >=20 > 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: >=20 > a. this draft > must refer to a) [RFC 5117] and > should refer to b) [draft-ietf-avtcore-rtp-topologies-update] >=20 > 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) >=20 >=20 > 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) >=20 >=20 > 4. Call type: 2-party vs multiparty > =3D> this subject would be inherently addressed as well when referring > to RTP topologies (e.g., RTCP handling by RTP topology "RTP mixer" > etc etc) >=20 >=20 > 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 (=3D> 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 >=20 > 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. >=20 >=20 > 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 =3D RTCP capabilities according "core RTP" (i.e., > RFC 3550) b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | > 4585 | 5124 | .... c) supplementary RTCP services =3D e.g., RTCP XR > (RFC 3611), RFC 5760, RFC 6051 >=20 > 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. >=20 > 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). >=20 >=20 >=20 > Regards, >=20 > Albrecht >=20 >=20 > PS >=20 > [ITU-T H.248.88] >=20 > is just PRE-PUBLISHED, but the freely available document is expected > to be published soon at the ITU-T web site. >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Dienstag, 4. Februar 2014 16:25 > To: Lorenzo Miniero > Cc: straw@ietf.org; Colin Perkins; avt@ietf.org > Subject: Re: [straw] STRAW WG document review request: > draft-ietf-straw-b2bua-rtcp-00 >=20 >=20 >=20 > I do not believe that the document even accurately describes a two > person video call intermediated by a MANE/SFU. >=20 >=20 >=20 > > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" > > > wrote: >=20 > > >=20 > > Colin, Bernard, >=20 > > >=20 > > thanks for this feedback, this is exactly what we were waiting for! >=20 > > >=20 > > I agree the draft is pretty rough and simple right now. We started >=20 > > this way to gather some feedback on whether or not we were heading > > the >=20 > > right direction in the first place, before delving in some more >=20 > > complex use cases and scenarios. >=20 > > >=20 > > Just as a clarification, it is indeed focused on the simpler >=20 > > two-person case right now, but not only audio, actually: the same >=20 > > principles described in the draft can be effectively used for a > > video >=20 > > call between two people as well (I'm using them in some >=20 > > implementations as well), or at least they should. If you feel this > > is >=20 > > unclear right now, we can try and fix the text to make this clearer. >=20 > > >=20 > > We'll definitely address the scenarios you both mentioned in the > > next >=20 > > versions of the draft. >=20 > > >=20 > > Thanks, >=20 > > Lorenzo >=20 > > >=20 > > >=20 > > Il giorno Mon, 3 Feb 2014 08:39:39 -0800 Bernard Aboba >=20 > > > ha > > scritto: >=20 > > >=20 > >> I agree with Colin that this draft appears focused on a single use >=20 > >> case: a two-person voice call. It does not appear to apply to > >> video >=20 > >> use cases, such as those involving a MANE or Selective Forwarding >=20 > >> Unit. For example, the advice in Section 3.2 on processing of >=20 > >> feedback messages would not necessarily apply for the case of a >=20 > >> MANE/SFU. For example, the MANE/SFU might consume feedback messages >=20 > >> sent from a client and not forward them on to the source, instead >=20 > >> choosing to address the feedback itself. For example, in the case >=20 > >> where the client reports loss, a MANE may respond by reducing >=20 > >> bandwidth going to the client, by for example, dropping one or more >=20 > >> extension layers in SVC, or switching to a lower resolution > >> simulcast >=20 > >> stream. >=20 > >>> -----Original Message----- >=20 > >>> From: Colin Perkins [mailto:csp@csperkins.org] >=20 > >>> Sent: 3. helmikuuta 2014 12:32 >=20 > >>> To: Christer Holmberg >=20 > >>> Cc: avt@ietf.org >=20 > >>> Subject: Re: [AVTCORE] STRAW WG document review request: >=20 > >>> draft-ietf-straw-b2bua-rtcp-00 >=20 > >>> >=20 > >>> Christer, >=20 > >>> >=20 > >>> From a quick glance, this draft looks okay as far as it goes, >=20 > >>> although it seems to assume the B2BUA is processing a call with > >>> only >=20 > >>> two parties and a single media flow. For example, Section 3.2 has >=20 > >>> several mentions of "the SSRC" for packets that can contain > >>> multiple >=20 > >>> SSRCs. With RTCWEB and CLUE both supporting multiparty calls with >=20 > >>> multiple media flows, I would suggest that this draft needs to >=20 > >>> consider those use cases more fully. >=20 > >>> >=20 > >>> I see no mention of the rewriting the CSRC list, which is straight >=20 > >>> forward but necessary if an RTP mixer is in use. >=20 > >>> >=20 > >>> The list of RTCP packet types in Section 3.2 is incomplete. The >=20 > >>> draft should certainly discuss rewriting RTCP XR packets, and > >>> should >=20 > >>> probably consider the other RTCP packet types registered with IANA >=20 > >>> (even if only to explicitly list them as being for future >=20 > >>> specification). >=20 > >>> >=20 > >>> There are several cases where that draft says to "properly > >>> replace" >=20 > >>> a changed sequence number. It might be helpful to be specific what >=20 > >>> that means. If the goal is that the B2BUA forwards all packets, > >>> but >=20 > >>> rewrites the RTP sequence number, then the modifications are >=20 > >>> straight forward. If the B2BUA discards, combines, or splits RTP >=20 > >>> packets, then the modifications needed get much more complex, and >=20 > >>> are not obvious in many cases. Defining the scope clearly, and >=20 > >>> explaining what modifications are possible and what need more >=20 > >>> complex rules than described, is important here. >=20 > >>> >=20 > >>> Some of the discussion in the topologies draft is relevant, but > >>> that >=20 > >>> draft isn't cited. >=20 > >>> >=20 > >>> There's no mention of media path security (SRTP, etc.), keying, > >>> and >=20 > >>> how this impacts B2BUAs operating on the media traffic. >=20 > >>> >=20 > >>> Regards, >=20 > >>> Colin >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> On 29 Jan 2014, at 12:27, Christer Holmberg >=20 > >>> > > >>> wrote: >=20 > >>>> Hi, >=20 > >>>> >=20 > >>>> In the STRAW WG we are working on the following document: >=20 > >>>> >=20 > >>>> http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 >=20 > >>>> >=20 > >>>> The STRAW WG chairs think it would be very useful, and we would >=20 > >>>> deeply appreciate, if some people from the AVTCORE community > >>>> would >=20 > >>>> have some time and interest in reviewing and providing comments > >>>> on >=20 > >>>> the document (on the STRAW list). Please let me know if you are >=20 > >>>> willing to do such review :) Thanks! >=20 > >>>> >=20 > >>>> Regards, >=20 > >>>> >=20 > >>>> Christer >=20 > >>>> STRAW WG co-chair >=20 > >>>> _______________________________________________ >=20 > >>>> Audio/Video Transport Core Maintenance > >>>> avt@ietf.org >=20 > >>>> https://www.ietf.org/mailman/listinfo/avt >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> -- >=20 > >>> Colin Perkins >=20 > >>> http://csperkins.org/ >=20 > >>> >=20 > >>> >=20 > >>> >=20 > >>> _______________________________________________ >=20 > >>> Audio/Video Transport Core Maintenance > >>> avt@ietf.org >=20 > >>> https://www.ietf.org/mailman/listinfo/avt >=20 > >> >=20 > _______________________________________________ >=20 > straw mailing list >=20 > straw@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Feb 25 23:04:37 2014 Return-Path: X-Original-To: megaco@ietfa.amsl.com Delivered-To: megaco@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5E21A0860 for ; Tue, 25 Feb 2014 23:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 S6bWJVZ9FoUK for ; Tue, 25 Feb 2014 23:04:26 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4251A1A085F for ; Tue, 25 Feb 2014 23:04:26 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1Q74N58000752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 01:04:24 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1Q74M8I031631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:04:22 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.116]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 08:04:22 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "megaco@ietf.org" Thread-Topic: SDP codepoints for gateway control; FW: IANA "proto" codepoints; Thread-Index: AQHPMsD56Os1z7p3a0iEMQbjafOBpQ== Date: Wed, 26 Feb 2014 07:04:22 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC1A4203@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/megaco/WKCNZVCKfjHbaUb1RCz2r0CHpQk Cc: "3GPP_TSG_CT_WG4@LIST.ETSI.ORG" <3GPP_TSG_CT_WG4@LIST.ETSI.ORG> Subject: [Megaco] SDP codepoints for gateway control; FW: IANA "proto" codepoints; X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 07:04:34 -0000 fyi, we'd like to tackle below identified issue concerning dedicated SDP co= depoints for gateway control at coming ITU-T Rapporteur Meeting of Question= s 1, 2, 3, and 5/16 (http://wftp3.itu.int/av-arch/avc-site/2013-2016/1403_G= en/1403_Gen.html ): we've reserved following contribution numbers: AVD-4569 H.Supp.IANA (New): "SDP codepoints for gateway control" - Discussi= on AVD-4570 H.Supp.IANA (New): "SDP codepoints for gateway control" - Initial = draft AVD-4571 H.248.TCP - New clause "SDP for gateway control - IANA considerati= ons" AVD-4572 H.248.TLS - New clause "SDP for gateway control - IANA considerati= ons" AVD-4573 H.248.DTLS - New clause "SDP for gateway control - IANA considerat= ions" AVD-4574 H.248.SCTP - New clause "SDP for gateway control - IANA considerat= ions" =09 -Albrecht ALCATEL-LUCENT From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Freitag, 24. Januar 2014 01:39 To: Christian Groves; Schwarz, Albrecht (Albrecht); Nevenka Biondic; 'Belli= ng, Thomas (NSN - DE/Munich)'; Kall, Jan (NSN - FI/Espoo); Yangweiwei (Tomm= y); LANDAIS, BRUNO (BRUNO); Peter Schmitt Cc: DRAGE, Keith (Keith); Arturo Martin De Nicolas Subject: Re: IANA "proto" codepoints; RE: [eMEDIASEC] P-CR C4-140311 (ex006= 5) application agnostic DTLS Hi Christian, I=92ll see what I can find out. I guess one reason could be that the draft didn't contain any justification= /requirements/use-cases. Regards, Christer Sent from Windows Mail From:=A0Christian Groves Sent:=A0=FDFriday=FD, =FDJanuary=FD =FD24=FD, =FD2014 =FD1=FD:=FD37=FD =FDA= M To:=A0Hans-Christer Holmberg, Schwarz, Albrecht (Albrecht), Nevenka Biondic= , 'Belling, Thomas (NSN - DE/Munich)', Kall, Jan (NSN - FI/Espoo), Yangweiw= ei (Tommy), ext LANDAIS, BRUNO (BRUNO), Peter Schmitt Cc:=A0DRAGE, Keith (Keith), Arturo Martin De Nicolas Hello Christer, It would be good to find out the reason from the MMUSIC chairs/ADs why=20 the draft was actually withdrawn. My guess is that because RFC5764 introduced TCP/TLS/RTP/SAVP,=20 UDP/TLS/RTP/SAVP=A0 and=A0 DCCP/TLS/RTP/SAVP=A0 there wasn't much left in=20 draft-ietf-mmusic-sdp-dtls-00.=A0 It would only have left=A0 UDP/TLS and=20 DCCP/TLS . It would be good to know why these were dropped. Regards, Christian On 23/01/2014 5:31 PM, Christer Holmberg wrote: > Hi, > > =91UDP/TLS/RTP/SAVP=92 and =91DCCP/TLS/RTP/SAVP=92 were defined in RFC 57= 64. > > I don=92t remember what happened to the draft mentioned by Christian,=20 > and why, but obviously it is not progressed. > > > yes, "UDP/TLS" would fit. > > Didn't noticed that draft. > > > > Had a quick chat with Christer this morning, he's still thinking=20 > about that topic. > > One of your suggestions below (Q1) was to do this in the udptl-dtls=20 > draft. However, as I also told Albrecht, I don=92t support that=20 > idea. For one thing, =91UDP/TLS=92 would not be fax specific. > Another idea mentioned from my side: trying to get a self-contained=20 > IETF RFC for that purpose, sth like, > > >draft-mmusic-sdp-for-gw: "SDP codepoints for gateway control" > >scope: > >1. registration of the "-" (pending since 2005) > >2. application-agnostic specifically for eMEDIASEC, but there are=20 > also other use cases (such as >in context of WebRTC) > >3. SDP for interlinkage capability (H.248.SEPLINK ->we'll provide=20 > some analysis in AVD-4482) > >4. others (pending issues from the past?) > > > >The overall justification is given by the fact that SDP itself is a=20 > self-contained protocol, >independent of other protocols such as SIP. > >Further, SDP is used in > >a) application control protocols (such as SAP, SIP) > >b) gateway control protocols (such as H.248, MGCP) > > If a draft is written, I think there should be a clear H.248 scope. > > >The very majority of SDP elements is common to both control plane=20 > protocol categories, >however, there a a few differences: > >i) SDP for bearer type indication: also application-agnostic=20 > codepoints required besides the >usual application-aware codepoints > >ii) SDP for mode of operation control: the combination of SDP across=20 > multiple H.248 >terminations (in order to indicated different MG=20 > behaviour) > > IETF may, of course, decide that a draft is not needed, that ITU-T can=20 > specify the H.248 SDP extensions themselves, and they would then be=20 > IANA registered e.g. using an expert review. > > It would probably be a good idea to talk with the MMUSIC chairs and=20 > ADs, and ask for guidance. Two of them are sitting in my office=20 > corridor, so I can have a chat with them next week. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Donnerstag, 23. Januar 2014 05:44 > To: Schwarz, Albrecht (Albrecht); Nevenka Biondic; 'Belling, Thomas=20 > (NSN - DE/Munich)'; 'Kall, Jan (NSN - FI/Espoo)'; 'tommy@huawei.com';=20 > LANDAIS, BRUNO (BRUNO); Peter Schmitt; Christer Holmberg > Cc: DRAGE, Keith (Keith); Arturo Martin De Nicolas (AC/EED) > Subject: Re: IANA "proto" codepoints; RE: [eMEDIASEC] P-CR C4-140311=20 > (ex0065) application agnostic DTLS > > Hello Albrecht, > > I'm not sure what happened to this draft: > http://tools.ietf.org/html/draft-ietf-mmusic-sdp-dtls-00 > > In it there was a request for: >=A0=A0=A0=A0 Type=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SDP Name=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Reference >=A0=A0=A0=A0 ----=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------------------=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 --------- >=A0=A0=A0=A0 proto=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TCP/TLS/RTP/SAVP [RFC-XXX= X] >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UDP/TLS/RTP/S= AVP [RFC-XXXX] >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DCCP/TLS/RTP/= SAVP [RFC-XXXX] >=A0=A0=A0=A0=A0=A0=A0=A0=A0 --->>=A0=A0=A0=A0=A0 UDP/TLS [RFC-XXXX] >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DCCP/TLS [RFC= -XXXX] > > Regards, Christian > > On 22/01/2014 6:36 PM, Schwarz, Albrecht (Albrecht) wrote: > > Hello Christer, et al., > > > > the two UDPTL kind of interworking functions by IMS-AGW (e2ea, e2e)=20 > are both application agnostic (see also C4-140203), thus,=20 > application-aware codepoint "UDP/TLS/UDPTL" doesn't really match at=20 > the H.248 interface. > > What's required is rather > > a) "UDP/TLS" or > > b) "UDP/DTLS". > > > > Option a has the issue of 'TLS', but would be consistent with=20 > initial DTLS based IANA codepoints (RFC 5764). > > Option b would be consistent with proposed "SCTP-DTLS" codepoints=20 > (SCTP/DTLS, DTLS/SCTP), but inconsistent to "UDP/TLS/UDPTL". > > > > Anyway, either a or b would be much better than "UDP/TLS/UDPTL" for=20 > above MG interworking scenarios. > > Now, there might be three options: > > an IANA registry via > > O1) IETF MMUSIC, e.g. your draft considers in addition SDP for=20 > gateway control (as in H.248, MGCP) > > O2) ITU-T Q.3/16 requests additional SDP codepoints by IANA (as=20 > e.g., done in the past by the T.38 folks for udptl) > > O3) ITU-T Q.3/16 uses non-SDP based bearer type indications > > > > I'm in favour of the first option, perhaps we may use your draft for=20 > such a second SDP codepoint, see attachment. > > > > Comments? > > Albrecht > > > > PS > > Pragmatically we could misuse "UDP/TLS/UDPTL" for eMEDIASEC, but the=20 > general concern is a future safe design, given by the lessons learnt=20 > with e.g. the TISPAN BGW IaV1 and 3GPP IMS-AGW IqV1, which both=20 > started as pure media-agnostic gateways, and noone could imagine any=20 > need for media aware support functions (remembering the pure "-"=20 > design). But both H.248 profiles developed later on to more and more=20 > application-specific support functions (IMS-AGW: + ATGW, +audio=20 > transcoding, ... +WebRTC). > > > > > > > > -----Original Message----- > > From: Schwarz, Albrecht (Albrecht) > > Sent: Mittwoch, 22. Januar 2014 08:10 > > To: 'Nevenka Biondic'; 'Belling, Thomas (NSN - DE/Munich)'; 'Kall,=20 > Jan (NSN - FI/Espoo)'; 'tommy@huawei.com'; LANDAIS, BRUNO (BRUNO);=20 > 'Peter Schmitt'; 'Christer Holmberg' > > Cc: DRAGE, Keith (Keith) > > Subject: [eMEDIASEC] P-CR C4-140311 (ex0065) application agnostic DTLS > > > > Dear All, > > attached the update proposal of this P-CR: > > 1) clarification of "application" (as discussed by 140203) > > 2) upgrade to: draft-ietf-mmusic-udptl-dtls-03 (not any impact from=20 > -02 based changes) > > 3) E.N. related to IANA registry > > > > Comments? > > Albrecht > > > > PS > > Like to circulate a separate email concerning the IANA topic. > > >