Re: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00
"Schwarz, Albrecht (Albrecht)" <[email protected]> Tue, 11 Feb 2014 16:20:24 +0000
| Newsgroups | gmane.ietf.megaco,gmane.ietf.avt |
|---|---|
| Message-ID | <786615F3A85DF44AA2A76164A71FE1AC17EB79@FR711WXCHMBA01.zeu.alcatel-lucent.com> |
--===============3511158931399599217== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_" --_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:[email protected]] On Behalf Of Bernard Aboba Sent: Dienstag, 4. Februar 2014 16:25 To: Lorenzo Miniero Cc: [email protected]; Colin Perkins; [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_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_ 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 12 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @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:0cm; 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:0cm; 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:0cm; 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";} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} 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:-18.0pt;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --></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-GB" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoPlainText">Dear All,<o:p></o:p></p> <p class=3D"MsoPlainText">like to provide further review comments:<o:p></o:= p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">1.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>Terminology:<br> [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC 7092.<b= r> <br> <o:p></o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">2.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>Media plane B2BUA vs RTP 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></p> <p class=3D"MsoPlainText" style=3D"margin-left:72.0pt;text-indent:-18.0pt;m= so-list:l0 level2 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">a.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>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></p= > <p class=3D"MsoPlainText" style=3D"margin-left:72.0pt;text-indent:-18.0pt;m= so-list:l0 level2 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">b.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>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)<br> <br> <o:p></o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">3.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>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)<br> <br> <o:p></o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">4.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>Call type: 2-party vs multiparty<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)<br> <br> <o:p></o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">5.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>B2BUAs in integrated and 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.<br> <br> <o:p></o:p></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt;text-indent:-18.0pt;m= so-list:l0 level1 lfo1"> <![if !supportLists]><span style=3D"mso-list:Ignore">6.<span style=3D"font:= 7.0pt "Times New Roman""> </span></span><![endif]>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).<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></p> <p class=3D"MsoPlainText" style=3D"margin-left:36.0pt"><o:p> </o:p></p= > <p class=3D"MsoPlainText">Regards,<o:p></o:p></p> <p class=3D"MsoPlainText">Albrecht<br> <br> <o:p></o:p></p> <p class=3D"MsoPlainText">PS<o:p></o:p></p> <p class=3D"MsoPlainText">[ITU-T H.248.88]<o:p></o:p></p> <p class=3D"MsoPlainText">is just PRE-PUBLISHED, but the freely available d= ocument is expected to be published soon at the ITU-T web site.<o:p></o:p><= /p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText"><span lang=3D"EN-US">-----Original Message-----<b= r> From: straw [mailto:[email protected]] On Behalf Of Bernard Aboba<br> Sent: Dienstag, 4. Februar 2014 16:25<br> To: Lorenzo Miniero<br> Cc: [email protected]; Colin Perkins; [email protected]<br> Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00</span><o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">I do not believe that the document even accuratel= y describes a two person video call intermediated by a MANE/SFU. <o:p></o:p></p> <p class=3D"MsoPlainText"><o:p> </o:p></p> <p class=3D"MsoPlainText">> On Feb 4, 2014, at 2:01 AM, "Lorenzo Mi= niero" <<a href=3D"mailto:[email protected]"><span style=3D"colo= r:windowtext;text-decoration:none">[email protected]</span></a>> wrot= e:<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> Colin, Bernard,<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> thanks for this feedback, this is exactly wh= at we were waiting for!<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> I agree the draft is pretty rough and simple= right now. We started <o:p></o:p></p> <p class=3D"MsoPlainText">> this way to gather some feedback on whether = or not we were heading the <o:p></o:p></p> <p class=3D"MsoPlainText">> right direction in the first place, before d= elving in some more <o:p></o:p></p> <p class=3D"MsoPlainText">> complex use cases and scenarios.<o:p></o:p><= /p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> Just as a clarification, it is indeed focuse= d on the simpler <o:p></o:p></p> <p class=3D"MsoPlainText">> two-person case right now, but not only audi= o, actually: the same <o:p></o:p></p> <p class=3D"MsoPlainText">> principles described in the draft can be eff= ectively used for a video <o:p></o:p></p> <p class=3D"MsoPlainText">> call between two people as well (I'm using t= hem in some <o:p></o:p></p> <p class=3D"MsoPlainText">> implementations as well), or at least they s= hould. If you feel this is <o:p></o:p></p> <p class=3D"MsoPlainText">> unclear right now, we can try and fix the te= xt to make this clearer.<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> We'll definitely address the scenarios you b= oth mentioned in the next <o:p></o:p></p> <p class=3D"MsoPlainText">> versions of the draft.<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> Thanks,<o:p></o:p></p> <p class=3D"MsoPlainText">> Lorenzo<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">> Il giorno Mon, 3 Feb 2014 08:39:39 -0800 Ber= nard Aboba <o:p> </o:p></p> <p class=3D"MsoPlainText">> <<a href=3D"mailto:bernard_aboba@hotmail.= com"><span style=3D"color:windowtext;text-decoration:none">bernard_aboba@ho= tmail.com</span></a>> ha scritto:<o:p></o:p></p> <p class=3D"MsoPlainText">> <o:p></o:p></p> <p class=3D"MsoPlainText">>> I agree with Colin that this draft appea= rs focused on a single use<o:p></o:p></p> <p class=3D"MsoPlainText">>> case: a two-person voice call. It = does not appear to apply to video <o:p></o:p></p> <p class=3D"MsoPlainText">>> use cases, such as those involving a&nbs= p; MANE or Selective Forwarding <o:p></o:p></p> <p class=3D"MsoPlainText">>> Unit. For example, the advice in Section= 3.2 on processing of <o:p></o:p></p> <p class=3D"MsoPlainText">>> feedback messages would not necessarily = apply for the case of a <o:p></o:p></p> <p class=3D"MsoPlainText">>> MANE/SFU. For example, the MANE/SFU migh= t consume feedback messages <o:p></o:p></p> <p class=3D"MsoPlainText">>> sent from a client and not forward them = on to the source, instead <o:p></o:p></p> <p class=3D"MsoPlainText">>> choosing to address the feedback itself.= For example, in the case <o:p></o:p></p> <p class=3D"MsoPlainText">>> where the client reports loss, a MANE ma= y respond by reducing <o:p></o:p></p> <p class=3D"MsoPlainText">>> bandwidth going to the client, by for ex= ample, dropping one or more <o:p></o:p></p> <p class=3D"MsoPlainText">>> extension layers in SVC, or switching to= a lower resolution simulcast <o:p></o:p></p> <p class=3D"MsoPlainText">>> stream.<o:p></o:p></p> <p class=3D"MsoPlainText">>>> -----Original Message-----<o:p></o:p= ></p> <p class=3D"MsoPlainText">>>> From: Colin Perkins [<a href=3D"mail= to:[email protected]"><span style=3D"color:windowtext;text-decoration:none"= >mailto:[email protected]</span></a>]<o:p></o:p></p> <p class=3D"MsoPlainText">>>> Sent: 3. helmikuuta 2014 12:32<o:p><= /o:p></p> <p class=3D"MsoPlainText">>>> To: Christer Holmberg<o:p></o:p></p> <p class=3D"MsoPlainText">>>> Cc: <a href=3D"mailto:[email protected]">= <span style=3D"color:windowtext;text-decoration:none">[email protected]</span></= a><o:p></o:p></p> <p class=3D"MsoPlainText">>>> Subject: Re: [AVTCORE] STRAW WG docu= ment review request:<o:p></o:p></p> <p class=3D"MsoPlainText">>>> draft-ietf-straw-b2bua-rtcp-00<o:p><= /o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> Christer,<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> From a quick glance, this draft look= s okay as far as it goes, <o:p></o:p></p> <p class=3D"MsoPlainText">>>> although it seems to assume the B2BU= A is processing a call with only <o:p></o:p></p> <p class=3D"MsoPlainText">>>> two parties and a single media flow.= For example, Section 3.2 has <o:p></o:p></p> <p class=3D"MsoPlainText">>>> several mentions of "the SSRC&q= uot; for packets that can contain multiple <o:p></o:p></p> <p class=3D"MsoPlainText">>>> SSRCs. With RTCWEB and CLUE both sup= porting multiparty calls with <o:p></o:p></p> <p class=3D"MsoPlainText">>>> multiple media flows, I would sugges= t that this draft needs to <o:p></o:p></p> <p class=3D"MsoPlainText">>>> consider those use cases more fully.= <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> I see no mention of the rewriting th= e CSRC list, which is straight <o:p></o:p></p> <p class=3D"MsoPlainText">>>> forward but necessary if an RTP mixe= r is in use.<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> The list of RTCP packet types in Sec= tion 3.2 is incomplete. The <o:p></o:p></p> <p class=3D"MsoPlainText">>>> draft should certainly discuss rewri= ting RTCP XR packets, and should <o:p></o:p></p> <p class=3D"MsoPlainText">>>> probably consider the other RTCP pac= ket types registered with IANA <o:p></o:p></p> <p class=3D"MsoPlainText">>>> (even if only to explicitly list the= m as being for future <o:p></o:p></p> <p class=3D"MsoPlainText">>>> specification).<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> There are several cases where that d= raft says to "properly replace"<o:p></o:p></p> <p class=3D"MsoPlainText">>>> a changed sequence number. It might = be helpful to be specific what <o:p></o:p></p> <p class=3D"MsoPlainText">>>> that means. If the goal is that the = B2BUA forwards all packets, but <o:p></o:p></p> <p class=3D"MsoPlainText">>>> rewrites the RTP sequence number, th= en the modifications are <o:p></o:p></p> <p class=3D"MsoPlainText">>>> straight forward. If the B2BUA disca= rds, combines, or splits RTP <o:p></o:p></p> <p class=3D"MsoPlainText">>>> packets, then the modifications need= ed get much more complex, and <o:p></o:p></p> <p class=3D"MsoPlainText">>>> are not obvious in many cases. Defin= ing the scope clearly, and <o:p></o:p></p> <p class=3D"MsoPlainText">>>> explaining what modifications are po= ssible and what need more <o:p></o:p></p> <p class=3D"MsoPlainText">>>> complex rules than described, is imp= ortant here.<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> Some of the discussion in the topolo= gies draft is relevant, but that <o:p></o:p></p> <p class=3D"MsoPlainText">>>> draft isn't cited.<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> There's no mention of media path sec= urity (SRTP, etc.), keying, and <o:p></o:p></p> <p class=3D"MsoPlainText">>>> how this impacts B2BUAs operating on= the media traffic.<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> Regards,<o:p></o:p></p> <p class=3D"MsoPlainText">>>> Colin<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> On 29 Jan 2014, at 12:27, Christer H= olmberg <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <<a href=3D"mailto:christer.holmb= [email protected]"><span style=3D"color:windowtext;text-decoration:none">chr= [email protected]</span></a>> wrote:<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> Hi,<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> In the STRAW WG we are working o= n the following document:<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> <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></p> <p class=3D"MsoPlainText">>>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> The STRAW WG chairs think it wou= ld be very useful, and we would <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> deeply appreciate, if some peopl= e from the AVTCORE community would <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> have some time and interest in r= eviewing and providing comments on <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> the document (on the STRAW list)= . Please let me know if you are <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> willing to do such review :) Tha= nks!<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> Regards,<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>>> Christer<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> STRAW WG co-chair<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> ________________________________= _______________<o:p></o:p></p> <p class=3D"MsoPlainText">>>>> Audio/Video Transport Core Maint= enance <a href=3D"mailto:[email protected]"> <span style=3D"color:windowtext;text-decoration:none">[email protected]</span></= a> <o:p> </o:p></p> <p class=3D"MsoPlainText">>>>> <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></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> --<o:p></o:p></p> <p class=3D"MsoPlainText">>>> Colin Perkins<o:p></o:p></p> <p class=3D"MsoPlainText">>>> <a href=3D"http://csperkins.org/"><s= pan style=3D"color:windowtext;text-decoration:none">http://csperkins.org/</= span></a><o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> <o:p></o:p></p> <p class=3D"MsoPlainText">>>> ____________________________________= ___________<o:p></o:p></p> <p class=3D"MsoPlainText">>>> Audio/Video Transport Core Maintenan= ce <a href=3D"mailto:[email protected]"> <span style=3D"color:windowtext;text-decoration:none">[email protected]</span></= a> <o:p> </o:p></p> <p class=3D"MsoPlainText">>>> <a href=3D"https://www.ietf.org/mail= man/listinfo/avt"><span style=3D"color:windowtext;text-decoration:none">htt= ps://www.ietf.org/mailman/listinfo/avt</span></a><o:p></o:p></p> <p class=3D"MsoPlainText">>>  = ; &n= bsp; <o:p></o:p></p> <p class=3D"MsoPlainText">_______________________________________________<o= :p></o:p></p> <p class=3D"MsoPlainText">straw mailing list<o:p></o:p></p> <p class=3D"MsoPlainText"><a href=3D"mailto:[email protected]"><span style=3D"= color:windowtext;text-decoration:none">[email protected]</span></a><o:p></o:p>= </p> <p class=3D"MsoPlainText"><a href=3D"https://www.ietf.org/mailman/listinfo/= straw"><span style=3D"color:windowtext;text-decoration:none">https://www.ie= tf.org/mailman/listinfo/straw</span></a><o:p></o:p></p> </div> </body> </html> --_000_786615F3A85DF44AA2A76164A71FE1AC17EB79FR711WXCHMBA01zeu_-- --===============3511158931399599217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list [email protected] https://www.ietf.org/mailman/listinfo/megaco --===============3511158931399599217==--