From christer.holmberg@ericsson.com Mon Feb 3 05:52:28 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1A1A0426 for ; Mon, 3 Feb 2014 05:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 Id8FJiGlzqy4 for ; Mon, 3 Feb 2014 05:52:26 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7B53E1A043D for ; Mon, 3 Feb 2014 03:21:51 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-b8-52ef7bce9ff5 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 16.81.04853.ECB7FE25; Mon, 3 Feb 2014 12:21:51 +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; Mon, 3 Feb 2014 12:21:50 +0100 From: Christer Holmberg To: Colin Perkins Thread-Topic: [AVTCORE] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 Thread-Index: AQHPIMstksqM7qKwZ0SElbnN1Av2FpqjYo1w Date: Mon, 3 Feb 2014 11:21:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje756vdBBr+Xi1m87FnJbrH85QlG ByaPaffvs3ksWfKTKYApissmJTUnsyy1SN8ugSujd+JXloLXYhWXp1xna2DcKNTFyMEhIWAi cWSnRRcjJ5ApJnHh3nq2LkYuDiGBE4wSGyZMZoRwFjFK7P36lxGkgU3AQqL7nzZIg4iAqsSO 4//AwswCihKT2iVBwsICkRIbbq5ngiiJkthwaAI7hG0k8eZpBwuIzSKgInFn03ywOK+Ar8SX TT/B6oUEWhglunbVgdicAo4SM558ZwOxGYFu+35qDVgNs4C4xK0n85kgbhaQWLLnPDOELSrx 8vE/Voi3FCWW98tBlOtILNj9iQ3C1pZYtvA1M8RaQYmTM5+wTGAUm4Vk6iwkLbOQtMxC0rKA kWUVo2RxanFxbrqRgV5uem6JXmpRZnJxcX6eXnHqJkZgBB3c8ttoB+PJPfaHGKU5WJTEea+z 1gQJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCxYOfPX/U0fQl5k6O2PuyhupX4ms7iI/3fk DfE/emVe356sONYSYLKWOybxVETzvG2ugduFql/lnp9yb/ucz15zOsS8SnvfFWRu4pVPW760 6N2jDEbGWZc7bgl/eT3r/MmSB5t93J9yG8/3qzjHcTMtuawk7axbRcDUe4Wel2o/zs542Jju slWJpTgj0VCLuag4EQCD2HiibgIAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 13:52:28 -0000 Hi Colin, Thanks for your input! Now, if you could also post it on the STRAW list ;) Regards, Christer -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: 3. helmikuuta 2014 12:32 To: Christer Holmberg Cc: avt@ietf.org Subject: Re: [AVTCORE] STRAW WG document review request: draft-ietf-straw-b= 2bua-rtcp-00 Christer, >From a quick glance, this draft looks okay as far as it goes, although it s= eems to assume the B2BUA is processing a call with only two parties and a s= ingle media flow. For example, Section 3.2 has several mentions of "the SSR= C" for packets that can contain multiple SSRCs. With RTCWEB and CLUE both s= upporting multiparty calls with multiple media flows, I would suggest that = this draft needs to consider those use cases more fully.=20 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 shoul= d certainly discuss rewriting RTCP XR packets, and should probably consider= the other RTCP packet types registered with IANA (even if only to explicit= ly list them as being for future specification). There are several cases where that draft says to "properly replace" a chang= ed 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 seque= nce number, then the modifications are straight forward. If the B2BUA disca= rds, combines, or splits RTP packets, then the modifications needed get muc= h more complex, and are not obvious in many cases. Defining the scope clear= ly, and explaining what modifications are possible and what need more compl= ex rules than described, is important here. Some of the discussion in the topologies draft is relevant, but that draft = isn't cited.=20 There's no mention of media path security (SRTP, etc.), keying, and how thi= s impacts B2BUAs operating on the media traffic.=20 Regards, Colin On 29 Jan 2014, at 12:27, Christer Holmberg wrote: > Hi, > =20 > In the STRAW WG we are working on the following document: > =20 > http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 > =20 > The STRAW WG chairs think it would be very useful, and we would deeply ap= preciate, if some people from the AVTCORE community would have some time an= d interest in reviewing and providing comments on the document (on the STRA= W list). > =20 > Please let me know if you are willing to do such review :) > =20 > Thanks! > =20 > Regards, > =20 > Christer > STRAW WG co-chair > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Feb 3 06:00:57 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936CB1A0236 for ; Mon, 3 Feb 2014 06:00:57 -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] 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 WOL9cGXNOavI for ; Mon, 3 Feb 2014 06:00:55 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B461A0277 for ; Mon, 3 Feb 2014 02:32:02 -0800 (PST) Received: from [130.209.247.112] (port=55389 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WAGoq-0003uD-DB; Mon, 03 Feb 2014 10:32:01 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> Date: Mon, 3 Feb 2014 10:32:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "avt@ietf.org" Subject: Re: [AVTCORE] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:00:57 -0000 Christer, =46rom 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 =93the SSRC=94 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.=20 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 =93properly replace=94 = 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=92t cited.=20 There=92s no mention of media path security (SRTP, etc.), keying, and = how this impacts B2BUAs operating on the media traffic.=20 Regards, Colin On 29 Jan 2014, at 12:27, Christer Holmberg = wrote: > Hi, > =20 > In the STRAW WG we are working on the following document: > =20 > http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 > =20 > 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). > =20 > Please let me know if you are willing to do such review :) > =20 > Thanks! > =20 > Regards, > =20 > Christer > STRAW WG co-chair > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From bernard_aboba@hotmail.com Mon Feb 3 08:39:42 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B981A0121; Mon, 3 Feb 2014 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 h_7nmOddkc0h; Mon, 3 Feb 2014 08:39:40 -0800 (PST) Received: from blu0-omc2-s23.blu0.hotmail.com (blu0-omc2-s23.blu0.hotmail.com [65.55.111.98]) by ietfa.amsl.com (Postfix) with ESMTP id 298391A010D; Mon, 3 Feb 2014 08:39:40 -0800 (PST) Received: from BLU181-W54 ([65.55.111.72]) by blu0-omc2-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Feb 2014 08:39:39 -0800 X-TMN: [qoPQuG8U/si7esy+KnN6ZUNZTKKz0qKMy6JVIn8ij3A=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_af3b65e6-552a-40ad-ae14-e08bdbb31d64_" From: Bernard Aboba To: Colin Perkins Date: Mon, 3 Feb 2014 08:39:39 -0800 Importance: Normal In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se>, , <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2014 16:39:39.0748 (UTC) FILETIME=[884BBA40:01CF20FE] Cc: "avt@ietf.org" , "straw@ietf.org" Subject: Re: [AVTCORE] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 16:39:43 -0000 --_af3b65e6-552a-40ad-ae14-e08bdbb31d64_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Colin that this draft appears focused on a single use case: a= two-person voice call.=20 It does not appear to apply to video use cases=2C such as those involving a= MANE or Selective Forwarding Unit.=20 For example=2C the advice in Section 3.2 on processing of feedback messages= would not necessarily apply for the case of a MANE/SFU.=20 For example=2C the MANE/SFU might consume feedback messages sent from a cli= ent and not forward them on to the source=2C instead choosing to address th= e feedback itself. For example=2C in the case where the client reports los= s=2C a MANE may respond by reducing bandwidth going to the client=2C by for= example=2C dropping one or more extension layers in SVC=2C or switching to= a lower resolution simulcast stream. =20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > 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 >=20 > Christer=2C >=20 > From a quick glance=2C this draft looks okay as far as it goes=2C althoug= h it seems to assume the B2BUA is processing a call with only two parties a= nd a single media flow. For example=2C Section 3.2 has several mentions of = "the SSRC" for packets that can contain multiple SSRCs. With RTCWEB and CLU= E both supporting multiparty calls with multiple media flows=2C I would sug= gest that this draft needs to consider those use cases more fully.=20 >=20 > I see no mention of the rewriting the CSRC list=2C which is straight forw= ard but necessary if an RTP mixer is in use. >=20 > The list of RTCP packet types in Section 3.2 is incomplete. The draft sho= uld certainly discuss rewriting RTCP XR packets=2C and should probably cons= ider the other RTCP packet types registered with IANA (even if only to expl= icitly list them as being for future specification). >=20 > There are several cases where that draft says to "properly replace" a cha= nged sequence number. It might be helpful to be specific what that means. I= f the goal is that the B2BUA forwards all packets=2C but rewrites the RTP s= equence number=2C then the modifications are straight forward. If the B2BUA= discards=2C combines=2C or splits RTP packets=2C then the modifications ne= eded get much more complex=2C and are not obvious in many cases. Defining t= he scope clearly=2C and explaining what modifications are possible and what= need more complex rules than described=2C is important here. >=20 > Some of the discussion in the topologies draft is relevant=2C but that dr= aft isn't cited.=20 >=20 > There's no mention of media path security (SRTP=2C etc.)=2C keying=2C and= how this impacts B2BUAs operating on the media traffic.=20 >=20 > Regards=2C > Colin >=20 >=20 >=20 > On 29 Jan 2014=2C at 12:27=2C Christer Holmberg wrote: > > Hi=2C > > =20 > > In the STRAW WG we are working on the following document: > > =20 > > http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 > > =20 > > The STRAW WG chairs think it would be very useful=2C and we would deepl= y appreciate=2C if some people from the AVTCORE community would have some t= ime and interest in reviewing and providing comments on the document (on th= e STRAW list). > > =20 > > Please let me know if you are willing to do such review :) > > =20 > > Thanks! > > =20 > > Regards=2C > > =20 > > Christer > > STRAW WG co-chair > > _______________________________________________ > > Audio/Video Transport Core Maintenance avt@ietf.org=20 > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt = --_af3b65e6-552a-40ad-ae14-e08bdbb31d64_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Colin that thi= s draft appears focused on a single use case:  =3Ba two-person voice ca= ll. =3B

It does not appear to apply to video u= se cases=2C such as those involving a  =3BMANE or Selective Forwarding = Unit. =3B

For example=2C the advice in Section= 3.2 on processing of feedback messages would not necessarily apply for the= case of a MANE/SFU. =3B

For example=2C the MA= NE/SFU might consume feedback messages sent from a client and not forward t= hem on to the source=2C instead choosing to address the feedback itself. &n= bsp=3BFor example=2C in the case where the client reports loss=2C a MANE ma= y respond by reducing bandwidth going to the client=2C by for example=2C dr= opping one or more extension layers in SVC=2C or switching to a lower resol= ution simulcast stream.  =3B

>=3B -----Original Message= -----
>=3B From: Colin Perkins [mailto:csp@csperkins.org]
>=3B S= ent: 3. helmikuuta 2014 12:32
>=3B To: Christer Holmberg
>=3B Cc:= avt@ietf.org
>=3B Subject: Re: [AVTCORE] STRAW WG document review req= uest: draft-ietf-straw-b2bua-rtcp-00
>=3B
>=3B Christer=2C
&g= t=3B
>=3B From a quick glance=2C this draft looks okay as far as it g= oes=2C although it seems to assume the B2BUA is processing a call with only= two parties and a single media flow. For example=2C Section 3.2 has severa= l mentions of "the SSRC" for packets that can contain multiple SSRCs. With = RTCWEB and CLUE both supporting multiparty calls with multiple media flows= =2C I would suggest that this draft needs to consider those use cases more = fully.
>=3B
>=3B I see no mention of the rewriting the CSRC lis= t=2C which is straight forward but necessary if an RTP mixer is in use.
= >=3B
>=3B The list of RTCP packet types in Section 3.2 is incomplet= e. The draft should certainly discuss rewriting RTCP XR packets=2C and shou= ld probably consider the other RTCP packet types registered with IANA (even= if only to explicitly list them as being for future specification).
>= =3B
>=3B There are several cases where that draft says to "properly r= eplace" a changed sequence number. It might be helpful to be specific what = that means. If the goal is that the B2BUA forwards all packets=2C but rewri= tes the RTP sequence number=2C then the modifications are straight forward.= If the B2BUA discards=2C combines=2C or splits RTP packets=2C then the mod= ifications needed get much more complex=2C and are not obvious in many case= s. Defining the scope clearly=2C and explaining what modifications are poss= ible and what need more complex rules than described=2C is important here.<= br>>=3B
>=3B Some of the discussion in the topologies draft is rele= vant=2C but that draft isn't cited.
>=3B
>=3B There's no mentio= n of media path security (SRTP=2C etc.)=2C keying=2C and how this impacts B= 2BUAs operating on the media traffic.
>=3B
>=3B Regards=2C
&= gt=3B Colin
>=3B
>=3B
>=3B
>=3B On 29 Jan 2014=2C at= 12:27=2C Christer Holmberg <=3Bchrister.holmberg@ericsson.com>=3B wrot= e:
>=3B >=3B Hi=2C
>=3B >=3B
>=3B >=3B In the STRAW = WG we are working on the following document:
>=3B >=3B
>=3B &= gt=3B http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00
>=3B &= gt=3B
>=3B >=3B The STRAW WG chairs think it would be very useful= =2C and we would deeply appreciate=2C if some people from the AVTCORE commu= nity would have some time and interest in reviewing and providing comments = on the document (on the STRAW list).
>=3B >=3B
>=3B >=3B Pl= ease let me know if you are willing to do such review :)
>=3B >=3B =
>=3B >=3B Thanks!
>=3B >=3B
>=3B >=3B Regards=2C>=3B >=3B
>=3B >=3B Christer
>=3B >=3B STRAW WG co-cha= ir
>=3B >=3B _______________________________________________
>= =3B >=3B Audio/Video Transport Core Maintenance avt@ietf.org
>=3B &= gt=3B https://www.ietf.org/mailman/listinfo/avt
>=3B
>=3B
&g= t=3B
>=3B --
>=3B Colin Perkins
>=3B http://csperkins.org/=
>=3B
>=3B
>=3B
>=3B _______________________________= ________________
>=3B Audio/Video Transport Core Maintenance
>=3B= avt@ietf.org
>=3B https://www.ietf.org/mailman/listinfo/avt
=
= --_af3b65e6-552a-40ad-ae14-e08bdbb31d64_-- From bernard_aboba@hotmail.com Tue Feb 4 07:24:59 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36A1A012A; Tue, 4 Feb 2014 07:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, 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 sKRip4xRvuPk; Tue, 4 Feb 2014 07:24:56 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id B1E561A010A; Tue, 4 Feb 2014 07:24:56 -0800 (PST) Received: from BLU406-EAS208 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Feb 2014 07:24:56 -0800 X-TMN: [16LgQEOxaYQRoLWqnKNfl1Mv+R08N5pU] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> <20140204110132.0edc1a1b@lminiero> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <20140204110132.0edc1a1b@lminiero> Date: Tue, 4 Feb 2014 07:24:52 -0800 To: Lorenzo Miniero X-OriginalArrivalTime: 04 Feb 2014 15:24:56.0409 (UTC) FILETIME=[426E3C90:01CF21BD] Cc: "straw@ietf.org" , Colin Perkins , "avt@ietf.org" Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 15:24:59 -0000 I do not believe that the document even accurately describes a two person vi= deo call intermediated by a MANE/SFU.=20 > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" wrote= : >=20 > Colin, Bernard, >=20 > thanks for this feedback, this is exactly what we were waiting for! >=20 > 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. >=20 > 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. >=20 > We'll definitely address the scenarios you both mentioned in the next > versions of the draft. >=20 > Thanks, > Lorenzo >=20 >=20 > Il giorno Mon, 3 Feb 2014 08:39:39 -0800 > Bernard Aboba ha scritto: >=20 >> 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. =20 >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org]=20 >>> 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 >>>=20 >>> Christer, >>>=20 >>> =46rom 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.=20 >>>=20 >>> I see no mention of the rewriting the CSRC list, which is straight >>> forward but necessary if an RTP mixer is in use. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> Some of the discussion in the topologies draft is relevant, but >>> that draft isn't cited.=20 >>>=20 >>> There's no mention of media path security (SRTP, etc.), keying, and >>> how this impacts B2BUAs operating on the media traffic.=20 >>>=20 >>> Regards, >>> Colin >>>=20 >>>=20 >>>=20 >>> On 29 Jan 2014, at 12:27, Christer Holmberg >>> wrote: >>>> Hi, >>>>=20 >>>> In the STRAW WG we are working on the following document: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 >>>>=20 >>>> 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! >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>> STRAW WG co-chair >>>> _______________________________________________ >>>> Audio/Video Transport Core Maintenance avt@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/avt >>>=20 >>>=20 >>>=20 >>> --=20 >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> =20 From lorenzo@meetecho.com Tue Feb 4 02:01:39 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB66A1A03D4 for ; Tue, 4 Feb 2014 02:01:38 -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 sgR9WBpNpwCQ for ; Tue, 4 Feb 2014 02:01:36 -0800 (PST) Received: from smtpdg1.aruba.it (smtpdg221.aruba.it [62.149.158.221]) by ietfa.amsl.com (Postfix) with ESMTP id 1617D1A03B8 for ; Tue, 4 Feb 2014 02:01:35 -0800 (PST) Received: from lminiero ([143.225.229.166]) by smtpcmd01.ad.aruba.it with bizsmtp id NA1Y1n01F3c3Lvj01A1Ytj; Tue, 04 Feb 2014 11:01:33 +0100 Date: Tue, 4 Feb 2014 11:01:32 +0100 From: Lorenzo Miniero To: Bernard Aboba Message-ID: <20140204110132.0edc1a1b@lminiero> In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D14960D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D15563F@ESESSMB209.ericsson.se> 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: Tue, 04 Feb 2014 15:39:00 -0800 Cc: "straw@ietf.org" , Colin Perkins , "avt@ietf.org" Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 10:01:39 -0000 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 > From ron.even.tlv@gmail.com Fri Feb 7 14:08:47 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715B81AD623 for ; Fri, 7 Feb 2014 14:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 C70XDR5B3hni for ; Fri, 7 Feb 2014 14:08:44 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4B41ACC8B for ; Fri, 7 Feb 2014 14:08:44 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id q10so1543531ead.24 for ; Fri, 07 Feb 2014 14:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=7OLiD3vOa710kUIjerS4KpBFLbE/VioLr2kEv65I5MQ=; b=Dc1isvdnUk/hqbD0VNz+86i0t8WaNbspDMNSYYq45ycBabl+1Vc7GjJ4EExb54RTRa /BXPHF4krpGzK2p6XNSyy8ZF+wHjS5zGFdqO797fOTC+hn+0oBAC1b62KiODE9uvc4yZ qSyCdux0ihUj1qd8oCAJxbx8nqmrLxfYddby4XVnWlgamuBYZrz+MXnvDKBwaA4ZF8RI fDrHvwvHs/egtc+Z1U76Gcm0TfobpdGN4+sq+4SZumdF5zMLSYxqStRCniUBixplFRg+ mpDqqya5Xma/Q7RaB4x0lxhKBPVTKznOvs1YGv6C37dXRzgcOl2309SrrU6IP5g/xnU+ puQg== X-Received: by 10.14.9.134 with SMTP id 6mr6909932eet.70.1391810888975; Fri, 07 Feb 2014 14:08:08 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id x6sm21486001eew.20.2014.02.07.14.08.06 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Feb 2014 14:08:08 -0800 (PST) From: "Roni Even" To: Date: Sat, 8 Feb 2014 00:08:03 +0200 Message-ID: <06dd01cf2451$1417aac0$3c470040$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06DE_01CF2461.D7A16520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kURIE/81AOWUkQn21vVmOv+DXjQ== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] Agenda time requests for AVTCore - IETF89 London X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:08:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06DE_01CF2461.D7A16520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. avtcore Session Monday , afternoon session I 15:20 - 17:20 Room Name: Buckingham Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool . * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_06DE_01CF2461.D7A16520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time.

 

    avtcore Session Monday  , = afternoon session I 15:20 – 17:20

    Room Name: Buckingham

 

       =

Some important = dates:

 

  • 2014-02-07 = (Friday): Final = agenda to be published.
  • 2014-02-14 = (Friday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 23:59, = upload using IETF ID Submission = Tool.
  • 2014-02-17 = (Monday): Draft = Working Group agendas due by UTC 23:59, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore chair

 

------=_NextPart_000_06DE_01CF2461.D7A16520-- From ron.even.tlv@gmail.com Fri Feb 7 14:18:38 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB81ACC8B; Fri, 7 Feb 2014 14:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 V5TgSQKsOO7k; Fri, 7 Feb 2014 14:18:36 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id D02AB1A0449; Fri, 7 Feb 2014 14:18:35 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id h14so1797303eaj.21 for ; Fri, 07 Feb 2014 14:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=UDSPHstb/HIR5WafqKWw3gjvxq+pbY2/rNzzVQgOmNY=; b=hdMzj+UhW/fwPOEy3SDTzgsDI92jL3koi/03eJRAl7I6lem7Glp2jDjfpjXFyqnkDo 9Nh1MHec+BTFad0z0qAgZR6j+h0CZtE4CJWK5TP3UAkQNjWFcIzFL1wc5xh558Ys40Wg LnJ9WrcLXEBP2iY/Ng9w98XlaiaxVayhsWUoaqk3Z62iDNRFCF2xvKYC2cR2597zoCUG sAoUSk5+Un2KjR/9drqwKdbwTUqM3uk5DBpSv4dlKuQp5qWk/9JERJyZI4lj1R+k7Wnc uEMcn8SirZF2p7VmlQ1q2SArA0m4A6zOHw4mTo2fMGkPU0Dea7n3johc4/AXIl2oMC/C V+cg== X-Received: by 10.14.127.72 with SMTP id c48mr19206358eei.16.1391811515219; Fri, 07 Feb 2014 14:18:35 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id o43sm21450686eef.12.2014.02.07.14.18.31 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Feb 2014 14:18:34 -0800 (PST) From: "Roni Even" To: , , Date: Sat, 8 Feb 2014 00:18:24 +0200 Message-ID: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E3_01CF2463.4CF91BF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kUaZJHKi9Q4W3TB67kd3MihP7sA== Content-Language: en-us Cc: avt@ietf.org, draft-nandakumar-payload-sdp-max-video-resolution@tools.ietf.org Subject: [AVTCORE] Request for agenda time for payload - IETF89 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:18:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06E3_01CF2463.4CF91BF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the IETF89 agenda: Please send the WG chairs requests for agenda time. payload Session Tuesday , afternoon session III 16:30 - 17:30 Room Name: Park Suite We intend to discuss the VP8 and H.265 open issues based on the mailing list discussion and would like to get feedback from the editors if they intend to present. Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool . * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_06E3_01CF2463.4CF91BF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = IETF89 agenda:

 

Please send = the WG chairs requests for agenda time.

 

    payload Session Tuesday  , = afternoon session III 16:30 – 17:30

    Room Name: Park = Suite

 

    

We intend to discuss the VP8 and H.265 open issues = based on the mailing list discussion and would like to get feedback from = the editors if they intend to present.

  

Some important dates:

 

  • 2014-02-07 = (Friday): Final = agenda to be published.
  • 2014-02-14 = (Friday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 23:59, = upload using IETF ID Submission = Tool.
  • 2014-02-17 = (Monday): Draft = Working Group agendas due by UTC 23:59, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore chair

 

 

------=_NextPart_000_06E3_01CF2463.4CF91BF0-- From ron.even.tlv@gmail.com Fri Feb 7 14:20:53 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081BA1AD628 for ; Fri, 7 Feb 2014 14:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 tu5ng3xpY9Go for ; Fri, 7 Feb 2014 14:20:51 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC441A021E for ; Fri, 7 Feb 2014 14:20:50 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id z10so1823715ead.6 for ; Fri, 07 Feb 2014 14:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=LFBKVIEzJPYH8FY0wnSyabchYeEucqw7lMAigdhiH0c=; b=ADSSil0ZOlBFzVPjzV5olBM+zqzhV4Ygg0mP2Bt6YOLAnBODrXJ4MfmX6+elchNzxl GTpWrRhyLmtBUv62RBfmhsbi1GYhXnLpipAc80P+/ZvcfXid4kkiqbku7iJdwT3YGpF3 YlAux7bp3wMwzwu9mFNo81OPULd7vDmOkmkxPdfThR332aVcbFGhXsnih1gtnco/ziEC Vr86w8R8vpL9W661iodxYdBLOp2CNA0OtjBYJ7Ml87pzwkThBllimavtfIh0TKyFCr5K pQPkFaHtqt3ztr4CZ6QoXc3YUc8B5Uaf1UApaSITaSfbyGTE7RcSo0vAsPK5c2A9OnD+ sxVQ== X-Received: by 10.14.221.201 with SMTP id r49mr914039eep.116.1391811649847; Fri, 07 Feb 2014 14:20:49 -0800 (PST) Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id k6sm21524052eep.17.2014.02.07.14.20.47 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Feb 2014 14:20:49 -0800 (PST) From: "Roni Even" To: Date: Sat, 8 Feb 2014 00:20:44 +0200 Message-ID: <06e701cf2452$d9e1dd10$8da59730$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06E8_01CF2463.9D6B9770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8kURIE/81AOWUkQn21vVmOv+DXjQ== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] Agenda time requests for AVTCore - IETF89 London X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:20:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06E8_01CF2463.9D6B9770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. avtcore Session Monday , afternoon session I 13:00 - 15:00 Room Name: Buckingham Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool . * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_06E8_01CF2463.9D6B9770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time.

 

    avtcore Session Monday  , = afternoon session I 13:00 – 15:00

    Room Name: Buckingham

 

       =

Some important = dates:

 

  • 2014-02-07 = (Friday): Final = agenda to be published.
  • 2014-02-14 = (Friday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 23:59, = upload using IETF ID Submission = Tool.
  • 2014-02-17 = (Monday): Draft = Working Group agendas due by UTC 23:59, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore chair

 

------=_NextPart_000_06E8_01CF2463.9D6B9770-- From albrecht.schwarz@alcatel-lucent.com Tue Feb 11 08:20:46 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@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: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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: avt@ietfa.amsl.com Delivered-To: avt@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 Cc: Colin Perkins , "megaco@ietf.org" , "Campos, Simao" , "avt@ietf.org" , "straw@ietf.org" Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 snandaku@cisco.com Mon Feb 10 09:59:54 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D9A1A0402; Mon, 10 Feb 2014 09:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 VYm2rn2uI3cU; Mon, 10 Feb 2014 09:59:52 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A3D111A0386; Mon, 10 Feb 2014 09:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7616; q=dns/txt; s=iport; t=1392055192; x=1393264792; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZQpzpSw1SDKPJwIIem30llvKbs0P5Yiy7uRKFPl0wR0=; b=ZOa2Jxm8JvM1rY8vIpXSXYIftUBSxLNpDkqS4SyBI6Om2bQLytmDkXdO 2TblptxQ8Z/riOlTGmUHkhIgP3bvxgRqPwJ0CLa7apsQZ4MeiqAzR01bT FYP5LAtPOMwsY/u+fIR5tIqciDgLh6B06eUUTqrih7lCIOpNr+UqAX31F k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHES+VKtJV2d/2dsb2JhbABZgkpEOFW9SYEUFgF0g30BAQEEbgsQAgEIDgMEAQELJCERHQgBAQQBDQUIh2gDEQ26KQ2HYhMEjH+BYi0EB4MjgRMEliuORYU6gyuCKg X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208,217";a="300060193" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 10 Feb 2014 17:59:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AHxqbX019671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 17:59:52 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.234]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 11:59:52 -0600 From: "Suhas Nandakumar (snandaku)" To: Roni Even , "payload@ietf.org" Thread-Topic: Request for agenda time for payload - IETF89 Thread-Index: Ac8kUaZJHKi9Q4W3TB67kd3MihP7sACOA1cw Date: Mon, 10 Feb 2014 17:59:52 +0000 Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D07AC66@xmb-aln-x12.cisco.com> References: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> In-Reply-To: <06e201cf2452$896f6190$9c4e24b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.99] Content-Type: multipart/alternative; boundary="_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 11 Feb 2014 12:24:35 -0800 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Request for agenda time for payload - IETF89 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:59:54 -0000 --_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Roni I would like to request a 25 mins slot to discuss draft-nandakumar-payl= oad-sdp-max-video-resolution. Please let me know your thoughts Cheers Suhas ________________________________ From: Roni Even [ron.even.tlv@gmail.com] Sent: Friday, February 07, 2014 2:18 PM To: payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.org; draft-ietf-pay= load-rtp-h265@tools.ietf.org Cc: Ali C. Begen (abegen); avt@ietf.org; draft-nandakumar-payload-sdp-max-v= ideo-resolution@tools.ietf.org Subject: Request for agenda time for payload - IETF89 Hi, This is the IETF89 agenda: Please send the WG chairs requests for agenda time. payload Session Tuesday , afternoon session III 16:30 =96 17:30 Room Name: Park Suite We intend to discuss the VP8 and H.265 open issues based on the mailing lis= t discussion and would like to get feedback from the editors if they intend= to present. Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59, upload using IETF ID Submission Tool. * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, up= load using IETF Meeting Materials Management Tool. Roni Even AVTcore chair --_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Roni

    I would like to request a 25 mins slot to discuss <= span style=3D"font-size: small;">draft-nandakumar-payload-sdp-max-video-res= olution.
 
   Please let me know your= thoughts
   
Cheers
Suhas
From: Roni Even [ron.even.tlv@gmail.com]<= br> Sent: Friday, February 07, 2014 2:18 PM
To: payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.org; draft-i= etf-payload-rtp-h265@tools.ietf.org
Cc: Ali C. Begen (abegen); avt@ietf.org; draft-nandakumar-payload-sd= p-max-video-resolution@tools.ietf.org
Subject: Request for agenda time for payload - IETF89

Hi,

This is the IETF89 agenda:

 

Please send the WG chairs requests for agenda time. =

 

    payload Session Tuesday  = , afternoon session III 16:30 =96 17:30

    Room Name: Park Suite

 

    

We intend to discuss the VP8 and H.265 open issue= s based on the mailing list discussion and would like to get feedback from = the editors if they intend to present.

  

Some important dates:

 

  • 2014-02-07 (Friday): Final agenda to be published.
  • 2014-02-14 (Friday):<= /strong> Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upl= oad using IETF ID Submission Tool= .
  • 2014-02-17 (Monday): = Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Managemen= t Tool.

 

Roni Even

AVTcore chair

 

 

--_000_37D91FC30D69DE43B61E5EEADD959F180D07AC66xmbalnx12ciscoc_-- From ron.even.tlv@gmail.com Tue Feb 11 23:44:32 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AE51A087C for ; Tue, 11 Feb 2014 23:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zc_nXemtK-UM for ; Tue, 11 Feb 2014 23:44:30 -0800 (PST) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9721A0874 for ; Tue, 11 Feb 2014 23:44:30 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id z10so878972ead.5 for ; Tue, 11 Feb 2014 23:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=Gxc7VgHrElGGXnHIJFCsnjjXvO8DEa2ZB7C9fCEjoxc=; b=lHIVrH0ge6/pDqffe3enKZtMBXTh/oT7zmOPTf/RhkKbXDJ4QPhUTtry+HOL75Pe6R q7AA+QBRKNGJTQVb0z25Omsx0lw96gfpEY8hMU6jOX9gaKhafzz444AM0JbSzzSpFmRJ Y2GTj52861r96UDzJYcEWbvFWC9ggxZ3qztGp6J9CeeG1KjDwKYhEQYj8/qh0rJPpn7S I2oCLxe49hBmmbI7TQVR2sSCD4/Cxoh8M/rgirHXv7UAJ2EK5681BBX+9JdYdIdKG8BQ AaScHNf5hgA2Ps1P/IeslL8dS9yM2wVE3dH8/btkwbqe/6PTN00AER82If0jZUf786jK Kc5A== X-Received: by 10.14.174.193 with SMTP id x41mr1152003eel.87.1392191068870; Tue, 11 Feb 2014 23:44:28 -0800 (PST) Received: from RoniE (bzq-79-181-189-161.red.bezeqint.net. [79.181.189.161]) by mx.google.com with ESMTPSA id k41sm78434177een.19.2014.02.11.23.44.26 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Feb 2014 23:44:27 -0800 (PST) From: "Roni Even" To: Date: Wed, 12 Feb 2014 09:44:17 +0200 Message-ID: <09e301cf27c6$3e7a3d00$bb6eb700$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09E4_01CF27D7.0203F760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8nxjhsv7iJ/L/uT5e+zVgEmQbdSw== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] Agenda time requests for AVTCore - IETF89 London - reminder X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 07:44:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_09E4_01CF27D7.0203F760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. avtcore Session Monday , afternoon session I 13:00 - 15:00 Room Name: Buckingham Some important dates: * 2014-02-07 (Friday): Final agenda to be published. * 2014-02-14 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool . * 2014-02-17 (Monday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_09E4_01CF27D7.0203F760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time.

 

    avtcore Session Monday  , = afternoon session I 13:00 – 15:00

    Room Name: Buckingham

 

       =

Some important = dates:

 

  • 2014-02-07 = (Friday): Final = agenda to be published.
  • 2014-02-14 = (Friday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 23:59, = upload using IETF ID Submission = Tool.
  • 2014-02-17 = (Monday): Draft = Working Group agendas due by UTC 23:59, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore chair

 

------=_NextPart_000_09E4_01CF27D7.0203F760-- From simao.campos@itu.int Wed Feb 12 02:07:07 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@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 Cc: "'csp@csperkins.org'" , "'megaco@ietf.org'" , "'straw@ietf.org'" , "'avt@ietf.org'" Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance 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 lorenzo@meetecho.com Wed Feb 12 01:12:38 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD241A08CF for ; Wed, 12 Feb 2014 01:12:38 -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 imf8yCo-HVZN for ; Wed, 12 Feb 2014 01:12:35 -0800 (PST) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id C01AA1A08C2 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:04:12 -0800 Cc: "megaco@ietf.org" , "avt@ietf.org" , "straw@ietf.org" , "Campos, Simao" , Colin Perkins Subject: Re: [AVTCORE] [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:12:38 -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 nobody Fri Feb 14 11:18:03 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133BA1A034A; Fri, 14 Feb 2014 11:17:53 -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] 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 rCXJQnc4VGmZ; Fri, 14 Feb 2014 11:17:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B23D51A0068; Fri, 14 Feb 2014 11:17:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214191750.6512.22636.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:17:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/bcxR-dCXJb_cRaZ6Ttiqv0AgGDE Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:17:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Authors : Colin Perkins Varun Singh Filename : draft-ietf-avtcore-rtp-circuit-breakers-05.txt Pages : 19 Date : 2014-02-14 Abstract: The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP "circuit-breakers". Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 14:41:41 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DC51A02D0; Fri, 14 Feb 2014 14:41: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] 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 9c1HdnXptShs; Fri, 14 Feb 2014 14:41:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C811A1A00BB; Fri, 14 Feb 2014 14:41:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214224131.19332.86930.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:41:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/Lr0lfia0sUH17QI65BTFEELDEZM Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:41:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback Authors : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-optimisation-02.txt Pages : 15 Date : 2014-02-14 Abstract: RTP allows multiple media streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-multi-stream-optimisation-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 14:51:17 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0221A029A; Fri, 14 Feb 2014 14:51:09 -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] 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 4UV9yoUAp5ig; Fri, 14 Feb 2014 14:51:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B011A01C4; Fri, 14 Feb 2014 14:51:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214225105.12651.48135.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:51:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/PHvAtttaFWvQ4g7Hy1hA6nU5kOI Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:51:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session Authors : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-03.txt Pages : 22 Date : 2014-02-14 Abstract: This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are using multiple synchronization sources (SSRCs), e.g. for sending multiple media streams, in a single RTP session. In particular, issues involving RTCP Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. It also updates RFC 4585 to clarify the calculation of the timeout of SSRCs and the inclusion of feeback messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-multi-stream-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 14:55:42 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6812D1A0381; Fri, 14 Feb 2014 14:55:32 -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] 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 2LtlFGO8TOS1; Fri, 14 Feb 2014 14:55:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE20C1A02D0; Fri, 14 Feb 2014 14:55:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214225525.13873.49406.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 14:55:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/GF5orAW6-Wc4ErNlz7cHQrhZonE Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:55:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Sending Multiple Types of Media in a Single RTP Session Authors : Magnus Westerlund Colin Perkins Jonathan Lennox Filename : draft-ietf-avtcore-multi-media-rtp-session-05.txt Pages : 17 Date : 2014-02-14 Abstract: This document specifies how an RTP session can contain media streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-media-rtp-session-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 15:24:59 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F275A1A0414; Fri, 14 Feb 2014 15:24:55 -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] 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 roDupnzh8y29; Fri, 14 Feb 2014 15:24:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A51A0491; Fri, 14 Feb 2014 15:24:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214232454.14682.79656.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:24:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avt/jumvIu6sYER6XJvBswDbKawS_X4 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:24:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Encrypted Key Transport for Secure RTP Authors : David A. McGrew Dan Wing Filename : draft-ietf-avtcore-srtp-ekt-02.txt Pages : 44 Date : 2014-02-14 Abstract: Encrypted Key Transport (EKT) is an extension to Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, Rollover Counters, and other information. This facility enables SRTP to work for decentralized conferences with minimal control. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP, and MIKEY. With EKT, these other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the SRTP keys within the session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-ekt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 16:30:20 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026911A00A5 for ; Fri, 14 Feb 2014 16:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 ueYjKKxXluXM for ; Fri, 14 Feb 2014 16:30:16 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5991A00DE for ; Fri, 14 Feb 2014 16:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6858; q=dns/txt; s=iport; t=1392424215; x=1393633815; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=VbfMkAjHdxLZhuM/LOikWbRoPrOr0VHOKBsvLFNHSAA=; b=R1GbfunNHwOjT3JcVP+Ox4OR9UkqnZS8qtVM3BPhuKpQt9mOrMf4dNz7 Gpdcaty5a0IEBoC4W43wTcqHIRg2cLcgQDwAQquMdGCnjUC3fOzdLegFG LydWaW/W+ly+nbXyTVwu2JmuQWPXo2mFh1l/DyWLYXhOhDzsGE06jUC7p U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAOuz/lKrRDoI/2dsb2JhbABZgwY4wAmBFxZ0giUBAQEDOzoFBYE5HBKHYgcOyGoXjigBAU+CNnWBFASJSIp7g2mBMpBxg04bgSwHAhc X-IronPort-AV: E=Sophos;i="4.95,848,1384300800"; d="scan'208";a="103210099" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Feb 2014 00:30:14 +0000 Received: from sjc-vpn7-1605.cisco.com (sjc-vpn7-1605.cisco.com [10.21.150.69]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1F0U2lq026271; Sat, 15 Feb 2014 00:30:11 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Feb 2014 16:30:02 -0800 Message-Id: To: "avt@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/avt/BapjJkWbaRJpAEQC4GLxh4Ph7Us Cc: "" Subject: [AVTCORE] EKT update, draft-ietf-avtcore-srtp-ekt-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:30:19 -0000 We just posted draft-ietf-avtcore-srtp-ekt-02, = http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02. It contains a brief summary of changes, = http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-02#section-1.1, In draft-ietf-avtcore-srtp-ekt-02 (this document), SRTP master keys have to be always generated randomly and never shared, MKI is no longer allowed with EKT (as MKI duplicates some of EKT's functions), and text clarifies that EKT must be negotiated during call setup. Some text was consolidated and re-written, notably Section 2.6 ("Timing and Reliability"). Additionally, -02 removed the ability to re-direct DTLS-SRTP handshake = to another host ("Scaling to Large Groups" which introduced the SDP = attribute dtls-srtp-host). This was removed because the only interested = person never responded to my emails, and because proper support really = needs ICE- or ICE-like handling for NAT traversal. If interest grows, = this can be done in a separate draft, and may have value even without = EKT. As you may recall, there were a bunch of great comments from Magnus, = Michael, and John. Almost all of those were integrated into -02, with = the exception of those I was hoping to get feedback from the working = group, which I had discussed in [1], "changes planned for EKT" where I = summarized some planned changes. In that post, I had written: > 1. Only use EKT over SRTP, and remove the ability to send EKT over = SRTCP. As you may recall, EKT originally worked only over SRTCP, then = added support for both SRTP and SRTCP. Our desire to abandon SRTCP is = because of several deficiencies with carrying EKT over SRTCP compared to = carrying EKT over SRTP, specifically: > - SRTCP compound packet problem described in Magnus' review (his point = "G2"). See URL to his review below. > - lack of fate sharing between SRTCP (signaling the new SRTP master = key) and SRTP (using the new SRTP master key). > - RTCP rate limits for AVP and AVPF profiles, which prevent sending = EKT in SRTCP as aggressively as one might like when rekeying or when = joining a session as a new sender. > - unsure how we might handle ISN (initial sequence number) for the key = protecting SRTCP (immediately or later), because RTCP does not have a = sequence number. > - implementations would have to support EKT over RTP and RTCP. Due to unidirectional audio (recvonly, sendonly), limiting EKT to only = RTP means we need to send an RTP packet. While my confidence was high = that we would never need or want to change the SRTCP key when using EKT = (and hence not need to ever send an RTP packet with EKT), I admit this = does not seem to be consensus. =20 The authors were unable to resolve the SRTCP compound packet issue = noticed by Magnus. Details of the issue are in Magnus' review, see URL = below. I believe the best we can do is document this problem in the = specification, and provide an additional encouragement to use = EKT-over-SRTP. Comments or feedback or better ideas? I have some = candidate text pointing out the problem and providing further = encouragement to use EKT-over-SRTP (rather than EKT-over-SRTCP), but I = am not yet happy with the text (see [2], below). The other points in the bulleted list (fate sharing, RTCP rate limits, = ISN) were added to draft-ietf-avtcore-srtp-ekt-02. > 2. require SRTP master keys to always be randomly generated and never = shared between sessions, ever. New text in draft-ietf-avtcore-srtp-ekt-02, All SRTP master keys MUST NOT be re-used, MUST be randomly generated according to [RFC4086], [and] MUST NOT be equal to or derived from = other SRTP master keys. > 3. Remove MKI support from EKT, as they are duplicative functions. As = a reminder, MKI (master key index) is defined in SRTP (RFC3711) and = allows to pre-stage a key using call setup key signaling (e.g., Security = Descriptions, MIKEY, DTLS-SRTP, etc.), whereas EKT has its own mechanism = to perform a similar function (ISN, initial sequence number, which is = when a pre-staged key will be used). Currently the EKT draft has a weak = discussion of how these interact, and instead of improving this text and = imposing the implementation burden for MKI support on EKT endpoints, we = would like to declare MKI with EKT as unsupported and out of scope. =20 MKI is now prohibited with EKT in draft-ietf-avtcore-srtp-ekt-02. > 4. Require EKT to be negotiated during call setup, and require = endpoints to wait until receiving the EKT Full Field packet (containing = the decryption key) before attempting to authenticate packets (to avoid = doubling authentication effort). This avoids new joiners attempting to = authenticate two packets when they join an EKT session (the first = attempt using the SRTP master key from normal key-management (MIKEY, = SDESC, DTLS-SRTP, whatever) and if that fails the second attempt from = the EKT-provided SRTP master key). EKT is now required to be negotiated during call set-up in = draft-ietf-avtcore-srtp-ekt-02. >=20 > Review URLs: > Magnus Westerlund review, = http://www.ietf.org/mail-archive/web/avt/current/msg16109.html > Michael Peck review, = http://www.ietf.org/mail-archive/web/avt/current/msg16107.html > John Mattsson review, = http://www.ietf.org/mail-archive/web/avt/current/msg16095.html >=20 >=20 [1] http://www.ietf.org/mail-archive/web/avt/current/msg16129.html [2] candidate text providing further incentive for EKT-over-SRTCP: 2.5. Transport EKT SHOULD be used over SRTP, and MAY be used over SRTCP. SRTP is preferred because it shares fate with transmitted media, because SRTP rekeying can occur without concern for RTCP transmission limits, and | because of SRTCP compound packets with RTP translators and mixers. | This specification requires the EKT SSRC match the SSRC in the RTCP | header, but Section 6.1 of [RFC3550] encourages creating SRTCP | compound packets: | | It is RECOMMENDED that translators and mixers combine individual | RTCP packets from the multiple sources they are forwarding into | one compound packet whenever feasible in order to amortize the | packet overhead (see Section 7). | | These compound SRTCP packets might have an SSRC that does not match | the EKT SSRC. There is no good solution to handling these SRTCP | compound packets, except hoping the mixer or translator round robin | between the SSRCs, but this would require several SRTCP packets, | further delaying receipt of EKT over RTCP. This impact of RTP | translators and mixers, and the inability to realibly determine an | RTP translator or mixer might be involved in an RTP session, provides | further incentive to send EKT over RTP. -d From nobody Sun Feb 16 14:47:06 2014 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE801A027B; Sat, 15 Feb 2014 10:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-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 e0BWHI_tXtGW; Sat, 15 Feb 2014 10:37:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5F1A026E; Sat, 15 Feb 2014 10:37:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 517027FC2C9; Sat, 15 Feb 2014 10:37:57 -0800 (PST) To: coien@cisco.com, mbaugher@cisco.com, elisabetta.carrara@ericsson.com, mcgrew@cisco.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com From: RFC Errata System Message-Id: <20140215183757.517027FC2C9@rfc-editor.org> Date: Sat, 15 Feb 2014 10:37:57 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/avt/yBSFvn38qSBb69--aXKOd5nhR1U X-Mailman-Approved-At: Sun, 16 Feb 2014 14:47:04 -0800 Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, avt@ietf.org Subject: [AVTCORE] [Errata Held for Document Update] RFC3711 (3712) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 18:38:01 -0000 The following errata report has been held for document update for RFC3711, "The Secure Real-time Transport Protocol (SRTP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=3712 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Christian S Oien Date Reported: 2013-08-27 Held by: Richard Barnes (IESG) Section: 4.3.2 Original Text ------------- Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use