Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00
Christer Holmberg <[email protected]> Tue, 11 Feb 2014 16:26:22 +0000
| Newsgroups | gmane.ietf.avt,gmane.ietf.megaco |
|---|---|
| Message-ID | <[email protected]> |
--===============8467894880174497108== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_" --_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:[email protected]] On Behalf Of Schwarz, Albrecht = (Albrecht) Sent: Tuesday, February 11, 2014 5:20 PM To: Bernard Aboba; Lorenzo Miniero Cc: [email protected]; Campos, Simao; [email protected]; [email protected]; 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:[email protected]] On Behalf Of Bernard Aboba Sent: Dienstag, 4. Februar 2014 16:25 To: Lorenzo Miniero Cc: [email protected]<mailto:[email protected]>; Colin Perkins; [email protected]<mail= to:[email protected]> 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" <[email protected]<mailt= o:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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:[email protected]] >>> Sent: 3. helmikuuta 2014 12:32 >>> To: Christer Holmberg >>> Cc: [email protected]<mailto:[email protected]> >>> 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 >>> <[email protected]<mailto:[email protected]>>= 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 [email protected]<mailto:[email protected]= g> >>>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance [email protected]<mailto:[email protected]= > >>> https://www.ietf.org/mailman/listinfo/avt >> _______________________________________________ straw mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/straw --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {mso-style-priority:99; mso-style-link:"Plain Text Char"; margin:0in; margin-bottom:.0001pt; font-size:10.5pt; font-family:Consolas;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.PlainTextChar {mso-style-name:"Plain Text Char"; mso-style-priority:99; mso-style-link:"Plain Text"; font-family:Consolas;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:1130828063; mso-list-type:hybrid; mso-list-template-ids:768507204 134807567 134807577 134807579 134807567 13= 4807577 134807579 134807567 134807577 134807579;} @list l0:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">(As co-chair)<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Albrecht,<o:p></o:p= ></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Thanks for your review= !<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Regards,<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D">Christer<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p> </o:p></spa= n></p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> straw [m= ailto:[email protected]] <b>On Behalf Of </b>Schwarz, Albrecht (Albrecht)<br> <b>Sent:</b> Tuesday, February 11, 2014 5:20 PM<br> <b>To:</b> Bernard Aboba; Lorenzo Miniero<br> <b>Cc:</b> [email protected]; Campos, Simao; [email protected]; [email protected]; Co= lin Perkins<br> <b>Subject:</b> Re: [straw] STRAW WG document review request: draft-ietf-st= raw-b2bua-rtcp-00<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">Dear All,<o:p></o:p></span><= /p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">like to provide further revi= ew comments:<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><o:p> </o:p></span></p> <p class=3D"MsoPlainText" style=3D"mso-margin-top-alt:0in;margin-right:0in;= margin-bottom:12.0pt;margin-left:.5in;text-indent:-.25in;mso-list:l0 level1= lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">1= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">Terminology:<br> [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC 7092.<o= :p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:.5in;text-indent:-.25in;mso-= list:l0 level1 lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">2= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">Media plane B2BUA vs RT= P topologies:<br> 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.<br> And the “RTP/RTCP B2BUA” behaviour is actually the concept rela= ted to “RTP topologies” (RFC 5117).<br> Conclusions: <o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:1.0in;text-indent:-.25in;mso= -list:l0 level2 lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">a= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">this draft <br> must refer to a) [RFC 5117] and<br> should refer to b) [draft-ietf-avtcore-rtp-topologies-update]<o:p></o:p></s= pan></p> <p class=3D"MsoPlainText" style=3D"mso-margin-top-alt:0in;margin-right:0in;= margin-bottom:12.0pt;margin-left:1.0in;text-indent:-.25in;mso-list:l0 level= 2 lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">b= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">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)<o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"mso-margin-top-alt:0in;margin-right:0in;= margin-bottom:12.0pt;margin-left:.5in;text-indent:-.25in;mso-list:l0 level1= lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">3= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">Why reference to “= ;RTP topology” concept?<br> 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)<o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"mso-margin-top-alt:0in;margin-right:0in;= margin-bottom:12.0pt;margin-left:.5in;text-indent:-.25in;mso-list:l0 level1= lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">4= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">Call type: 2-party vs m= ultiparty<br> =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)<o:p></o:p></span></p> <p class=3D"MsoPlainText" style=3D"mso-margin-top-alt:0in;margin-right:0in;= margin-bottom:12.0pt;margin-left:.5in;text-indent:-.25in;mso-list:l0 level1= lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">5= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">B2BUAs in integrated an= d decomposed SBCs:<br> 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).<br> Concerning decomposed SBCs, following reference might be beneficial:<br> [ITU-T H.248.88] Gateway control protocol: RTP topology dependent RTCP hand= ling by ITU-T H.248 media gateways with IP terminations<br> <br> 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.<o:p></o:p></span></p= > <p class=3D"MsoPlainText" style=3D"margin-left:.5in;text-indent:-.25in;mso-= list:l0 level1 lfo2"> <![if !supportLists]><span lang=3D"EN-GB"><span style=3D"mso-list:Ignore">6= .<span style=3D"font:7.0pt "Times New Roman""> </span></span></span><![endif]><span lang=3D"EN-GB">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).<br> This problem could be solved by introducing a “RTCP service” co= ncept. E.g., H.248.88 uses following service model:<br> a) basic RTCP service =3D RTCP capabilities according “core RTP”= ; (i.e., RFC 3550)<br> b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= ….<br> c) supplementary RTCP services =3D e.g., RTCP XR (RFC 3611), RFC 5760, RFC = 6051<br> <br> 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.<br> Such a proceeding is drastically simplifying the complexity space … a= nd may be also motivated/justified from network operational point.<br> <br> 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></o:p></span></p> <p class=3D"MsoPlainText" style=3D"margin-left:.5in"><span lang=3D"EN-GB"><= o:p> </o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">Regards,<o:p></o:p></span></= p> <p class=3D"MsoPlainText" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-G= B">Albrecht<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">PS<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">[ITU-T H.248.88]<o:p></o:p><= /span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">is just PRE-PUBLISHED, but t= he freely available document is expected to be published soon at the ITU-T = web site.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><o:p> </o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><o:p> </o:p></span></p> <p class=3D"MsoPlainText">-----Original Message-----<br> From: straw [<a href=3D"mailto:[email protected]">mailto:straw-bounces= @ietf.org</a>] On Behalf Of Bernard Aboba<br> Sent: Dienstag, 4. Februar 2014 16:25<br> To: Lorenzo Miniero<br> Cc: <a href=3D"mailto:[email protected]">[email protected]</a>; Colin Perkins; <a= href=3D"mailto:[email protected]"> [email protected]</a><br> Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00<span lang=3D"EN-GB"><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><o:p> </o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">I do not believe that the do= cument even accurately describes a two person video call intermediated by a= MANE/SFU. <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><o:p> </o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> On Feb 4, 2014, at 2:01= AM, "Lorenzo Miniero" <<a href=3D"mailto:[email protected]= "><span style=3D"color:windowtext;text-decoration:none">[email protected]= m</span></a>> wrote:<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> Colin, Bernard,<o:p></o= :p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> thanks for this feedbac= k, this is exactly what we were waiting for!<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> I agree the draft is pr= etty rough and simple right now. We started <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> this way to gather some= feedback on whether or not we were heading the <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> right direction in the = first place, before delving in some more <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> complex use cases and s= cenarios.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> Just as a clarification= , it is indeed focused on the simpler <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> two-person case right n= ow, but not only audio, actually: the same <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> principles described in= the draft can be effectively used for a video <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> call between two people= as well (I'm using them in some <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> implementations as well= ), or at least they should. If you feel this is <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> unclear right now, we c= an try and fix the text to make this clearer.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> We'll definitely addres= s the scenarios you both mentioned in the next <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> versions of the draft.<= o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> Thanks,<o:p></o:p></spa= n></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> Lorenzo<o:p></o:p></spa= n></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> Il giorno Mon, 3 Feb 20= 14 08:39:39 -0800 Bernard Aboba <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <<a href=3D"mailto:b= [email protected]"><span style=3D"color:windowtext;text-decoration:n= one">[email protected]</span></a>> ha scritto:<o:p></o:p></span>= </p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> I agree with Colin = that this draft appears focused on a single use<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> case: a two-p= erson voice call. It does not appear to apply to video <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> use cases, such as = those involving a MANE or Selective Forwarding <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> Unit. For example, = the advice in Section 3.2 on processing of <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> feedback messages w= ould not necessarily apply for the case of a <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> MANE/SFU. For examp= le, the MANE/SFU might consume feedback messages <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> sent from a client = and not forward them on to the source, instead <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> choosing to address= the feedback itself. For example, in the case <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> where the client re= ports loss, a MANE may respond by reducing <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> bandwidth going to = the client, by for example, dropping one or more <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> extension layers in= SVC, or switching to a lower resolution simulcast <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> stream.<o:p></o:p><= /span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> -----Original M= essage-----<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> From: Colin Per= kins [<a href=3D"mailto:[email protected]"><span style=3D"color:windowtext;= text-decoration:none">mailto:[email protected]</span></a>]<o:p></o:p></span= ></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Sent: 3. helmik= uuta 2014 12:32<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> To: Christer Ho= lmberg<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Cc: <a href=3D"= mailto:[email protected]"> <span style=3D"color:windowtext;text-decoration:none">[email protected]</span></= a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Subject: Re: [A= VTCORE] STRAW WG document review request:<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> draft-ietf-stra= w-b2bua-rtcp-00<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Christer,<o:p><= /o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> From a quick gl= ance, this draft looks okay as far as it goes, <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> although it see= ms to assume the B2BUA is processing a call with only <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> two parties and= a single media flow. For example, Section 3.2 has <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> several mention= s of "the SSRC" for packets that can contain multiple <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> SSRCs. With RTC= WEB and CLUE both supporting multiparty calls with <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> multiple media = flows, I would suggest that this draft needs to <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> consider those = use cases more fully.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> I see no mentio= n of the rewriting the CSRC list, which is straight <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> forward but nec= essary if an RTP mixer is in use.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> The list of RTC= P packet types in Section 3.2 is incomplete. The <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> draft should ce= rtainly discuss rewriting RTCP XR packets, and should <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> probably consid= er the other RTCP packet types registered with IANA <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> (even if only t= o explicitly list them as being for future <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> specification).= <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> There are sever= al cases where that draft says to "properly replace"<o:p></o:p></= span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> a changed seque= nce number. It might be helpful to be specific what <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> that means. If = the goal is that the B2BUA forwards all packets, but <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> rewrites the RT= P sequence number, then the modifications are <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> straight forwar= d. If the B2BUA discards, combines, or splits RTP <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> packets, then t= he modifications needed get much more complex, and <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> are not obvious= in many cases. Defining the scope clearly, and <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> explaining what= modifications are possible and what need more <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> complex rules t= han described, is important here.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Some of the dis= cussion in the topologies draft is relevant, but that <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> draft isn't cit= ed.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> There's no ment= ion of media path security (SRTP, etc.), keying, and <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> how this impact= s B2BUAs operating on the media traffic.<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Regards,<o:p></= o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Colin<o:p></o:p= ></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> On 29 Jan 2014,= at 12:27, Christer Holmberg <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <<a href=3D"= mailto:[email protected]"><span style=3D"color:windowtext;text= -decoration:none">[email protected]</span></a>> wrote:<o:p>= </o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> Hi,<o:p></o= :p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <o:p></o:p>= </span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> In the STRA= W WG we are working on the following document:<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <o:p></o:p>= </span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <a href=3D"= http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00"> <span style=3D"color:windowtext;text-decoration:none">http://tools.ietf.org= /html/draft-ietf-straw-b2bua-rtcp-00</span></a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <o:p></o:p>= </span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> The STRAW W= G chairs think it would be very useful, and we would <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> deeply appr= eciate, if some people from the AVTCORE community would <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> have some t= ime and interest in reviewing and providing comments on <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> the documen= t (on the STRAW list). Please let me know if you are <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> willing to = do such review :) Thanks!<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <o:p></o:p>= </span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> Regards,<o:= p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <o:p></o:p>= </span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> Christer<o:= p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> STRAW WG co= -chair<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> ___________= ____________________________________<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> Audio/Video= Transport Core Maintenance <a href=3D"mailto:[email protected]"><span style=3D"color:windowtext;text-decora= tion:none">[email protected]</span></a> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>>> <a href=3D"= https://www.ietf.org/mailman/listinfo/avt"> <span style=3D"color:windowtext;text-decoration:none">https://www.ietf.org/= mailman/listinfo/avt</span></a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> --<o:p></o:p></= span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Colin Perkins<o= :p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <a href=3D"http= ://csperkins.org/"><span style=3D"color:windowtext;text-decoration:none">ht= tp://csperkins.org/</span></a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <o:p></o:p></sp= an></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> _______________= ________________________________<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> Audio/Video Tra= nsport Core Maintenance <a href=3D"mailto:[email protected]"><span style=3D"color:windowtext;text-decora= tion:none">[email protected]</span></a> <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>>> <a href=3D"http= s://www.ietf.org/mailman/listinfo/avt"> <span style=3D"color:windowtext;text-decoration:none">https://www.ietf.org/= mailman/listinfo/avt</span></a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">>> &n= bsp;  = ; <o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">____________________________= ___________________<o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB">straw mailing list<o:p></o:p= ></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><a href=3D"mailto:straw@ietf= .org"><span style=3D"color:windowtext;text-decoration:none">[email protected]<= /span></a><o:p></o:p></span></p> <p class=3D"MsoPlainText"><span lang=3D"EN-GB"><a href=3D"https://www.ietf.= org/mailman/listinfo/straw"><span style=3D"color:windowtext;text-decoration= :none">https://www.ietf.org/mailman/listinfo/straw</span></a><o:p></o:p></s= pan></p> </div> </body> </html> --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_-- --===============8467894880174497108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Audio/Video Transport Core Maintenance [email protected] https://www.ietf.org/mailman/listinfo/avt --===============8467894880174497108==--