From victor.pascual.avila@gmail.com Sat Feb 1 09:42:15 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D91A1A043C for ; Sat, 1 Feb 2014 09:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 hEXX_7yK8wVD for ; Sat, 1 Feb 2014 09:42:14 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 11DA91A0395 for ; Sat, 1 Feb 2014 09:42:14 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so5614139pbc.28 for ; Sat, 01 Feb 2014 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jli2Bzc+8+uua7ePjVViFYQ2rGJQjvz2b46Ve1iPE9I=; b=fEwtDauzG1fOaNDdpe/oOhyHkR8XNA6gwUuzRMD3AOmYrdorwxEvkLQdfSF9kEqSEX XyvJ22DuMU7GAPpjJSesyuDYv8j5NxTudxeJl1EXBOp6aee08Ia9l36CV9Z9H8vb8BSx /EbxV91TuccvsLQ4zI9owTXIVM56JJruqSAuwYKIbjC9TKg3EANJD/Rb2YWpI7EU6TuI uQ9I6xTe9OAfNG/Ohe8FNBtSjlF/dvnEbElHZ0bbuiHTqY93p+vRl0DT3ufESemyLluZ bwvjvhdTRSaU+MM9QNDyl47XVQd0FpM0+kpIwRzbJM4CD0VQMour1/b8+V4Rl3AFM97R 5M9A== MIME-Version: 1.0 X-Received: by 10.66.192.162 with SMTP id hh2mr2000537pac.150.1391276529592; Sat, 01 Feb 2014 09:42:09 -0800 (PST) Received: by 10.68.200.97 with HTTP; Sat, 1 Feb 2014 09:42:09 -0800 (PST) Date: Sat, 1 Feb 2014 18:42:09 +0100 Message-ID: From: Victor Pascual Avila To: "straw@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [straw] Agenda requests - London X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 17:42:15 -0000 WG, If you would like to have agenda time, please send an email to the chairs (straw-chairs@tools.ietf.org). Cheers, Christer and Victor From bernard_aboba@hotmail.com Mon Feb 3 08:39:42 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@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: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" 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 lorenzo@meetecho.com Tue Feb 4 02:01:39 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114671A03B8 for ; Tue, 4 Feb 2014 02:01:39 -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 HKoN3WMmoBrE 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 1610C1A02BC 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 Cc: "straw@ietf.org" , Colin Perkins , "avt@ietf.org" Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" 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 bernard_aboba@hotmail.com Tue Feb 4 07:24:59 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@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: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" 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 internet-drafts@ietf.org Mon Feb 10 07:12:09 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27E91A0878; Mon, 10 Feb 2014 07:12: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 Rfvyz4UsaZLL; Mon, 10 Feb 2014 07:12:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 448A71A0308; Mon, 10 Feb 2014 07:12:07 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210151207.15879.2810.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 07:12:07 -0800 Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-loop-detection-04.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:12:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF. Title : Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to- Back User Agents (B2BUAs) Authors : Hadriel Kaplan Victor Pascual Filename : draft-ietf-straw-b2bua-loop-detection-04.txt Pages : 6 Date : 2014-02-10 Abstract: SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-loop-detection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-loop-detection-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-loop-detection-04 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 albrecht.schwarz@alcatel-lucent.com Tue Feb 11 08:20:46 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@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: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" 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: straw@ietfa.amsl.com Delivered-To: straw@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: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:26:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi Albrecht, Thanks for your review! Regards, Christer From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Schwarz, Albrecht = (Albrecht) Sent: Tuesday, February 11, 2014 5:20 PM To: Bernard Aboba; Lorenzo Miniero Cc: megaco@ietf.org; Campos, Simao; straw@ietf.org; avt@ietf.org; Colin Per= kins Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00 Dear All, like to provide further review comments: 1. Terminology: [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC 7092. 2. Media plane B2BUA vs RTP topologies: RFC 7092 differentiates precisely between the signalling (SIP) B2BUA and me= dia plane B2BUA part. Hence, this draft is just focusing on the media plane= B2BUA entity with scope on RTP/RTCP traffic handling only. And the "RTP/RTCP B2BUA" behaviour is actually the concept related to "RTP = topologies" (RFC 5117). Conclusions: a. this draft must refer to a) [RFC 5117] and should refer to b) [draft-ietf-avtcore-rtp-topologies-update] b. Terms "media relay", "media-aware relay" & "media-terminator" could and= should be linked (or even replaced) by concrete RTP topology types (here, = I guess: RTP transport translator, RTP media translator and RTP endsystem) 3. Why reference to "RTP topology" concept? Because "RTCP handling" is (loosely / tightly) coupled to "RTP topologies" = (see above references). Thus, the "RTCP B2BUA" behaviour is essentially det= ermined firstly by the RTP topology ... (being aware that above RTP topolog= y references could still add more detailed RTCP handling behaviour ... and = this is one purpose of avtcore-rtp-topologies-update in our understanding) 4. Call type: 2-party vs multiparty =3D> this subject would be inherently addressed as well when referring to R= TP topologies (e.g., RTCP handling by RTP topology "RTP mixer" etc etc) 5. B2BUAs in integrated and decomposed SBCs: Fig.1 isn't specific on that aspect, but looks like an integrated SBC (but = signalling isn't indicated), hence could be also just the media plane B2BUA= instance (=3D> would change the Fig. title). Concerning decomposed SBCs, following reference might be beneficial: [ITU-T H.248.88] Gateway control protocol: RTP topology dependent RTCP hand= ling by ITU-T H.248 media gateways with IP terminations Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P handling in case of decomposed SBCs following the H.248 gateway model. H.= 248.88 is tightly coupled to the RTP topology concept. 6. Principal challenge for "RTCP B2BUA" behaviour: guess you got already t= he feeling that it is fairly difficult to define unambiguous RTCP handling = for the entire plethora of "media plane B2BUA" types (RTP topologies). This problem could be solved by introducing a "RTCP service" concept. E.g.,= H.248.88 uses following service model: a) basic RTCP service =3D RTCP capabilities according "core RTP" (i.e., RFC= 3550) b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= .... c) supplementary RTCP services =3D e.g., RTCP XR (RFC 3611), RFC 5760, RFC = 6051 Now, H.248.88 makes the assumption that RTCP service categories (a & b) are= tightly coupled to the RTP topology, but category (c) could be independent= of the applied RTP topology. Such a proceeding is drastically simplifying the complexity space ... and m= ay be also motivated/justified from network operational point. Example: a performance monitoring service (RTCP XR based) as an network ove= rlay on top of the variety of RTP node types (RTP transport translator, RTP= mixer, etc). Regards, Albrecht PS [ITU-T H.248.88] is just PRE-PUBLISHED, but the freely available document is expected to be = published soon at the ITU-T web site. -----Original Message----- From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Dienstag, 4. Februar 2014 16:25 To: Lorenzo Miniero Cc: straw@ietf.org; Colin Perkins; avt@ietf.org Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2b= ua-rtcp-00 I do not believe that the document even accurately describes a two person v= ideo call intermediated by a MANE/SFU. > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" > wrote: > > Colin, Bernard, > > thanks for this feedback, this is exactly what we were waiting for! > > I agree the draft is pretty rough and simple right now. We started > this way to gather some feedback on whether or not we were heading the > right direction in the first place, before delving in some more > complex use cases and scenarios. > > Just as a clarification, it is indeed focused on the simpler > two-person case right now, but not only audio, actually: the same > principles described in the draft can be effectively used for a video > call between two people as well (I'm using them in some > implementations as well), or at least they should. If you feel this is > unclear right now, we can try and fix the text to make this clearer. > > We'll definitely address the scenarios you both mentioned in the next > versions of the draft. > > Thanks, > Lorenzo > > > Il giorno Mon, 3 Feb 2014 08:39:39 -0800 Bernard Aboba > > ha scritto: > >> I agree with Colin that this draft appears focused on a single use >> case: a two-person voice call. It does not appear to apply to video >> use cases, such as those involving a MANE or Selective Forwarding >> Unit. For example, the advice in Section 3.2 on processing of >> feedback messages would not necessarily apply for the case of a >> MANE/SFU. For example, the MANE/SFU might consume feedback messages >> sent from a client and not forward them on to the source, instead >> choosing to address the feedback itself. For example, in the case >> where the client reports loss, a MANE may respond by reducing >> bandwidth going to the client, by for example, dropping one or more >> extension layers in SVC, or switching to a lower resolution simulcast >> stream. >>> -----Original Message----- >>> From: Colin Perkins [mailto:csp@csperkins.org] >>> Sent: 3. helmikuuta 2014 12:32 >>> To: Christer Holmberg >>> Cc: avt@ietf.org >>> Subject: Re: [AVTCORE] STRAW WG document review request: >>> draft-ietf-straw-b2bua-rtcp-00 >>> >>> Christer, >>> >>> From a quick glance, this draft looks okay as far as it goes, >>> although it seems to assume the B2BUA is processing a call with only >>> two parties and a single media flow. For example, Section 3.2 has >>> several mentions of "the SSRC" for packets that can contain multiple >>> SSRCs. With RTCWEB and CLUE both supporting multiparty calls with >>> multiple media flows, I would suggest that this draft needs to >>> consider those use cases more fully. >>> >>> I see no mention of the rewriting the CSRC list, which is straight >>> forward but necessary if an RTP mixer is in use. >>> >>> The list of RTCP packet types in Section 3.2 is incomplete. The >>> draft should certainly discuss rewriting RTCP XR packets, and should >>> probably consider the other RTCP packet types registered with IANA >>> (even if only to explicitly list them as being for future >>> specification). >>> >>> There are several cases where that draft says to "properly replace" >>> a changed sequence number. It might be helpful to be specific what >>> that means. If the goal is that the B2BUA forwards all packets, but >>> rewrites the RTP sequence number, then the modifications are >>> straight forward. If the B2BUA discards, combines, or splits RTP >>> packets, then the modifications needed get much more complex, and >>> are not obvious in many cases. Defining the scope clearly, and >>> explaining what modifications are possible and what need more >>> complex rules than described, is important here. >>> >>> Some of the discussion in the topologies draft is relevant, but that >>> draft isn't cited. >>> >>> There's no mention of media path security (SRTP, etc.), keying, and >>> how this impacts B2BUAs operating on the media traffic. >>> >>> Regards, >>> Colin >>> >>> >>> >>> On 29 Jan 2014, at 12:27, Christer Holmberg >>> >= wrote: >>>> Hi, >>>> >>>> In the STRAW WG we are working on the following document: >>>> >>>> http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 >>>> >>>> The STRAW WG chairs think it would be very useful, and we would >>>> deeply appreciate, if some people from the AVTCORE community would >>>> have some time and interest in reviewing and providing comments on >>>> the document (on the STRAW list). Please let me know if you are >>>> willing to do such review :) Thanks! >>>> >>>> Regards, >>>> >>>> Christer >>>> STRAW WG co-chair >>>> _______________________________________________ >>>> Audio/Video Transport Core Maintenance avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw --_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi Albrecht,

 

Thanks for your review= !

 

Regards,

 

Christer

 

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

 

Dear All,<= /p>

like to provide further revi= ew comments:

 

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

2= .  Media plane B2BUA vs RT= P topologies:
RFC 7092 differentiates precisely between the signalling (SIP) B2BUA and me= dia plane B2BUA part. Hence, this draft is just focusing on the media plane= B2BUA entity with scope on RTP/RTCP traffic handling only.
And the “RTP/RTCP B2BUA” behaviour is actually the concept rela= ted to “RTP topologies” (RFC 5117).
Conclusions:

a= .  this draft
must refer to a) [RFC 5117] and
should refer to b) [draft-ietf-avtcore-rtp-topologies-update]

b= .  Terms “media rela= y”, “media-aware relay” & “media-terminatorR= 21; could and should be linked (or even replaced) by concrete RTP topology = types (here, I guess: RTP transport translator, RTP media translator and RT= P endsystem)

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

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

5= .  B2BUAs in integrated an= d decomposed SBCs:
Fig.1 isn’t specific on that aspect, but looks like an integrated SBC= (but signalling isn’t indicated), hence could be also just the media= plane B2BUA instance (=3D> would change the Fig. title).
Concerning decomposed SBCs, following reference might be beneficial:
[ITU-T H.248.88] Gateway control protocol: RTP topology dependent RTCP hand= ling by ITU-T H.248 media gateways with IP terminations

Background: H.248.88 defines the media plane B2BUA behaviour concerning RTC= P handling in case of decomposed SBCs following the H.248 gateway model. H.= 248.88 is tightly coupled to the RTP topology concept.

6= .  Principal challenge for= “RTCP B2BUA” behaviour: guess you got already the feeling that= it is fairly difficult to define unambiguous RTCP handling for the entire = plethora of “media plane B2BUA” types (RTP topologies).
This problem could be solved by introducing a “RTCP service” co= ncept. E.g., H.248.88 uses following service model:
a) basic RTCP service =3D RTCP capabilities according “core RTP”= ; (i.e., RFC 3550)
b) RTP profile dependent RTCP services =3D RFCs 3551 | 3711 | 4585 | 5124 |= ….
c) supplementary RTCP services =3D e.g., RTCP XR (RFC 3611), RFC 5760, RFC = 6051

Now, H.248.88 makes the assumption that RTCP service categories (a & b)= are tightly coupled to the RTP topology, but category (c) could be indepen= dent of the applied RTP topology.
Such a proceeding is drastically simplifying the complexity space … a= nd may be also motivated/justified from network operational point.

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

<= o:p> 

Regards,

Albrecht

PS

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

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

 

 

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

 

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

 

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

>

> Colin, Bernard,

>

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

>

> I agree the draft is pr= etty rough and simple right now. We started

> this way to gather some= feedback on whether or not we were heading the

> right direction in the = first place, before delving in some more

> complex use cases and s= cenarios.

>

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

> two-person case right n= ow, but not only audio, actually: the same

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

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

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

> unclear right now, we c= an try and fix the text to make this clearer.

>

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

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

>

> Thanks,

> Lorenzo

>

>

> Il giorno Mon, 3 Feb 20= 14 08:39:39 -0800 Bernard Aboba

> <bernard_aboba@hotmail.com> ha scritto:=

>

>> I agree with Colin = that this draft appears focused on a single use

>> case:  a two-p= erson voice call. It does not appear to apply to video

>> use cases, such as = those involving a  MANE or Selective Forwarding

>> Unit. For example, = the advice in Section 3.2 on processing of

>> feedback messages w= ould not necessarily apply for the case of a

>> MANE/SFU. For examp= le, the MANE/SFU might consume feedback messages

>> sent from a client = and not forward them on to the source, instead

>> choosing to address= the feedback itself.  For example, in the case

>> where the client re= ports loss, a MANE may respond by reducing

>> bandwidth going to = the client, by for example, dropping one or more

>> extension layers in= SVC, or switching to a lower resolution simulcast

>> stream.<= /span>

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

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

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

>>> To: Christer Ho= lmberg

>>> Cc: avt@ietf.org

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

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

>>>

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

>>>

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

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

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

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

>>> SSRCs. With RTC= WEB and CLUE both supporting multiparty calls with

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

>>> consider those = use cases more fully.

>>>

>>> I see no mentio= n of the rewriting the CSRC list, which is straight

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

>>>

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

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

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

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

>>> specification).=

>>>

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

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

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

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

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

>>> packets, then t= he modifications needed get much more complex, and

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

>>> explaining what= modifications are possible and what need more

>>> complex rules t= han described, is important here.

>>>

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

>>> draft isn't cit= ed.

>>>

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

>>> how this impact= s B2BUAs operating on the media traffic.

>>>

>>> Regards,

>>> Colin

>>>

>>>

>>>

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

>>> <christer.holmberg@ericsson.com> wrote:=

>>>> Hi,

>>>> =

>>>> In the STRA= W WG we are working on the following document:

>>>> =

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

>>>> =

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

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

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

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

>>>> willing to = do such review :) Thanks!

>>>> =

>>>> Regards,

>>>> =

>>>> Christer

>>>> STRAW WG co= -chair

>>>> ___________= ____________________________________

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

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

>>>

>>>

>>>

>>> --

>>> Colin Perkins

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

>>>

>>>

>>>

>>> _______________= ________________________________

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

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

>>   &n= bsp;            = ;        

____________________________= ___________________

straw mailing list

straw@ietf.org<= /span>

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

--_000_7594FB04B1934943A5C02806D1A2204B1D16B527ESESSMB209erics_-- From lorenzo@meetecho.com Wed Feb 12 01:12:35 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89E1A08C1 for ; Wed, 12 Feb 2014 01:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKLAf65DeEbx for ; Wed, 12 Feb 2014 01:12:32 -0800 (PST) Received: from smtpdg2.aruba.it (smtpdg220.aruba.it [62.149.158.220]) by ietfa.amsl.com (Postfix) with ESMTP id C845A1A08C8 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 Cc: Bernard Aboba , "megaco@ietf.org" , "avt@ietf.org" , "straw@ietf.org" , "Campos, Simao" , Colin Perkins Subject: Re: [straw] STRAW WG document review request: draft-ietf-straw-b2bua-rtcp-00 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:12:35 -0000 Il giorno Tue, 11 Feb 2014 16:20:24 +0000 "Schwarz, Albrecht (Albrecht)" ha scritto: > Dear All, > > like to provide further review comments: > > Thanks for your detailed comments, Albrecht! We'll definitely address them in the next version of the draft. Lorenzo > > 1. Terminology: > [I-D.ietf-straw-b2bua-taxonomy] could and should be replaced by RFC > 7092. > > > 2. Media plane B2BUA vs RTP topologies: > RFC 7092 differentiates precisely between the signalling (SIP) B2BUA > and media plane B2BUA part. Hence, this draft is just focusing on the > media plane B2BUA entity with scope on RTP/RTCP traffic handling > only. And the "RTP/RTCP B2BUA" behaviour is actually the concept > related to "RTP topologies" (RFC 5117). Conclusions: > > a. this draft > must refer to a) [RFC 5117] and > should refer to b) [draft-ietf-avtcore-rtp-topologies-update] > > b. Terms "media relay", "media-aware relay" & "media-terminator" > could and should be linked (or even replaced) by concrete RTP > topology types (here, I guess: RTP transport translator, RTP media > translator and RTP endsystem) > > > 3. Why reference to "RTP topology" concept? > Because "RTCP handling" is (loosely / tightly) coupled to "RTP > topologies" (see above references). Thus, the "RTCP B2BUA" behaviour > is essentially determined firstly by the RTP topology ... (being > aware that above RTP topology references could still add more > detailed RTCP handling behaviour ... and this is one purpose of > avtcore-rtp-topologies-update in our understanding) > > > 4. Call type: 2-party vs multiparty > => this subject would be inherently addressed as well when referring > to RTP topologies (e.g., RTCP handling by RTP topology "RTP mixer" > etc etc) > > > 5. B2BUAs in integrated and decomposed SBCs: > Fig.1 isn't specific on that aspect, but looks like an integrated SBC > (but signalling isn't indicated), hence could be also just the media > plane B2BUA instance (=> would change the Fig. title). Concerning > decomposed SBCs, following reference might be beneficial: [ITU-T > H.248.88] Gateway control protocol: RTP topology dependent RTCP > handling by ITU-T H.248 media gateways with IP terminations > > Background: H.248.88 defines the media plane B2BUA behaviour > concerning RTCP handling in case of decomposed SBCs following the > H.248 gateway model. H.248.88 is tightly coupled to the RTP topology > concept. > > > 6. Principal challenge for "RTCP B2BUA" behaviour: guess you got > already the feeling that it is fairly difficult to define unambiguous > RTCP handling for the entire plethora of "media plane B2BUA" types > (RTP topologies). This problem could be solved by introducing a "RTCP > service" concept. E.g., H.248.88 uses following service model: a) > basic RTCP service = RTCP capabilities according "core RTP" (i.e., > RFC 3550) b) RTP profile dependent RTCP services = RFCs 3551 | 3711 | > 4585 | 5124 | .... c) supplementary RTCP services = e.g., RTCP XR > (RFC 3611), RFC 5760, RFC 6051 > > Now, H.248.88 makes the assumption that RTCP service categories (a & > b) are tightly coupled to the RTP topology, but category (c) could be > independent of the applied RTP topology. Such a proceeding is > drastically simplifying the complexity space ... and may be also > motivated/justified from network operational point. > > Example: a performance monitoring service (RTCP XR based) as an > network overlay on top of the variety of RTP node types (RTP > transport translator, RTP mixer, etc). > > > > Regards, > > Albrecht > > > PS > > [ITU-T H.248.88] > > is just PRE-PUBLISHED, but the freely available document is expected > to be published soon at the ITU-T web site. > > > > > > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Bernard Aboba > Sent: Dienstag, 4. Februar 2014 16:25 > To: Lorenzo Miniero > Cc: straw@ietf.org; Colin Perkins; avt@ietf.org > Subject: Re: [straw] STRAW WG document review request: > draft-ietf-straw-b2bua-rtcp-00 > > > > I do not believe that the document even accurately describes a two > person video call intermediated by a MANE/SFU. > > > > > On Feb 4, 2014, at 2:01 AM, "Lorenzo Miniero" > > > wrote: > > > > > > Colin, Bernard, > > > > > > thanks for this feedback, this is exactly what we were waiting for! > > > > > > I agree the draft is pretty rough and simple right now. We started > > > this way to gather some feedback on whether or not we were heading > > the > > > right direction in the first place, before delving in some more > > > complex use cases and scenarios. > > > > > > Just as a clarification, it is indeed focused on the simpler > > > two-person case right now, but not only audio, actually: the same > > > principles described in the draft can be effectively used for a > > video > > > call between two people as well (I'm using them in some > > > implementations as well), or at least they should. If you feel this > > is > > > unclear right now, we can try and fix the text to make this clearer. > > > > > > We'll definitely address the scenarios you both mentioned in the > > next > > > versions of the draft. > > > > > > Thanks, > > > Lorenzo > > > > > > > > > Il giorno Mon, 3 Feb 2014 08:39:39 -0800 Bernard Aboba > > > > ha > > scritto: > > > > > >> I agree with Colin that this draft appears focused on a single use > > >> case: a two-person voice call. It does not appear to apply to > >> video > > >> use cases, such as those involving a MANE or Selective Forwarding > > >> Unit. For example, the advice in Section 3.2 on processing of > > >> feedback messages would not necessarily apply for the case of a > > >> MANE/SFU. For example, the MANE/SFU might consume feedback messages > > >> sent from a client and not forward them on to the source, instead > > >> choosing to address the feedback itself. For example, in the case > > >> where the client reports loss, a MANE may respond by reducing > > >> bandwidth going to the client, by for example, dropping one or more > > >> extension layers in SVC, or switching to a lower resolution > >> simulcast > > >> stream. > > >>> -----Original Message----- > > >>> From: Colin Perkins [mailto:csp@csperkins.org] > > >>> Sent: 3. helmikuuta 2014 12:32 > > >>> To: Christer Holmberg > > >>> Cc: avt@ietf.org > > >>> Subject: Re: [AVTCORE] STRAW WG document review request: > > >>> draft-ietf-straw-b2bua-rtcp-00 > > >>> > > >>> Christer, > > >>> > > >>> From a quick glance, this draft looks okay as far as it goes, > > >>> although it seems to assume the B2BUA is processing a call with > >>> only > > >>> two parties and a single media flow. For example, Section 3.2 has > > >>> several mentions of "the SSRC" for packets that can contain > >>> multiple > > >>> SSRCs. With RTCWEB and CLUE both supporting multiparty calls with > > >>> multiple media flows, I would suggest that this draft needs to > > >>> consider those use cases more fully. > > >>> > > >>> I see no mention of the rewriting the CSRC list, which is straight > > >>> forward but necessary if an RTP mixer is in use. > > >>> > > >>> The list of RTCP packet types in Section 3.2 is incomplete. The > > >>> draft should certainly discuss rewriting RTCP XR packets, and > >>> should > > >>> probably consider the other RTCP packet types registered with IANA > > >>> (even if only to explicitly list them as being for future > > >>> specification). > > >>> > > >>> There are several cases where that draft says to "properly > >>> replace" > > >>> a changed sequence number. It might be helpful to be specific what > > >>> that means. If the goal is that the B2BUA forwards all packets, > >>> but > > >>> rewrites the RTP sequence number, then the modifications are > > >>> straight forward. If the B2BUA discards, combines, or splits RTP > > >>> packets, then the modifications needed get much more complex, and > > >>> are not obvious in many cases. Defining the scope clearly, and > > >>> explaining what modifications are possible and what need more > > >>> complex rules than described, is important here. > > >>> > > >>> Some of the discussion in the topologies draft is relevant, but > >>> that > > >>> draft isn't cited. > > >>> > > >>> There's no mention of media path security (SRTP, etc.), keying, > >>> and > > >>> how this impacts B2BUAs operating on the media traffic. > > >>> > > >>> Regards, > > >>> Colin > > >>> > > >>> > > >>> > > >>> On 29 Jan 2014, at 12:27, Christer Holmberg > > >>> > > >>> wrote: > > >>>> Hi, > > >>>> > > >>>> In the STRAW WG we are working on the following document: > > >>>> > > >>>> http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-00 > > >>>> > > >>>> The STRAW WG chairs think it would be very useful, and we would > > >>>> deeply appreciate, if some people from the AVTCORE community > >>>> would > > >>>> have some time and interest in reviewing and providing comments > >>>> on > > >>>> the document (on the STRAW list). Please let me know if you are > > >>>> willing to do such review :) Thanks! > > >>>> > > >>>> Regards, > > >>>> > > >>>> Christer > > >>>> STRAW WG co-chair > > >>>> _______________________________________________ > > >>>> Audio/Video Transport Core Maintenance > >>>> avt@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/avt > > >>> > > >>> > > >>> > > >>> -- > > >>> Colin Perkins > > >>> http://csperkins.org/ > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Audio/Video Transport Core Maintenance > >>> avt@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/avt > > >> > > _______________________________________________ > > straw mailing list > > straw@ietf.org > > https://www.ietf.org/mailman/listinfo/straw From christer.holmberg@ericsson.com Wed Feb 12 12:44:15 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DC11A06F0 for ; Wed, 12 Feb 2014 12:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 AKqBfsnX7a3x for ; Wed, 12 Feb 2014 12:44:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 43A791A06AE for ; Wed, 12 Feb 2014 12:44:13 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-68-52fbdd1b4f6f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 70.EF.23809.B1DDBF25; Wed, 12 Feb 2014 21:44:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 21:44:11 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: Status update: draft-ietf-straw-b2bua-loop-detection-04 Thread-Index: Ac8oMy63z90p9qn3Rn+F5YP0XrDKbw== Date: Wed, 12 Feb 2014 20:44:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16F4C1@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvja703d9BBnOWG1vcan7M6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMNbpzEXHGSs+Heqj72BcSZjFyMnh4SAicSevydZIWwxiQv3 1rN1MXJxCAkcYpSYeuIrO4SzmFFi3rq/QBkODjYBC4nuf9ogDSICqhITvtwEGyQs4CCx6Nxp Joi4q8SSy5dZQMpFBPQkeuZxgIRZgMrnbb4LVs4r4Ctxe/YGNhCbEWjv91NrwFqZBcQlbj2Z zwRxj4DEkj3nmSFsUYmXj/9B3akosfNsOzNEvY7Egt2f2CBsbYllC18zQ8wXlDg58wnLBEbh WUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxttYgQG8cEtv1V3MN45J3KIUZqDRUmc98Nb5yAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjO46t8zvNXB7d5/1fqghxjKneerMYPl3az+933DE NNrs/96UFTcYjzMyfp0kaJzgY/TO7s/W7cbmsfIl5y9/j7RWvi8ZcFplzvyGRslgjcowc7+z b66rstyPOnryjfDd/G+ZGxdpZISymnx4x8RyY+nld0eevz+xe2646MkZ6wP9T6mFd2QvTlVi Kc5INNRiLipOBACWXxhwMAIAAA== Subject: [straw] Status update: draft-ietf-straw-b2bua-loop-detection-04 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:44:15 -0000 (As co-chair) Hi, I'd just like to inform the community that the proto writeup for draft-ietf= -straw-b2bua-loop-detection-04 has now been submitted to the AD. Regards, Christer= From christer.holmberg@ericsson.com Wed Feb 12 12:46:27 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06E51A06AE for ; Wed, 12 Feb 2014 12:46:27 -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 liO4ISKj1aPI for ; Wed, 12 Feb 2014 12:46:26 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F31A0450 for ; Wed, 12 Feb 2014 12:46:25 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-fa-52fbdd9fe851 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 87.17.04249.F9DDBF25; Wed, 12 Feb 2014 21:46:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 12 Feb 2014 21:46:23 +0100 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: Agenda requests for AVTEXT at IETF 89 - London Thread-Index: AQHPKBEo9vbuYpXrrki9v8ZiznlR25qyFqQl Date: Wed, 12 Feb 2014 20:46:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D16F50D@ESESSMB209.ericsson.se> References: <1111524F-EA73-4059-B3FF-F480AEE0805B@vidyo.com> In-Reply-To: <1111524F-EA73-4059-B3FF-F480AEE0805B@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje78u7+DDBpmaVvcan7M6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJsv7jEXNHNVLGg4wtzA+JC9i5GTQ0LAROL8+h2sELaYxIV7 69m6GLk4hASOMEr0rjnHDuEsZpTY82sbUBUHB5uAhUT3P22QBhEBVYkJX24ygtjCAtYSx79u ZAcpERGwkZj8MxOixEhi79sJzCA2C1D5rO1PwPbyCvhKTP5wA2yvEFD5i4/fmUBsTgFbife/ NoDVMwLd8/3UGrA4s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/qPsVJXaebWeGqNeRWLD7ExuE rS2xbOFrZoi9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRo7i1OKk3HQjg02MwLA/uOW3 xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExZouZib/v9qId DBb5spqFi77/+nHyaZdCvaxX5y3JX6a8k9VDlLh9zOwla54dtuDfmBIx5+RVcebE+GktLseC Hoazr9JeGiCzS0lg/bf6lKS1O9dukn9oG/d/Zkjb56oXcxb5PNDzt/XQFFc+1PeeXYZ3lfF0 e7Z9M1Lf7td9W+U46ZZhXpMSS3FGoqEWc1FxIgDy6WywSQIAAA== Subject: [straw] FW: Agenda requests for AVTEXT at IETF 89 - London X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 20:46:28 -0000 (As co-chair) FYI, Stay tuned for further information, if you intend to attend the STRAW sessi= on :) Regards, Christer ________________________________________ From: Jonathan Lennox [jonathan@vidyo.com] Sent: Wednesday, 12 February 2014 6:40 PM To: avtext@ietf.org Cc: straw-chairs@tools.ietf.org Subject: Agenda requests for AVTEXT at IETF 89 - London AVTEXT will be meeting on Thursday afternoon at IETF 89: 1520-1650 Afternoon Session II 1700-1830 Afternoon Session III Buckingham RAI avtext Audio/Video Transport Exten= sions WG Buckingham RAI avtext Audio/Video Transport Exten= sions WG (We don't anticipate needing the entire time.) If you have not already done so, please send the WG chairs requests for age= nda time if you have items you would like to discuss. AVTEXT is currently scheduled opposite the STRAW working group. The primar= y item on STRAW's agenda is the B2BUA-RTCP draft, which we expect to be of = interest to many participants in AVTEXT. We will be coordinating with the = STRAW chairs to make sure participants can attend both sessions, possibly (= given the large time window AVTEXT has) by running the sessions back-to-bac= k in the same room. From nobody Thu Feb 20 08:14:09 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641491A01E3 for ; Thu, 20 Feb 2014 08:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 t56106dD6hPm for ; Thu, 20 Feb 2014 08:14:04 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id F35001A01EA for ; Thu, 20 Feb 2014 08:14:03 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so2085738pbc.24 for ; Thu, 20 Feb 2014 08:14:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SzbfpsyzSdKkN1nqrqp5CVbesfVhfRi7f8GRXvg/HTk=; b=Ta0oHjouKWiiiWh6vOiMuTc1s1wBHVIvfwERXdF4P/Y7W5UnAAsLr+HGtd6KeV8883 M106phSvPi9aysWg9oJ+9sogHYi3g8TNNMD64Ui1AUM0P+ZYn7CMGHSYaOClFKjdt4HX xIDqU3A6L7z0vlZT6k9dkkE0eXyAOUOX1oiIBEAwopX6/PG/4pkjfNsPVzVlxfqXHTHk WiyHbuW91lJz5FyczaGZPZrEavw++BpyrHRjU2Z0mh+aw6gsPTldt2HWhqRacaOj6/Lb pRBueU2Ru3IWLnSXegahSgLnOS/4TThBU5IkzuAz1g5m+Oay6HFfTU8j/UazeA46Bbqx xUcA== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr2956329pbb.144.1392912476572; Thu, 20 Feb 2014 08:07:56 -0800 (PST) Received: by 10.68.184.161 with HTTP; Thu, 20 Feb 2014 08:07:56 -0800 (PST) Date: Thu, 20 Feb 2014 17:07:56 +0100 Message-ID: From: Victor Pascual Avila To: "straw@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/6Cs-F2yft5ILaK_CL85qwEXU-pk Subject: [straw] STRAW WG session in London X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:14:08 -0000 Dear WG, the primary item on the STRAW agenda for IETF 89 is draft-ietf-straw-b2bua-rtcp. Since it is of substantial interest to AVTEXT participants, in order to avoid overlaps STRAW and AVTEXT sessions will be run consecutively in the same room. https://datatracker.ietf.org/meeting/89/agenda.html THURSDAY, March 6, 2014 1520-1650 Afternoon Session II -- Buckingham RAI straw Sip Traversal Required for Applications to Work WG - (1520-1605) RAI avtext Audio/Video Transport Extensions WG - (1605-1830) 1700-1830 Afternoon Session III -- Buckingham RAI avtext Audio/Video Transport Extensions WG - (1605-1830) Thank you, -Victor From nobody Sun Feb 23 22:44:46 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAF1A0339 for ; Sun, 23 Feb 2014 22:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvxiKKKBfHIr for ; Sun, 23 Feb 2014 22:44:43 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFA81A0103 for ; Sun, 23 Feb 2014 22:44:42 -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 s1O6ifmq005594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Feb 2014 00:44:42 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1O6ie6B008360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Feb 2014 07:44:40 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 24 Feb 2014 07:44:40 +0100 From: "DRAGE, Keith (Keith)" To: "straw@ietf.org" Thread-Topic: [straw] STRAW WG session in London Thread-Index: AQHPLlcXrgl34wMkQkWh3tujd84rj5q+VT+g Date: Mon, 24 Feb 2014 06:44:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B137914@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/uXBza9JinVVl9S0jMOFXV1XNwuo Subject: Re: [straw] STRAW WG session in London X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 06:44:45 -0000 As a postscript, do not rely on a specific time for where one group finishs= and the other starts. At the moment there is time in hand, so if STRAW has some interesting and c= onstructive discussions, they may carry on a bit longer, conversely AVTEXT = will start as soon as STRAW finishes, and if that is early, then AVTEXT wil= l make use of the time. Regards Keith=20 > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of=20 > Victor Pascual Avila > Sent: 20 February 2014 16:08 > To: straw@ietf.org > Subject: [straw] STRAW WG session in London >=20 > Dear WG, >=20 > the primary item on the STRAW agenda for IETF 89 is=20 > draft-ietf-straw-b2bua-rtcp. Since it is of substantial=20 > interest to AVTEXT participants, in order to avoid overlaps=20 > STRAW and AVTEXT sessions will be run consecutively in the same room. >=20 > https://datatracker.ietf.org/meeting/89/agenda.html >=20 > THURSDAY, March 6, 2014 >=20 > 1520-1650 Afternoon Session II -- Buckingham > RAI straw Sip Traversal Required for Applications to=20 > Work WG - (1520-1605) > RAI avtext Audio/Video Transport Extensions WG - (1605-1830) >=20 > 1700-1830 Afternoon Session III -- Buckingham > RAI avtext Audio/Video Transport Extensions WG - (1605-1830) >=20 > Thank you, > -Victor >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw > =