From csp@csperkins.org Mon Jan 3 06:19:30 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D336E28C128 for ; Mon, 3 Jan 2011 06:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjTS5YD9Lv0K for ; Mon, 3 Jan 2011 06:19:29 -0800 (PST) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id 9FD2C28C11B for ; Mon, 3 Jan 2011 06:19:29 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PZlI0-0001vQ-nU; Mon, 03 Jan 2011 14:21:36 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> Date: Mon, 3 Jan 2011 14:21:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1082) Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 14:19:30 -0000 Ali, On 21 Dec 2010, at 07:10, Ali C. Begen (abegen) wrote: > This revision includes the changes we agreed on in the last week's = call and after the feedback on the list. It also addresses Glen's = comments, makes some clarifications here and there. This is looking good. Some minor comments only: - Section 3: =93Therefore, the server will need the client to also = include the Token along with the RTCP messages that are different from = the RTCP message that triggerred the unicast session establishment.=94 - = I don=92t understand what this means. Can you clarify in the draft? - Section 4.1: =93Here, the SSRC value is not necessarily linked to the = one used by the client in the multicast session.=94 - what do you mean = by =93not necessarily=94 here? They=92re either part of the same RTP = session, in which case the client should use the same SSRC; or they=92re = not, in which case the client should choose its SSRC randomly. - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet diagram = showing the format of such an element with enough entries to fill more = than one 32 bit block and require padding to the next. - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the server. This field = might be clearer called =93Failed PT=94? I didn't look at the SDP sections, sorry. --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Jan 3 08:22:35 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD04C3A682D for ; Mon, 3 Jan 2011 08:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT1B3ksL6B8j for ; Mon, 3 Jan 2011 08:22:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D6F203A67F8 for ; Mon, 3 Jan 2011 08:22:34 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI6GIU2rRN+J/2dsb2JhbACkNHOicZhdhUoEhGWJQg X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="395667707" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 03 Jan 2011 16:24:42 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p03GOggB020300; Mon, 3 Jan 2011 16:24:42 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 08:24:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2011 08:24:36 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 Thread-Index: AcurUY4r/Z0m0s6oQ+GJOg8eAl4RdwAD8ITA References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 03 Jan 2011 16:24:41.0895 (UTC) FILETIME=[B995FB70:01CBAB62] Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:22:35 -0000 Hi Colin, > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, January 03, 2011 9:22 AM > To: Ali C. Begen (abegen) > Cc: avt@ietf.org > Subject: Re: [AVT] FW: New Version Notification for = draft-ietf-avt-ports-for-ucast-mcast-rtp-10 >=20 > Ali, >=20 > On 21 Dec 2010, at 07:10, Ali C. Begen (abegen) wrote: > > This revision includes the changes we agreed on in the last week's = call and after the feedback on the list. It also addresses > Glen's comments, makes some clarifications here and there. >=20 >=20 > This is looking good. Some minor comments only: >=20 > - Section 3: =93Therefore, the server will need the client to also = include the Token along with the RTCP messages that are > different from the RTCP message that triggerred the unicast session = establishment.=94 - I don=92t understand what this means. > Can you clarify in the draft? Certain messages don=92t establish a unicast session but control it, and = they can be required to be bundled with a token as well as described in = 4.3.1. =20 > - Section 4.1: =93Here, the SSRC value is not necessarily linked to = the one used by the client in the multicast session.=94 - what do > you mean by =93not necessarily=94 here? They=92re either part of the = same RTP session, in which case the client should use the > same SSRC; or they=92re not, in which case the client should choose = its SSRC randomly. When requesting a Token, the SSRC used or chosen by the client does not = matter. Think about a client requesting a token during booting. It can = use that token with any ssm session later on. We could say "Here the = SSRC value can be chosen randomly by the client since the Port Mapping = Request message is not necessarily linked to a specific multicast = session." Is this better? =20 > - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet > diagram showing the format of such an element with enough entries to = fill more than one 32 bit block and require padding > to the next. OK, I will give it a shot. =20 > - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the server. > This field might be clearer called =93Failed PT=94? Sounds good. =20 > I didn't look at the SDP sections, sorry. Thanks anyway. -acbegen =20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From csp@csperkins.org Mon Jan 3 08:38:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B923A6A09 for ; Mon, 3 Jan 2011 08:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWhrLnLIG9Hk for ; Mon, 3 Jan 2011 08:38:47 -0800 (PST) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 689293A69BE for ; Mon, 3 Jan 2011 08:38:47 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PZnSo-0004gP-gK; Mon, 03 Jan 2011 16:40:54 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> Date: Mon, 3 Jan 2011 16:40:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1082) Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:38:50 -0000 Hi Ali, On 3 Jan 2011, at 16:24, Ali C. Begen (abegen) wrote: > Hi Colin, >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, January 03, 2011 9:22 AM >> To: Ali C. Begen (abegen) >> Cc: avt@ietf.org >> Subject: Re: [AVT] FW: New Version Notification for = draft-ietf-avt-ports-for-ucast-mcast-rtp-10 >>=20 >> Ali, >>=20 >> On 21 Dec 2010, at 07:10, Ali C. Begen (abegen) wrote: >>> This revision includes the changes we agreed on in the last week's = call and after the feedback on the list. It also addresses >> Glen's comments, makes some clarifications here and there. >>=20 >>=20 >> This is looking good. Some minor comments only: >>=20 >> - Section 3: =93Therefore, the server will need the client to also = include the Token along with the RTCP messages that are >> different from the RTCP message that triggerred the unicast session = establishment.=94 - I don=92t understand what this means. >> Can you clarify in the draft? >=20 > Certain messages don=92t establish a unicast session but control it, = and they can be required to be bundled with a token as well as described = in 4.3.1. Sure, I understand that. But the text in the draft is unclear, and needs = updating. >> - Section 4.1: =93Here, the SSRC value is not necessarily linked to = the one used by the client in the multicast session.=94 - what do >> you mean by =93not necessarily=94 here? They=92re either part of the = same RTP session, in which case the client should use the >> same SSRC; or they=92re not, in which case the client should choose = its SSRC randomly. >=20 > When requesting a Token, the SSRC used or chosen by the client does = not matter. Think about a client requesting a token during booting. It = can use that token with any ssm session later on. We could say "Here the = SSRC value can be chosen randomly by the client since the Port Mapping = Request message is not necessarily linked to a specific multicast = session." >=20 > Is this better? Not really, since it's just as vague. Saying the SSRC "can" be chosen = randomly doesn't help: either it is chosen randomly, or it isn't. Which = is it? >> - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet >> diagram showing the format of such an element with enough entries to = fill more than one 32 bit block and require padding >> to the next. >=20 > OK, I will give it a shot. >=20 >> - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the server. >> This field might be clearer called =93Failed PT=94? >=20 > Sounds good. >=20 >> I didn't look at the SDP sections, sorry. >=20 > Thanks anyway. > -acbegen >=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Jan 3 08:47:45 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4683A69BE for ; Mon, 3 Jan 2011 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjto37mDiXwE for ; Mon, 3 Jan 2011 08:47:43 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A1F653A68C9 for ; Mon, 3 Jan 2011 08:47:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMuMIU2rRDoJ/2dsb2JhbACkNHOif5hhhUoEhGWJQg X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="239867007" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 03 Jan 2011 16:49:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p03GnjDB015398; Mon, 3 Jan 2011 16:49:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 08:49:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2011 08:49:38 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3F3@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 Thread-Index: AcurZQkkSO9igBb9R3y42hNqeHbofwAAB3DA References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 03 Jan 2011 16:49:45.0723 (UTC) FILETIME=[39EFECB0:01CBAB66] Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:47:45 -0000 > >> This is looking good. Some minor comments only: > >> > >> - Section 3: =93Therefore, the server will need the client to also = include the Token along with the RTCP messages that are > >> different from the RTCP message that triggerred the unicast session = establishment.=94 - I don=92t understand what this means. > >> Can you clarify in the draft? > > > > Certain messages don=92t establish a unicast session but control it, = and they can be required to be bundled with a token as > well as described in 4.3.1. >=20 > Sure, I understand that. But the text in the draft is unclear, and = needs updating. What about: During the unicast session lifetime, client's certain actions and messages sent by the client might need to be authorized by the server = by requiring a valid Token. Therefore, the client needs to also include the Token along with such RTCP messages.=20 These are explained later in this document. =20 > >> - Section 4.1: =93Here, the SSRC value is not necessarily linked to = the one used by the client in the multicast session.=94 - what > do > >> you mean by =93not necessarily=94 here? They=92re either part of = the same RTP session, in which case the client should use the > >> same SSRC; or they=92re not, in which case the client should choose = its SSRC randomly. > > > > When requesting a Token, the SSRC used or chosen by the client does = not matter. Think about a client requesting a token > during booting. It can use that token with any ssm session later on. = We could say "Here the SSRC value can be chosen > randomly by the client since the Port Mapping Request message is not = necessarily linked to a specific multicast session." > > > > Is this better? >=20 > Not really, since it's just as vague. Saying the SSRC "can" be chosen = randomly doesn't help: either it is chosen randomly, or it > isn't. Which is it? "Is chosen" then. I was reluctant to say this explicitly since a client = who asks for a token right on the instant it needed one could still use = the SSRC from the multicast session if it wants to. But, doing so will = not break anything. -acbegen =20 > >> - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet > >> diagram showing the format of such an element with enough entries = to fill more than one 32 bit block and require > padding > >> to the next. > > > > OK, I will give it a shot. > > > >> - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the > server. > >> This field might be clearer called =93Failed PT=94? > > > > Sounds good. > > > >> I didn't look at the SDP sections, sorry. > > > > Thanks anyway. > > -acbegen > > > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From oran@cisco.com Mon Jan 3 08:55:06 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC393A68C9 for ; Mon, 3 Jan 2011 08:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vvXSqSOe49y for ; Mon, 3 Jan 2011 08:55:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1351A3A67C0 for ; Mon, 3 Jan 2011 08:55:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,267,1291593600"; d="scan'208";a="199002869" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2011 16:57:11 +0000 Received: from dhcp-161-44-173-230.cisco.com (dhcp-161-44-173-230.cisco.com [161.44.173.230]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p03GvAN0000785; Mon, 3 Jan 2011 16:57:11 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3F3@xmb-sjc-215.amer.cisco.com> Date: Mon, 3 Jan 2011 11:57:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3BF3E0F5-2588-41C4-9C0B-5B105E8AE61F@cisco.com> References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3F3@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1082) Cc: Colin Perkins , avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:55:06 -0000 On Jan 3, 2011, at 11:49 AM, Ali C. Begen (abegen) wrote: >>>> This is looking good. Some minor comments only: >>>>=20 >>>> - Section 3: =93Therefore, the server will need the client to also = include the Token along with the RTCP messages that are >>>> different from the RTCP message that triggerred the unicast session = establishment.=94 - I don=92t understand what this means. >>>> Can you clarify in the draft? >>>=20 >>> Certain messages don=92t establish a unicast session but control it, = and they can be required to be bundled with a token as >> well as described in 4.3.1. >>=20 >> Sure, I understand that. But the text in the draft is unclear, and = needs updating. >=20 > What about: >=20 > During the unicast session lifetime, client's certain actions and > messages sent by the client might need to be authorized by the = server by > requiring a valid Token. Therefore, the client needs > to also include the Token along with such RTCP messages.=20 > These are explained later in this document. >=20 How about some word-smithing: "During the lifetime of a unicast session, a client may need to send = RTCP messages that require server authorization. Since such messages = require a valid Token for authorization, the client needs to include the = token along with such RTCP messages as explained in detail in later = sections of the document" >>>> - Section 4.1: =93Here, the SSRC value is not necessarily linked to = the one used by the client in the multicast session.=94 - what >> do >>>> you mean by =93not necessarily=94 here? They=92re either part of = the same RTP session, in which case the client should use the >>>> same SSRC; or they=92re not, in which case the client should choose = its SSRC randomly. >>>=20 >>> When requesting a Token, the SSRC used or chosen by the client does = not matter. Think about a client requesting a token >> during booting. It can use that token with any ssm session later on. = We could say "Here the SSRC value can be chosen >> randomly by the client since the Port Mapping Request message is not = necessarily linked to a specific multicast session." >>>=20 >>> Is this better? >>=20 >> Not really, since it's just as vague. Saying the SSRC "can" be chosen = randomly doesn't help: either it is chosen randomly, or it >> isn't. Which is it? >=20 > "Is chosen" then. I was reluctant to say this explicitly since a = client who asks for a token right on the instant it needed one could = still use the SSRC from the multicast session if it wants to. But, doing = so will not break anything. >=20 > -acbegen >=20 >=20 >>>> - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet >>>> diagram showing the format of such an element with enough entries = to fill more than one 32 bit block and require >> padding >>>> to the next. >>>=20 >>> OK, I will give it a shot. >>>=20 >>>> - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the >> server. >>>> This field might be clearer called =93Failed PT=94? >>>=20 >>> Sounds good. >>>=20 >>>> I didn't look at the SDP sections, sorry. >>>=20 >>> Thanks anyway. >>> -acbegen >>>=20 >>>> -- >>>> Colin Perkins >>>> http://csperkins.org/ >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Mon Jan 3 09:04:38 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9962A3A685A for ; Mon, 3 Jan 2011 09:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.541 X-Spam-Level: X-Spam-Status: No, score=-103.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsbasigIGOyI for ; Mon, 3 Jan 2011 09:04:37 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 5CA903A67C0 for ; Mon, 3 Jan 2011 09:04:37 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PZnrn-0006c4-cR; Mon, 03 Jan 2011 17:06:44 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <3BF3E0F5-2588-41C4-9C0B-5B105E8AE61F@cisco.com> Date: Mon, 3 Jan 2011 17:06:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <216DD630-FDFD-4F63-A1EB-F2BD28D008FD@csperkins.org> References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3F3@xmb-sjc-215.amer.cisco.com> <3BF3E0F5-2588-41C4-9C0B-5B105E8AE61F@cisco.com> To: David R Oran X-Mailer: Apple Mail (2.1082) Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 17:04:38 -0000 Looks good. Colin On 3 Jan 2011, at 16:57, David R Oran wrote: >=20 > On Jan 3, 2011, at 11:49 AM, Ali C. Begen (abegen) wrote: >=20 >>>>> This is looking good. Some minor comments only: >>>>>=20 >>>>> - Section 3: =93Therefore, the server will need the client to = also include the Token along with the RTCP messages that are >>>>> different from the RTCP message that triggerred the unicast = session establishment.=94 - I don=92t understand what this means. >>>>> Can you clarify in the draft? >>>>=20 >>>> Certain messages don=92t establish a unicast session but control = it, and they can be required to be bundled with a token as >>> well as described in 4.3.1. >>>=20 >>> Sure, I understand that. But the text in the draft is unclear, and = needs updating. >>=20 >> What about: >>=20 >> During the unicast session lifetime, client's certain actions and >> messages sent by the client might need to be authorized by the = server by >> requiring a valid Token. Therefore, the client needs >> to also include the Token along with such RTCP messages.=20 >> These are explained later in this document. >>=20 > How about some word-smithing: > "During the lifetime of a unicast session, a client may need to send = RTCP messages that require server authorization. Since such messages = require a valid Token for authorization, the client needs to include the = token along with such RTCP messages as explained in detail in later = sections of the document" >=20 >=20 >>>>> - Section 4.1: =93Here, the SSRC value is not necessarily linked = to the one used by the client in the multicast session.=94 - what >>> do >>>>> you mean by =93not necessarily=94 here? They=92re either part of = the same RTP session, in which case the client should use the >>>>> same SSRC; or they=92re not, in which case the client should = choose its SSRC randomly. >>>>=20 >>>> When requesting a Token, the SSRC used or chosen by the client does = not matter. Think about a client requesting a token >>> during booting. It can use that token with any ssm session later on. = We could say "Here the SSRC value can be chosen >>> randomly by the client since the Port Mapping Request message is not = necessarily linked to a specific multicast session." >>>>=20 >>>> Is this better? >>>=20 >>> Not really, since it's just as vague. Saying the SSRC "can" be = chosen randomly doesn't help: either it is chosen randomly, or it >>> isn't. Which is it? >>=20 >> "Is chosen" then. I was reluctant to say this explicitly since a = client who asks for a token right on the instant it needed one could = still use the SSRC from the multicast session if it wants to. But, doing = so will not break anything. >>=20 >> -acbegen >>=20 >>=20 >>>>> - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a packet >>>>> diagram showing the format of such an element with enough entries = to fill more than one 32 bit block and require >>> padding >>>>> to the next. >>>>=20 >>>> OK, I will give it a shot. >>>>=20 >>>>> - Figure 6: =93PT of request=94 - the RTCP packet that causes this = respond to be generated might not be a request to the >>> server. >>>>> This field might be clearer called =93Failed PT=94? >>>>=20 >>>> Sounds good. >>>>=20 >>>>> I didn't look at the SDP sections, sorry. >>>>=20 >>>> Thanks anyway. >>>> -acbegen >>>>=20 >>>>> -- >>>>> Colin Perkins >>>>> http://csperkins.org/ >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>>=20 >>>=20 >>>=20 >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Jan 3 12:39:35 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9634F3A6BB5; Mon, 3 Jan 2011 12:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+YJL6VzGVqH; Mon, 3 Jan 2011 12:39:34 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 583233A6BB1; Mon, 3 Jan 2011 12:39:34 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKLDIU2rR7Hu/2dsb2JhbACkNXOiZpkShUoEhGWJQg X-IronPort-AV: E=Sophos;i="4.60,268,1291593600"; d="scan'208";a="300752048" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 03 Jan 2011 20:41:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p03KffrD009063; Mon, 3 Jan 2011 20:41:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 12:41:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Jan 2011 12:41:11 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF513@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Participation for ACM MMSys 2011 - San Jose, CA Thread-Index: AcurfwSPhtZ1t8taRBCJ355o8icSfg== From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 03 Jan 2011 20:41:41.0604 (UTC) FILETIME=[A072DA40:01CBAB86] Subject: [AVT] Call for Participation for ACM MMSys 2011 - San Jose, CA X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 20:39:35 -0000 Sorry if you see this call multiple times, but many of the regular = sessions and two special sessions are particularly of interest for the = avt and httpstreaming communities. Technical program and registration = are now available on the Web site. http://www.mmsys.org/?q=3Dnode/41=20 -acbegen =3D=3D=3D=3D MMSys 2011 Call For Participation =3D=3D=3D=3D ACM Multimedia Systems 2011 Feb. 23 - 25, 2011 San Jose, CA www.mmsys.org Conference registration now open at: http://www.regonline.com/mmsys2011=20 New This Year: * Low registration fees made possible by Cisco's hosting support. * Keynote Speaker: Mark Watson, Netflix * Special Session: Modern Media Transport * Dataset Track * Full program at www.mmsys.org The ACM Multimedia Systems conference provides a forum for researchers, = engineers, and scientist to present and share their latest research = findings in multimedia systems. While research about specific aspects of = multimedia systems is regularly published in the various proceedings and = transactions of the networking, operating system, real-time system, and = database communities, MMSys aims to cut across these domains in the = context of multimedia data types. This provides a unique opportunity to = view the intersections and interplay of the various approaches and = solutions developed across these domains to deal with multimedia data = types. Furthermore, MMSys provides an avenue for communicating research = that addresses multimedia systems holistically. Industrial participants are highly encouraged to attend. Students are = invited to take advantage of special student pricing.=20 Sponsored by ACM SIG Multimedia In-cooperation with SIGCOMM and SIGOPS General Co-Chairs Ketan Mayer-Patel, Univ. of North Carolina, USA Ali C. Begen, Cisco, Canada Technical Program Chair Mark Claypool, Worcester Polytechnic Institute, USA Technical Program Committee Luca Abeni, University of Trento, Italy Kevin Almeroth, University of California at Santa Barbara, USA Grenville Armitage, Swinburne University of Technology, Australia Ali Begen, Cisco, Canada Azer Bestavros, Boston University, USA Dick Bulterman, CWI, Netherlands Surendar Chandra, FXPAL, USA Bruce Davie, Cisco, USA Wu-Chang Feng, Portland State University, USA Wu-Chi Feng, Portland State University, USA Carsten Griwodz, University of Oslo, Norway P=E5l Halvorsen, University of Oslo, Norway Mohamed Hefeeda, Simon Fraser University, Canada Tristan Henderson, University of St. Andrews, UK Sugih Jamin, University of Michigan, USA Charles "Buck" Krasic, University of British Columbia, Canada Baochun Li, University of Toronto, Canada Kang Li, University of Georgia, USA Tom Little, Boston University, USA Dwight Makaroff, University of Saskatchewan, Canada Andreas Mauthe, Lancaster University, UK John Miller, Microsoft, UK Klara Nahrstedt, University of Illinois Urbana-Champaign, USA Wei Tsang Ooi, National University of Singapore, Singapore Reza Rejaie, University of Oregon, USA Christoph Rensing, University of Darmstadt, Germany Larry Rowe, FXPAL, USA Nabil Sarhan, Wayne State University, USA Travis Schluessler, Intel, USA Prashant Shenoy, University of Massachusetts, USA Shervin Shirmohammadi, University of Ottawa, Canada Michael Vernick, Avaya, USA Carey Williamson, University of Calgary, Canada Huahui Wu, Google, USA Roger Zimmerman, National University of Singapore, Singapore Michael Zink, University of Massachusetts, USA From keith.drage@alcatel-lucent.com Tue Jan 4 03:38:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91E73A69D1 for ; Tue, 4 Jan 2011 03:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.655 X-Spam-Level: X-Spam-Status: No, score=-105.655 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDAjq78d0G+V for ; Tue, 4 Jan 2011 03:38:12 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 33F5A3A69B7 for ; Tue, 4 Jan 2011 03:38:11 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p04BeHbi017321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 4 Jan 2011 12:40:17 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 4 Jan 2011 12:40:17 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Tue, 4 Jan 2011 12:40:16 +0100 Thread-Topic: Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-03.txt Thread-Index: Acuq9pVH55mPrpbwQZ+F4idT1D/cLQBC7/9g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [AVT] FW: Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 11:38:13 -0000 (As WG co-chair) As part of the publication request process to become an RFC, i-ds go throug= h a number of separate reviews.=20 I'm forwarding this review to the list as correcting it has impact on the b= its on the wire, and AVT may have some input on what change they would like= to see. If so, please express. regards Keith -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]=20 Sent: Monday, January 03, 2011 3:27 AM To: General Area Review Team; draft-ietf-avt-rtp-cnames.all@tools.ietf.org Subject: Gen-ART Telechat review of draft-ietf-avt-rtp-cnames-03.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for= this draft (for background on Gen-ART, please see http://www.alvestrand.no= /ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting = a new version of the draft. Document: draft-ietf-avt-rtp-cnames-03.txt Reviewer: Suresh Krishnan Review Date: 2011/01/02 IESG Telechat date: 2011/01/06 Summary: This draft has addressed my comments from the previous Last Call r= eview but has a new issue that needs to be fixed before publication as a Pr= oposed Standard. * Section 5 Step 2 This step describes the use of an EUI-64 identifier and how to generate one= if it does not exists. The procedure for the creation of the EUI-64 from a= 48 bit MAC address is incorrect. RFC4291 describes how to create a **modified EUI-64** identifier (and not a= EUI-64 identifier) from a MAC address. A MAC address of xx:78:90:12:34:56 will be transformed to a modified EUI-64 of yy7890FFFE123456 where yy is the value of xx with the u/l bit (bit 6) flipped. The IEEE reference for creation of an EUI-64 from a 48 bit MAC address http://standards.ieee.org/develop/regauth/tut/eui64.pdf would result in an EUI-64 of xx7890FFFF123456 for the same MAC address. I understand that there will be no interoperability issues due to this (sin= ce the cname is opaque) but there may be issues with testing compliance (si= nce the expected hash values will be way off). I recommend either using the term "modified EUI-64" instead of EUI-64 or ch= anging the reference from RFC4291 to the IEEE document in order to fix this= inconsistency. Thanks Suresh From rjsparks@nostrum.com Tue Jan 4 10:47:40 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEAD3A6A74 for ; Tue, 4 Jan 2011 10:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RHg2EyFCTeU for ; Tue, 4 Jan 2011 10:47:38 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 968803A6BDB for ; Tue, 4 Jan 2011 10:47:37 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p04IngR0038357 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Jan 2011 12:49:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-39-179686159 Date: Tue, 4 Jan 2011 12:49:42 -0600 References: To: IETF AVT WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [AVT] Fwd: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 18:47:40 -0000 --Apple-Mail-39-179686159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Forwarding to the AVT list in case folks there aren't watching = ietf@ietf.org. The recently released -03 reflects what's below RjS Begin forwarded message: > From: Colin Perkins > Date: December 17, 2010 11:59:51 AM CST > To: Allison Mankin > Cc: Allison Mankin , Ali Begen , = IETF Discussion , Transport Directorate = > Subject: Re: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02 >=20 > Allison, >=20 > Thanks for the review. These all seem like reasonable suggestions, = which we should incorporate.=20 >=20 > Colin >=20 >=20 >=20 > On 14 Dec 2010, at 02:56, Allison Mankin wrote: >> TSV-DIR Last Call review of "Guidelines for Chosing RTP Control = Protocol (RTCP) Canonical Names (CNAMEs) >>=20 >> I've reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. The authors should consider this = review together with any other last-call comments they receive. Please = always cc tsv-dir@ietf.org if you reply to or forward this review. >>=20 >> Summary: This draft is on the right track, but has open issues = described in the review. >>=20 >> The review below gives my basis for three recommendations: >> 1. For long-term persistent CNAMEs, differentiate among the UUID = "Versions" in RFC 4122 >> 2. For short-term persistent CNAMEs, allow IPv4-only endpoints to = generate a pseudo-random alternative to their MAC, if desired >> 3. For per-session CNAMEs, provide some guidance for the random value = and the key, which are currently left underspecified. >>=20 >> Section 3 sets up the major requirement to be met, which is better = uniqueness properties than those of the CNAME generation in RFC 3550. = There's a hint in the last sentence of the section about an additional = requirement to afford privacy support. This sentence only mentions = avoiding exposure of private addresses. Avoidance of linkage among RTP = streams due to the use of fixed CNAMEs comes up later. >>=20 >> Section 4 sets up the CNAME types, persistent versus per-session, and = within persistent types, short-term IPv4-only, short-term IPv6-capable, = and long-term. The methods of generating these CNAMEs are distinct and = I understand from the WG mailing list discussion of their AD review that = they are to be specified as mandatory. On December 2, Ali wrote to AVT = that the next revision will change language in Section 4 from the = existing: >>=20 >> Other methods, beyond the three methods listed above, are not >> compliant with this specification and SHOULD NOT be used. >>=20 >> To the following: >>=20 >> It is believed that obtaining uniqueness is an important property = that >> requires careful evaluation of the method. This document provides a >> number of methods, for which it is believed that at least one of = them >> would meet all deployment scenarios. This document therefore does = not >> provide for the implementor to define and select an alternative >> method. >>=20 >> A future specification might define an alternative method for >> generating RTCP CNAMEs as long as the proposed method has = appropriate >> uniqueness, and there is consistency between the methods used for >> multiple RTP sessions that are to be correlated. However, such a >> specification needs to be reviewed and approved before deployment. >>=20 >> The second sentence of the first paragraph could be written better: >>=20 >> This document provides a number of methods, at least one of which >> should be suitable for all deployment scenarios. >=20 > Agreed. >=20 >> My remaining discussion is about making this statement more true. >>=20 >> First, all the methods should afford some access to privacy support, = but as written, there is little or none for the long-term persistent and = the IPv4-only short-term persistent CNAMEs. >>=20 >> An implementation that wishes to >> discourage this type of third-party monitoring can generate a unique >> RTCP CNAME for each RTP session, or group of related RTP sessions, >> that it joins. Such a per-session RTCP CNAME cannot be used for >> traffic analysis, and so provides some limited form of privacy >>=20 >> The above statement implies that a long-term persistent CNAME = inherently cannot have privacy support. It's not necessarily so: if the = CNAME doesn't embed identifying information, observers get connections = among multiple streams but they only don't have a fixed host identity, = only a pseudonym. >>=20 >> Specific issues per CNAME method: >>=20 >> 1) Long-term persistent CNAMEs are required to be generated by an = adaptation of RFC 4122 UUIDs (the adaptation is to leave off the string = "urn:uuid:"). The draft references Section 3 of RFC 4122. It should = reference Section 4 instead because Section 3 does not detail the UUID = components. =20 >=20 > Agreed. This looks like a typo that should be fixed. >=20 >> Moreover, it would be good for the draft to advise on usage among the = four different versions of UUID that RFC 4122 covers: >>=20 >> + Version 1: generated from clock + MAC, or + MAC-format random = number >> + Version 3: generated from namespace:name >> + Version 4: generated from "truly random or pseudo-random number" >> + Version 5: generated from hash of namespace:name >>=20 >> There needs to be some guidance because the use of the UUID Versions = 3/5, derived from namespace:name, has the same problem with = non-uniqueness of FQDNs as the RFC 3550 FQDN-based CNAMEs. Perhaps this = document should advise against using 3/5. In addition, right now the = draft is silent on mitigating identity exposure, but it could offer some = guidance towards using the variant of Version 1 that does not expose the = MAC or towards using Version 4. >=20 > This guidance seems appropriate, thanks. >=20 >> 2) Short-term persistent CNAMEs are allowed to use a pseudo-randomly = generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, = but are required to exposetheir MACs if the device is IPv4-only. Why = not allow IPv4-only endpoints to to generate pseudo-random MACs using = the specification of doing so provided for the Version 1 variant in RFC = 4122? >=20 > That seems like a reasonable addition. >=20 >> 3) Per-session CNAMEs are generated using SHA1-HMAC over the = concatenation of the initially-used SSRC, the source and destination = addresses and ports, and "a randomly generated value". RFC 4086 is = given as a reference for the randomly generated value. I think an = implementer would like to know how many bytes of randomly generated = value should be used; this doesn't come out clearly from reading RFC = 4086. Further, what are the requirements for the key for HMAC here? In = reading RFC 2104, the reference for HMAC, I end up with some ideas about = the key length, but not about how long/where I can use the same key or = whether there are problematic keys - to mention two questions that come = to mind. Keying would not normally be easy to under-specify this way = because a security application would call for some keying details, but = in this application there is no security use for the keys. Either it = would be good to add some guidance or perhaps SHA1-HMAC could be = replaced with an "inse > cure hash." >=20 > We'll add some guidance in -03. >=20 > Thanks, > Colin >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-39-179686159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ietf@ietf.org.

The = recently released -03 reflects what's = below

RjS

Begin forwarded = message:

From: Colin Perkins <csp@csperkins.org>
Date: December 17, 2010 = 11:59:51 AM CST
To: Allison Mankin <allison.mankin@gmail.com><= br>
Cc: Allison Mankin <mankin@psg.com>, Ali Begen <abegen@cisco.com>, IETF = Discussion <ietf@ietf.org>, = Transport Directorate <tsv-dir@ietf.org>
=
Subject: Re: TSV-Dir Last = Call review of = draft-ietf-avt-rtp-cnames-02

Allison,

= Thanks for the review. These all seem like reasonable suggestions, which = we should incorporate.

Colin



On 14 Dec 2010, at = 02:56, Allison Mankin wrote:
TSV-DIR Last = Call review of "Guidelines for Chosing RTP Control Protocol (RTCP) = Canonical Names (CNAMEs)

I've reviewed = this document as part of the transport area directorate's ongoing effort = to review key IETF documents. These comments were written primarily for = the transport area directors, but are copied to the document's authors = for their information and to allow them to address any issues raised. = The authors should consider this review together with any other = last-call comments they receive.  Please always cc tsv-dir@ietf.org if you reply to or = forward this review.

Summary: This = draft is on the right track, but has open issues described in the = review.

The review = below gives my basis for three = recommendations:
1. For = long-term persistent CNAMEs, differentiate among the UUID "Versions" in = RFC 4122
2. For short-term = persistent CNAMEs, allow IPv4-only endpoints to generate a pseudo-random = alternative to their MAC, if desired
3. For per-session CNAMEs, provide some guidance for the = random value and the key, which are currently left = underspecified.

Section 3 sets = up the major requirement to be met, which is better uniqueness = properties than those of the CNAME generation in RFC 3550. There's a = hint in the last sentence of the section about an additional requirement = to afford privacy support.  This sentence only mentions avoiding = exposure of private addresses.  Avoidance of linkage among RTP = streams due to the use of fixed CNAMEs comes up = later.

Section 4 sets = up the CNAME types, persistent versus per-session, and within persistent = types, short-term IPv4-only, short-term IPv6-capable, and long-term. =  The methods of generating these CNAMEs are distinct and I = understand from the WG mailing list discussion of their AD review that = they are to be specified as mandatory.   On December 2, Ali = wrote to AVT that the next revision will change language in Section 4 = from the existing:

=   Other methods, beyond the three methods listed above, are = not
  compliant = with this specification and SHOULD NOT be = used.

To the = following:

  It = is believed that obtaining uniqueness is an important property = that
  requires = careful evaluation of the method. This document provides = a
  number of = methods, for which it is believed that at least one of = them
  would meet = all deployment scenarios. This document therefore does = not
  provide for = the implementor to define and select an = alternative
=   method.

  A = future specification might define an alternative method = for
  generating = RTCP CNAMEs as long as the proposed method has = appropriate
=   uniqueness, and there is consistency between the methods = used for
  multiple = RTP sessions that are to be correlated. However, such = a
  specification = needs to be reviewed and approved before = deployment.

The second = sentence of the first paragraph could be written = better:

=   This document provides a number of methods, at least one of = which
  should be = suitable for all deployment = scenarios.

Agreed.

My= remaining discussion is about making this statement more = true.

First, all the = methods should afford some access to privacy support, but as written, = there is little or none for the long-term persistent and the IPv4-only = short-term persistent CNAMEs.

=             &n= bsp;           &nbs= p;           An = implementation that wishes to
=  discourage this type of third-party monitoring can generate a = unique
 RTCP CNAME for = each RTP session, or group of related RTP = sessions,
 that it = joins.  Such a per-session RTCP CNAME cannot be used = for
 traffic analysis, = and so provides some limited form of privacy

The above = statement implies that a long-term persistent CNAME inherently cannot = have privacy support.  It's not necessarily so: if the CNAME = doesn't embed identifying information, observers get connections among = multiple streams but they only don't have a fixed host identity, only a = pseudonym.

Specific issues = per CNAME method:

1) Long-term = persistent CNAMEs are required to be generated by an adaptation of RFC = 4122 UUIDs (the adaptation is to leave off the string "urn:uuid:"). The = draft references Section 3 of RFC 4122.  It should reference = Section 4 instead because Section 3 does not detail the UUID components. =  

Agreed. This looks like a typo that should be = fixed.

Moreover, it would be good for = the draft to advise on usage among the four different versions of UUID = that RFC 4122 covers:

+ Version 1: = generated from clock + MAC, or + MAC-format random = number
+ Version 3: generated = from namespace:name
+ Version = 4: generated from "truly random or pseudo-random = number"
+ Version 5: generated = from hash of namespace:name

There needs to = be some guidance because the use of the UUID Versions 3/5, derived from = namespace:name, has the same problem with non-uniqueness of FQDNs as the = RFC 3550 FQDN-based CNAMEs.  Perhaps this document should advise = against using 3/5.  In addition, right now the draft is silent on = mitigating identity exposure, but it could offer some guidance towards = using the variant of Version 1 that does not expose the MAC or towards = using Version 4.

This guidance seems appropriate, = thanks.

2) Short-term persistent CNAMEs =  are allowed to use a pseudo-randomly generated RFC 4941 IPv6 = privacy address if the device is IPv6-capable, but are required to = exposetheir MACs if the device is IPv4-only.  Why not allow = IPv4-only endpoints to to generate pseudo-random MACs using the = specification of doing so provided for the Version 1 variant in RFC = 4122?

That seems like a reasonable = addition.

3) Per-session CNAMEs are = generated using SHA1-HMAC over the concatenation of the initially-used = SSRC, the source and destination addresses and ports, and "a randomly = generated value".  RFC 4086 is given as a reference for the = randomly generated value.  I think an implementer would like to = know how many bytes of randomly generated value should be used; this = doesn't come out clearly from reading RFC 4086. Further, what are the = requirements for the key for HMAC here?  In reading RFC 2104, the = reference for HMAC, I end up with some ideas about the key length, but = not about how long/where I can use the same key or whether there are = problematic keys - to mention two questions that come to mind. =  Keying would not normally be easy to under-specify this way = because a security application would call for some keying details, but = in this application there is no security use for the keys.  Either = it would be good to add some guidance or perhaps SHA1-HMAC could be = replaced with an "inse
cure hash."

We'll add = some guidance in -03.

Thanks,
Colin

--
Colin = Perkins
http://csperkins.org/



__= _____________________________________________
Ietf mailing = list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

= --Apple-Mail-39-179686159-- From abegen@cisco.com Tue Jan 4 12:44:01 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F13A3A6B6A for ; Tue, 4 Jan 2011 12:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgxQ7shloXFd for ; Tue, 4 Jan 2011 12:44:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E74693A6A17 for ; Tue, 4 Jan 2011 12:43:59 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOEVI02rR7Ht/2dsb2JhbACkLHOjTZhuhUoEhGiJQg X-IronPort-AV: E=Sophos;i="4.60,274,1291593600"; d="scan'208";a="645219563" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 04 Jan 2011 20:46:07 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p04Kk7ag014243; Tue, 4 Jan 2011 20:46:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Jan 2011 12:46:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Jan 2011 12:45:56 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF809@xmb-sjc-215.amer.cisco.com> In-Reply-To: <216DD630-FDFD-4F63-A1EB-F2BD28D008FD@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 Thread-Index: AcuraJ5xRCA+fZ3XTceYDEOaTl7cnAA54G6Q References: <20101221063801.32FE03A69DD@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DEF4023@xmb-sjc-215.amer.cisco.com> <2C992ED0-C498-4268-99DB-8AC361FCF74A@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3D6@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF3F3@xmb-sjc-215.amer.cisco.com> <3BF3E0F5-2588-41C4-9C0B-5B105E8AE61F@cisco.com> <216DD630-FDFD-4F63-A1EB-F2BD28D008FD@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" , "Dave Oran (oran)" X-OriginalArrivalTime: 04 Jan 2011 20:46:06.0987 (UTC) FILETIME=[690AD5B0:01CBAC50] Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-10 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 20:44:01 -0000 I asked the chairs yesterday when they will start WGLC. Just before they = do that we will submit a revision to address these minor changes. Chairs, please provide a timeline. -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, January 03, 2011 12:07 PM > To: Dave Oran (oran) > Cc: Ali C. Begen (abegen); avt@ietf.org > Subject: Re: [AVT] FW: New Version Notification for = draft-ietf-avt-ports-for-ucast-mcast-rtp-10 >=20 > Looks good. > Colin >=20 >=20 > On 3 Jan 2011, at 16:57, David R Oran wrote: >=20 > > > > On Jan 3, 2011, at 11:49 AM, Ali C. Begen (abegen) wrote: > > > >>>>> This is looking good. Some minor comments only: > >>>>> > >>>>> - Section 3: =93Therefore, the server will need the client to = also include the Token along with the RTCP messages that > are > >>>>> different from the RTCP message that triggerred the unicast = session establishment.=94 - I don=92t understand what this > means. > >>>>> Can you clarify in the draft? > >>>> > >>>> Certain messages don=92t establish a unicast session but control = it, and they can be required to be bundled with a token as > >>> well as described in 4.3.1. > >>> > >>> Sure, I understand that. But the text in the draft is unclear, and = needs updating. > >> > >> What about: > >> > >> During the unicast session lifetime, client's certain actions and > >> messages sent by the client might need to be authorized by the = server by > >> requiring a valid Token. Therefore, the client needs > >> to also include the Token along with such RTCP messages. > >> These are explained later in this document. > >> > > How about some word-smithing: > > "During the lifetime of a unicast session, a client may need to send = RTCP messages that require server authorization. Since > such messages require a valid Token for authorization, the client = needs to include the token along with such RTCP messages > as explained in detail in later sections of the document" > > > > > >>>>> - Section 4.1: =93Here, the SSRC value is not necessarily linked = to the one used by the client in the multicast session.=94 - > what > >>> do > >>>>> you mean by =93not necessarily=94 here? They=92re either part of = the same RTP session, in which case the client should use > the > >>>>> same SSRC; or they=92re not, in which case the client should = choose its SSRC randomly. > >>>> > >>>> When requesting a Token, the SSRC used or chosen by the client = does not matter. Think about a client requesting a > token > >>> during booting. It can use that token with any ssm session later = on. We could say "Here the SSRC value can be chosen > >>> randomly by the client since the Port Mapping Request message is = not necessarily linked to a specific multicast session." > >>>> > >>>> Is this better? > >>> > >>> Not really, since it's just as vague. Saying the SSRC "can" be = chosen randomly doesn't help: either it is chosen randomly, > or it > >>> isn't. Which is it? > >> > >> "Is chosen" then. I was reluctant to say this explicitly since a = client who asks for a token right on the instant it needed one > could still use the SSRC from the multicast session if it wants to. = But, doing so will not break anything. > >> > >> -acbegen > >> > >> > >>>>> - Section 4.2: The addition of the packet types element is good. = However, for clarify, it would be useful to include a > packet > >>>>> diagram showing the format of such an element with enough = entries to fill more than one 32 bit block and require > >>> padding > >>>>> to the next. > >>>> > >>>> OK, I will give it a shot. > >>>> > >>>>> - Figure 6: =93PT of request=94 - the RTCP packet that causes = this respond to be generated might not be a request to the > >>> server. > >>>>> This field might be clearer called =93Failed PT=94? > >>>> > >>>> Sounds good. > >>>> > >>>>> I didn't look at the SDP sections, sorry. > >>>> > >>>> Thanks anyway. > >>>> -acbegen > >>>> > >>>>> -- > >>>>> Colin Perkins > >>>>> http://csperkins.org/ > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Audio/Video Transport Working Group > >>>> avt@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/avt > >>> > >>> > >>> > >>> -- > >>> Colin Perkins > >>> http://csperkins.org/ > >>> > >>> > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From Internet-Drafts@ietf.org Wed Jan 5 07:30:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0718C3A6C78; Wed, 5 Jan 2011 07:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TX+TpXb-8t-6; Wed, 5 Jan 2011 07:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D532A3A6C24; Wed, 5 Jan 2011 07:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110105153001.4075.71353.idtracker@localhost> Date: Wed, 05 Jan 2011 07:30:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 15:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Port Mapping Between Unicast and Multicast RTP Sessions Author(s) : A. Begen, et al. Filename : draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt Pages : 35 Date : 2011-01-05 This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05072835.I-D@ietf.org> --NextPart-- From abegen@cisco.com Wed Jan 5 07:35:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A095D3A6C24 for ; Wed, 5 Jan 2011 07:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNewQwLZr8BC for ; Wed, 5 Jan 2011 07:35:20 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E22CC3A6AF4 for ; Wed, 5 Jan 2011 07:35:20 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMGAK4eJE2rR7Hu/2dsb2JhbACDd5IWjTZec6ZAilONVoEhgzd0BIRoiUc X-IronPort-AV: E=Sophos;i="4.60,278,1291593600"; d="scan'208";a="310621362" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2011 15:37:12 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p05FbCBs027111 for ; Wed, 5 Jan 2011 15:37:12 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 07:37:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 5 Jan 2011 07:36:33 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF9A1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20110105152836.A237A3A6C69@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 Thread-Index: Acus7YX6a/xdPfogTtKfudare1tbVwAAJ9kg References: <20110105152836.A237A3A6C69@core3.amsl.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 05 Jan 2011 15:37:12.0331 (UTC) FILETIME=[6BF085B0:01CBACEE] Subject: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 15:35:21 -0000 VGhpcyBoYXMgbWlub3IgZml4ZXMgQ29saW4gcG9pbnRlZCBvdXQgYSBmZXcgZGF5cyBhZ28uIFdl IGFyZSBub3QgYXdhcmUgb2YgYW55IHJlbWFpbmluZyBvcGVuIGlzc3VlIGFuZCB0aGUgZHJhZnQg c2hvdWxkIGJlIHJlYWR5IGZvciB0aGUgY2hhaXJzJyByZXZpZXcuDQoNCkRpZmY6DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dC1wb3J0cy1mb3ItdWNhc3Qt bWNhc3QtcnRwL2hpc3RvcnkvDQoNCi1hY2JlZ2VuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25A aWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA1LCAyMDExIDEwOjI5IEFNDQpU bzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpDYzogRGFuIFdpbmcgKGR3aW5nKTsgVG9tLlZhbl9D YWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaWV0Zi1hdnQtcG9ydHMtZm9yLXVjYXN0LW1jYXN0LXJ0cC0xMSANCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1hdnQtcG9ydHMtZm9yLXVjYXN0LW1j YXN0LXJ0cC0xMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGkgQmVn ZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0 LWlldGYtYXZ0LXBvcnRzLWZvci11Y2FzdC1tY2FzdC1ydHANClJldmlzaW9uOgkgMTENClRpdGxl OgkJIFBvcnQgTWFwcGluZyBCZXR3ZWVuIFVuaWNhc3QgYW5kIE11bHRpY2FzdCBSVFAgU2Vzc2lv bnMNCkNyZWF0aW9uX2RhdGU6CSAyMDExLTAxLTA1DQpXRyBJRDoJCSBhdnQNCk51bWJlcl9vZl9w YWdlczogMzUNCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgcG9ydCBtYXBw aW5nIHNvbHV0aW9uIHRoYXQgYWxsb3dzIFJUUA0KcmVjZWl2ZXJzIHRvIGNob29zZSB0aGVpciBv d24gcG9ydHMgZm9yIGFuIGF1eGlsaWFyeSB1bmljYXN0IHNlc3Npb24NCmluIFJUUCBhcHBsaWNh dGlvbnMgdXNpbmcgYm90aCB1bmljYXN0IGFuZCBtdWx0aWNhc3Qgc2VydmljZXMuICBUaGUNCnNv bHV0aW9uIHByb3ZpZGVzIHByb3RlY3Rpb24gYWdhaW5zdCBkZW5pYWwtb2Ytc2VydmljZSBvciBw YWNrZXQNCmFtcGxpZmljYXRpb24gYXR0YWNrcyB0aGF0IGNvdWxkIGJlIHVzZWQgdG8gY2F1c2Ug b25lIG9yIG1vcmUgUlRQDQpwYWNrZXRzIHRvIGJlIHNlbnQgdG8gYSB2aWN0aW0gY2xpZW50Lg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoN Cg== From keith.drage@alcatel-lucent.com Wed Jan 5 08:54:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C1A3A6C77 for ; Wed, 5 Jan 2011 08:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.675 X-Spam-Level: X-Spam-Status: No, score=-103.675 tagged_above=-999 required=5 tests=[AWL=-1.426, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2EAJIC9pJMB for ; Wed, 5 Jan 2011 08:54:12 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 68A093A6C84 for ; Wed, 5 Jan 2011 08:54:12 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p05GuHV6002976 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Jan 2011 17:56:17 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 5 Jan 2011 17:56:17 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Wed, 5 Jan 2011 17:56:15 +0100 Thread-Topic: WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 Thread-Index: Acus+XcFC0D9cga/RRCdy+Ao8da8RQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" Subject: [AVT] WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 16:54:13 -0000 (As WG co-chair) The WG chairs believe this document now represents working group consensus = on the technical solution so... This is to announce a working group last call for draft-ietf-avt-ports-for-= ucast-mcast-rtp-11 with comments to be provided by 19th January. http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-ucast-mcast-rt= p-11.txt In providing comments, please identify the level you believe the comment is= (editorial, minor technical, major technical) in order to give some guidan= ce to prioritizing the show stoppers.=20 Please provide your comments in reply to this message. If you read it and have no comments, and believe the document is therefore = OK, then please send a message to the WG chairs - this is extremely helpful= in determining level of review the document has had. regards Keith= From keith.drage@alcatel-lucent.com Wed Jan 5 09:13:08 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E932E3A6BC5 for ; Wed, 5 Jan 2011 09:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.656 X-Spam-Level: X-Spam-Status: No, score=-105.656 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3IctRZVfLVr for ; Wed, 5 Jan 2011 09:13:08 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id AB3A63A6AF4 for ; Wed, 5 Jan 2011 09:13:06 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p05HFC5g008102 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Jan 2011 18:15:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 5 Jan 2011 18:15:12 +0100 From: "DRAGE, Keith (Keith)" To: "DRAGE, Keith (Keith)" , "avt@ietf.org" Date: Wed, 5 Jan 2011 18:11:25 +0100 Thread-Topic: WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 Thread-Index: Acus+XcFC0D9cga/RRCdy+Ao8da8RQAAgErw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" Subject: Re: [AVT] WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 17:13:09 -0000 (As WG co-chair) I should add that the document is intended as proposed standard, so please = take that into account in your review. Keith=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of DRAGE, Keith (Keith) > Sent: Wednesday, January 05, 2011 4:56 PM > To: avt@ietf.org > Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: [AVT] WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 >=20 > (As WG co-chair) >=20 > The WG chairs believe this document now represents working=20 > group consensus on the technical solution so... >=20 > This is to announce a working group last call for=20 > draft-ietf-avt-ports-for-ucast-mcast-rtp-11 with comments to=20 > be provided by 19th January. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-u > cast-mcast-rtp-11.txt >=20 > In providing comments, please identify the level you believe=20 > the comment is (editorial, minor technical, major technical)=20 > in order to give some guidance to prioritizing the show stoppers.=20 >=20 > Please provide your comments in reply to this message. >=20 > If you read it and have no comments, and believe the document=20 > is therefore OK, then please send a message to the WG chairs=20 > - this is extremely helpful in determining level of review=20 > the document has had. >=20 > regards >=20 > Keith > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > = From fruchtalle@googlemail.com Fri Jan 7 01:42:37 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4933A67F7 for ; Fri, 7 Jan 2011 01:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raYDRheDl8FA for ; Fri, 7 Jan 2011 01:42:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1158C3A6804 for ; Fri, 7 Jan 2011 01:42:35 -0800 (PST) Received: by fxm9 with SMTP id 9so16977832fxm.31 for ; Fri, 07 Jan 2011 01:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=lgLSqCB0yO7mgjaDj2dE5d6ykrIbxC9BeBwKSb2YDh4=; b=ZXUWuJBC5zVNLYwk7p5GXN3owquGeCXf545FKwvyXetbPRb5MBtjoAHt8nKmeTklDQ itjXtJY3LfmrUc03Jpwoa+Xgj1Xv+4KjBl3IgQ0NmkbADk/7Q3rIRR0cUstoNHhUtWZg 0S8GCVlxeFEGAFayr6fVWmmPk2cQXkPEMT1Nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Y7I8MKS0oCcwXba9X6dyRtJ9lsxh7G4VkJJ9Qrpjg4tvplVc8xBkxuDDEcINltvEV2 QBqBbZP90rtXEjOMjwCYWQJG6GTOM759Pp1o7myIWMs7E1J/XDiVihx+4JhWN86cw/db XfOjSTDuAcQ5twyoZpFkcOhaF7WkA1MO06VQU= MIME-Version: 1.0 Received: by 10.223.83.11 with SMTP id d11mr4499634fal.37.1294393482311; Fri, 07 Jan 2011 01:44:42 -0800 (PST) Received: by 10.223.18.1 with HTTP; Fri, 7 Jan 2011 01:44:42 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Jan 2011 10:44:42 +0100 Message-ID: From: Siga To: avt@ietf.org Content-Type: multipart/alternative; boundary=20cf3054a549b68f5704993e7701 Subject: [AVT] RTP Protocol cannot be started X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 09:42:37 -0000 --20cf3054a549b68f5704993e7701 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have implemented a SIP Client and to extend my project I wrote a RTP Protocol and try to send the RTP packets and when I notice it using wireshark I get a strange message, let me show it so that you can have better idea *CLIENT SERVER* SIP Request:INVITE ------------------------------------*>* SIP Status: 100 Trying *<*------------------------------------ SIP/SDP Status: 200 OK *<*------------------------------------ SIP Request:ACK ------------------------------------*>* *UDP Source port: bre Destination port* ---------------------------------------*>* Here I am planning to send RTP Packets but instead I get this strange message on my wireshark. Do anybody have an idea where I am making my mistake. Regards, Siga --20cf3054a549b68f5704993e7701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
I have implemented a SIP Client and to ex= tend my project I wrote a RTP Protocol and try to send the RTP packets and = when I notice it using wireshark I get a strange=A0 message, let me show it= so that you can have better idea

=A0C= LIENT =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SERVER

=A0=A0=A0=A0=A0=A0=A0 SIP Request:= INVITE
=A0=A0=A0=A0=A0 ------------= ------------------------>


=A0=A0=A0=A0=A0=A0 SIP Status: 100 Trying
=A0=A0=A0 <------------------------------------


=A0=A0=A0=A0=A0=A0 SIP/SDP Status: 200 OK=A0=A0=A0 <---------------= ---------------------


=A0=A0=A0=A0=A0=A0 SIP Request= :ACK
=A0=A0=A0 --------------------= ---------------->


=A0=A0=A0=A0=A0 UDP Source port: bre Destination port
=A0=A0=A0 --------------------------------------->=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Here I am planning to send RTP P= ackets but instead I get this strange message on my wireshark.

Do an= ybody have an idea where I am making my mistake.


Regards,
Siga



--20cf3054a549b68f5704993e7701-- From keith.drage@alcatel-lucent.com Fri Jan 7 05:23:20 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2569A3A68BD for ; Fri, 7 Jan 2011 05:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.334 X-Spam-Level: X-Spam-Status: No, score=-105.334 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8qhRmx8Yekf for ; Fri, 7 Jan 2011 05:23:19 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id E79A03A683B for ; Fri, 7 Jan 2011 05:23:18 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p07DPN5i010130 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 7 Jan 2011 14:25:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 7 Jan 2011 14:25:23 +0100 From: "DRAGE, Keith (Keith)" To: Siga , "avt@ietf.org" Date: Fri, 7 Jan 2011 14:25:22 +0100 Thread-Topic: [AVT] RTP Protocol cannot be started Thread-Index: AcuuT4vfIquL1SIuTWGJabjcKCFmwwAHoa/g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [AVT] RTP Protocol cannot be started X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 13:23:20 -0000 I would suggest you post your query to: sip-implementors@cs.columbia.edu=20 I suspect you will need to provide details of the SDP offer and answer in t= he SIP messages you show before anyone can provide any meaningful response.= =20 regards Keith ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Siga Sent: Friday, January 07, 2011 9:45 AM To: avt@ietf.org Subject: [AVT] RTP Protocol cannot be started =09 =09 Hi, =09 I have implemented a SIP Client and to extend my project I wrote a RTP Pro= tocol and try to send the RTP packets and when I notice it using wireshark = I get a strange message, let me show it so that you can have better idea =09 CLIENT SERVER =09 SIP Request:INVITE ------------------------------------> =09 =09 SIP Status: 100 Trying <------------------------------------ =09 =09 SIP/SDP Status: 200 OK <------------------------------------ =09 =09 SIP Request:ACK ------------------------------------> =09 =09 UDP Source port: bre Destination port ---------------------------------------> Here I am = planning to send RTP Packets but instead I get this strange message on my w= ireshark. =09 Do anybody have an idea where I am making my mistake. =09 =09 Regards, Siga =09 =09 =09 From keith.drage@alcatel-lucent.com Sat Jan 8 10:06:38 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14AA83A6800 for ; Sat, 8 Jan 2011 10:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.637 X-Spam-Level: X-Spam-Status: No, score=-105.637 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwS3zHZsMY9k for ; Sat, 8 Jan 2011 10:06:37 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id CC7B03A677C for ; Sat, 8 Jan 2011 10:06:36 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p08I8eg6030264 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 8 Jan 2011 19:08:40 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 8 Jan 2011 19:08:40 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Sat, 8 Jan 2011 19:08:38 +0100 Thread-Topic: Guidelines for the use of Variable Bit Rate Audio with Secure RTP Thread-Index: AcuvXxKwuQUl+K/cRz+NVH4ciClV1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [AVT] Guidelines for the use of Variable Bit Rate Audio with Secure RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 18:06:38 -0000 (As WG co-chair) In support of the milestone: Feb 2011 Guidelines for the use of Variable Bit Rate Audio with Secure RTP= as informational (or possibly BCP) This is a WG consensus call to adopt all (or some) of the text of: http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-05.txt to fulfil that milestone. At this stage the text does not have to be regard= ed perfect, the question is more "Does this text form a better basis for co= mpleting the work in the working group that some text yet to be submitted?" Please respond by Monday 18th January with your positions. While the prime intention of this call is to adopt the entire text of the a= uthor draft, if you consider that some of the text is appropriate, but that= some of the text does not form a reasonable start for the work, then pleas= e indicate that text and we will make a separate call on it (and adopt the = rest). regards Keith= From swc@iis.sinica.edu.tw Sun Jan 9 22:07:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5473A6A10 for ; Sun, 9 Jan 2011 22:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vJTFeXQGgYt for ; Sun, 9 Jan 2011 22:07:33 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.10.76]) by core3.amsl.com (Postfix) with ESMTP id 381B53A6A0E for ; Sun, 9 Jan 2011 22:07:32 -0800 (PST) Received: from DHCP-22087.iis.sinica.edu.tw (EHLO ErinPC) ([140.109.22.87]) by gate.sinica.edu.tw (MOS 3.10.10a-GA FastPath queued) with ESMTP id DKW33094; Mon, 10 Jan 2011 14:09:44 +0800 (CST) From: "Sheng-Wei \(Kuan-Ta\) Chen" To: Date: Mon, 10 Jan 2011 14:09:18 +0800 Message-ID: <000e01cbb08c$eafd2600$c0f77200$@sinica.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuwjOm7UecRCqokQMKnBsQSssIuTg== Content-Language: zh-tw x-cr-hashedpuzzle: AFrC A+5N BIKx Bw6T CTZM Dhta Djlh Dp8K ET7U EYj0 EqPt FJHF Fyqe HQ8H Ha02 IvDn; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {E17FA4F8-EF56-4FD8-AB47-4BC747BE9119}; cwB3AGMAQABpAGkAcwAuAHMAaQBuAGkAYwBhAC4AZQBkAHUALgB0AHcA; Mon, 10 Jan 2011 06:09:17 GMT; WwBBAHAAbwBsAG8AZwBpAGUAcwAgAGkAZgAgAHkAbwB1ACAAcgBlAGMAZQBpAHYAZQAgAHQAaABpAHMAIABtAG8AcgBlACAAdABoAGEAbgAgAG8AbgBjAGUAXQA= x-cr-puzzleid: {E17FA4F8-EF56-4FD8-AB47-4BC747BE9119} Subject: [AVT] [Apologies if you receive this more than once] X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:07:34 -0000 [Apologies if you receive this more than once] +++++++++++++++++++++ [ NOSSDAV 2011 Call for Papers ] = +++++++++++++++++++++++ The 21th International Workshop on Network and Operating Systems Support for Digital Audio and Video June 2-3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ NOSSDAV 2011 is the 21th anniversary of SIGMM's leading workshop on = network and operating systems support for digital audio and video. The workshop, = hosted at the University of British Columbia (UBC), will continue to focus on = emerging research topics, controversial ideas, and future research directions in = the area of multimedia systems research. As in previous years, we will maintain the focused single-track format a = setting that stimulates lively discussions among the senior and junior = participants. NOSSDAV encourages experimental research based on real systems and real = data sets. Public availability of the source code and data sets discussed in papers = presented at NOSSDAV is highly encouraged. For NOSSDAV 2011, we will accept papers on broad ranges of topics = related to the transmission and presentation of digital audio/video objects. We are = particularly interested in soliciting articles that discuss system-level support for = distributed social media, as well as papers that focus on enabling multimedia = applications in distributed cloud. Other topics of interest include (but are not = restricted to): * OS, middleware and network support * Overlay networks * Media streaming, distribution and storage support * Web 2.0 systems and social networks * Media sensor and ad hoc networks / embedded systems * Multicore architecture support * Wireless and mobile multimedia systems / network processor support * Networked GPUs, graphics and virtual environments * Networked games / real-time immersive systems * Multimedia communications and system security * Grid/Cloud computing support Please contact the workshop co-chairs to check if your topic is within = the scope of NOSSDAV. Papers will be judged on their relevance, technical content and = correctness, and the clarity of presentation of the research. Papers should not be = under review at another venue nor previously published elsewhere. Submissions should be at most SIX pages, using standard ACM proceedings = style. We expect these submissions to be the kernel of what will eventually = lead to full-length papers at high-quality conferences or journals. Important Dates Paper Submission Deadline: 24 Feb 2011 Decision Notification: 24 Mar 2011 Camera Ready Due: 7 Apr 2011 For more information, please visit the workshop website at http://nss.cs.ubc.ca/nossdav2011/ From swc@iis.sinica.edu.tw Sun Jan 9 22:09:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53473A6A17 for ; Sun, 9 Jan 2011 22:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLjPvye7ttG7 for ; Sun, 9 Jan 2011 22:09:19 -0800 (PST) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.10.76]) by core3.amsl.com (Postfix) with ESMTP id 8289A3A6A12 for ; Sun, 9 Jan 2011 22:09:19 -0800 (PST) Received: from DHCP-22087.iis.sinica.edu.tw (EHLO ErinPC) ([140.109.22.87]) by gate.sinica.edu.tw (MOS 3.10.10a-GA FastPath queued) with ESMTP id DKW33446; Mon, 10 Jan 2011 14:11:32 +0800 (CST) From: "Sheng-Wei \(Kuan-Ta\) Chen" To: Date: Mon, 10 Jan 2011 14:11:07 +0800 Message-ID: <001201cbb08d$2b50bd20$81f23760$@sinica.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuwjSov122s4GLuSU6YX6/kOSoo9w== Content-Language: zh-tw x-cr-hashedpuzzle: w6o= 9zU= AJYG AOOQ A3rL BGzr CRm4 CeQg DOtG Dmfg E01f E8LD JKGv JnuE KJwi Kboo; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {BF60FF5B-8879-445F-B770-6095433BCDF6}; cwB3AGMAQABpAGkAcwAuAHMAaQBuAGkAYwBhAC4AZQBkAHUALgB0AHcA; Mon, 10 Jan 2011 06:11:05 GMT; TgBPAFMAUwBEAEEAVgAgADIAMAAxADEAIABDAGEAbABsACAAZgBvAHIAIABQAGEAcABlAHIAcwA= x-cr-puzzleid: {BF60FF5B-8879-445F-B770-6095433BCDF6} Subject: [AVT] NOSSDAV 2011 Call for Papers X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 06:09:20 -0000 [Apologies if you receive this more than once] +++++++++++++++++++++ [ NOSSDAV 2011 Call for Papers ] = +++++++++++++++++++++++ The 21th International Workshop on Network and Operating Systems Support for Digital Audio and Video June 2-3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ NOSSDAV 2011 is the 21th anniversary of SIGMM's leading workshop on = network and operating systems support for digital audio and video. The workshop, = hosted at the University of British Columbia (UBC), will continue to focus on = emerging research topics, controversial ideas, and future research directions in = the area of multimedia systems research. As in previous years, we will maintain the focused single-track format a = setting that stimulates lively discussions among the senior and junior = participants. NOSSDAV encourages experimental research based on real systems and real = data sets. Public availability of the source code and data sets discussed in papers = presented at NOSSDAV is highly encouraged. For NOSSDAV 2011, we will accept papers on broad ranges of topics = related to the transmission and presentation of digital audio/video objects. We are = particularly interested in soliciting articles that discuss system-level support for = distributed social media, as well as papers that focus on enabling multimedia = applications in distributed cloud. Other topics of interest include (but are not = restricted to): * OS, middleware and network support * Overlay networks * Media streaming, distribution and storage support * Web 2.0 systems and social networks * Media sensor and ad hoc networks / embedded systems * Multicore architecture support * Wireless and mobile multimedia systems / network processor support * Networked GPUs, graphics and virtual environments * Networked games / real-time immersive systems * Multimedia communications and system security * Grid/Cloud computing support Please contact the workshop co-chairs to check if your topic is within = the scope of NOSSDAV. Papers will be judged on their relevance, technical content and = correctness, and the clarity of presentation of the research. Papers should not be = under review at another venue nor previously published elsewhere. Submissions should be at most SIX pages, using standard ACM proceedings = style. We expect these submissions to be the kernel of what will eventually = lead to full-length papers at high-quality conferences or journals. Important Dates Paper Submission Deadline: 24 Feb 2011 Decision Notification: 24 Mar 2011 Camera Ready Due: 7 Apr 2011 For more information, please visit the workshop website at http://nss.cs.ubc.ca/nossdav2011/ From iesg-secretary@ietf.org Mon Jan 10 11:43:31 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7B628C0E4; Mon, 10 Jan 2011 11:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8UnIrp3ttTa; Mon, 10 Jan 2011 11:43:30 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E308428C110; Mon, 10 Jan 2011 11:43:29 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110110194329.11611.49520.idtracker@localhost> Date: Mon, 10 Jan 2011 11:43:29 -0800 Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions' to Proposed Standard (draft-ietf-avt-rtcp-port-for-ssm-04.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:43:32 -0000 The IESG has approved the following document: - 'RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions' (draft-ietf-avt-rtcp-port-for-ssm-04.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtcp-port-for-ssm/ Technical Summary The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. Working Group Summary The document achieved consensus in the AVT working group. Document Quality The document was reviewed by both the AVT and MMUSIC working groups. Personnel Keith Drage is the document shepherd. Robert Sparks is the responsible AD. From csp@csperkins.org Mon Jan 10 13:44:08 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64283A6820 for ; Mon, 10 Jan 2011 13:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ato2bq+os7Qf for ; Mon, 10 Jan 2011 13:44:07 -0800 (PST) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 6E3F83A679C for ; Mon, 10 Jan 2011 13:44:07 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PcPZF-0005ex-lE; Mon, 10 Jan 2011 21:46:21 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DFAF9A1@xmb-sjc-215.amer.cisco.com> Date: Mon, 10 Jan 2011 21:46:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110105152836.A237A3A6C69@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540DFAF9A1@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1082) Cc: avt@ietf.org Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:44:08 -0000 Thanks, these address my comments. Colin On 5 Jan 2011, at 15:36, Ali C. Begen (abegen) wrote: > This has minor fixes Colin pointed out a few days ago. We are not = aware of any remaining open issue and the draft should be ready for the = chairs' review. >=20 > Diff: > = https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp/= history/ >=20 > -acbegen >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Wednesday, January 05, 2011 10:29 AM > To: Ali C. Begen (abegen) > Cc: Dan Wing (dwing); Tom.Van_Caenegem@alcatel-lucent.com > Subject: New Version Notification for = draft-ietf-avt-ports-for-ucast-mcast-rtp-11=20 >=20 >=20 > A new version of I-D, draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt = has been successfully submitted by Ali Begen and posted to the IETF = repository. >=20 > Filename: draft-ietf-avt-ports-for-ucast-mcast-rtp > Revision: 11 > Title: Port Mapping Between Unicast and Multicast RTP = Sessions > Creation_date: 2011-01-05 > WG ID: avt > Number_of_pages: 35 >=20 > Abstract: > This document presents a port mapping solution that allows RTP > receivers to choose their own ports for an auxiliary unicast session > in RTP applications using both unicast and multicast services. The > solution provides protection against denial-of-service or packet > amplification attacks that could be used to cause one or more RTP > packets to be sent to a victim client. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From petithug@acm.org Mon Jan 10 14:04:57 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D572D3A63D2 for ; Mon, 10 Jan 2011 14:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EAu4cyeqOwy for ; Mon, 10 Jan 2011 14:04:56 -0800 (PST) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 947353A63CA for ; Mon, 10 Jan 2011 14:04:56 -0800 (PST) Received: by server.implementers.org (Postfix, from userid 1001) id B7EF711BC401E; Mon, 10 Jan 2011 22:07:10 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 241E811BC401C for ; Mon, 10 Jan 2011 22:07:10 +0000 (UTC) Message-ID: <4D2B830C.4030706@acm.org> Date: Mon, 10 Jan 2011 14:07:09 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: avt@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [AVT] Support for multiple clock rates in an RTP session X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 22:04:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just released a new version of this draft: http://www.ietf.org/internet-drafts/draft-petithuguenin-avt-multiple-clock-rates-03.txt I presented this draft during IETF 77, seeking WG adoption for this work. There was a positive response, but unfortunately the WG workload was too high at the time for this. So would the WG be interested to adopt this (I can present again in Prague) this time, or should I try another way to have this published? Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk0rgwsACgkQ9RoMZyVa61c7FACgoN7r3sspM0lq8sDCS/TECv1P YpUAmwSaIsWGlKgjbSNmjmkyD9F+IeGQ =HXbp -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Mon Jan 10 16:45:02 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2AA3A684E; Mon, 10 Jan 2011 16:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrwV16ViCrJX; Mon, 10 Jan 2011 16:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B1F3A67ED; Mon, 10 Jan 2011 16:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111004501.1637.43557.idtracker@localhost> Date: Mon, 10 Jan 2011 16:45:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-cnames-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 00:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author(s) : A. Begen, et al. Filename : draft-ietf-avt-rtp-cnames-04.txt Pages : 11 Date : 2011-01-10 The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-cnames-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-cnames-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-10164203.I-D@ietf.org> --NextPart-- From frans.de.bont@philips.com Tue Jan 11 01:47:36 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3033A69F8 for ; Tue, 11 Jan 2011 01:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.615 X-Spam-Level: X-Spam-Status: No, score=-3.615 tagged_above=-999 required=5 tests=[AWL=-2.316, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plMULv3sjYQP for ; Tue, 11 Jan 2011 01:47:33 -0800 (PST) Received: from AM1EHSOBE003.bigfish.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by core3.amsl.com (Postfix) with ESMTP id 7CE2E3A6975 for ; Tue, 11 Jan 2011 01:47:32 -0800 (PST) Received: from mail55-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 09:49:48 +0000 Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1-R.bigfish.com (Postfix) with ESMTP id 13A531BF8566; Tue, 11 Jan 2011 09:49:48 +0000 (UTC) X-SpamScore: -57 X-BigFish: VPS-57(zzbb2cK15d6O9251J542N1432N217bL9371P10d1Izz1202hzz8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLAMSEXE03.connect1.local; RD:smtpx.philips.com; EFVD:NLI Received: from mail55-am1 (localhost.localdomain [127.0.0.1]) by mail55-am1 (MessageSwitch) id 1294739379993368_970; Tue, 11 Jan 2011 09:49:39 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.248]) by mail55-am1.bigfish.com (Postfix) with ESMTP id DA718E0004F; Tue, 11 Jan 2011 09:49:39 +0000 (UTC) Received: from NLAMSEXE03.connect1.local (168.87.56.20) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 09:49:37 +0000 Received: from NLHILEXH02.connect1.local (172.16.153.92) by connect1.philips.com (172.16.156.42) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 11 Jan 2011 10:49:41 +0100 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by NLHILEXH02.connect1.local ([172.16.153.92]) with mapi; Tue, 11 Jan 2011 10:49:37 +0100 From: "Bont, Frans de" To: "DRAGE, Keith (Keith)" , "avt@ietf.org" Date: Tue, 11 Jan 2011 10:49:30 +0100 Thread-Topic: WGLC on draft-ietf-avt-rfc3016bis Thread-Index: AcuLFsBeOQY1OiawTUaiQTw9W2XKpQJiYaWgBzAEjjA= Message-ID: <19FE62CE8D62CF4B96C845DC556B88137D2029BB8E@NLCLUEXM01.connect1.local> References: <00e201cb8b16$c634edd0$529ec970$%roni@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "draft-ietf-avt-rfc3016bis.all@tools.ietf.org" Subject: Re: [AVT] WGLC on draft-ietf-avt-rfc3016bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:47:36 -0000 Hi Keith, Thanks for your extensive review. Please find our comments below in-line. Best regards, Frans > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of DRA= GE, > Keith (Keith) > Sent: 2010 Dec 06 12:59 AM > To: avt@ietf.org > Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org > Subject: Re: [AVT] WGLC on draft-ietf-avt-rfc3016bis > > I've reviewed the document, comments as follows > > 1) This document has inherited a considerable problem from the previ= ous > RFC 3016, in that much of that document is written with strange RFC 2119 > usage, and pretty much entirely in the passive case. How readers assess > conformance to this document I don't know. However, given that anyone who= is > going to implement these parts of RFC 3016 will presumably already have d= one > so, I have limited my comments on this part to areas where I think the > requirements are totally unclear, and specifically tagged them as on the > existing text. If anyone thinks it would be useful to go further, then I = can > certainly submit a large number of further comments on the existing text,= but > they are not included here. The purpose of this document is mainly to correct some errors in RFC 3016, = and to provide an extension to signal the presence of MPEG Surround audio d= ata. Indeed existing users will use this, so we see no need to go much furt= her with the level of the comments. > 2) (Editorial). Abstract. > > Comments are solicited and should be addressed to the working group's > mailing list at avt@ietf.org and/or the author(s). > > Delete this text. I don't know why people include this in an internet-dra= ft in > the first place, given that it states the obvious, and it is not needed i= n the > RFC. Will be deleted, Roni made the same comment. > 3) (Existing text). Section 1.1 > > The fragmentation rule recommends not to map more than one VOP in an > RTP packet so that the RTP timestamp uniquely indicates the VOP time > framing. On the other hand, MPEG-4 video may generate VOPs of very > small size, in cases with an empty VOP (vop_coded=3D0) containing only > VOP header or an arbitrary shaped VOP with a small number of coding > blocks. To reduce the overhead for such cases, the fragmentation > rule permits concatenating multiple VOPs in an RTP packet. (See > fragmentation rule (4) in section 3.2 and marker bit and timestamp in > section 3.1.) > > The use of recommends here is a pseudo quote from later in the document. = It > would be better if it was a real quote as in the previous paragraph, thus= it > should be modified as follows, > > The fragmentation rule "Different VOPs SHOULD be fragmented into diffe= rent > RTP packets" is made > so that the RTP timestamp uniquely indicates the VOP time > framing. On the other hand, MPEG-4 video may generate VOPs of very > small size, in cases with an empty VOP (vop_coded=3D0) containing only > VOP header or an arbitrary shaped VOP with a small number of coding > blocks. To reduce the overhead for such cases, the fragmentation > rule permits concatenating multiple VOPs in an RTP packet. (See > fragmentation rule (4) in section 3.2 and marker bit and timestamp in > section 3.1.) Agreed. > 4) (Existing text). Section 1.2 > > in RTP transmission there is no need for the last two features. > Therefore, these two features MUST NOT be used in applications based > on RTP packetization specified by this document. Since LATM has been > developed for only natural audio coding tools, i.e., not for > synthesis tools, it seems difficult to transmit Structured Audio (SA) > data and Text to Speech Interface (TTSI) data by LATM. Therefore, SA > data and TTSI data MUST NOT be transported by the RTP packetization > in this document. > > Section 1.2 is an introductory section. Therefore it is inappropriate to = start > introducing RFC 2119 language at this stage. As far as I can see, these > requirements are not elsewhere in the document, so we will need to create= a > place for them. I suggest a new section 3 immediate before the existing > section 3, and renumber accordingly (given that the numbering of the exis= ting > RFC 3016 has not been preserved. A new section 3 will be created. > Similar considerations apply to the following two paragraphs: > > For transmission of scalable streams, audio data of each layer SHOULD > be packetized onto different RTP streams allowing for the different > layers to be treated differently at the IP level, for example via > some means of differentiated service. On the other hand, all > configuration data of the scalable streams are contained in one LATM > configuration data "StreamMuxConfig" and every scalable layer shares > the StreamMuxConfig. The mapping between each layer and its > configuration data is achieved by LATM header information attached to > the audio data. In order to indicate the dependency information of > the scalable streams, the signaling mechanism as specified in > [RFC5583] SHOULD be used (see section 4.2). This paragraph will be added to the new section 3. > For MPEG-4 Audio coding tools, as is true for other audio coders, if > the payload is a single audio frame, packet loss will not impair the > decodability of adjacent packets. Therefore, the additional media > specific header for recovering errors will not be required for MPEG-4 > Audio. Existing RTP protection mechanisms, such as Generic Forward > Error Correction (RFC 5109 [RFC5109]) and Redundant Audio Data (RFC > 2198 [RFC2198]), MAY be applied to improve error resiliency. As this paragraph doesn't contain RFC 2119 language we feel that this parag= raph can stay in the introduction. > 5) Section 1.3. > > I first looked for this at the end of the document, in some kind of appen= dix, > because that is where I expected to find it, and I wanted to check this f= irst. > So my first comment is that while there is no rule on this, I would prefe= r it > to appear at the end of the document. Will be moved to the end of the document. > 6) Section 1.3. > > I do not think the list as currently drafted gives a very good indication= to > existing implementors at what they need to look at in order to update the= ir > implementations. This should be redrafted to identify key things that are > revised implementation will need to look at. For example: > > o The audio parameter "SBR-enabled" is not defined within RFC 3016 > but used by 3GPP > > should become something like: > > o The use of an audio parameter "SBR-enabled" is now defined in this > document, which is used by 3GPP implementations [informative reference to= 3GPP > specification here]. Agreed. > 6) Section 1.3. For the text: > > Furthermore some comments have been addressed and signaling support > for MPEG surround [23003-1] was added. It should be noted that the > audio payload format described here has some known limitations. For > new system designs RFC 3640 [RFC3640] is recommended. > > Remove the contruct "It should be noted that the". It is mixing material = that > could be confused as normative with definitely informative material. Agreed. > It is also unclear how RFC 3640 is recommended, as the reference is > informative, and this is the only place it is referenced. I assume you me= an > that new implementations would not be using this document at all. But tha= t > surely should be called out in the Abstract of this document. The last two sentences of this paragraph will be moved to the Abstract. > 7) Section 2 (Editorial) > > This memo makes use of terms, specified in [14496-2], [14496-3], and > [23003-1]. In addition, the following terms are used in this > document and have specific meaning within the context of this > document. > > Change to: > > This document makes use of terms, specified in [14496-2], [14496-3], a= nd > [23003-1]. In addition, the following terms are used in this > document and have specific meaning within the context of this > document. Agreed. > 8) Section 3 (Existing text) > > This section specifies RTP packetization rules for MPEG-4 Visual > content. An MPEG-4 Visual bitstream is mapped directly onto RTP > packets without the addition of extra header fields or any removal of > Visual syntax elements. The Combined Configuration/Elementary stream > mode MUST be used so that configuration information will be carried > to the same RTP port as the elementary stream. (see 6.2.1 "Start > codes" of ISO/IEC 14496-2 [14496-2]) The configuration information > MAY additionally be specified by some out-of-band means. If needed > for an H.323 terminal, H.245 codepoint > "decoderConfigurationInformation" MUST be used for this purpose. If > needed by systems using Media Type parameters and SDP parameters, > e.g., SIP and RTSP, the optional parameter "config" MUST be used to > specify the configuration information (see 5.1 and 5.2). > > The abbreviation "e.g." means for example, and "MUST" can never be and > example. I supect the example here is only the string "e.g., SIP and RTSP= " so > I suggest that this bit is placed in parenthesis, as follows: "(e.g., SIP= and > RTSP)" You are correct, the draft will be updated accordingly. > 9) Section 3.2 (Existing text). In the following text: > > (5) It is RECOMMENDED that a single video packet is sent as a single > RTP packet. The size of a video packet SHOULD be adjusted in such a > way that the resulting RTP packet is not larger than the path-MTU. > Note: Rule (5) does not apply when the video packet is disabled by > the coder configuration (by setting resync_marker_disable in the VOL > header to 1), or in coding tools where the video packet is not > supported. In this case, a VOP MAY be split at arbitrary byte- > positions. > > remove the mix of the word "note" with normative text. I suggest: > > (5) It is RECOMMENDED that a single video packet is sent as a single > RTP packet. The size of a video packet SHOULD be adjusted in such a > way that the resulting RTP packet is not larger than the path-MTU. > If the video packet is disabled by > the coder configuration (by setting resync_marker_disable in the VOL > header to 1), or in coding tools where the video packet is not > supported, a VOP MAY be split at arbitrary byte- > positions. Agreed. > 10) Section 3.3 (Existing text. In the following text: > > When concatenating more than one video packets into an RTP packet, > VOP header or video_packet_header() shall not be placed in the middle > of the RTP payload. The packetization as in (b) is not allowed by > criterion (2) due to the aspect of the error resiliency. Comparing > this example with Figure 2(d), although two video packets are mapped > onto two RTP packets in both cases, the packet-loss resiliency is not > identical. Namely, if the second RTP packet is lost, both video > packets 1 and 2 are lost in the case of Figure 3(b) whereas only > video packet 2 is lost in the case of Figure 2(d). > > is the "shall" here denoting a requirements (in which case it should be > capitalised and replaced with "MUST", and moved to a section that is not > titled "Example") or is it denoting something else, e.g. an impossibility= , in > which case change the modal auxiliary to something else. The requirements used here are already listed in (old) section 3.2 ".. is p= rohibited by criterion of 3.2". The "shall not be placed" will be replaced by "are not allowed to be placed= ". > 11) Section 4.2, 1st paragraph: > > Payload Type (PT): The assignment of an RTP payload type for this new > packet format is outside the scope of this document, and will not be > specified here. It is expected that the RTP profile for a particular > class of applications will assign a payload type for this encoding, > or if that is not done then a payload type in the dynamic range shall > be chosen by means of an out-of-band signaling protocol (e.g., H.245, > SIP, etc). In the dynamic assignment of RTP payload types for > scalable streams, a different value SHOULD be assigned to each layer. > The dependency relationships between the enhance layer and the base > layer SHOULD be signaled as specified in [RFC5583]. An example of > the use of such signaling for scalable audio streams can be found in > [RFC5691]. > > Write the above new text in the active, i.e. "In the dynamic assignment o= f RTP > payload types for scalable streams, the server SHOULD assign a different = value > to each layer. The server SHOULD signal ...". Agreed. > Under what circumstances does the "SHOULD" not apply. It is good practice= when > using "SHOULD" to give guidance tot he reader of the conditions under whi= ch it > is safe to ignore the requirement. Otherwise may implementors treat the w= ord > as a straight option and ignore it. Will be changed into "SHALL". > It is also noted that a requirement specifying the assignment of the payl= oad > type is inconsistent with the first sentence, which says "assignment of a= n RTP > payload type for this new packet format is outside the scope of this > document". This sentence will therefore need to be altered. Will be changed into "... is outside the scope of this document, and will o= nly be restricted here.". > 12) Section 4.2 (Existing text). Is the following meant to be normati= ve: > > Timestamp: The timestamp indicates the sampling instance of the first > audio frame contained in the RTP packet. Timestamps are recommended > to start at a random value for security reasons. > > It is currently drafted as such, but "recommended" is lower case. Will be made upper case. > 13) Section 4.3 (Existing text). What is the meaning of the final > sentence: > > If it cannot, the audioMuxElement MAY > be fragmented and spread across multiple packets. > > As written it is telling me I have an option to fragment it and spread it > across multiple packets. Is that what is meant. Indeed, there is no option. The "MAY" will be changed into "SHALL". > 14) Section 5.1. The following text: > > Note, any unspecified parameter MUST be ignored by the receiver to > ensure that additional parameters can be added in any future revision > of this specification. > > has the word "MUST" mandatory requirement, following the word "note" whic= h > many people interpret as informative. Assuming a mandatory requirement is > meant, delete the word "Note". The text should also be redrafted in the > active, e.g.: > > The receiver MUST ignore any unspecified parameter, to > ensure that additional parameters can be added in any future revision > of this specification. Agreed. > This is also a registration section. Surely normative requirements on the > implementation should be elsewhere in the document, so I suggest this tex= t is > moved to another more appropriate section. We checked RFC 3640 and it has this text also in the registration section. = Not sure where else to place this text. > 15) Section 5.1. > > Published specification: > > The specifications for MPEG-4 Visual streams are presented in ISO/ > IEC 14469-2 [14496-2]. The RTP payload format is described in RFC > XXXX. > > Why not just say: "The RTP payload format is described in this document." > > Same change for the following two entries, and also in section 5.3. Agreed. > 16) Section 5.3, 5.4.1.3 and 5.4.1.4. This document does not define t= he > coding of the SBR-enabled parameter. I get the impression from reading th= e > document that it is defined elsewhere, but no reference is made to the po= int > where it is defined. That would surely need to be a normative reference. The "SBR-enabled" parameter is defined as a boolean parameter in 5.3. Do we= miss your point? > 17) Section 5.3. > > Note, any unspecified parameter MUST be ignored by the receiver to > ensure that additional parameters can be added in any future revision > of this specification. > > See comments on similar text at the start of section 4.1. And our response at 14) > 18) Section 5.3 (Existing text): > > Required parameters: > > rate: the rate parameter indicates the RTP time stamp clock rate. > The default value is 90000. Other rates MAY be specified only if > they are set to the same value as the audio sampling rate (number > of samples per second). > > Change "specified" to "indicated". The AVT working group is the specifier= . Agreed. > 19) Section 5.3 (Existing text). There are a number of lower case "sh= all" > here. Do these constitute requirements. How is the reader of this > specification expected to understand and interpret them. > > If they are not requirements, then change them. Will be made upper case. > 19) Section 5.3 (existing text) > > MPS-profile-level-id: a decimal representation of the MPEG > Surround Profile Level indication as defined in ISO/IEC 14496-3 > [14496-3]. This parameter indicates the MPEG Surround profile and > level that the decoder must be capable in order to decode the > stream. > > What is the meaning of the final sentence? This sentence will be modified into. "This parameter indicates the support of the MPEG Surround profile and leve= l by the decoder to be capable to decode the stream." > 20) Section 5.3 (existing text) > > ptime: RECOMMENDED duration of each packet in milliseconds. > > Why is this a requirement. Hows does an implementation conform to it. "RECOMMENDED" will be removed. > 21) Section 5.3 > > If this parameter is set to 0, a decoder SHALL expect that SBR is > not used. If this parameter is set to 1, a decoder SHOULD > upsample the audio data with the SBR tool, regardless whether SBR > data is present in the stream or not. > > First sentence is not written as a conformable requirement. What does the > decoder need to do to conform? For the second sentence, see comments earl= ier > on use of SHOULD. The SHALL and SHOULD will be replaced by MAY and CAN, respectively. > 22) Section 5.3 > > If the presence of SBR can not be detected from out-of-band > configuration and the SBR-enabled parameter is not present, the > parameter defaults to 1 for an SBR-capable decoder. If the > resulting output sampling rate or the computational complexity is > not supported, the SBR tool may be disabled or run in downsampled > mode. > > Change "may" to "can" to indicate that it is definitely not a conformance > requirement. Agreed. > 23) Section 5.4.1.3 > > In this example, the presence of SBR can not be determined by the SDP > parameter set. The clock rate represents the core codec sampling > rate. An SBR enabled decoder SHOULD use the SBR tool to upsample the > audio data if complexity and resulting output sampling rate permits. > > This section is entitled "Example". Such sections ideally should not incl= ude > conformable requirements. So if this is a requirement then move it somewh= ere > else. Also comments elsewhere about the use of SHOULD also apply here. The "SHOULD" will be replaced by "can", as it is not a requirement. > 24) Section 5.4.1.4 > > In this example, the clock rate is still 24000 and this information > should be used for RTP timestamp calculation. The value of 24000 is > used to support old AAC decoders. This makes the decoder supporting > only AAC understand the HE AAC coded data, although only plain AAC is > supported. A HE AAC decoder is able to generate output data with the > SBR sampling rate. > > Change "should be" to "is" to avoid confusion with a conformable requirem= ent. Agreed. > 25) Section 6. > > This memo defines additional optional format parameters to the Media > Type "audio" and its subtype "MP4A-LATM", as defined in RFC XXXX. > The Media Type parameters are defined in sections 5.1 and 5.3 of RFC > XXXX. > > Just say "sections 5.1 and 5.3 of this document". A similar comment was made by Roni. The proposal is to change it into. This document updates the media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in Section 6.1 and Section 6.3 of this document. > 26) Section 6.1. > > This memo defines the following additional optional parameters which > SHOULD be used if SBR or MPEG Surround data is present inside the > payload of an AAC elementary stream. > > We do not need a SHOULD (or any other RFC 2119 language in relation to an= IANA > considerations section. > > I suspect this is just superfluous, and not a real conformable requiremen= t on > implementations. (old) Sections 6.1 and 6.2 will be removed, see a comment made by Roni. > 27) Section 6 > > An IANA considerations section should basically consists of a set of > instructions to IANA as to what they need to include in their tables. See > http://www.iana.org/protocols/ > > I cannot ascertain from this section whether they need to do work. > > Are there any existing RFC 3013 registrations where the reference needs t= o be > updated? > > Are there any of these parameters that actually need registration? See our remark at 25) > > > regards > > Keith > > > ________________________________ > > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Tuesday, November 23, 2010 2:00 PM > To: avt@ietf.org > Cc: DRAGE, Keith (Keith); draft-ietf-avt-rfc3016bis.all@tools.iet= f.org > Subject: WGLC on draft-ietf-avt-rfc3016bis > > > > Hi, > > I would like to start a working group last call on > http://tools.ietf.org/html/draft-ietf-avt-rfc3016bis-01 > > > > RTP Payload Format for MPEG-4 Audio/Visual Streams > > > > The WGLC will end on December 13th , 2010 > > Please review the draft and send comments to the list > > > > Note that section 1.3 and 1.4 discuss the changes from RFC3016 > > > > Roni Even > > AVT co- ass=3DMsoNormal> > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Internet-Drafts@ietf.org Tue Jan 11 02:00:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508B73A6A34; Tue, 11 Jan 2011 02:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-4TdjPiMXxM; Tue, 11 Jan 2011 02:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0845E3A6A13; Tue, 11 Jan 2011 02:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111100002.11229.17920.idtracker@localhost> Date: Tue, 11 Jan 2011 02:00:02 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MPEG-4 Audio/Visual Streams Author(s) : M. Schmidt, et al. Filename : draft-ietf-avt-rfc3016bis-02.txt Pages : 32 Date : 2011-01-11 This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). The audio payload format described in this document has some limitations. for new system designs [RFC3640] is preferred. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rfc3016bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11015213.I-D@ietf.org> --NextPart-- From frans.de.bont@philips.com Tue Jan 11 02:57:40 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F69B28C26E for ; Tue, 11 Jan 2011 02:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R63ziQ1krpb6 for ; Tue, 11 Jan 2011 02:57:39 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by core3.amsl.com (Postfix) with ESMTP id 2203828C100 for ; Tue, 11 Jan 2011 02:57:38 -0800 (PST) Received: from mail30-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.8; Tue, 11 Jan 2011 10:59:54 +0000 Received: from mail30-tx2 (localhost.localdomain [127.0.0.1]) by mail30-tx2-R.bigfish.com (Postfix) with ESMTP id 12F6B3181BD for ; Tue, 11 Jan 2011 10:59:54 +0000 (UTC) X-SpamScore: -63 X-BigFish: VPS-63(zz15d6O9251J936eK542N1432N14ffO217bL9371Pzz1202hzz8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:NLHILEXE01.connect1.local; RD:smtpx.philips.com; EFVD:NLI Received: from mail30-tx2 (localhost.localdomain [127.0.0.1]) by mail30-tx2 (MessageSwitch) id 1294743593659129_13282; Tue, 11 Jan 2011 10:59:53 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.240]) by mail30-tx2.bigfish.com (Postfix) with ESMTP id 9445C159804F for ; Tue, 11 Jan 2011 10:59:53 +0000 (UTC) Received: from NLHILEXE01.connect1.local (168.87.56.20) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 11 Jan 2011 10:59:53 +0000 Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.150) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 11 Jan 2011 11:59:37 +0100 Received: from NLCLUEXM01.connect1.local ([172.16.153.50]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Tue, 11 Jan 2011 11:59:38 +0100 From: "Bont, Frans de" To: "avt@ietf.org" Date: Tue, 11 Jan 2011 11:59:30 +0100 Thread-Topic: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-02.txt Thread-Index: AcuxdqeziI0lHYuqTiKRzpa7shFyMgAB7iLw Message-ID: <19FE62CE8D62CF4B96C845DC556B88137D2029BC0F@NLCLUEXM01.connect1.local> References: <20110111100002.11229.17920.idtracker@localhost> In-Reply-To: <20110111100002.11229.17920.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 10:57:40 -0000 Hi all, The WGLC ended last month and a number of reviews have been received, thanks for those. We have responded to the individual reviews on the list and have updated the draft accordingly. The new draft has been submitted and can be found using the link in the announcement below. Below a summary of the major changes. 1. The paragraphs including RFC 2119 keywords have been moved from the Introduction to a new section entitled "LATM Restrictions for RTP Packetization of MPEG-4 Audio Bitstreams". 2. The restrictions on the RTP packet format for MPEG-4 Audio bitstreams has been updated to make them better readable and unambiguous. 3. The IANA considerations section has been reduced to what is really needed. 4. The Security Considerations section been updated with text from recent payload format RFC's. 5. The differences with respect to RFC 3016 have been moved to a new section at the end of the draft. 6. An ackowledgement section has been added. Your comments are welcome! Best regards, Frans > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: 2011 Jan 11 11:00 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVT] I-D Action:draft-ietf-avt-rfc3016bis-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Working Group of t= he > IETF. > > > Title : RTP Payload Format for MPEG-4 Audio/Visual Stream= s > Author(s) : M. Schmidt, et al. > Filename : draft-ietf-avt-rfc3016bis-02.txt > Pages : 32 > Date : 2011-01-11 > > This document describes Real-Time Transport Protocol (RTP) payload format= s for > carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using = MPEG- > 4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitst= reams > onto RTP packets, it provides specifications for the use of RTP header fi= elds > and also specifies fragmentation rules. It also provides specifications = for > Media Type registration and the use of Session Description Protocol (SDP)= . > The audio payload format described in this document has some limitations. > for new system designs [RFC3640] is preferred. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc3016bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Internet-Drafts@ietf.org Tue Jan 11 04:30:05 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D9228C270; Tue, 11 Jan 2011 04:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfY0IN3Rmazu; Tue, 11 Jan 2011 04:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6EE28C11E; Tue, 11 Jan 2011 04:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111123002.22708.97991.idtracker@localhost> Date: Tue, 11 Jan 2011 04:30:02 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-ipmr-15.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 12:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for IP-MR Speech Codec Author(s) : D. Yudin Filename : draft-ietf-avt-rtp-ipmr-15.txt Pages : 20 Date : 2011-01-11 This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the real-time transport protocol (RTP). The payload format supports transmission of multiple frames per packet and introduced redundancy for robustness against packet loss and bit errors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-ipmr-15.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-ipmr-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11041505.I-D@ietf.org> --NextPart-- From albrecht.schwarz@alcatel-lucent.com Tue Jan 11 07:17:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601E128C299 for ; Tue, 11 Jan 2011 07:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsZoa17m7x5D for ; Tue, 11 Jan 2011 07:17:14 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 8672C28C18B for ; Tue, 11 Jan 2011 07:17:13 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0BFJQEI029329 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Jan 2011 16:19:27 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.53]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 11 Jan 2011 16:19:26 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "Belling, Thomas (NSN - DE/Munich)" , IETF AVT WG , Magnus Westerlund Date: Tue, 11 Jan 2011 16:19:26 +0100 Thread-Topic: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? Thread-Index: AcuhNAsmlspD8taLSQKcFIXkclH6fQQbm3rA Message-ID: <5F7BCCF5541B7444830A2288ABBEBC961D4FED0874@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC961D4FED0874FRMRSSXCHMBSD_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "PALAT, Sudeep \(Sudeep\)" , "LANDAIS, BRUNO \(BRUNO\)" Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:17:21 -0000 --_000_5F7BCCF5541B7444830A2288ABBEBC961D4FED0874FRMRSSXCHMBSD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >It would be quite helpful to have it available for the upcoming SA4 meetin= g. Thomas, there wasn't any update nor any ECN contribution to SA4#62 this wee= k, right? Thanks, Albrecht ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Belli= ng, Thomas (NSN - DE/Munich) Sent: Dienstag, 21. Dezember 2010 18:26 To: IETF AVT WG; Magnus Westerlund Subject: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-fai= th initialisation? Dear Magnus, allow me to continue a discussion we had about a month ago. You were suggesting that the leap of faith initialisation method requires A= VPF because this allows XR ECN summary reports can then be sent quicker and= shorter reporting interval than the average 5secs can be negotiated. Corre= ct? The draft contains the following related procedure in 6.2.3: If the sender marks all packets as ECT while transmitting on a path that contains an ECN-blocking middlebox, then receivers downstream of that middlebox will not receive any RTP data packets from the sender, and hence will not consider it to be an active RTP SSRC. The sender can detect this and revert to sending packets without ECT marks, since RTCP SR/RR packets from such receivers will either not include a report for sender's SSRC, or will report that no packets have been received, but this takes at least one RTCP reporting interval. It should be noted that a receiver might generate its first RTCP packet immediately on joining a unicast session, or very shortly after joining a RTP/AVPF session, before it has had chance to receive any data packets. A sender that receives RTCP SR/RR packet indicating lack of reception by a receiver SHOULD therefore wait for a second RTCP report from that receiver to be sure that the lack of reception is due to ECT-marking. Since this recovery process can take several tens of seconds, during which time the RTP session is unusable for media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation method be used in environments where ECN-blocking middleboxes are likely to be present. So there is no particular trigger for the receiver to sent SR/RR reports th= at would allow it to benefit from the more flexible timing rules of AVPF. One could think about using the AVPF early RTCP feedback if the sender does= not receive any packets for a while at call setup, but the duration is qui= te open and it might also be part of normal operation that no packets are r= eceived - consider early media that are usually only transmitted in backwar= d direction as an example. You suggested to negotiate a higher RTCP transmission rate as a remedy. In = my understanding this would work both with AVP and AVPF using SDP RTCP band= width modifiers. But I am not convinced this is a good idea given the extra required bandwid= th. There is a clear wording already that the leap of faith method is not = recommended in environments where ECN-blocking middleboxes are likely to be= present. It is really meant for operator controlled environments where suc= h problems will hardly occur. Is it really worth spending more bandwidth to= improve the handling of a very unlikely event? If there is a real risk tha= t ECN-marked packets are blocked in a network, other initialisation methods= are preferable anyway. As said, I also still doubt that you would have any benefit from AVPF for t= hat initialisation method. But even I only fail to understand the advantage= s you had in mind (do you assume some particular receiver behaviour describ= ed nowhere up to now?), I doubt this would be worth the extra complexity, = only to improve the handling of a very unlikely error. Again, in an networ= k where there is a real risk that ECN-marked packets are blocked, other ini= tialisation methods are preferable anyway. As an unrelated question, are you working on an update of the draft? It would be quite helpful to have it available for the upcoming SA4 meeting= . I would also welcome if you could share the draft with me for a quick rev= iew before distributing it further, at least if time allows. Regards, Thomas --_000_5F7BCCF5541B7444830A2288ABBEBC961D4FED0874FRMRSSXCHMBSD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of= -faith initialisation?
>It would be quite = helpful to have it available = for the=20 upcoming SA4 meeting.
 
Thomas, there wasn't any update nor any ECN contri= bution to=20 SA4#62 this week, right?
 
Thanks,
Albrecht

From: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] On Behalf Of Belling, Thomas (NSN -= =20 DE/Munich)
Sent: Dienstag, 21. Dezember 2010 18:26
To:=20 IETF AVT WG; Magnus Westerlund
Subject: [AVT]=20 draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith=20 initialisation?

Dear Magnus,

allow me=20 to continue a discussion we had<= SPAN=20 lang=3Den-gb> about a month ago.

Yo= u<= FONT=20 face=3DCalibri> were suggesting that the leap of faith initialisation=20 me<= FONT=20 face=3DCalibri>thod requires AVPF because this allows XR = ECN summary=20 reports can then be sent quicker and shorter=20 reporting interval than the=20 average 5secs can be negotiated.=20 Correct?

The draft=20 contains the following related procedure in 6.2.3:

  <= /SPAN> = If the sender=20 marks all packets as ECT while transmitting on a path

 = ;  that=20 contains an ECN-blocking middlebox, then receivers downstream=20 of

 = ;  that=20 middlebox will not receive any RTP data packets from the=20 sender,

 = ;  and=20 hence will not consider it to be an active RTP SSRC.  The=20 sender

 = ;  can=20 detect this and revert to sending packets without ECT marks,

 = ;  since=20 RTCP SR/RR packets from such receivers will either not=20 include

 = ;  a=20 report for sender's SSRC, or will report that no packets have=20 been

 = ; =20 received, but this takes at least one RTCP reporting interval. =20 It

 = ; =20 should be noted that a receiver might generate its first RTCP=20 packet

 = ; =20 immediately on joining a unicast session, or very shortly=20 after

 = ; =20 joining a RTP/AVPF session, before it has had chance to receive=20 any

 = ;  data=20 packets.  A sender that receives RTCP SR/RR packet=20 indicating

 = ;  lack=20 of reception by a receiver SHOULD therefore wait for a=20 second

 = ;  RTCP=20 report from that receiver to be sure that the lack of=20 reception

 = ;  is=20 due to ECT-marking.  Since this recovery process can take=20 several

 = ;  tens=20 of seconds, during which time the RTP session is unusable=20 for

 = ; =20 media, it is NOT RECOMMENDED that the leap-of-faith ECT=20 initiation

 = ; =20 method be used in environments where ECN-blocking middleboxes=20 are

   likely to be present.

So there is=20 no particular trigger for the receiver to=20 sent SR/RR reports that would allow it to=20 benefit=20 from the more flexible timing rules of AVPF.

One could think abou= t=20 using the AVPF=20 early RTCP feedback if the sender does not=20 receive any packets for a while at call setup, but the durati= on is quite=20 open and it might also be part of normal operation that= =20 no packets are received –<= /SPAN>=20 consider early media that are usually only transmitted in backward= =20 direction as an example.

You=20 suggested to negotiate a higher RTCP transmission r= ate as=20 a remedy. In my understanding this would work both with AVP and AVP= F=20 using<= FONT=20 face=3DCalibri> SDP RTCP bandwidth modifiers.<= /SPAN>

But I am=20 not convinced this is a good idea given the extra require= d=20 bandwidth.= There is a clea= r=20 wording already that the leap of faith method=20 is not  recommended in environments where ECN-blocking middleboxes are likely to be present= . It is really meant for operator controlled=20 environments where such problems will hardly occur.=20 Is it really wor<= SPAN=20 lang=3Den-gb>th spending more bandwidth to improve the = handling of=20 a very unlikely <= FONT=20 face=3DCalibri>event? If there is a r= eal risk=20 that ECN-marked packets are blocked in<= SPAN=20 lang=3Den-gb> a network, other initiali= sation=20 methods are preferable anyway.

As said, I=20 also still doubt that you would have any benefit from=20 AVPF for that=20 initialisation method.<= SPAN=20 lang=3Dde> But even I= only fail to understand the advantages = you had=20 in mind (d<= FONT=20 face=3DCalibri>o you assume some particul= ar receiver behaviour described = nowhere up=20 to now?<= FONT=20 face=3DCalibri>),  I doubt this would=20 be worth the=20 extra complexity<= FONT=20 face=3DCalibri>, only to improve  the handling of a very unlikely= =20 error.=20 Again, in an network where there is a real= risk that=20 ECN-marked packets are blocked, other initialisation methods are pref= erable=20 anyway.

As an unrelated ques= tion, are=20 you working on an update of the draft?

It would=20 be quite helpful <= FONT=20 face=3DCalibri>to have it available for the upcoming SA4 meeting. I=20 would also welcome if you could share the dra= ft with=20 me for a quick review before distributing it further, at least if time=20 allows.

Regards,=20 Thomas

--_000_5F7BCCF5541B7444830A2288ABBEBC961D4FED0874FRMRSSXCHMBSD_-- From keith.drage@alcatel-lucent.com Tue Jan 11 07:46:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B403428C2AA for ; Tue, 11 Jan 2011 07:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.644 X-Spam-Level: X-Spam-Status: No, score=-105.644 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndfza72AULDv for ; Tue, 11 Jan 2011 07:46:18 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B8C0928C18B for ; Tue, 11 Jan 2011 07:46:17 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0BFmXcg000500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Jan 2011 16:48:33 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 11 Jan 2011 16:48:33 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Tue, 11 Jan 2011 16:48:32 +0100 Thread-Topic: Conference announcements Thread-Index: Acuwu1+O1zGDRdohScCrCpmHojxMQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [AVT] Conference announcements X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 15:46:18 -0000 (As WG co-chair) In general we try and discourage blanket conference announcements on IETF l= ists. Generally when this occurs, anyone on an IETF list ends up receiving = multiple copies, amongst their already overloaded inboxes. Generally the criteria for any such announcements should be that they progr= ess work on one of our deliverables, because that is what the scope of our = IETF mailing list is. In general, if you believe such an announcement is ju= stified, then tell us (the list) how it does that as part of the announceme= nt. It will make us all happier that we understand why the conference is im= portant, and you will probably get a better result from this list by doing = so. If you feel the need to apologise because we are receiving a message multip= le times, then in general you are probably outside this criteria, and certa= inly have not explained the relevance to AVT. If you are in doubt, consult with the WG chairs. regards Keith= From magnus.westerlund@ericsson.com Tue Jan 11 09:01:42 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D8528C274 for ; Tue, 11 Jan 2011 09:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk7k9eBT37Mq for ; Tue, 11 Jan 2011 09:01:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C454F28C0E8 for ; Tue, 11 Jan 2011 09:01:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-0f-4d2c8d7c92f4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8E.70.13987.D7D8C2D4; Tue, 11 Jan 2011 18:03:57 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 18:03:56 +0100 Message-ID: <4D2C8D7C.2060204@ericsson.com> Date: Tue, 11 Jan 2011 18:03:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:01:42 -0000 Please see some response at the bottom. Magnus Belling, Thomas (NSN - DE/Munich) skrev 2010-12-21 18:25: > Dear Magnus, > > allow me to continue a discussion we hadabout a month ago. > > Youwere suggesting that the leap of faith initialisation method requires > AVPF becausethis allows XR ECN summary reports can then be sent quicker > and shorter reportingintervalthan the average 5secs canbe > negotiated.Correct? > > The draft contains the following relatedprocedurein6.2.3: > > If the sender marks all packets as ECT while transmitting on a path > > that contains an ECN-blocking middlebox, then receivers downstream of > > that middlebox will not receive any RTP data packets from the sender, > > and hence will not consider it to be an active RTP SSRC. The sender > > can detect this and revert to sending packets without ECT marks, > > since RTCP SR/RR packets from such receivers will either not include > > a report for sender's SSRC, or will report that no packets have been > > received, but this takes at least one RTCP reporting interval. It > > should be noted that a receiver might generate its first RTCP packet > > immediately on joining a unicast session, or very shortly after > > joining a RTP/AVPF session, before it has had chance to receive any > > data packets. A sender that receives RTCP SR/RR packet indicating > > lack of reception by a receiver SHOULD therefore wait for a second > > RTCP report from that receiver to be sure that the lack of reception > > is due to ECT-marking. Since this recovery process can take several > > tens of seconds, during which time the RTP session is unusable for > > media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation > > method be used in environments where ECN-blocking middleboxes are > > likely to be present. > > So there is noparticulartrigger for the receiver to sentSR/RR > reportsthat would allow it to benefitfrom the more flexible timing rules > of AVPF. > > One could think about usingthe AVPFearly RTCP feedback if the sender > does not receiveany packets for a whileat call setup, but the duration > is quite open and it might also bepart of normal operationthat no > packets are received–considerearly media that are usually only > transmitted in backward direction as an example. > > You suggested to negotiate a higher RTCP transmission rate as aremedy.In > my understanding this would work both with AVP and AVPF usingSDP RTCP > bandwidth modifiers. > > But I am not convinced this is a good idea given the extra required > bandwidth.There is a clear wordingalreadythat theleap of faith method > isnot recommendedin environments whereECN-blocking middleboxes arelikely > to be present. It is really meant for operator controlled environments > where such problemswill hardly occur.Isit really worth spending more > bandwidthto improve the handling of a very unlikelyevent?If there is a > real risk that ECN-marked packets are blocked ina network, other > initialisation methods are preferable anyway. > > As said, I alsostilldoubt that you would have any benefit from AVPFfor > thatinitialisationmethod.ButevenIonly failto understand the advantages > you had in mind (do youassume some particular receiverbehaviourdescribed > nowhere up to now?), I doubt this would beworth the extra complexity, > only to improve the handling of a very unlikely error. Again, in > annetworkwherethere is a real risk that ECN-marked packets are blocked, > other initialisation methods are preferable anyway. > On the above I will have to review the discussion and refresh myself on our document. I will come back to you. > > > As an unrelated question, are you working on an update of the draft? The authors plan was to provide an update in December. That has clearly failed. It is on my to do list and I do hope that we can provide one within a few weeks. > > It would be quitehelpfulto have it available for the upcoming SA4 > meeting. I would also welcome if you could share the draft with me for a > quick review before distributing it further, at least if time allows. > Sorry about that. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Tue Jan 11 09:52:26 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45213A6A75 for ; Tue, 11 Jan 2011 09:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3MLcEt7ulAD for ; Tue, 11 Jan 2011 09:52:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E849A3A6A6E for ; Tue, 11 Jan 2011 09:52:23 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEGAI4nLE2rR7Ht/2dsb2JhbACWKI4Rc6NamHGFTASEaIlM Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Jan 2011 17:54:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0BHsfjD021370 for ; Tue, 11 Jan 2011 17:54:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jan 2011 09:54:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jan 2011 09:53:31 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E0AD015@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated CNAME draft based on IESG review Thread-Index: AcuxtyChfls0bqNWTLe3Jlzy+NpWTg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 11 Jan 2011 17:54:41.0053 (UTC) FILETIME=[9F0A1CD0:01CBB1B8] Subject: [AVT] Updated CNAME draft based on IESG review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 17:52:26 -0000 We revised the CNAME draft. For diff and the full text, refer to: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-cnames/ There are some minor fixes. In addition, we were also asked to make some = clarifications around the uniqueness requirements. Basically, we want = uniqueness with a high probability. Collision will not result in RTP = functionality failure anyway. We also changed hashing from sha-1 to = sha-256 as the former is slowly being obsoleted. More importantly, we = extended the security section and made it clear that the goal behind = hashing was not security but to achieve a reasonable uniqueness.=20 We hope these will address the IESG comments. If you have questions, = please email. -acbegen From Internet-Drafts@ietf.org Wed Jan 12 09:30:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5E63A6A5B; Wed, 12 Jan 2011 09:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyiG9A7adYEE; Wed, 12 Jan 2011 09:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5A53A6A4B; Wed, 12 Jan 2011 09:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112173002.6916.20611.idtracker@localhost> Date: Wed, 12 Jan 2011 09:30:02 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-srtp-big-aes-06.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 17:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The use of AES-192 and AES-256 in Secure RTP Author(s) : D. McGrew Filename : draft-ietf-avt-srtp-big-aes-06.txt Pages : 21 Date : 2011-01-12 This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It details Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-big-aes-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-srtp-big-aes-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12092837.I-D@ietf.org> --NextPart-- From Even.roni@huawei.com Wed Jan 12 10:26:45 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED85B3A6A62 for ; Wed, 12 Jan 2011 10:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.494 X-Spam-Level: X-Spam-Status: No, score=-80.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCFl26ijOG7K for ; Wed, 12 Jan 2011 10:26:44 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2F73E3A6A3F for ; Wed, 12 Jan 2011 10:26:44 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00IMXA0547@szxga05-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:28:53 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00A1OA05TV@szxga05-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:28:53 +0800 (CST) Received: from YOUR6108 ([128.107.28.149]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00HWZA01Y0@szxml01-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:28:53 +0800 (CST) Date: Wed, 12 Jan 2011 20:28:54 +0200 From: Roni Even To: avt@ietf.org Message-id: <003501cbb286$93710310$ba530930$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+uceS2gsZSCrvaQczQzMdg)" Content-language: he Thread-index: AcuyhpEfrpkWC3ZuQriRlIaksPMBhg== Subject: [AVT] WG Review: Audio/Video Transport Core Maintenence (avtcore) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:26:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+uceS2gsZSCrvaQczQzMdg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI, Please review and send comments to iesg@ietf.org Roni A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Audio/Video Transport Core Maintenence (avtcore) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. The AVTCORE working group is chartered to maintain the core RTP/RTCP protocols and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Dec 2010 Submit Guideline for Choosing RTCP CNAME as Proposed Standard Dec 2010 Submit use of AES-192 and AES-256 in Secure RTP for Proposed Standard Dec 2010 Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Dec 2010 Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Feb 2011 Submit Monitoring Architecture for RTP for Informational Feb 2011 Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP) Apr 2011 Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2011 Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 RTCP indication for retransmission suppression as proposed standard Sep 2011 Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard --Boundary_(ID_+uceS2gsZSCrvaQczQzMdg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

FYI, Please review and send comments to iesg@ietf.org

Roni

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided forinformational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Audio/Video Transport Core Maintenence (avtcore)

-------------------------------------------

Current Status: Proposed Working Group

Last mo o:p>

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

 

Real-Time Applica Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

The Real-time Transport Protocol, RTP, along with its associated

profiles an d payloa al-time transmission of

audio and video over unicast and multicast transports.  RTP itself has

been shepherded to Full Standard. Its associated profiles, extensions,

and payload formats are currently at various levels of standards

maturity.

 

The AVTCORE working group is chartered to maintain the core RTP/RTCP

provide architectural guidance for extending the protocols and

guidelines for their proper use. While other working groups may be

chartered to work on application-specific extensions to the protocols,

extensions that are generally applicable will be developed in AVTCORE.

 

The AVTCORE working group will coordinate closely with the Security Are awhile working on maintenance and enhancements to the SRTP Profile.

 

In addition to the milestones called out below, the AVTCORE working

group's initial tasks will include completing any remaining work

identified in those drafts from the AVT working group already in IESG

Evaluation, with the exception of the Rapid Acquisition of Multicast RTP

 

Goals and Milestones:

Dec 2010  Submit Guideline for Choosing RTCP CNAME as Proposed Standard

Dec 2010  Submit use of AES-192 and AES-256 in Secure RTP for Proposed

          Standard

Dec 2010  Submit Port Mapping Between Unicast and Multicast RTP Sessions

          for Proposed Standard

Dec 2010  Submit Real-Time Transport Control Protocol (RTCP) in Overlay

          Multicast for Proposed Standard

Feb 2011  Submit Monitoring Architecture for RTP for Informational

Feb 2011  Guidelines for the use of Variable Bit Rate Audio with Secure

          RTP as information al (or p span>

Apr 2011  Submit in band keying mechanism for SRTP draft for Proposed

          Standard

Apr 2011  Submit Explicit Congestion Notification (ECN) for RTP over UDP

          for Proposed Standard

May 2011  RTCP indication for retransmission suppression as proposed

      &nb sp;  >

Sep 2011  Encryption of Header Extensions in the Secure Real-Time

          Transport Protocol (SRTP) for Proposed Standard

 

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_+uceS2gsZSCrvaQczQzMdg)-- From Even.roni@huawei.com Wed Jan 12 10:27:58 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD7028C133 for ; Wed, 12 Jan 2011 10:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.344 X-Spam-Level: X-Spam-Status: No, score=-81.344 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MANGLED_TIME=2.3, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YosoxhtcaZV for ; Wed, 12 Jan 2011 10:27:56 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B093B28C12C for ; Wed, 12 Jan 2011 10:27:55 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00N5EA251F@szxga03-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:30:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00J68A25E7@szxga03-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:30:05 +0800 (CST) Received: from YOUR6108 ([128.107.28.149]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00HZAA23Y0@szxml01-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:30:05 +0800 (CST) Date: Wed, 12 Jan 2011 20:30:07 +0200 From: Roni Even To: avt@ietf.org Message-id: <003a01cbb286$be628300$3b278900$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rQ4XLrwJbS6U4bGIHaoh7w)" Content-language: he Thread-index: AcuyhrzwM0SaqVPfQoOXivNIhfABvg== Subject: [AVT] WG Review: Audio/Video Transport Extensions (avtext) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:27:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rQ4XLrwJbS6U4bGIHaoh7w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI, please review and send any comments to iesg@ietf.org Roni Even A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Audio/Video Transport Extensions (avtext) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group. The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Dec 2010 Submit Considerations for RAMS Scenarios for Informational Oct 2011 Submit RTP Header extension for mixer to client audio level indication as Proposed Standard Oct 2011 Submit RTP Header extension for client to mixer audio level indication as proposed standard Dec 2011 Submit Support for multiple clock rates in an RTP session for Proposed Standard Dec 2011 Submit SRTP Store-and-Forward Use Cases and Requirements for Informational Dec 2011 Submit Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications for Proposed Standard --Boundary_(ID_rQ4XLrwJbS6U4bGIHaoh7w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

FYI, please review and send any comments to iesg@ietf.org

Roni Even

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Audio/Video Transport Extensions (avtext)

-------------------------------------------

Current Status: Proposed Working Group

Last

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

 

Real-Ti me Appli e Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

  The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along

  d profiles and payload formats provides for real-

  time transmission of audio and video over unicast and multicast

  transports. RTP is widely implemented, and deployed for a wide range

  of applications, ranging from telephony to television over IP. As new

  applications have emerged, the need for guidelines for the use of the

  RTP/RTCP protocols and extensions specific to those applications

  has been identified.

 

  The AVTEXT working group is charted to develop application-specific

  guidelines for the use of RTP/RTCP protocols with the AVP, SAVP,

  AVPF, and SAVPF profiles, and extensions to those protocols that are

  driven by application-specific needs. Proposals for extensions with

  general applicability to many di fferent

  taken to the AVTCORE working group.

 

  The AVTEXT working group is constrained to use the protocol extension

  mechanisms defined in the core protocols (such as RTP Header

  extensions [RFC5285], AVPF Feedback Messages [RFC4585], and

  SDES Items [RFC3550]). If new ways to extend the core protocols are

  needed, they will be developed in the AVTCORE working group.

 

  In addition to the milestones called out below, the AVTEXT working

  group's initial tasks will include completing any new work identified

  during IESG evaluation for the Rapid Acquisition of Multicast RTP

  Sessions.

 

Goals and Milestones:

Dec 2010  Submit Considerations for RAMS Scenarios for Informational

Oct 2011  Submit RTP Header extension for mixer to client audio level

          indication as Proposed Standard

Oct 2011  Submit RTP Header extension for client to mixer audio level

          indication as proposed standard

Dec 2011  Submit Support for multiple clock rates in an RTP session for

          Proposed Standard

Dec 2011  Submit SRTP Store-and-Forward Use Cases and Requirements for

          Informational

Dec 2011  Submit Use of the Secure Real-time Transport Protocol (SRTP)

          in Store-and-Forward Applications for Proposed S tandard< lass=MsoNormal> 

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_rQ4XLrwJbS6U4bGIHaoh7w)-- From Even.roni@huawei.com Wed Jan 12 10:29:02 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C783A6A75 for ; Wed, 12 Jan 2011 10:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.919 X-Spam-Level: X-Spam-Status: No, score=-82.919 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRwkzQHMQRE5 for ; Wed, 12 Jan 2011 10:29:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9947C3A69B7 for ; Wed, 12 Jan 2011 10:29:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00C5ZA3TG7@szxga04-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:31:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX004EGA3THF@szxga04-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:31:05 +0800 (CST) Received: from YOUR6108 ([128.107.28.149]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00H0LA3QY0@szxml01-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:31:05 +0800 (CST) Date: Wed, 12 Jan 2011 20:31:07 +0200 From: Roni Even To: avt@ietf.org Message-id: <004501cbb286$e24007c0$a6c01740$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fvqZg0DlK+l1YbGoGtmnug)" Content-language: he Thread-index: AcuyhuCSk83hVJQRTMCr9L+U1zZkFQ== Subject: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:29:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_fvqZg0DlK+l1YbGoGtmnug) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI, Please review and send any comments to iesg@ietf.org Roni Even A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new metrics. The group will follow the guidelines established in RFC5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the RTPCORE working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric Reporting Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting --Boundary_(ID_fvqZg0DlK+l1YbGoGtmnug) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

FYI,

Please review and send any comments to iesg@ietf.org

Roni Even

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided for

informational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

-------------------------------------------

Current Status: p>

Last modified: 2010-12-03

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

Real-Time Applications and Infrastructure Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

RFC3611, "RTP Control Protocol Extended Re ports (R

a framework to allow new information to be conveyed in RTCP,

supplementing the original report blocks defined in RFC 3550, "RTP: A

Transport Protocol for Real-Time Applications".

 

The XRBLOCK working group is chartered to work within this framework,

evaluating proposals for report block definitions containing new

"Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP

Monitoring Architecture being developed in the RTPCORE working group.

 

Goals and Milestones:

 

Mar 2011  Submit RTCP XR Report Block for Measurement Identity

          Reporting

Mar 2011  Submit RTCP XR Report Block for Burst/Gap Loss metric

          Reporting

Jun 2011  Submit RTCP XR Report Block for Concealed Seconds metric

          Reporting

Jun 2 011  lock for Delay metric Reporting

Jun 2011  Submit RTCP XR Report Block for Discard metric Reporting

Sep 2011  Submit RTCP XR Report Block for Jitter Buffer Metric Reporting

Sep 2011  Submit RTCP XR Report Block for Loss Concealment metric

          Reporting

Sep 2011  Submit RTCP XR Report Block for Packet Delay Variation Metric

   &n sp;   Reporting

Dec 2011  Submit RTCP XR Report Block for Run Length Encodings of

          Discarded Packets

Dec 2011  Submit RTCP XR Report Block for QoE Metrics Reporting   

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_fvqZg0DlK+l1YbGoGtmnug)-- From Even.roni@huawei.com Wed Jan 12 10:30:07 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9F53A69B7 for ; Wed, 12 Jan 2011 10:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.144 X-Spam-Level: X-Spam-Status: No, score=-83.144 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMz4EqiBVfa1 for ; Wed, 12 Jan 2011 10:30:05 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3E6F73A6A62 for ; Wed, 12 Jan 2011 10:30:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00DF9A5QB8@szxga03-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:32:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00CJIA5Q3S@szxga03-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:32:14 +0800 (CST) Received: from YOUR6108 ([128.107.28.149]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00H27A5KY0@szxml01-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 02:32:14 +0800 (CST) Date: Wed, 12 Jan 2011 20:32:13 +0200 From: Roni Even To: avt@ietf.org Message-id: <004a01cbb287$0b9786c0$22c69440$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OHPDpYzEJgDh+qojFKlfVA)" Content-language: he Thread-index: AcuyhwfIpPCGdPZfS/CddhJRn8twwQ== Subject: [AVT] WG Review: Audio/Video Transport Payloads (payload) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 18:30:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_OHPDpYzEJgDh+qojFKlfVA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT FYI, please review and send any comments to iesg@ietf.org Roni Even A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Audio/Video Transport Payloads (payload) ------------------------------------------- Current Status: Proposed Working Group Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format" (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Dec 2010 Submit RTP Payload Format for MIDI for Proposed Standard Feb 2011 Submit How to Write an RTP Payload Format for Informational Feb 2011 Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Mar 2011 Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Mar 2011 Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Mar 2011 Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Apr 2011 Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard Apr 2011 Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Apr 2011 Submit RTP Payload Format for the iSAC codec for Proposed Standard Apr 2011 Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Jun 2011 Submit RTP Payload Format for MVC Video for Proposed Standard --Boundary_(ID_OHPDpYzEJgDh+qojFKlfVA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

FYI, please review and send any comments to iesg@ietf.org

Roni Even

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Audio/Video Transport Payloads (payload)

-------------------------------------------

Current Status: Proposed Working Group

Last m /o:p>

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

 

Real-Tim e Applic Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

  The PAYLOAD working group is tasked with the specification and

  ; m mats for use with the Real-Time Transport

  Protocol, RTP [RFC3550]. The group will follow the guidelines

  established in "Guidelines for Writers of RTP Payload Format

  Specifications" [BCP 36], the "How to Write an RTP Payload Format"

  (under development) and is responsible for maintaining those

  guidelines.

 < /span>  This working group will develop RTP payload formats for new media

  codecs, review and revise existing payload formats to advance those

  which are useful to Draft Standard or Standard, and declare others

  Historic.

 

Goals and Milestones:

Dec 2010  Submit RTP Payload Format for MIDI for Proposed Standa rd< MsoNormal>Feb 2011  Submit How to Write an RTP Payload Format for Informational

Feb 2011  Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for

          Proposed Standard

Mar 2011  Submit RTP Payload Format for EVBR/G.718 for Proposed Standard

Mar 2011  Submit RTP Payload Format for Enhanced Variable Rate

           Narrowba W) for Proposed Standard

Mar 2011  Submit RTP Payload Format for Bluetooth's SBC audio codec for

          Proposed Standard

Apr 2011  Submit RTP Payload Format for MPEG2-TS preamble for Proposed

          Standard

Apr 2011  Submit RTP Payload Format for DV (IEC 61834) Video for

 &nbs p;  nbsp;  Proposed Standard

Apr 2011  Submit RTP Payload Format for the iSAC codec for Proposed

          Standard

Apr 2011  Submit RTP profile for the carriage of SMPTE 336M data for

          Proposed Standard

Jun 2011  Submit RTP Payload Format for MVC Video for Proposed Standard

 



__________ Informatio n from E ion of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_OHPDpYzEJgDh+qojFKlfVA)-- From kpfleming@digium.com Wed Jan 12 12:47:54 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42F823A69A4 for ; Wed, 12 Jan 2011 12:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJt7EsscP8xo for ; Wed, 12 Jan 2011 12:47:53 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id E32DE3A69A1 for ; Wed, 12 Jan 2011 12:47:52 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Pd7e0-0001fu-Tw for avt@ietf.org; Wed, 12 Jan 2011 14:50:12 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id D6DB3D8193 for ; Wed, 12 Jan 2011 14:50:12 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyJb7pQAiNoC for ; Wed, 12 Jan 2011 14:50:12 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 4E32BD8192 for ; Wed, 12 Jan 2011 14:50:12 -0600 (CST) Message-ID: <4D2E1404.1060004@digium.com> Date: Wed, 12 Jan 2011 14:50:12 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org References: <004a01cbb287$0b9786c0$22c69440$%roni@huawei.com> In-Reply-To: <004a01cbb287$0b9786c0$22c69440$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVT] WG Review: Audio/Video Transport Payloads (payload) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 20:47:54 -0000 On 01/12/2011 12:32 PM, Roni Even wrote: > FYI, please review and send any comments to iesg@ietf.org > > > Roni Even > > A new IETF working group has been proposed in the Real-Time Applications > > and Infrastructure Area. The IESG has not made any determination as yet. > > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG mailing > > list (iesg at ietf.org) by Tuesday, January 18, 2011. > > Audio/Video Transport Payloads (payload) > > ------------------------------------------- > > Current Status: Proposed Working Group > > Last m /o:p> > > Chairs: TBD > > Real-Time Applications and Infrastructure Area Directors: > > Gonzalo Camarillo > > Robert Sparks > > Real-Tim e Applic Area Advisor: > > Robert Sparks > > Mailing Lists: TBD > > Description of Working Group: > > The PAYLOAD working group is tasked with the specification and > > ; m mats for use with the Real-Time Transport > > Protocol, RTP [RFC3550]. The group will follow the guidelines > > established in "Guidelines for Writers of RTP Payload Format > > Specifications" [BCP 36], the "How to Write an RTP Payload Format" > > (under development) and is responsible for maintaining those > > guidelines. > > This working group will develop RTP payload formats for new media > > codecs, review and revise existing payload formats to advance those > > which are useful to Draft Standard or Standard, and declare others > > Historic. This description is badly broken up, and it appears that other parts of the message were corrupted as well. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From Even.roni@huawei.com Wed Jan 12 15:21:04 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AE83A6809 for ; Wed, 12 Jan 2011 15:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.632 X-Spam-Level: X-Spam-Status: No, score=-93.632 tagged_above=-999 required=5 tests=[AWL=10.863, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw77Mbj3EbVz for ; Wed, 12 Jan 2011 15:21:01 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9AEE03A67EC for ; Wed, 12 Jan 2011 15:21:01 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00J9CNMITR@szxga04-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 07:23:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00JRJNMILR@szxga04-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 07:23:06 +0800 (CST) Received: from YOUR6108 ([128.107.28.149]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00HEPNMGC2@szxml01-in.huawei.com>; Thu, 13 Jan 2011 07:23:06 +0800 (CST) Date: Thu, 13 Jan 2011 01:23:09 +0200 From: Roni Even In-reply-to: <4D2E1404.1060004@digium.com> To: "'Kevin P. Fleming'" , avt@ietf.org Message-id: <007a01cbb2af$ae31c7b0$0a955710$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: he Content-transfer-encoding: 7BIT Thread-index: Acuymlm2g8JIDxrDQWeIuMpmv8CCDgAFPEVw References: <004a01cbb287$0b9786c0$22c69440$%roni@huawei.com> <4D2E1404.1060004@digium.com> Subject: Re: [AVT] WG Review: Audio/Video Transport Payloads (payload) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 23:21:04 -0000 Hi, I am sorry, but I did not get the original messages from the announce list. I took it from the archive which can be seen at http://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html on January 11th. So you can see the original message there. Thanks Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Kevin P. Fleming > Sent: Wednesday, January 12, 2011 10:50 PM > To: avt@ietf.org > Subject: Re: [AVT] WG Review: Audio/Video Transport Payloads (payload) > > On 01/12/2011 12:32 PM, Roni Even wrote: > > FYI, please review and send any comments to iesg@ietf.org > > > > > > Roni Even > > > > A new IETF working group has been proposed in the Real-Time > Applications > > > > and Infrastructure Area. The IESG has not made any determination as > yet. > > > > The following draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to the IESG > mailing > > > > list (iesg at ietf.org) by Tuesday, January 18, 2011. > > > > Audio/Video Transport Payloads (payload) > > > > ------------------------------------------- > > > > Current Status: Proposed Working Group > > > > Last m /o:p> > > > > Chairs: TBD > > > > Real-Time Applications and Infrastructure Area Directors: > > > > Gonzalo Camarillo > > > > Robert Sparks > > > > Real-Tim e Applic Area Advisor: > > > > Robert Sparks > > > > Mailing Lists: TBD > > > > Description of Working Group: > > > > The PAYLOAD working group is tasked with the specification and > > > > ; m mats for use with the Real-Time Transport > > > > Protocol, RTP [RFC3550]. The group will follow the guidelines > > > > established in "Guidelines for Writers of RTP Payload Format > > > > Specifications" [BCP 36], the "How to Write an RTP Payload Format" > > > > (under development) and is responsible for maintaining those > > > > guidelines. > > > > This working group will develop RTP payload formats for new media > > > > codecs, review and revise existing payload formats to advance those > > > > which are useful to Draft Standard or Standard, and declare others > > > > Historic. > > This description is badly broken up, and it appears that other parts of > the message were corrupted as well. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5781 (20110112) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5781 (20110112) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5782 (20110112) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5782 (20110112) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From stewe@stewe.org Wed Jan 12 16:09:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D8A3A6784; Wed, 12 Jan 2011 16:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLb9O9hGaetq; Wed, 12 Jan 2011 16:09:11 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DDB2A3A65A6; Wed, 12 Jan 2011 16:09:10 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 50557-1743317 for multiple; Thu, 13 Jan 2011 01:11:29 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 12 Jan 2011 16:11:20 -0800 From: Stephan Wenger To: Message-ID: Thread-Topic: proposed AVT WG split Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3377693488_23135744" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: avt@ietf.org Subject: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 00:09:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3377693488_23135744 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi IESG, As already communicated in Maastricht, I continue to believe that this step is a bad idea. I didn't attend Beijing, and don't know whether there was any discussion about the subject. I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf. If there was, some of the points below may be redundant, and I apologize in advance. Essentially, you guys are suggesting to split one "eternal" WG into four. I'm writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a simila= r scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads that is probably self-evident. For the XR stuff: metrics pop up all the time, like payload formats. Metrics are also known to make people quick bucks on patent licensing. There will be more metric proposals. If the RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I have my doubts. But that's a different discussion. The positive effects of the split could be -chair workload is split among more people, and -there are more meeting seconds for RTP related work at any given IETF meeting. =20 Assuming unlimited resources, both are good things. Unfortunately, resources are not unlimited. The negative effects are IMO: -the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience. But they may no= t want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot. Also, the burden for remote participants in far-away time zones goes up. I= n other words, the resource meeting-seconds for those people is not unlimited= , and they will have to prioritize differently. The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call. -more people get chair positions and are burdened with administrative stuff -> less time to do real work -WG scheduling gets more difficult -AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice) -there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles. Some of these issues can be solved by joint WG meetings and/or careful chai= r selection. However, both options have drawbacks as well. A joint session would be counter-productive to the allocation of more meeting minutes. And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties. No matter how I see it, splitting the group is not a good idea. Other options to alleviate problems could come to mind: If the problem to be solved is chair-workload: add more chairs (but not 6 o= f them). If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc. In other words, stretch out the AVT meeting in the interval between IETF meetings. Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A. Should I continue with this brainstorm? If the problem is something else, I would like to know=8A Thanks for your consideration, and apologies for the wordcount, Stephan --B_3377693488_23135744 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi IESG,

As already communicated in Maastricht, I continue to believe that this= step is a bad idea.  I didn't attend Beijing, and don't know whether t= here was any discussion about the subject.  I didn't see anything menti= oned in the AVT minutes, though, nor did I see any discussion since Beijing = on ietf@ietf.  If there was, some of the points below may be redundant,= and I apologize in advance.

Essentially, you guys = are suggesting to split one "eternal" WG into four.  I'm writing "etern= al", because I don't see that any of the WGs can fulfill its charter before = other work items will likely get chartered with a similar scope, and in the = same WG.  For RTP core, RTP extensions, and RTP payloads that is probab= ly self-evident.  For the XR stuff: metrics pop up all the time, like p= ayload formats.  Metrics are also known to make people quick bucks on p= atent licensing.  There will be more metric proposals.  If the RTC= P-XR metrics ever get momentum in the marketplace, that is.  Somehow, I= have my doubts.  But that's a different discussion.  
<= br>
The positive effects of the split could be 
-ch= air workload is split among more people, and 
-there are more= meeting seconds for RTP related work at any given IETF meeting.  

Assuming unlimited resources, both are good things. &nb= sp;Unfortunately, resources are not unlimited.

The = negative effects are IMO:
-the key knowledgeable people in AVT ide= ally would have to sit in all four meetings so that all four groups can tap = their experience.  But they may not want to do so, because it leaves le= ss time for cross-area involvement, coordination, and draft-writing outside = the AVT sessions, and whatnot.  Also, the burden for remote participant= s in far-away time zones goes up.  In other words, the resource meeting= -seconds for those people is not unlimited, and they will have to prioritize= differently.    The result could be that what I called "key knowl= edgable people" would perhaps not attend the mere RTCP-XR or Payload session= ; and the guys there may be wasting their time doing work that does not make= sense architecturally, just to see the hammer coming down at IETF last call= .
-more people get chair positions and are burdened with administr= ative stuff -> less time to do real work
-WG scheduling gets mo= re difficult
-AD load potentially goes up (someone needs to coordi= nate between those groups, and the AD would seem to me the natural choice)
-there is no reason to believe that the overall manpower availabili= ty goes up through this change, so all the inefficiencies introduced go stra= ight against the available cycles.

Some of these is= sues can be solved by joint WG meetings and/or careful chair selection. &nbs= p;However, both options have drawbacks as well.  A joint session would = be counter-productive to the allocation of more meeting minutes.  And w= hen you have, say, 8 chairs for four WG, all of which know the RTP architect= ure well enough, then you have pretty much exhausted, if not overdrawn alrea= dy, the pool of "key knowledgable people", and burdened them with (in many c= ases: additional) chair duties.

No matter how I see= it, splitting the group is not a good idea.

Other = options to alleviate problems could come to mind:

I= f the problem to be solved is chair-workload: add more chairs (but not 6 of = them).
If the problem to be solved is meeting-second shortages: ha= ve interim meetings, conf calls, etc.  In other words, stretch out the = AVT meeting in the interval between IETF meetings.  Require a web-ex pr= esentation of every draft to be discussed in the AVT session at least 4 week= s before the meeting, with a two hour timeslot for Q/A.  Should I conti= nue with this brainstorm?

If the problem is somethi= ng else, I would like to know…

Thanks for you= r consideration, and apologies for the wordcount,

S= tephan



--B_3377693488_23135744-- From sunseawq@huawei.com Wed Jan 12 18:16:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4FF3A6806 for ; Wed, 12 Jan 2011 18:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXubWIqcE6Xm for ; Wed, 12 Jan 2011 18:16:49 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1B02B3A680E for ; Wed, 12 Jan 2011 18:16:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00H9VVPKDW@szxga05-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 10:17:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00GGLVPJ4D@szxga05-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 10:17:44 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX005YXVPJRV@szxml06-in.huawei.com> for avt@ietf.org; Thu, 13 Jan 2011 10:17:43 +0800 (CST) Date: Thu, 13 Jan 2011 10:17:42 +0800 From: Qin Wu To: avt@ietf.org Message-id: <026101cbb2c8$0f6fce60$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_seNCqfxxu6UV8CWMfvESEQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] Fw: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 02:16:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_seNCqfxxu6UV8CWMfvESEQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT FYI. ----- Original Message ----- From: Qin Wu To: iesg@ietf.org Sent: Thursday, January 13, 2011 10:07 AM Subject: Fw: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) Hi, IESG: Since the proposed XRBLOCK new working group is chartered based on RTP Monitoring Architecture and RFC5968, rather than develop RTP Monitoring Architecture in AVTCore, why not move the milestone for RTP Monitoring Architecture from AVTCore to XRBlock and build with other Report Block work items together? Regards! -Qin ----- Original Message ----- From: Roni Even To: avt@ietf.org Sent: Thursday, January 13, 2011 2:31 AM Subject: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) FYI, Please review and send any comments to iesg@ietf.org Roni Even A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) ------------------------------------------- Current Status: p> Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: RFC3611, "RTP Control Protocol Extended Re ports (R a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the RTPCORE working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric Reporting Jun 2 011 lock for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric &n sp; Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting __________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_seNCqfxxu6UV8CWMfvESEQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
FYI.
----- Original Message -----
From: Qin Wu
Sent: Thursday, January 13, 2011 10:07 AM
Subject: Fw: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

Hi, IESG:
Since the proposed XRBLOCK new working group is chartered based on RTP Monitoring Architecture
and RFC5968, rather than develop RTP Monitoring Architecture in AVTCore,
why not move the milestone for RTP Monitoring Architecture
from AVTCore to  XRBlock and build with other Report Block work items together?
 
Regards!
-Qin
----- Original Message -----
From: Roni Even
Sent: Thursday, January 13, 2011 2:31 AM
Subject: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

FYI,

Please review and send any comments to iesg@ietf.org

Roni Even

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided for

informational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

-------------------------------------------

Current Status: p>

Last modified: 2010-12-03

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

Real-Time Applications and Infrastructure Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

RFC3611, "RTP Control Protocol Extended Re ports (R

a framework to allow new information to be conveyed in RTCP,

supplementing the original report blocks defined in RFC 3550, "RTP: A

Transport Protocol for Real-Time Applications".

 

The XRBLOCK working group is chartered to work within this framework,

evaluating proposals for report block definitions containing new

"Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP

Monitoring Architecture being developed in the RTPCORE working group.

 

Goals and Milestones:

 

Mar 2011  Submit RTCP XR Report Block for Measurement Identity

          Reporting

Mar 2011  Submit RTCP XR Report Block for Burst/Gap Loss metric

          Reporting

Jun 2011  Submit RTCP XR Report Block for Concealed Seconds metric

          Reporting

Jun 2 011  lock for Delay metric Reporting

Jun 2011  Submit RTCP XR Report Block for Discard metric Reporting

Sep 2011  Submit RTCP XR Report Block for Jitter Buffer Metric Reporting

Sep 2011  Submit RTCP XR Report Block for Loss Concealment metric

          Reporting

Sep 2011  Submit RTCP XR Report Block for Packet Delay Variation Metric

   &n sp;   Reporting

Dec 2011  Submit RTCP XR Report Block for Run Length Encodings of

          Discarded Packets

Dec 2011  Submit RTCP XR Report Block for QoE Metrics Reporting   

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_seNCqfxxu6UV8CWMfvESEQ)-- From sunseawq@huawei.com Wed Jan 12 19:13:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C913A6847; Wed, 12 Jan 2011 19:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVqTQYxHT0B8; Wed, 12 Jan 2011 19:13:22 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C85723A6846; Wed, 12 Jan 2011 19:13:21 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX006WIYAW2V@szxga04-in.huawei.com>; Thu, 13 Jan 2011 11:13:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00LP1YAWDY@szxga04-in.huawei.com>; Thu, 13 Jan 2011 11:13:44 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00JW7YAV3K@szxml06-in.huawei.com>; Thu, 13 Jan 2011 11:13:44 +0800 (CST) Date: Thu, 13 Jan 2011 11:13:43 +0800 From: Qin Wu To: iesg@ietf.org, avt@ietf.org Message-id: <03b401cbb2cf$e2939bd0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_n4XmMuBRhfdBHVBsaSD9aA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVT] Fw: WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 03:13:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_n4XmMuBRhfdBHVBsaSD9aA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, iesg: As for milestone, I remembered some new XR works have been identified and discussed in the last two or three meetings. And based on the results of meetings, these work are waiting for being taken on after monitoring architecture work is complete. So isn't better to allow XRblock identify or take on some potential new works? Regards! -Qin ----- Original Message ----- From: Roni Even To: avt@ietf.org Sent: Thursday, January 13, 2011 2:31 AM Subject: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock) FYI, Please review and send any comments to iesg@ietf.org Roni Even A new IETF working group has been proposed in the Real-Time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by Tuesday, January 18, 2011. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) ------------------------------------------- Current Status: p> Last modified: 2010-12-03 Chairs: TBD Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-Time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: TBD Description of Working Group: RFC3611, "RTP Control Protocol Extended Re ports (R a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the RTPCORE working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric Reporting Jun 2 011 lock for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric &n sp; Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting __________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_n4XmMuBRhfdBHVBsaSD9aA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi, iesg:
As for milestone, I remembered some new XR works have been identified and discussed in the last two or three meetings.
And based on the results of meetings, these work are waiting for being taken on after monitoring architecture work is complete.
So isn't better to allow XRblock identify or take on some potential new works?
 
Regards!
-Qin
----- Original Message -----
From: Roni Even
Sent: Thursday, January 13, 2011 2:31 AM
Subject: [AVT] WG Review: Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

FYI,

Please review and send any comments to iesg@ietf.org

Roni Even

 

A new IETF working group has been proposed in the Real-Time Applications

and Infrastructure Area.  The IESG has not made any determination as yet.

The following draft charter was submitted, and is provided for

informational purposes only. Please send your comments to the IESG mailing

list (iesg at ietf.org) by Tuesday, January 18, 2011.              

 

Metric Blocks for use with RTCP's Extended Report Framework (xrblock)

-------------------------------------------

Current Status: p>

Last modified: 2010-12-03

 

Chairs: TBD

 

Real-Time Applications and Infrastructure Area Directors:

  Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>

  Robert Sparks <rjsparks at nostrum.com>

Real-Time Applications and Infrastructure Area Advisor:

  Robert Sparks <rjsparks at nostrum.com>

 

Mailing Lists: TBD

 

Description of Working Group:

 

RFC3611, "RTP Control Protocol Extended Re ports (R

a framework to allow new information to be conveyed in RTCP,

supplementing the original report blocks defined in RFC 3550, "RTP: A

Transport Protocol for Real-Time Applications".

 

The XRBLOCK working group is chartered to work within this framework,

evaluating proposals for report block definitions containing new

"Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP

Monitoring Architecture being developed in the RTPCORE working group.

 

Goals and Milestones:

 

Mar 2011  Submit RTCP XR Report Block for Measurement Identity

          Reporting

Mar 2011  Submit RTCP XR Report Block for Burst/Gap Loss metric

          Reporting

Jun 2011  Submit RTCP XR Report Block for Concealed Seconds metric

          Reporting

Jun 2 011  lock for Delay metric Reporting

Jun 2011  Submit RTCP XR Report Block for Discard metric Reporting

Sep 2011  Submit RTCP XR Report Block for Jitter Buffer Metric Reporting

Sep 2011  Submit RTCP XR Report Block for Loss Concealment metric

          Reporting

Sep 2011  Submit RTCP XR Report Block for Packet Delay Variation Metric

   &n sp;   Reporting

Dec 2011  Submit RTCP XR Report Block for Run Length Encodings of

          Discarded Packets

Dec 2011  Submit RTCP XR Report Block for QoE Metrics Reporting   

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5781 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_n4XmMuBRhfdBHVBsaSD9aA)-- From casner@acm.org Wed Jan 12 20:30:37 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549C83A6839; Wed, 12 Jan 2011 20:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsu9CPvxZK-F; Wed, 12 Jan 2011 20:30:35 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by core3.amsl.com (Postfix) with ESMTP id C94EB3A6837; Wed, 12 Jan 2011 20:30:35 -0800 (PST) Received: from packetdesign.com (vpn-int.packetdesign.com [192.168.0.180]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p0D4WlaZ003703; Wed, 12 Jan 2011 20:32:48 -0800 Date: Wed, 12 Jan 2011 20:32:46 -0800 (PST) From: Stephen Casner To: Stephan Wenger In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: iesg@ietf.org, avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 04:30:37 -0000 +1, definitely. When I was chair, I once thought that AVT should try to draw to a close. Later I realized that this was not only unlikely but also not required. -- Steve On Wed, 12 Jan 2011, Stephan Wenger wrote: > Hi IESG, > > As already communicated in Maastricht, I continue to believe that this step > is a bad idea. I didn't attend Beijing, and don't know whether there was > any discussion about the subject. I didn't see anything mentioned in the > AVT minutes, though, nor did I see any discussion since Beijing on > ietf@ietf. If there was, some of the points below may be redundant, and I > apologize in advance. > > Essentially, you guys are suggesting to split one "eternal" WG into four. > I'm writing "eternal", because I don't see that any of the WGs can fulfill > its charter before other work items will likely get chartered with a similar > scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads > that is probably self-evident. For the XR stuff: metrics pop up all the > time, like payload formats. Metrics are also known to make people quick > bucks on patent licensing. There will be more metric proposals. If the > RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I > have my doubts. But that's a different discussion. > > The positive effects of the split could be > -chair workload is split among more people, and > -there are more meeting seconds for RTP related work at any given IETF > meeting. > > Assuming unlimited resources, both are good things. Unfortunately, > resources are not unlimited. > > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to sit in all four > meetings so that all four groups can tap their experience. But they may not > want to do so, because it leaves less time for cross-area involvement, > coordination, and draft-writing outside the AVT sessions, and whatnot. > Also, the burden for remote participants in far-away time zones goes up. In > other words, the resource meeting-seconds for those people is not unlimited, > and they will have to prioritize differently. The result could be that > what I called "key knowledgable people" would perhaps not attend the mere > RTCP-XR or Payload session; and the guys there may be wasting their time > doing work that does not make sense architecturally, just to see the hammer > coming down at IETF last call. > -more people get chair positions and are burdened with administrative stuff > -> less time to do real work > -WG scheduling gets more difficult > -AD load potentially goes up (someone needs to coordinate between those > groups, and the AD would seem to me the natural choice) > -there is no reason to believe that the overall manpower availability goes > up through this change, so all the inefficiencies introduced go straight > against the available cycles. > > Some of these issues can be solved by joint WG meetings and/or careful chair > selection. However, both options have drawbacks as well. A joint session > would be counter-productive to the allocation of more meeting minutes. And > when you have, say, 8 chairs for four WG, all of which know the RTP > architecture well enough, then you have pretty much exhausted, if not > overdrawn already, the pool of "key knowledgable people", and burdened them > with (in many cases: additional) chair duties. > > No matter how I see it, splitting the group is not a good idea. > > Other options to alleviate problems could come to mind: > > If the problem to be solved is chair-workload: add more chairs (but not 6 of > them). > If the problem to be solved is meeting-second shortages: have interim > meetings, conf calls, etc. In other words, stretch out the AVT meeting in > the interval between IETF meetings. Require a web-ex presentation of every > draft to be discussed in the AVT session at least 4 weeks before the > meeting, with a two hour timeslot for Q/A. Should I continue with this > brainstorm? > > If the problem is something else, I would like to know? > > Thanks for your consideration, and apologies for the wordcount, > > Stephan From michael.speer@oracle.com Wed Jan 12 22:28:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE713A6AAB for ; Wed, 12 Jan 2011 22:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN9nlubsUHmi for ; Wed, 12 Jan 2011 22:28:31 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 92D933A686E for ; Wed, 12 Jan 2011 22:28:31 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0D6UpUC024043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Jan 2011 06:30:53 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0D6UoOh028160 for ; Thu, 13 Jan 2011 06:30:51 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 955773811294900137; Wed, 12 Jan 2011 22:28:57 -0800 Received: from dhcp-whq-twvpn-1-vpnpool-10-159-242-205.vpn.oracle.com (/10.159.242.205) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jan 2011 22:28:56 -0800 Message-ID: <4D2E9B9A.2000206@oracle.com> Date: Wed, 12 Jan 2011 22:28:42 -0800 From: Michael Speer Organization: Solaris Core OS User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 06:28:34 -0000 +1, go for it. On 1/12/11 8:32 PM, Stephen Casner wrote: > +1, definitely. > > When I was chair, I once thought that AVT should try to draw to a > close. Later I realized that this was not only unlikely but also not > required. > > -- Steve > > On Wed, 12 Jan 2011, Stephan Wenger wrote: > >> Hi IESG, >> >> As already communicated in Maastricht, I continue to believe that this step >> is a bad idea. I didn't attend Beijing, and don't know whether there was >> any discussion about the subject. I didn't see anything mentioned in the >> AVT minutes, though, nor did I see any discussion since Beijing on >> ietf@ietf. If there was, some of the points below may be redundant, and I >> apologize in advance. >> >> Essentially, you guys are suggesting to split one "eternal" WG into four. >> I'm writing "eternal", because I don't see that any of the WGs can fulfill >> its charter before other work items will likely get chartered with a similar >> scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads >> that is probably self-evident. For the XR stuff: metrics pop up all the >> time, like payload formats. Metrics are also known to make people quick >> bucks on patent licensing. There will be more metric proposals. If the >> RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I >> have my doubts. But that's a different discussion. >> >> The positive effects of the split could be >> -chair workload is split among more people, and >> -there are more meeting seconds for RTP related work at any given IETF >> meeting. >> >> Assuming unlimited resources, both are good things. Unfortunately, >> resources are not unlimited. >> >> The negative effects are IMO: >> -the key knowledgeable people in AVT ideally would have to sit in all four >> meetings so that all four groups can tap their experience. But they may not >> want to do so, because it leaves less time for cross-area involvement, >> coordination, and draft-writing outside the AVT sessions, and whatnot. >> Also, the burden for remote participants in far-away time zones goes up. In >> other words, the resource meeting-seconds for those people is not unlimited, >> and they will have to prioritize differently. The result could be that >> what I called "key knowledgable people" would perhaps not attend the mere >> RTCP-XR or Payload session; and the guys there may be wasting their time >> doing work that does not make sense architecturally, just to see the hammer >> coming down at IETF last call. >> -more people get chair positions and are burdened with administrative stuff >> -> less time to do real work >> -WG scheduling gets more difficult >> -AD load potentially goes up (someone needs to coordinate between those >> groups, and the AD would seem to me the natural choice) >> -there is no reason to believe that the overall manpower availability goes >> up through this change, so all the inefficiencies introduced go straight >> against the available cycles. >> >> Some of these issues can be solved by joint WG meetings and/or careful chair >> selection. However, both options have drawbacks as well. A joint session >> would be counter-productive to the allocation of more meeting minutes. And >> when you have, say, 8 chairs for four WG, all of which know the RTP >> architecture well enough, then you have pretty much exhausted, if not >> overdrawn already, the pool of "key knowledgable people", and burdened them >> with (in many cases: additional) chair duties. >> >> No matter how I see it, splitting the group is not a good idea. >> >> Other options to alleviate problems could come to mind: >> >> If the problem to be solved is chair-workload: add more chairs (but not 6 of >> them). >> If the problem to be solved is meeting-second shortages: have interim >> meetings, conf calls, etc. In other words, stretch out the AVT meeting in >> the interval between IETF meetings. Require a web-ex presentation of every >> draft to be discussed in the AVT session at least 4 weeks before the >> meeting, with a two hour timeslot for Q/A. Should I continue with this >> brainstorm? >> >> If the problem is something else, I would like to know? >> >> Thanks for your consideration, and apologies for the wordcount, >> >> Stephan > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Michael Speer Principal Software Engineer, Solaris Core OS Oracle e-mail: michael.speer@oracle.com phone: +1 408 276-6943 From casner@acm.org Wed Jan 12 23:28:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C7C3A6998 for ; Wed, 12 Jan 2011 23:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geos0cit6ZY3 for ; Wed, 12 Jan 2011 23:28:19 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by core3.amsl.com (Postfix) with ESMTP id B99CD3A695B for ; Wed, 12 Jan 2011 23:28:19 -0800 (PST) Received: from packetdesign.com (vpn-int.packetdesign.com [192.168.0.180]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p0D7Uep9007497; Wed, 12 Jan 2011 23:30:40 -0800 Date: Wed, 12 Jan 2011 23:30:39 -0800 (PST) From: Stephen Casner To: Michael Speer In-Reply-To: <4D2E9B9A.2000206@oracle.com> Message-ID: References: <4D2E9B9A.2000206@oracle.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 07:28:22 -0000 Hmmm, Michael's message makes me think mine may have not been clear. By +1, I meant that I agree with Stephan that splitting AVT into four WGs is a bad idea. -- Steve On Wed, 12 Jan 2011, Michael Speer wrote: > +1, go for it. > > On 1/12/11 8:32 PM, Stephen Casner wrote: > > +1, definitely. > > > > When I was chair, I once thought that AVT should try to draw to a > > close. Later I realized that this was not only unlikely but also not > > required. > > > > -- Steve > > > > On Wed, 12 Jan 2011, Stephan Wenger wrote: > > > > > Hi IESG, > > > > > > As already communicated in Maastricht, I continue to believe that this > > > step > > > is a bad idea. I didn't attend Beijing, and don't know whether there was > > > any discussion about the subject. I didn't see anything mentioned in the > > > AVT minutes, though, nor did I see any discussion since Beijing on > > > ietf@ietf. If there was, some of the points below may be redundant, and I > > > apologize in advance. > > > > > > Essentially, you guys are suggesting to split one "eternal" WG into four. > > > I'm writing "eternal", because I don't see that any of the WGs can fulfill > > > its charter before other work items will likely get chartered with a > > > similar > > > scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads > > > that is probably self-evident. For the XR stuff: metrics pop up all the > > > time, like payload formats. Metrics are also known to make people quick > > > bucks on patent licensing. There will be more metric proposals. If the > > > RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I > > > have my doubts. But that's a different discussion. > > > > > > The positive effects of the split could be > > > -chair workload is split among more people, and > > > -there are more meeting seconds for RTP related work at any given IETF > > > meeting. > > > > > > Assuming unlimited resources, both are good things. Unfortunately, > > > resources are not unlimited. > > > > > > The negative effects are IMO: > > > -the key knowledgeable people in AVT ideally would have to sit in all four > > > meetings so that all four groups can tap their experience. But they may > > > not > > > want to do so, because it leaves less time for cross-area involvement, > > > coordination, and draft-writing outside the AVT sessions, and whatnot. > > > Also, the burden for remote participants in far-away time zones goes up. > > > In > > > other words, the resource meeting-seconds for those people is not > > > unlimited, > > > and they will have to prioritize differently. The result could be that > > > what I called "key knowledgable people" would perhaps not attend the mere > > > RTCP-XR or Payload session; and the guys there may be wasting their time > > > doing work that does not make sense architecturally, just to see the > > > hammer > > > coming down at IETF last call. > > > -more people get chair positions and are burdened with administrative > > > stuff > > > -> less time to do real work > > > -WG scheduling gets more difficult > > > -AD load potentially goes up (someone needs to coordinate between those > > > groups, and the AD would seem to me the natural choice) > > > -there is no reason to believe that the overall manpower availability goes > > > up through this change, so all the inefficiencies introduced go straight > > > against the available cycles. > > > > > > Some of these issues can be solved by joint WG meetings and/or careful > > > chair > > > selection. However, both options have drawbacks as well. A joint session > > > would be counter-productive to the allocation of more meeting minutes. > > > And > > > when you have, say, 8 chairs for four WG, all of which know the RTP > > > architecture well enough, then you have pretty much exhausted, if not > > > overdrawn already, the pool of "key knowledgable people", and burdened > > > them > > > with (in many cases: additional) chair duties. > > > > > > No matter how I see it, splitting the group is not a good idea. > > > > > > Other options to alleviate problems could come to mind: > > > > > > If the problem to be solved is chair-workload: add more chairs (but not 6 > > > of > > > them). > > > If the problem to be solved is meeting-second shortages: have interim > > > meetings, conf calls, etc. In other words, stretch out the AVT meeting in > > > the interval between IETF meetings. Require a web-ex presentation of > > > every > > > draft to be discussed in the AVT session at least 4 weeks before the > > > meeting, with a two hour timeslot for Q/A. Should I continue with this > > > brainstorm? > > > > > > If the problem is something else, I would like to know? > > > > > > Thanks for your consideration, and apologies for the wordcount, > > > > > > Stephan > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > -- > Michael Speer > Principal Software Engineer, Solaris Core OS > Oracle > e-mail: michael.speer@oracle.com > phone: +1 408 276-6943 > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From john.elwell@siemens-enterprise.com Thu Jan 13 00:53:14 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5FD3A69AE; Thu, 13 Jan 2011 00:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWEn6EXv92h0; Thu, 13 Jan 2011 00:53:12 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 89FB53A6996; Thu, 13 Jan 2011 00:53:12 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2982893; Thu, 13 Jan 2011 09:55:23 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 9F2FB1EB82AB; Thu, 13 Jan 2011 09:55:23 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 13 Jan 2011 09:55:23 +0100 From: "Elwell, John" To: Stephan Wenger , "iesg@ietf.org" Date: Thu, 13 Jan 2011 09:55:22 +0100 Thread-Topic: proposed AVT WG split Thread-Index: AcuytnlqizE3AqjoR1KNUkoDDz/uPwAR33NQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 08:53:14 -0000 I have to agree with much, if not all, of what Stephan says. It would help,= of course, if those proposing the change could give a clear statement as t= o what they consider to be broken with the current arrangement.=20 I tend to have an interest in some, but not all, of the activities AVT is e= ngaged in. Therefore, I tend to pay attention to only parts of AVT face-to-= face sessions. It is not clear that the proposed split would make my partic= ipation easier - I suspect I would still be in a position of selecting part= icular topics from each of the WG sessions. If anything it would probably m= ake things harder - 4 WGs would typically involve 4 face-to-face sessions, = rather than the 2 that AVT typically holds, making conflicts with other WGs= in the RAI area (or elsewhere, for that matter) more likely. John > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Stephan Wenger > Sent: 13 January 2011 00:11 > To: iesg@ietf.org > Cc: avt@ietf.org > Subject: [AVT] proposed AVT WG split >=20 > Hi IESG, >=20 > As already communicated in Maastricht, I continue to believe=20 > that this step is a bad idea. I didn't attend Beijing, and=20 > don't know whether there was any discussion about the=20 > subject. I didn't see anything mentioned in the AVT minutes,=20 > though, nor did I see any discussion since Beijing on=20 > ietf@ietf. If there was, some of the points below may be=20 > redundant, and I apologize in advance. >=20 > Essentially, you guys are suggesting to split one "eternal"=20 > WG into four. I'm writing "eternal", because I don't see=20 > that any of the WGs can fulfill its charter before other work=20 > items will likely get chartered with a similar scope, and in=20 > the same WG. For RTP core, RTP extensions, and RTP payloads=20 > that is probably self-evident. For the XR stuff: metrics pop=20 > up all the time, like payload formats. Metrics are also=20 > known to make people quick bucks on patent licensing. There=20 > will be more metric proposals. If the RTCP-XR metrics ever=20 > get momentum in the marketplace, that is. Somehow, I have my=20 > doubts. But that's a different discussion. =20 >=20 > The positive effects of the split could be=20 > -chair workload is split among more people, and=20 > -there are more meeting seconds for RTP related work at any=20 > given IETF meeting. =20 >=20 > Assuming unlimited resources, both are good things. =20 > Unfortunately, resources are not unlimited. >=20 > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to=20 > sit in all four meetings so that all four groups can tap=20 > their experience. But they may not want to do so, because it=20 > leaves less time for cross-area involvement, coordination,=20 > and draft-writing outside the AVT sessions, and whatnot. =20 > Also, the burden for remote participants in far-away time=20 > zones goes up. In other words, the resource meeting-seconds=20 > for those people is not unlimited, and they will have to=20 > prioritize differently. The result could be that what I=20 > called "key knowledgable people" would perhaps not attend the=20 > mere RTCP-XR or Payload session; and the guys there may be=20 > wasting their time doing work that does not make sense=20 > architecturally, just to see the hammer coming down at IETF last call. > -more people get chair positions and are burdened with=20 > administrative stuff -> less time to do real work > -WG scheduling gets more difficult > -AD load potentially goes up (someone needs to coordinate=20 > between those groups, and the AD would seem to me the natural choice) > -there is no reason to believe that the overall manpower=20 > availability goes up through this change, so all the=20 > inefficiencies introduced go straight against the available cycles. >=20 > Some of these issues can be solved by joint WG meetings=20 > and/or careful chair selection. However, both options have=20 > drawbacks as well. A joint session would be=20 > counter-productive to the allocation of more meeting minutes.=20 > And when you have, say, 8 chairs for four WG, all of which=20 > know the RTP architecture well enough, then you have pretty=20 > much exhausted, if not overdrawn already, the pool of "key=20 > knowledgable people", and burdened them with (in many cases:=20 > additional) chair duties. >=20 > No matter how I see it, splitting the group is not a good idea. >=20 > Other options to alleviate problems could come to mind: >=20 > If the problem to be solved is chair-workload: add more=20 > chairs (but not 6 of them). > If the problem to be solved is meeting-second shortages: have=20 > interim meetings, conf calls, etc. In other words, stretch=20 > out the AVT meeting in the interval between IETF meetings. =20 > Require a web-ex presentation of every draft to be discussed=20 > in the AVT session at least 4 weeks before the meeting, with=20 > a two hour timeslot for Q/A. Should I continue with this brainstorm? >=20 > If the problem is something else, I would like to know... >=20 > Thanks for your consideration, and apologies for the wordcount, >=20 > Stephan >=20 >=20 >=20 > = From keith.drage@alcatel-lucent.com Thu Jan 13 10:57:02 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD1D3A6A58; Thu, 13 Jan 2011 10:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.632 X-Spam-Level: X-Spam-Status: No, score=-105.632 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5j9JM1Ahj1y; Thu, 13 Jan 2011 10:57:01 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D62F43A684B; Thu, 13 Jan 2011 10:57:00 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0DIxLD0030492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Jan 2011 19:59:21 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 13 Jan 2011 19:59:21 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Stephan Wenger , "iesg@ietf.org" Date: Thu, 13 Jan 2011 19:59:20 +0100 Thread-Topic: proposed AVT WG split Thread-Index: AcuytnlqizE3AqjoR1KNUkoDDz/uPwAR33NQABSCJUA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "avt@ietf.org" Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 18:57:02 -0000 This is AD initiated rather than WG chair initiated, although the ADs have = been discussing it with the WG chairs, and indeed also with the other RAI c= hairs. One of the issues we do have is WG chair load. Every time I do a review of = the current status of our working group items, it takes me over 3 hours. Th= at is just the sheer quantity of milestones we have. It therefore doesn't h= appen as often as it ought to because that is 3 hours away from doing other= tasks. =20 Currently in each meeting cycle we are starting the publication request pro= cess for on avaerage two documents each - i.e. AVT is forwarding 12 documen= ts a year to IESG. That is also a heavy chair load. The meeting load issues has already been discussed. I believe that the payl= oad group would meet rarely. In formal IETF terms it is really doing an exp= ert review process, but apparently needs a WG to do it, because we haven't = been able to codify all the good practice that an expert review should take= into account. We are not spending a lot of our current meeting time as AVT= discussing new or revised payload types. So your average 2 + 1 AVT sessions will probably turn into 1 + 1 + 1 workin= g group sessions of the new groups if this goes ahead. Keith > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Thursday, January 13, 2011 8:55 AM > To: Stephan Wenger; iesg@ietf.org > Cc: avt@ietf.org > Subject: Re: [AVT] proposed AVT WG split >=20 > I have to agree with much, if not all, of what Stephan says.=20 > It would help, of course, if those proposing the change could=20 > give a clear statement as to what they consider to be broken=20 > with the current arrangement.=20 >=20 > I tend to have an interest in some, but not all, of the=20 > activities AVT is engaged in. Therefore, I tend to pay=20 > attention to only parts of AVT face-to-face sessions. It is=20 > not clear that the proposed split would make my participation=20 > easier - I suspect I would still be in a position of=20 > selecting particular topics from each of the WG sessions. If=20 > anything it would probably make things harder - 4 WGs would=20 > typically involve 4 face-to-face sessions, rather than the 2=20 > that AVT typically holds, making conflicts with other WGs in=20 > the RAI area (or elsewhere, for that matter) more likely. >=20 > John >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of=20 > > Stephan Wenger > > Sent: 13 January 2011 00:11 > > To: iesg@ietf.org > > Cc: avt@ietf.org > > Subject: [AVT] proposed AVT WG split > >=20 > > Hi IESG, > >=20 > > As already communicated in Maastricht, I continue to=20 > believe that this=20 > > step is a bad idea. I didn't attend Beijing, and don't=20 > know whether=20 > > there was any discussion about the subject. I didn't see anything=20 > > mentioned in the AVT minutes, though, nor did I see any discussion=20 > > since Beijing on ietf@ietf. If there was, some of the points below=20 > > may be redundant, and I apologize in advance. > >=20 > > Essentially, you guys are suggesting to split one "eternal"=20 > > WG into four. I'm writing "eternal", because I don't see=20 > that any of=20 > > the WGs can fulfill its charter before other work items will likely=20 > > get chartered with a similar scope, and in the same WG. =20 > For RTP core,=20 > > RTP extensions, and RTP payloads that is probably=20 > self-evident. For=20 > > the XR stuff: metrics pop up all the time, like payload formats. =20 > > Metrics are also known to make people quick bucks on patent=20 > licensing. =20 > > There will be more metric proposals. If the RTCP-XR=20 > metrics ever get=20 > > momentum in the marketplace, that is. Somehow, I have my=20 > doubts. But=20 > > that's a different discussion. > >=20 > > The positive effects of the split could be -chair workload is split=20 > > among more people, and -there are more meeting seconds for=20 > RTP related=20 > > work at any given IETF meeting. > >=20 > > Assuming unlimited resources, both are good things. =20 > > Unfortunately, resources are not unlimited. > >=20 > > The negative effects are IMO: > > -the key knowledgeable people in AVT ideally would have to=20 > sit in all=20 > > four meetings so that all four groups can tap their=20 > experience. But=20 > > they may not want to do so, because it leaves less time for=20 > cross-area=20 > > involvement, coordination, and draft-writing outside the=20 > AVT sessions,=20 > > and whatnot. > > Also, the burden for remote participants in far-away time=20 > zones goes=20 > > up. In other words, the resource meeting-seconds for those=20 > people is=20 > > not unlimited, and they will have to > > prioritize differently. The result could be that what I=20 > > called "key knowledgable people" would perhaps not attend the mere=20 > > RTCP-XR or Payload session; and the guys there may be wasting their=20 > > time doing work that does not make sense architecturally,=20 > just to see=20 > > the hammer coming down at IETF last call. > > -more people get chair positions and are burdened with=20 > administrative=20 > > stuff -> less time to do real work -WG scheduling gets more=20 > difficult=20 > > -AD load potentially goes up (someone needs to coordinate between=20 > > those groups, and the AD would seem to me the natural=20 > choice) -there=20 > > is no reason to believe that the overall manpower=20 > availability goes up=20 > > through this change, so all the inefficiencies introduced=20 > go straight=20 > > against the available cycles. > >=20 > > Some of these issues can be solved by joint WG meetings=20 > and/or careful=20 > > chair selection. However, both options have drawbacks as well. A=20 > > joint session would be counter-productive to the allocation of more=20 > > meeting minutes. > > And when you have, say, 8 chairs for four WG, all of which=20 > know the=20 > > RTP architecture well enough, then you have pretty much=20 > exhausted, if=20 > > not overdrawn already, the pool of "key knowledgable people", and=20 > > burdened them with (in many cases: > > additional) chair duties. > >=20 > > No matter how I see it, splitting the group is not a good idea. > >=20 > > Other options to alleviate problems could come to mind: > >=20 > > If the problem to be solved is chair-workload: add more chairs (but=20 > > not 6 of them). > > If the problem to be solved is meeting-second shortages:=20 > have interim=20 > > meetings, conf calls, etc. In other words, stretch out the AVT=20 > > meeting in the interval between IETF meetings. > > Require a web-ex presentation of every draft to be discussed in the=20 > > AVT session at least 4 weeks before the meeting, with a two hour=20 > > timeslot for Q/A. Should I continue with this brainstorm? > >=20 > > If the problem is something else, I would like to know... > >=20 > > Thanks for your consideration, and apologies for the wordcount, > >=20 > > Stephan > >=20 > >=20 > >=20 > >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > = From Even.roni@huawei.com Thu Jan 13 11:56:39 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDC928B56A; Thu, 13 Jan 2011 11:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.354 X-Spam-Level: X-Spam-Status: No, score=-92.354 tagged_above=-999 required=5 tests=[AWL=5.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_WORKS=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byIXlBDEfkk1; Thu, 13 Jan 2011 11:56:30 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E0D403A6A74; Thu, 13 Jan 2011 11:56:29 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ009SN8TUGI@szxga05-in.huawei.com>; Fri, 14 Jan 2011 03:58:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ000PW8TUCB@szxga05-in.huawei.com>; Fri, 14 Jan 2011 03:58:42 +0800 (CST) Received: from YOUR6108 ([128.107.29.146]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ00C1X8TRZ0@szxml02-in.huawei.com>; Fri, 14 Jan 2011 03:58:42 +0800 (CST) Date: Thu, 13 Jan 2011 21:59:19 +0200 From: Roni Even In-reply-to: To: 'Stephan Wenger' , iesg@ietf.org Message-id: <004e01cbb35c$5f0b2480$1d216d80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_uFDuSh4FTLfjLnSTz10brg)" Content-language: he Thread-index: Acuytnu96nP31IURSDKeDwcxVS/RygApJgKQ References: Cc: avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 19:56:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_uFDuSh4FTLfjLnSTz10brg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I agree with Stephan view. My experience in AVT is that the WG review process depends on a number of individual that has a general interest in RTP and since payloads and RTCP XR are discussed in the same WG are contributing to this effort. Breaking the WG to 3 or 4 will not be helpful for these persons. If the issue is load on chairs we can add one more chair to help with document shepherding As for the current proposal if there is a strong support for it I think that the XR WG make sense bit should include the monitoring architecture document to it. As for RTP core and text this is an artificial division. We need one WG and if there is work that is not in the charter it should go to DISPATCH who will decide if to have a new group or assign it to AVT. The payload work should be part of the main AVT group since we want the people who are interested in AVT but are following and helping the payload work just because it is part of AVT to continue and not go away. To summarize the only division I can see if for RTCP XR for monitoring WG. Thanks Roni Even as individual From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Thursday, January 13, 2011 2:11 AM To: iesg@ietf.org Cc: avt@ietf.org Subject: [AVT] proposed AVT WG split Hi IESG, As already communicated in Maastricht, I continue to believe that this step is a bad idea. I didn't attend Beijing, and don't know whether there was any discussion about the subject. I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf. If there was, some of the points below may be redundant, and I apologize in advance. Essentially, you guys are suggesting to split one "eternal" WG into four. I'm writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads that is probably self-evident. For the XR stuff: metrics pop up all the time, like payload formats. Metrics are also known to make people quick bucks on patent licensing. There will be more metric proposals. If the RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I have my doubts. But that's a different discussion. The positive effects of the split could be -chair workload is split among more people, and -there are more meeting seconds for RTP related work at any given IETF meeting. Assuming unlimited resources, both are good things. Unfortunately, resources are not unlimited. The negative effects are IMO: -the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience. But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot. Also, the burden for remote participants in far-away time zones goes up. In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently. The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call. -more people get chair positions and are burdened with administrative stuff -> less time to do real work -WG scheduling gets more difficult -AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice) -there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles. Some of these issues can be solved by joint WG meetings and/or careful chair selection. However, both options have drawbacks as well. A joint session would be counter-productive to the allocation of more meeting minutes. And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties. No matter how I see it, splitting the group is not a good idea. Other options to alleviate problems could come to mind: If the problem to be solved is chair-workload: add more chairs (but not 6 of them). If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc. In other words, stretch out the AVT meeting in the interval between IETF meetings. Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A. Should I continue with this brainstorm? If the problem is something else, I would like to know. Thanks for your consideration, and apologies for the wordcount, Stephan __________ Information from ESET NOD32 Antivirus, version of virus signature database 5782 (20110112) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5782 (20110112) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --Boundary_(ID_uFDuSh4FTLfjLnSTz10brg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I agree with Stephan view. My experience in AVT is that the WG review process depends on a number of individual that has a general interest in RTP and since payloads and RTCP XR are discussed in the same WG are contributing to this effort. Breaking the WG to 3 or 4 will not be helpful for these persons. If the issue is load on chairs we can add one more chair to help with document shepherding

As for the current proposal if there is a strong supp ort for make sense bit should include the monitoring architecture document to it.

As for RTP core and text this is an artificial division. We need one WG and if there is work that is not in the charter it  should go to DISPATCH who will decide if to have a new group or assign it to AVT.

The payload work should be part of the main AVT group since we want the people who are interested in AVT but are following and helping the payload work just because it is part of AVT to continue and not go away.

To summarize the only division I can see if for RTCP XR for monitoring WG.

 

Thanks

Roni Even as individual

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Thursday, January 13, 2011 2:11 AM
To: iesg@ietf.org
Cc: avt@ietf.org
Subject WG split

 

Hi IESG,

 

As already communicated in Maastricht, I continue to believe that this step is a bad idea.  I didn't attend Beijing, and don't know whether there was any discussion about the subject.  I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf.  If there was, some of the points below may be redundant, and I apologize in advance.

&nb >

Essentially, you guys are suggesting to split one "eternal" WG into four.  I'm writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same WG.  For RTP core, RTP extensions, and RTP payloads that is probably self-evident.  For the XR stuff: metrics pop up all the time, like payload formats.  Metrics are also known to make people quick bucks on patent licensing.  There will be more metric proposals.  If the RTCP-XR metrics ever get momentum in the marketplace, that is.  Somehow, I have my doubts.  But that's a different discussion.  

 

The positive effects of the split could be 

-chair workload is split among more people, and 

-there are more meeting seconds for RTP related work at any given IETF meeting.  

 

Assuming unlimited resources, both are good things.  Unfortunately, resources are not unlimited.

The negative effects are IMO:

-the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience.  But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot.  Also, the burden for remote participants in far-away time zones goes up.  In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently.    The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing wor k that d ecturally, just to see the hammer coming down at IETF last call.

-more people get chair positions and are burdened with administrative stuff -> less time to do real work

-WG scheduling gets more difficult

-AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice)

-there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straigh ycles.

 

Some of these issues can be solved by joint WG meetings and/or careful chair selection.  However, both options have drawbacks as well.  A joint session would be counter-productive to the allocation of more meeting minutes.  And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties.

 

No matter how I see it, splitting the group is not a good idea.

 

Other options to alleviate problems could come to mind:

 

If the problem to be solved is chair-workload: add more chairs (but not 6 of them).

If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc. &n bsp;In o he AVT meeting in the interval between IETF meetings.  Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A.  Should I continue with this brainstorm?

 

If the problem is something else, I would like to know…

 

Thanks for your consideration, and apologies for the wordcount,

 

Stephan

 

 

 



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5782 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivir us, vers tabase 5782 (20110112) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_uFDuSh4FTLfjLnSTz10brg)-- From rjsparks@nostrum.com Thu Jan 13 13:25:36 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400CB3A6A90; Thu, 13 Jan 2011 13:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgxvWj1tsis2; Thu, 13 Jan 2011 13:25:34 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0BB2A3A6BDA; Thu, 13 Jan 2011 13:25:33 -0800 (PST) Received: from [192.168.2.105] (pool-173-74-105-210.dllstx.fios.verizon.net [173.74.105.210]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0DLRtYd010105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Jan 2011 15:27:56 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-98-966779175 From: Robert Sparks In-Reply-To: Date: Thu, 13 Jan 2011 15:27:55 -0600 Message-Id: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> References: To: Stephan Wenger X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.74.105.210 is authenticated by a trusted mechanism) Cc: IETF AVT WG , IESG IESG Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:25:36 -0000 --Apple-Mail-98-966779175 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Stephan - As I noted in response to your comments in Maastricht, I disagree. There are separable streams of work in AVT - it is really multiple = working groups in one shell at the moment. While there are key people currently in AVT that would overlap these = groups, they are not the majority of the contributors to the different = types of activities. The intended positive effect of this explicit division is to allow these = different streams to better parallelize, on list between meetings, not = just during the IETF in-person meeting time.=20 We'd like to try to channel these streams separately for a while. That = will require some additional coordination work from the area directors = and chairs, but it will bring significant benefits, especially in being able to better = prioritize work items within the streams. I realize that for folks like = you, who will actively participate=20 in all of the efforts, the benefits are more limited. I have had several participants express frustration, for example, with = the way the RAMs work eclipsed basic architectural work in AVT.=20 While that could be managed in place (we could have only one working = group per area in the extreme), it has shown itself to be difficult=20 with the set of things this group is working on. I also expect the separation will make it easier to evaluate when the = energy for a particular effort (such as the XR metrics you point to = below) exists,=20 and when that level of energy changes. Yes, conflicts between these working groups when they do meet in person = will have to be managed carefully, but we have mechanisms for that. As = Keith noted separately, we do not anticipate this significantly increasing the = number-of-minutes footprint on any given in-person IETF meeting. Also, = your comments assume all=20 four of these groups would have a session at each in-person meeting. I = don't expect that to be the case. RjS On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: > Hi IESG, >=20 > As already communicated in Maastricht, I continue to believe that this = step is a bad idea. I didn't attend Beijing, and don't know whether = there was any discussion about the subject. I didn't see anything = mentioned in the AVT minutes, though, nor did I see any discussion since = Beijing on ietf@ietf. If there was, some of the points below may be = redundant, and I apologize in advance. >=20 > Essentially, you guys are suggesting to split one "eternal" WG into = four. I'm writing "eternal", because I don't see that any of the WGs = can fulfill its charter before other work items will likely get = chartered with a similar scope, and in the same WG. For RTP core, RTP = extensions, and RTP payloads that is probably self-evident. For the XR = stuff: metrics pop up all the time, like payload formats. Metrics are = also known to make people quick bucks on patent licensing. There will = be more metric proposals. If the RTCP-XR metrics ever get momentum in = the marketplace, that is. Somehow, I have my doubts. But that's a = different discussion. =20 >=20 > The positive effects of the split could be=20 > -chair workload is split among more people, and=20 > -there are more meeting seconds for RTP related work at any given IETF = meeting. =20 >=20 > Assuming unlimited resources, both are good things. Unfortunately, = resources are not unlimited. >=20 > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to sit in all = four meetings so that all four groups can tap their experience. But = they may not want to do so, because it leaves less time for cross-area = involvement, coordination, and draft-writing outside the AVT sessions, = and whatnot. Also, the burden for remote participants in far-away time = zones goes up. In other words, the resource meeting-seconds for those = people is not unlimited, and they will have to prioritize differently. = The result could be that what I called "key knowledgable people" would = perhaps not attend the mere RTCP-XR or Payload session; and the guys = there may be wasting their time doing work that does not make sense = architecturally, just to see the hammer coming down at IETF last call. > -more people get chair positions and are burdened with administrative = stuff -> less time to do real work > -WG scheduling gets more difficult > -AD load potentially goes up (someone needs to coordinate between = those groups, and the AD would seem to me the natural choice) > -there is no reason to believe that the overall manpower availability = goes up through this change, so all the inefficiencies introduced go = straight against the available cycles. >=20 > Some of these issues can be solved by joint WG meetings and/or careful = chair selection. However, both options have drawbacks as well. A joint = session would be counter-productive to the allocation of more meeting = minutes. And when you have, say, 8 chairs for four WG, all of which = know the RTP architecture well enough, then you have pretty much = exhausted, if not overdrawn already, the pool of "key knowledgable = people", and burdened them with (in many cases: additional) chair = duties. >=20 > No matter how I see it, splitting the group is not a good idea. >=20 > Other options to alleviate problems could come to mind: >=20 > If the problem to be solved is chair-workload: add more chairs (but = not 6 of them). > If the problem to be solved is meeting-second shortages: have interim = meetings, conf calls, etc. In other words, stretch out the AVT meeting = in the interval between IETF meetings. Require a web-ex presentation of = every draft to be discussed in the AVT session at least 4 weeks before = the meeting, with a two hour timeslot for Q/A. Should I continue with = this brainstorm? >=20 > If the problem is something else, I would like to know=85 >=20 > Thanks for your consideration, and apologies for the wordcount, >=20 > Stephan >=20 >=20 >=20 --Apple-Mail-98-966779175 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = IESG,

As already communicated in Maastricht, I = continue to believe that this step is a bad idea.  I didn't attend = Beijing, and don't know whether there was any discussion about the = subject.  I didn't see anything mentioned in the AVT minutes, = though, nor did I see any discussion since Beijing on ietf@ietf. =  If there was, some of the points below may be redundant, and I = apologize in advance.

Essentially, you guys are = suggesting to split one "eternal" WG into four.  I'm writing = "eternal", because I don't see that any of the WGs can fulfill its = charter before other work items will likely get chartered with a similar = scope, and in the same WG.  For RTP core, RTP extensions, and RTP = payloads that is probably self-evident.  For the XR stuff: metrics = pop up all the time, like payload formats.  Metrics are also known = to make people quick bucks on patent licensing.  There will be more = metric proposals.  If the RTCP-XR metrics ever get momentum in the = marketplace, that is.  Somehow, I have my doubts.  But that's = a different discussion.  

The positive = effects of the split could be 
-chair workload is split = among more people, and 
-there are more meeting seconds = for RTP related work at any given IETF meeting. =  

Assuming unlimited resources, both are = good things.  Unfortunately, resources are not = unlimited.

The negative effects are = IMO:
-the key knowledgeable people in AVT ideally would have = to sit in all four meetings so that all four groups can tap their = experience.  But they may not want to do so, because it leaves less = time for cross-area involvement, coordination, and draft-writing outside = the AVT sessions, and whatnot.  Also, the burden for remote = participants in far-away time zones goes up.  In other words, the = resource meeting-seconds for those people is not unlimited, and they = will have to prioritize differently.    The result could be = that what I called "key knowledgable people" would perhaps not attend = the mere RTCP-XR or Payload session; and the guys there may be wasting = their time doing work that does not make sense architecturally, just to = see the hammer coming down at IETF last call.
-more people get = chair positions and are burdened with administrative stuff -> less = time to do real work
-WG scheduling gets more = difficult
-AD load potentially goes up (someone needs to = coordinate between those groups, and the AD would seem to me the natural = choice)
-there is no reason to believe that the overall = manpower availability goes up through this change, so all the = inefficiencies introduced go straight against the available = cycles.

Some of these issues can be solved by = joint WG meetings and/or careful chair selection.  However, both = options have drawbacks as well.  A joint session would be = counter-productive to the allocation of more meeting minutes.  And = when you have, say, 8 chairs for four WG, all of which know the RTP = architecture well enough, then you have pretty much exhausted, if not = overdrawn already, the pool of "key knowledgable people", and burdened = them with (in many cases: additional) chair = duties.

No matter how I see it, splitting the = group is not a good idea.

Other options to = alleviate problems could come to mind:

If the = problem to be solved is chair-workload: add more chairs (but not 6 of = them).
If the problem to be solved is meeting-second = shortages: have interim meetings, conf calls, etc.  In other words, = stretch out the AVT meeting in the interval between IETF meetings. =  Require a web-ex presentation of every draft to be discussed in = the AVT session at least 4 weeks before the meeting, with a two hour = timeslot for Q/A.  Should I continue with this = brainstorm?

If the problem is something else, I = would like to know=85

Thanks for your = consideration, and apologies for the = wordcount,

Stephan


<= /div>


= --Apple-Mail-98-966779175-- From fluffy@cisco.com Thu Jan 13 13:31:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5283A6BDF; Thu, 13 Jan 2011 13:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POqOQQ8+Arnn; Thu, 13 Jan 2011 13:31:32 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 781FA3A6A80; Thu, 13 Jan 2011 13:31:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF3+Lk2rR7Ht/2dsb2JhbACkTXOkMpg6hUwEhGiGKIMi Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2011 21:33:56 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0DLXs9c024239; Thu, 13 Jan 2011 21:33:55 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Thu, 13 Jan 2011 14:35:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephan Wenger X-Mailer: Apple Mail (2.1082) Cc: iesg@ietf.org, avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:31:35 -0000 Stephan, I see this differently than you. I think you are assuming that = four WG will take on more work in net than just one. First I don't think = this is true, and even if it is, then I would see that as a good thing = as it would be proof that the 1 WG was blocking useful work that the = community wanted to do. Let me address your cons inline. On Jan 12, 2011, at 5:11 PM, Stephan Wenger wrote: >=20 >=20 > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to sit in all = four meetings so that all four groups can tap their experience. I view that as the current situation. Right now, given the times on the = agenda move around in a meeting, everyone has to be at all the AVT = related talks regardless if they want to see just some parts of them or = all of them. It seem like the split would improve this. It can't make it = worse.=20 > But they may not want to do so, because it leaves less time for = cross-area involvement, coordination, and draft-writing outside the AVT = sessions, and whatnot. Also, the burden for remote participants in = far-away time zones goes up. In other words, the resource = meeting-seconds for those people is not unlimited, and they will have to = prioritize differently. The result could be that what I called "key = knowledgable people" would perhaps not attend the mere RTCP-XR or = Payload session; and the guys there may be wasting their time doing work = that does not make sense architecturally, just to see the hammer coming = down at IETF last call. > -more people get chair positions and are burdened with administrative = stuff -> less time to do real work Given the current chair bottlenecks, and the fact we have people that = would like to do this, I view the bunch more chairs a pro not a con > -WG scheduling gets more difficult Having been very involved with scheduling RAI for several years, I = strongly disagree. Right now you can't conflict AVT with anything, yet I = bet you could conflict the XR metrics with say BLISS without too many = problems.=20 > -AD load potentially goes up (someone needs to coordinate between = those groups, and the AD would seem to me the natural choice) The AD is going to have to be aware of all the work related to RTP = regardless of if it is split in one group or four. I know when I was AD = for AVT I felt this split would make things easier for me.=20 > -there is no reason to believe that the overall manpower availability = goes up through this change, so all the inefficiencies introduced go = straight against the available cycles. I agree the manpower to do AVT technical work does not improve. However, = having people who care less about 1 of the four stream be able to ignore = theses meetings and go elsewhere would improve the manpower available = available to other topics. The administrative work would go from two = chairs and split over more. I don't think it significantly increases the = total amount of admin-a-triva and having more people doing that is = likely to reduce administrative delays. Now you might think the = administrative delays have no impact on how many person hours are = required to do the technical work but if an admin delay causes something = to sit for 3 months, then all the technical people need to spend a bunch = of time reloading the context in their brain and getting back up to = speed on where the technical work is. This decreases the efficiently of = the the technical work.=20 >=20 > Some of these issues can be solved by joint WG meetings and/or careful = chair selection. However, both options have drawbacks as well. A joint = session would be counter-productive to the allocation of more meeting = minutes. And when you have, say, 8 chairs for four WG, all of which = know the RTP architecture well enough, then you have pretty much = exhausted, if not overdrawn already, the pool of "key knowledgable = people", and burdened them with (in many cases: additional) chair = duties. >=20 > No matter how I see it, splitting the group is not a good idea. >=20 > Other options to alleviate problems could come to mind: >=20 > If the problem to be solved is chair-workload: add more chairs (but = not 6 of them). The more chairs you have for a single WG, the more all chairs think some = other chair will do it and nothing happens. See track record of sipping = chairs for a concrete example of this and those were all chairs that had = proven track record of being effect chairs in other WGs. I agree with = your point that if all the top RTP architecture people were suddenly = spending all their time doing admin work this would be a disaster. I'm = sure the ADs won't do that and that theses people would not accept. But = I do think we need to ask, is our pool of really top RTP people that get = the architecture growing or shrinking? What can we do to grow it? = Dropping in some keen and smart person as chair is a not bad way of = growing deep expertise in an area.=20 > If the problem to be solved is meeting-second shortages: have interim = meetings, conf calls, etc. In other words, stretch out the AVT meeting = in the interval between IETF meetings. Require a web-ex presentation of = every draft to be discussed in the AVT session at least 4 weeks before = the meeting, with a two hour timeslot for Q/A. Should I continue with = this brainstorm? ( ahhgg I see all kinds of problems with that but lets ignore theses, = this is all based on the idea that we want to do more work which I think = is an orthogonal issue to the split proposal) >=20 > If the problem is something else, I would like to know=85 >=20 > Thanks for your consideration, and apologies for the wordcount, When I read what you are saying, I think much of it can be tracked back = to if we decide to try and do more work in the 4 groups than we were = doing in one group, that may not be a good thing. I agree with that and = think we need to manage that careful but that is equally true across the = area as a whole as it is in any single WG. The IETF as a whole is = familiar with managing that trade off.=20 >=20 > Stephan >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Thu Jan 13 13:53:00 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44063A687E; Thu, 13 Jan 2011 13:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.678 X-Spam-Level: X-Spam-Status: No, score=-96.678 tagged_above=-999 required=5 tests=[AWL=7.817, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhULNdyL+Kov; Thu, 13 Jan 2011 13:52:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5117B3A6848; Thu, 13 Jan 2011 13:52:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ005VOE7XK2@szxga04-in.huawei.com>; Fri, 14 Jan 2011 05:55:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ009PLE7XP2@szxga04-in.huawei.com>; Fri, 14 Jan 2011 05:55:09 +0800 (CST) Received: from YOUR6108 ([128.107.29.146]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ0097RE7UKE@szxml01-in.huawei.com>; Fri, 14 Jan 2011 05:55:09 +0800 (CST) Date: Thu, 13 Jan 2011 23:56:07 +0200 From: Roni Even In-reply-to: To: 'Cullen Jennings' , 'Stephan Wenger' Message-id: <006e01cbb36c$b0eb6d90$12c248b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: he Content-transfer-encoding: 7BIT Thread-index: AcuzaZ5cMJ9qhT1QR6+1LjBNtoyWywAAf7ig References: Cc: iesg@ietf.org, avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 21:53:00 -0000 Hi Cullen, I would like to point out that the AVT work was split between the two Ads so maybe we need a third AD to help with the work. I would also to state that I did not complain about work load. Some of the work is limited by the editors and reviewers. As for you other comments, see inline. Roni Even > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Thursday, January 13, 2011 11:36 PM > To: Stephan Wenger > Cc: iesg@ietf.org; avt@ietf.org > Subject: Re: [AVT] proposed AVT WG split > > > Stephan, I see this differently than you. I think you are assuming that > four WG will take on more work in net than just one. First I don't > think this is true, and even if it is, then I would see that as a good > thing as it would be proof that the 1 WG was blocking useful work that > the community wanted to do. Let me address your cons inline. > > > On Jan 12, 2011, at 5:11 PM, Stephan Wenger wrote: > > > > > > > The negative effects are IMO: > > -the key knowledgeable people in AVT ideally would have to sit in all > four meetings so that all four groups can tap their experience. > > I view that as the current situation. Right now, given the times on the > agenda move around in a meeting, everyone has to be at all the AVT > related talks regardless if they want to see just some parts of them or > all of them. It seem like the split would improve this. It can't make > it worse. [Roni Even] I see this as a pro since we get the relevant people in the meeting while if we divide I believe that some of them will not follow the payload and RTCP XR work. > > > But they may not want to do so, because it leaves less time for > cross-area involvement, coordination, and draft-writing outside the AVT > sessions, and whatnot. Also, the burden for remote participants in > far-away time zones goes up. In other words, the resource meeting- > seconds for those people is not unlimited, and they will have to > prioritize differently. The result could be that what I called "key > knowledgable people" would perhaps not attend the mere RTCP-XR or > Payload session; and the guys there may be wasting their time doing > work that does not make sense architecturally, just to see the hammer > coming down at IETF last call. > > -more people get chair positions and are burdened with administrative > stuff -> less time to do real work > > Given the current chair bottlenecks, and the fact we have people that > would like to do this, I view the bunch more chairs a pro not a con > > > -WG scheduling gets more difficult > > Having been very involved with scheduling RAI for several years, I > strongly disagree. Right now you can't conflict AVT with anything, yet > I bet you could conflict the XR metrics with say BLISS without too many > problems. [Roni Even] The conflicts will continue wand will be bigger since more chairs add conflicts (each chair has different preferences). > > > -AD load potentially goes up (someone needs to coordinate between > those groups, and the AD would seem to me the natural choice) > > The AD is going to have to be aware of all the work related to RTP > regardless of if it is split in one group or four. I know when I was AD > for AVT I felt this split would make things easier for me. > > > -there is no reason to believe that the overall manpower availability > goes up through this change, so all the inefficiencies introduced go > straight against the available cycles. > > I agree the manpower to do AVT technical work does not improve. > However, having people who care less about 1 of the four stream be able > to ignore theses meetings and go elsewhere would improve the manpower > available available to other topics. The administrative work would go > from two chairs and split over more. I don't think it significantly > increases the total amount of admin-a-triva and having more people > doing that is likely to reduce administrative delays. Now you might > think the administrative delays have no impact on how many person hours > are required to do the technical work but if an admin delay causes > something to sit for 3 months, then all the technical people need to > spend a bunch of time reloading the context in their brain and getting > back up to speed on where the technical work is. This decreases the > efficiently of the technical work. [Roni Even] Some of the delays is not due to the chairs but to the editors of the drafts. This is mostly true for payload. It also depends on how many items the Ads allow. We always have the DISPATCH WG for non chartered work. > > > > > Some of these issues can be solved by joint WG meetings and/or > careful chair selection. However, both options have drawbacks as well. > A joint session would be counter-productive to the allocation of more > meeting minutes. And when you have, say, 8 chairs for four WG, all of > which know the RTP architecture well enough, then you have pretty much > exhausted, if not overdrawn already, the pool of "key knowledgable > people", and burdened them with (in many cases: additional) chair > duties. > > > > No matter how I see it, splitting the group is not a good idea. > > > > Other options to alleviate problems could come to mind: > > > > If the problem to be solved is chair-workload: add more chairs (but > not 6 of them). > > The more chairs you have for a single WG, the more all chairs think > some other chair will do it and nothing happens. See track record of > sipping chairs for a concrete example of this and those were all chairs > that had proven track record of being effect chairs in other WGs. I > agree with your point that if all the top RTP architecture people were > suddenly spending all their time doing admin work this would be a > disaster. I'm sure the ADs won't do that and that theses people would > not accept. But I do think we need to ask, is our pool of really top > RTP people that get the architecture growing or shrinking? What can we > do to grow it? Dropping in some keen and smart person as chair is a not > bad way of growing deep expertise in an area. > > > If the problem to be solved is meeting-second shortages: have interim > meetings, conf calls, etc. In other words, stretch out the AVT meeting > in the interval between IETF meetings. Require a web-ex presentation > of every draft to be discussed in the AVT session at least 4 weeks > before the meeting, with a two hour timeslot for Q/A. Should I > continue with this brainstorm? > ( ahhgg I see all kinds of problems with that but lets ignore theses, > this is all based on the idea that we want to do more work which I > think is an orthogonal issue to the split proposal) > > > > > If the problem is something else, I would like to know. > > > > Thanks for your consideration, and apologies for the wordcount, > > When I read what you are saying, I think much of it can be tracked back > to if we decide to try and do more work in the 4 groups than we were > doing in one group, that may not be a good thing. I agree with that and > think we need to manage that careful but that is equally true across > the area as a whole as it is in any single WG. The IETF as a whole is > familiar with managing that trade off. > > > > > Stephan > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From Even.roni@huawei.com Thu Jan 13 14:01:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB393A6BE9; Thu, 13 Jan 2011 14:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.794 X-Spam-Level: X-Spam-Status: No, score=-97.794 tagged_above=-999 required=5 tests=[AWL=6.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AIqaW61LW+E; Thu, 13 Jan 2011 14:01:13 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E6B323A6BE7; Thu, 13 Jan 2011 14:01:12 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ003ODELPJT@szxga04-in.huawei.com>; Fri, 14 Jan 2011 06:03:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ00FBVELPI4@szxga04-in.huawei.com>; Fri, 14 Jan 2011 06:03:25 +0800 (CST) Received: from YOUR6108 ([128.107.29.146]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ001ZTELJVD@szxml02-in.huawei.com>; Fri, 14 Jan 2011 06:03:25 +0800 (CST) Date: Fri, 14 Jan 2011 00:04:24 +0200 From: Roni Even In-reply-to: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> To: 'Robert Sparks' , 'Stephan Wenger' Message-id: <006f01cbb36d$da96bc70$8fc43550$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_K2bGJVJirFlXIlOz7R3VXA)" Content-language: he Thread-index: AcuzaMv1Qz6v7Q8pSJK5dV2RQDe/ZAABJtpA References: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> Cc: 'IETF AVT WG' , 'IESG IESG' Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 22:01:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_K2bGJVJirFlXIlOz7R3VXA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Roberts, I do not think that the RAMS work should be the motivation to split AVT. 1. RAMS in today's structure should have gone to DISPATCH and not to AVT 2. The time it took was due to discussions on the correctness of the general solution and not because of AVT load. It always was the high priority work in AVT. Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Thursday, January 13, 2011 11:28 PM To: Stephan Wenger Cc: IETF AVT WG; IESG IESG Subject: Re: [AVT] proposed AVT WG split Stephan - As I noted in response to your comments in Maastricht, I disagree. There are separable streams of work in AVT - it is really multiple working groups in one shell at the moment. While there are key people currently in AVT that would overlap these groups, they are not the majority of the contributors to the different types of activities. The intended positive effect of this explicit division is to allow these different streams to better parallelize, on list between meetings, not just during the IETF in-person meeting time. We'd like to try to channel these streams separately for a while. That will require some additional coordination work from the area directors and chairs, but it will bring significant benefits, especially in being able to better prioritize work items within the streams. I realize that for folks like you, who will actively participate in all of the efforts, the benefits are more limited. I have had several participants express frustration, for example, with the way the RAMs work eclipsed basic architectural work in AVT. While that could be managed in place (we could have only one working group per area in the extreme), it has shown itself to be difficult with the set of things this group is working on. I also expect the separation will make it easier to evaluate when the energy for a particular effort (such as the XR metrics you point to below) exists, and when that level of energy changes. Yes, conflicts between these working groups when they do meet in person will have to be managed carefully, but we have mechanisms for that. As Keith noted separately, we do not anticipate this significantly increasing the number-of-minutes footprint on any given in-person IETF meeting. Also, your comments assume all four of these groups would have a session at each in-person meeting. I don't expect that to be the case. RjS On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: Hi IESG, As already communicated in Maastricht, I continue to believe that this step is a bad idea. I didn't attend Beijing, and don't know whether there was any discussion about the subject. I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf. If there was, some of the points below may be redundant, and I apologize in advance. Essentially, you guys are suggesting to split one "eternal" WG into four. I'm writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same WG. For RTP core, RTP extensions, and RTP payloads that is probably self-evident. For the XR stuff: metrics pop up all the time, like payload formats. Metrics are also known to make people quick bucks on patent licensing. There will be more metric proposals. If the RTCP-XR metrics ever get momentum in the marketplace, that is. Somehow, I have my doubts. But that's a different discussion. The positive effects of the split could be -chair workload is split among more people, and -there are more meeting seconds for RTP related work at any given IETF meeting. Assuming unlimited resources, both are good things. Unfortunately, resources are not unlimited. The negative effects are IMO: -the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience. But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot. Also, the burden for remote participants in far-away time zones goes up. In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently. The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call. -more people get chair positions and are burdened with administrative stuff -> less time to do real work -WG scheduling gets more difficult -AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice) -there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles. Some of these issues can be solved by joint WG meetings and/or careful chair selection. However, both options have drawbacks as well. A joint session would be counter-productive to the allocation of more meeting minutes. And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties. No matter how I see it, splitting the group is not a good idea. Other options to alleviate problems could come to mind: If the problem to be solved is chair-workload: add more chairs (but not 6 of them). If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc. In other words, stretch out the AVT meeting in the interval between IETF meetings. Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meeting, with a two hour timeslot for Q/A. Should I continue with this brainstorm? If the problem is something else, I would like to know. Thanks for your consideration, and apologies for the wordcount, Stephan __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --Boundary_(ID_K2bGJVJirFlXIlOz7R3VXA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Roberts,

I do not think that the RAMS work should be the motivation to split AVT.

1.       RAMS in today's structure should have gone to D ISPATCH

2.       The time it took was due to discussions on the correctness of the general solution and not because of AVT load. It always was the high priority work in AVT.

Roni Even

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: Thursday, January 13, 2011 11:28 PM
To: Stephan Wenger
Cc: IETF AVT WG; IESG IESG
Subject: Re: [AVT] proposed AVT WG split

 

Stephan -

 

As I noted in response to your comments in Maastricht, I disagree.

 

There are separable streams of work in AVT - it is really multiple working groups in one shell at the moment.

 

The intended positive effect of this explicit division is to allow these different streams to better parallelize, on list between meetings, not just during the IETF

in-person meeting time. 

 

We'd like to try to channel these streams separately for a while. That will require some additional coordination work from the area directors and chairs, but

it will bring significant benefits, especially in being able to better prioritize work items within the streams.  I realize that for folks like you, who will actively participate 

in all of the efforts, the ben :p>

 

I have had several participants express frustration, for example, with the way the RAMs work eclipsed basic architectural work in AVT. 

While that could be  managed in place  (we could have only one working group per area in the extreme), it has shown itself to be difficult 

with the set of things this group is working on.

 

I also expect  the separation will make it easier to evaluate when the energy for a particular effort (such as the XR metrics you point to below) exists, 

and when that level of energy changes.

 

separately, we do not anticipate this significantly increasing the number-of-minutes footprint on any given in-person IETF meeting. Also, your comments assume all 

four of these groups would have a session at each in-person meeting. I don't expect that to be the case.

 

 

RjS

 

 

On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote:



 

As already communicated in Maastricht, I continue to believe that this step is a bad idea.  I didn't attend Beijing, and don't know whether there was any discussion about the subject.  I didn't see anything mentioned in the AVT minutes, though, nor did I see any discussion since Beijing on ietf@ietf.  If there was, some of the points below may be redundant, and I apologize in advance.

 

Essentially, you guys are suggesting to split one "etern al" writing "eternal", because I don't see that any of the WGs can fulfill its charter before other work items will likely get chartered with a similar scope, and in the same WG.  For RTP core, RTP extensions, and RTP payloads that is probably self-evident.  For the XR stuff: metrics pop up all the time, like payload formats.  Metrics are also known to make people quick bucks on patent licensing.  There will be more metric proposals.  If the RTCP-XR metrics ever get momentum in the marketplace, that is.  Somehow, I have my doubts.  But that's a different discussion.  

 

The positive effects of the split could be 

-chair workload is split among more people, and 

-there are more meeting seconds for RTP related work at any given IETF meeting.  

 

Assuming unlimited resources, both are good things.  Unfortunately, resources are not unlimited.

 

The negative effects are IMO:

-the key knowledgeable people in AVT ideally would have to sit in all four meetings so that all four groups can tap their experience.  But they may not want to do so, because it leaves less time for cross-area involvement, coordination, and draft-writing outside the AVT sessions, and whatnot.  Also, the burden for remote participants in far-away time zones goes up.  In other words, the resource meeting-seconds for those people is not unlimited, and they will have to prioritize differently.    The result could be that what I called "key knowledgable people" would perhaps not attend the mere RTCP-XR or Payload session; and the guys there may be wasting their time doing work that does not make sense architecturally, just to see the hammer coming down at IETF last call.

-WG scheduling gets more difficult

-AD load potentially goes up (someone needs to coordinate between those groups, and the AD would seem to me the natural choice)

-there is no reason to believe that the overall manpower availability goes up through this change, so all the inefficiencies introduced go straight against the available cycles.

 

Some of these issues can be solved by joint WG meetings and/or careful chair selection.  However, both options have drawbacks as well.  A joint session would be counter-productive to the allocation of more meeting minutes.  And when you have, say, 8 chairs for four WG, all of which know the RTP architecture well enough, then you have pretty much exhausted, if not overdrawn already, the pool of "key knowledgable people", and burdened them with (in many cases: additional) chair duties.

 

No matter how I see it, splitting the group is not a good idea.

 

Other options to alleviate problems could come to mind:

 

If the problem to be solved is chair-workload: add more chairs (but not 6 of them).

If the problem to be solved is meeting-second shortages: have interim meetings, conf calls, etc.  In other words, stretch out the AVT meeting in the interval between IETF meetings.  Require a web-ex presentation of every draft to be discussed in the AVT session at least 4 weeks before the meet slot for Q/A.  Should I continue with this brainstorm?

 

If the problem is something else, I would like to know…

 

Thanks for your consideration, and apologies for the wordcount,

 

Stephan 

 

 




__________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



__________ Information from ESET NOD32 A ntivirus ure database 5785 (20110113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
--Boundary_(ID_K2bGJVJirFlXIlOz7R3VXA)-- From stewe@stewe.org Thu Jan 13 17:16:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FBE3A687A; Thu, 13 Jan 2011 17:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMd0ZAYKCcPW; Thu, 13 Jan 2011 17:16:46 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id CAFEC3A67F0; Thu, 13 Jan 2011 17:16:45 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 50960-1743317 for multiple; Fri, 14 Jan 2011 02:19:07 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 13 Jan 2011 17:18:59 -0800 From: Stephan Wenger To: Cullen Jennings Message-ID: Thread-Topic: [AVT] proposed AVT WG split In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: iesg@ietf.org, avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 01:16:47 -0000 On 1.13.2011 13:35 , "Cullen Jennings" wrote: > >Stephan, I see this differently than you. I think you are assuming that >four WG will take on more work in net than just one. First I don't think >this is true, and even if it is, then I would see that as a good thing as >it would be proof that the 1 WG was blocking useful work that the >community wanted to do. Let me address your cons inline. Actually, that's not my assumption. Quite the opposite. My main argument is that handling the same number of docs in a larger number of groups naturally leads to less efficiency. Also a few additional replies inline. > > >On Jan 12, 2011, at 5:11 PM, Stephan Wenger wrote: > >>=20 >>=20 >> The negative effects are IMO: >> -the key knowledgeable people in AVT ideally would have to sit in all >>four meetings so that all four groups can tap their experience. > >I view that as the current situation. Right now, given the times on the >agenda move around in a meeting, everyone has to be at all the AVT >related talks regardless if they want to see just some parts of them or >all of them. It seem like the split would improve this. It can't make it >worse. Your analysis would be correct if the number of meeting seconds for the (currently two) AVT sessions is similar to the proposed four successor WG's sessions. Somehow I doubt that would be the case in the long term, even if you guys would succeed to enforce it in the short term... >=20 > >> But they may not want to do so, because it leaves less time for >>cross-area involvement, coordination, and draft-writing outside the AVT >>sessions, and whatnot. Also, the burden for remote participants in >>far-away time zones goes up. In other words, the resource >>meeting-seconds for those people is not unlimited, and they will have to >>prioritize differently. The result could be that what I called "key >>knowledgable people" would perhaps not attend the mere RTCP-XR or >>Payload session; and the guys there may be wasting their time doing work >>that does not make sense architecturally, just to see the hammer coming >>down at IETF last call. >> -more people get chair positions and are burdened with administrative >>stuff -> less time to do real work > >Given the current chair bottlenecks, and the fact we have people that >would like to do this, I view the bunch more chairs a pro not a con Really? At almost every plenary I hear folks whining about how difficult it is to get *qualified* chairs. (Some would say that AVT, in its present incarnation, clearly shows that difficulty) > >> -WG scheduling gets more difficult > >Having been very involved with scheduling RAI for several years, I >strongly disagree. Right now you can't conflict AVT with anything, yet I >bet you could conflict the XR metrics with say BLISS without too many >problems. Perhaps. You are way more experienced than I am on these matters. >=20 > >> -AD load potentially goes up (someone needs to coordinate between those >>groups, and the AD would seem to me the natural choice) > >The AD is going to have to be aware of all the work related to RTP >regardless of if it is split in one group or four. I know when I was AD >for AVT I felt this split would make things easier for me. Interesting. I didn't know you like multiparty coordination so much :-) Your insight is not intuitive, though, at least not to me. >=20 > >> -there is no reason to believe that the overall manpower availability >>goes up through this change, so all the inefficiencies introduced go >>straight against the available cycles. > >I agree the manpower to do AVT technical work does not improve. However, >having people who care less about 1 of the four stream be able to ignore >theses meetings and go elsewhere would improve the manpower available >available to other topics. The administrative work would go from two >chairs and split over more. I don't think it significantly increases the >total amount of admin-a-triva and having more people doing that is likely >to reduce administrative delays. Now you might think the administrative >delays have no impact on how many person hours are required to do the >technical work but if an admin delay causes something to sit for 3 >months, then all the technical people need to spend a bunch of time >reloading the context in their brain and getting back up to speed on >where the technical work is. This decreases the efficiently of the the >technical work. Roni has answered this point already, and I concur: things are not slow because of admin delays. Things are slow because parts of AVT's work is highly contentious. That's natural, to me at least. >=20 > >>=20 >> Some of these issues can be solved by joint WG meetings and/or careful >>chair selection. However, both options have drawbacks as well. A joint >>session would be counter-productive to the allocation of more meeting >>minutes. And when you have, say, 8 chairs for four WG, all of which >>know the RTP architecture well enough, then you have pretty much >>exhausted, if not overdrawn already, the pool of "key knowledgable >>people", and burdened them with (in many cases: additional) chair duties. >>=20 >> No matter how I see it, splitting the group is not a good idea. >>=20 >> Other options to alleviate problems could come to mind: >>=20 >> If the problem to be solved is chair-workload: add more chairs (but not >>6 of them). > >The more chairs you have for a single WG, the more all chairs think some >other chair will do it and nothing happens. See track record of sipping >chairs for a concrete example of this and those were all chairs that had >proven track record of being effect chairs in other WGs. I agree with >your point that if all the top RTP architecture people were suddenly >spending all their time doing admin work this would be a disaster. I'm >sure the ADs won't do that and that theses people would not accept. But I >do think we need to ask, is our pool of really top RTP people that get >the architecture growing or shrinking? What can we do to grow it? >Dropping in some keen and smart person as chair is a not bad way of >growing deep expertise in an area. > >> If the problem to be solved is meeting-second shortages: have interim >>meetings, conf calls, etc. In other words, stretch out the AVT meeting >>in the interval between IETF meetings. Require a web-ex presentation of >>every draft to be discussed in the AVT session at least 4 weeks before >>the meeting, with a two hour timeslot for Q/A. Should I continue with >>this brainstorm? >( ahhgg I see all kinds of problems with that but lets ignore theses, >this is all based on the idea that we want to do more work which I think >is an orthogonal issue to the split proposal) > >>=20 >> If the problem is something else, I would like to know=8A >>=20 >> Thanks for your consideration, and apologies for the wordcount, > >When I read what you are saying, I think much of it can be tracked back >to if we decide to try and do more work in the 4 groups than we were >doing in one group, that may not be a good thing. I agree with that and >think we need to manage that careful but that is equally true across the >area as a whole as it is in any single WG. The IETF as a whole is >familiar with managing that trade off. > >>=20 >> Stephan >>=20 >>=20 >>=20 >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt From stewe@stewe.org Thu Jan 13 17:25:05 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F157D3A67A4; Thu, 13 Jan 2011 17:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL5QvYdkJAyi; Thu, 13 Jan 2011 17:24:51 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id D23763A67D3; Thu, 13 Jan 2011 17:24:50 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 50963-1743317 for multiple; Fri, 14 Jan 2011 02:27:14 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 13 Jan 2011 17:27:08 -0800 From: Stephan Wenger To: Robert Sparks Message-ID: Thread-Topic: [AVT] proposed AVT WG split In-Reply-To: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3377784433_28584930" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: IETF AVT WG , IESG IESG Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 01:25:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3377784433_28584930 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Robert, We have exchanged these arguments before. I guess it's most efficient for both of us to agree to disagree, and continue with our day job=8A (which in your case may require making a decision I don't like, but I still hope for what I consider common sense :-). Just one word on the RAMS example: if you have two major contributing companies at each other's throat, combined with cultural differences, and a couple of difficult individuals to spice up the broth, it does not matter a bit how many groups you have: things are going to be slow in this group. More importantly for this discussion, slowdown will also occur in related groups. Overspill happens. Horse-trading happens. Retaliation by blockin= g happens. It's IMO na=EFve to assume a good set of chair can prevent any of these deplorable events. Stephan From: "rjsparks@nostrum.com" Date: Thu, 13 Jan 2011 15:27:55 -0600 To: Stephan Wenger Cc: IETF AVT WG , IESG IESG Subject: Re: [AVT] proposed AVT WG split Stephan - As I noted in response to your comments in Maastricht, I disagree. There are separable streams of work in AVT - it is really multiple working groups in one shell at the moment. While there are key people currently in AVT that would overlap these groups= , they are not the majority of the contributors to the different types of activities. The intended positive effect of this explicit division is to allow these different streams to better parallelize, on list between meetings, not just during the IETF in-person meeting time. We'd like to try to channel these streams separately for a while. That will require some additional coordination work from the area directors and chairs, but it will bring significant benefits, especially in being able to better prioritize work items within the streams. I realize that for folks like you, who will actively participate in all of the efforts, the benefits are more limited. I have had several participants express frustration, for example, with the way the RAMs work eclipsed basic architectural work in AVT. While that could be managed in place (we could have only one working grou= p per area in the extreme), it has shown itself to be difficult with the set of things this group is working on. I also expect the separation will make it easier to evaluate when the energy for a particular effort (such as the XR metrics you point to below) exists,=20 and when that level of energy changes. Yes, conflicts between these working groups when they do meet in person wil= l have to be managed carefully, but we have mechanisms for that. As Keith noted separately, we do not anticipate this significantly increasing the number-of-minutes footprint on any given in-person IETF meeting. Also, your comments assume all four of these groups would have a session at each in-person meeting. I don'= t expect that to be the case. RjS On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: > Hi IESG, >=20 > As already communicated in Maastricht, I continue to believe that this st= ep is > a bad idea. I didn't attend Beijing, and don't know whether there was an= y > discussion about the subject. I didn't see anything mentioned in the AVT > minutes, though, nor did I see any discussion since Beijing on ietf@ietf.= If > there was, some of the points below may be redundant, and I apologize in > advance. >=20 > Essentially, you guys are suggesting to split one "eternal" WG into four.= I'm > writing "eternal", because I don't see that any of the WGs can fulfill it= s > charter before other work items will likely get chartered with a similar > scope, and in the same WG. For RTP core, RTP extensions, and RTP payload= s > that is probably self-evident. For the XR stuff: metrics pop up all the = time, > like payload formats. Metrics are also known to make people quick bucks = on > patent licensing. There will be more metric proposals. If the RTCP-XR > metrics ever get momentum in the marketplace, that is. Somehow, I have m= y > doubts. But that's a different discussion. >=20 > The positive effects of the split could be > -chair workload is split among more people, and > -there are more meeting seconds for RTP related work at any given IETF > meeting. =20 >=20 > Assuming unlimited resources, both are good things. Unfortunately, resou= rces > are not unlimited. >=20 > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to sit in all fou= r > meetings so that all four groups can tap their experience. But they may = not > want to do so, because it leaves less time for cross-area involvement, > coordination, and draft-writing outside the AVT sessions, and whatnot. A= lso, > the burden for remote participants in far-away time zones goes up. In ot= her > words, the resource meeting-seconds for those people is not unlimited, an= d > they will have to prioritize differently. The result could be that wha= t I > called "key knowledgable people" would perhaps not attend the mere RTCP-X= R or > Payload session; and the guys there may be wasting their time doing work = that > does not make sense architecturally, just to see the hammer coming down a= t > IETF last call. > -more people get chair positions and are burdened with administrative stu= ff -> > less time to do real work > -WG scheduling gets more difficult > -AD load potentially goes up (someone needs to coordinate between those > groups, and the AD would seem to me the natural choice) > -there is no reason to believe that the overall manpower availability goe= s up > through this change, so all the inefficiencies introduced go straight aga= inst > the available cycles. >=20 > Some of these issues can be solved by joint WG meetings and/or careful ch= air > selection. However, both options have drawbacks as well. A joint sessio= n > would be counter-productive to the allocation of more meeting minutes. A= nd > when you have, say, 8 chairs for four WG, all of which know the RTP > architecture well enough, then you have pretty much exhausted, if not > overdrawn already, the pool of "key knowledgable people", and burdened th= em > with (in many cases: additional) chair duties. >=20 > No matter how I see it, splitting the group is not a good idea. >=20 > Other options to alleviate problems could come to mind: >=20 > If the problem to be solved is chair-workload: add more chairs (but not 6= of > them). > If the problem to be solved is meeting-second shortages: have interim > meetings, conf calls, etc. In other words, stretch out the AVT meeting i= n the > interval between IETF meetings. Require a web-ex presentation of every d= raft > to be discussed in the AVT session at least 4 weeks before the meeting, w= ith a > two hour timeslot for Q/A. Should I continue with this brainstorm? >=20 > If the problem is something else, I would like to know=8A >=20 > Thanks for your consideration, and apologies for the wordcount, >=20 > Stephan >=20 >=20 >=20 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --B_3377784433_28584930 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Robert,

We have exchanged these arguments before.  I guess it's most ef= ficient for both of us to agree to disagree, and continue with our day job&#= 8230; (which in your case may require making a decision I don't like, but I = still hope for what I consider common sense :-).

Ju= st one word on the RAMS example: if you have two major contributing companie= s at each other's throat, combined with cultural differences, and a couple o= f difficult individuals to spice up the broth, it does not matter a bit how = many groups you have: things are going to be slow in this group.  More = importantly for this discussion, slowdown will also occur in related groups.=  Overspill happens.  Horse-trading happens.  Retaliation by = blocking happens.  It's IMO na=EFve to assume a good set of chair can pre= vent any of these deplorable events.

Stephan
<= div>

From: "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Date: Thu, 13 Jan 2011 15:27:55 -0600
To: Stephan Wenger <stewe@stewe.org>
Cc: I= ETF AVT WG <avt@ietf.org>, IESG IESG= <iesg@ietf.org>
Subject: Re: [AVT] proposed AVT WG split

Stephan -

As I noted in response to your comments in Maastricht, I disagree.

There are separable streams of work in AVT - it is r= eally multiple working groups in one shell at the moment.

While there are key people currently in AVT that would overlap these = groups, they are not the majority of the contributors to the different types= of activities.
The intended positive effect of this explicit divi= sion is to allow these different streams to better parallelize, on list betw= een meetings, not just during the IETF
in-person meeting time.&nbs= p;

We'd like to try to channel these streams separa= tely for a while. That will require some additional coordination work from t= he area directors and chairs, but
it will bring significant benefi= ts, especially in being able to better prioritize work items within the= streams.  I realize that for folks like you, who will actively partici= pate 
in all of the efforts, the benefits are more limit= ed.

I have had several participants express fr= ustration, for example, with the way the RAMs work eclipsed basic archi= tectural work in AVT. 
While that could be  managed = ;in place  (we could have only one working group per area in the extrem= e), it has shown itself to be difficult 
with the set of= things this group is working on.

I also expect &nb= sp;the separation will make it easier to evaluate when the energy for a part= icular effort (such as the XR metrics you point to below) exists, =
and when that level of energy changes.

Yes, conflicts between these working groups when they do meet in pe= rson will have to be managed carefully, but we have mechanisms for that. As = Keith noted
separately, we do not anticipate this significan= tly increasing the number-of-minutes footprint on any given in-person IETF m= eeting. Also, your comments assume all 
four of these groups = would have a session at each in-person meeting. I don't expect that to be th= e case.


RjS


=
On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote:

Hi IESG,

As already communicated in Maastricht, = I continue to believe that this step is a bad idea.  I didn't attend Be= ijing, and don't know whether there was any discussion about the subject. &n= bsp;I didn't see anything mentioned in the AVT minutes, though, nor did I se= e any discussion since Beijing on ietf@ietf.  If there was, some of the= points below may be redundant, and I apologize in advance.

Essentially, you guys are suggesting to split one "eternal" WG into= four.  I'm writing "eternal", because I don't see that any of the WGs = can fulfill its charter before other work items will likely get chartered wi= th a similar scope, and in the same WG.  For RTP core, RTP extensions, = and RTP payloads that is probably self-evident.  For the XR stuff: metr= ics pop up all the time, like payload formats.  Metrics are also known = to make people quick bucks on patent licensing.  There will be more met= ric proposals.  If the RTCP-XR metrics ever get momentum in the marketp= lace, that is.  Somehow, I have my doubts.  But that's a different= discussion.  

The positive effects of the spl= it could be 
-chair workload is split among more people, and&= nbsp;
-there are more meeting seconds for RTP related work at any = given IETF meeting.  

Assuming unlimited resou= rces, both are good things.  Unfortunately, resources are not unlimited= .

The negative effects are IMO:
-the key = knowledgeable people in AVT ideally would have to sit in all four meetings s= o that all four groups can tap their experience.  But they may not want= to do so, because it leaves less time for cross-area involvement, coordinat= ion, and draft-writing outside the AVT sessions, and whatnot.  Also, th= e burden for remote participants in far-away time zones goes up.  In ot= her words, the resource meeting-seconds for those people is not unlimited, a= nd they will have to prioritize differently.    The result could b= e that what I called "key knowledgable people" would perhaps not attend the = mere RTCP-XR or Payload session; and the guys there may be wasting their tim= e doing work that does not make sense architecturally, just to see the hamme= r coming down at IETF last call.
-more people get chair positions = and are burdened with administrative stuff -> less time to do real work
-WG scheduling gets more difficult
-AD load potentially g= oes up (someone needs to coordinate between those groups, and the AD would s= eem to me the natural choice)
-there is no reason to believe that = the overall manpower availability goes up through this change, so all the in= efficiencies introduced go straight against the available cycles.
=
Some of these issues can be solved by joint WG meetings and/o= r careful chair selection.  However, both options have drawbacks as wel= l.  A joint session would be counter-productive to the allocation of mo= re meeting minutes.  And when you have, say, 8 chairs for four WG, all = of which know the RTP architecture well enough, then you have pretty much ex= hausted, if not overdrawn already, the pool of "key knowledgable people", an= d burdened them with (in many cases: additional) chair duties.
No matter how I see it, splitting the group is not a good idea.<= /div>

Other options to alleviate problems could come to m= ind:

If the problem to be solved is chair-workload:= add more chairs (but not 6 of them).
If the problem to be solved = is meeting-second shortages: have interim meetings, conf calls, etc.  I= n other words, stretch out the AVT meeting in the interval between IETF meet= ings.  Require a web-ex presentation of every draft to be discussed in = the AVT session at least 4 weeks before the meeting, with a two hour timeslo= t for Q/A.  Should I continue with this brainstorm?

If the problem is something else, I would like to know…

Thanks for your consideration, and apologies for the wordco= unt,

Stephan




_______________________= ________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/ma= ilman/listinfo/avt --B_3377784433_28584930-- From abegen@cisco.com Thu Jan 13 18:17:46 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A0B3A67F8; Thu, 13 Jan 2011 18:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRTmTRCrnbM5; Thu, 13 Jan 2011 18:17:45 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 264413A67F6; Thu, 13 Jan 2011 18:17:45 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAORBL02rRN+K/2dsb2JhbACkTXOkH5hPhUwEhGiJUA Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2011 02:20:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0E2K9mY029957; Fri, 14 Jan 2011 02:20:09 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 18:20:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 18:19:36 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16D87A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] proposed AVT WG split Thread-Index: AcuzaMrFtVAqa0tvT+uIvuKiJDLY8QAJoRwQ References: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> From: "Ali C. Begen (abegen)" To: "Robert Sparks" , "Stephan Wenger" X-OriginalArrivalTime: 14 Jan 2011 02:20:09.0337 (UTC) FILETIME=[90EE7E90:01CBB391] Cc: IETF AVT WG , IESG IESG Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 02:17:47 -0000 I do believe that some re-organization along the lines proposed by the = ADs might help with the unnecessarily long delays for important specs = like RAMS.=20 If you ask my opinion, RAMS draft was finished rather slowly: my = personal target was to finish it in a year. While we had urgency since = other organizations were waiting for us, starting the wglc process and = completing it took almost a year. We did more than 20 revisions btw. So, = editors were not the blocking factor here.=20 Yet, many avt-seasoned people told me that 2 years was actually quite a = big success for a spec like RAMS. They are probably right, but often a = late spec is almost as good as no spec, if not worse, especially if = another organization does something that would break something like RTP. = It is often impossible to clean up the mess once the damage is done. =20 I don't think the process can get much slower if some form of splitting = happens. I am sure you know this better than I do but many other = organizations are afraid to bring their work to the IETF in general or = seek approval because they are concerned about the delays. If AVT wants = to stay relevant in related standards, I think we need to address this = problem. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Robert Sparks > Sent: Thursday, January 13, 2011 10:28 PM > To: Stephan Wenger > Cc: IETF AVT WG; IESG IESG > Subject: Re: [AVT] proposed AVT WG split >=20 > Stephan - >=20 > As I noted in response to your comments in Maastricht, I disagree. >=20 > There are separable streams of work in AVT - it is really multiple = working groups in one shell at the moment. >=20 > While there are key people currently in AVT that would overlap these = groups, they are not the majority of the contributors to > the different types of activities. > The intended positive effect of this explicit division is to allow = these different streams to better parallelize, on list between > meetings, not just during the IETF > in-person meeting time. >=20 > We'd like to try to channel these streams separately for a while. That = will require some additional coordination work from > the area directors and chairs, but > it will bring significant benefits, especially in being able to better = prioritize work items within the streams. I realize that for > folks like you, who will actively participate > in all of the efforts, the benefits are more limited. >=20 > I have had several participants express frustration, for example, with = the way the RAMs work eclipsed basic architectural > work in AVT. > While that could be managed in place (we could have only one working = group per area in the extreme), it has shown itself > to be difficult > with the set of things this group is working on. >=20 > I also expect the separation will make it easier to evaluate when the = energy for a particular effort (such as the XR metrics > you point to below) exists, > and when that level of energy changes. >=20 > Yes, conflicts between these working groups when they do meet in = person will have to be managed carefully, but we have > mechanisms for that. As Keith noted > separately, we do not anticipate this significantly increasing the = number-of-minutes footprint on any given in-person IETF > meeting. Also, your comments assume all > four of these groups would have a session at each in-person meeting. I = don't expect that to be the case. >=20 >=20 > RjS >=20 >=20 > On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: >=20 >=20 > Hi IESG, >=20 > As already communicated in Maastricht, I continue to believe that = this step is a bad idea. I didn't attend Beijing, and > don't know whether there was any discussion about the subject. I = didn't see anything mentioned in the AVT minutes, though, > nor did I see any discussion since Beijing on ietf@ietf. If there = was, some of the points below may be redundant, and I > apologize in advance. >=20 > Essentially, you guys are suggesting to split one "eternal" WG into = four. I'm writing "eternal", because I don't see that > any of the WGs can fulfill its charter before other work items will = likely get chartered with a similar scope, and in the same > WG. For RTP core, RTP extensions, and RTP payloads that is probably = self-evident. For the XR stuff: metrics pop up all the > time, like payload formats. Metrics are also known to make people = quick bucks on patent licensing. There will be more > metric proposals. If the RTCP-XR metrics ever get momentum in the = marketplace, that is. Somehow, I have my doubts. But > that's a different discussion. >=20 > The positive effects of the split could be > -chair workload is split among more people, and > -there are more meeting seconds for RTP related work at any given = IETF meeting. >=20 > Assuming unlimited resources, both are good things. Unfortunately, = resources are not unlimited. >=20 > The negative effects are IMO: > -the key knowledgeable people in AVT ideally would have to sit in all = four meetings so that all four groups can tap > their experience. But they may not want to do so, because it leaves = less time for cross-area involvement, coordination, and > draft-writing outside the AVT sessions, and whatnot. Also, the burden = for remote participants in far-away time zones goes > up. In other words, the resource meeting-seconds for those people is = not unlimited, and they will have to prioritize > differently. The result could be that what I called "key = knowledgable people" would perhaps not attend the mere RTCP-XR > or Payload session; and the guys there may be wasting their time doing = work that does not make sense architecturally, just to > see the hammer coming down at IETF last call. > -more people get chair positions and are burdened with administrative = stuff -> less time to do real work > -WG scheduling gets more difficult > -AD load potentially goes up (someone needs to coordinate between = those groups, and the AD would seem to me the > natural choice) > -there is no reason to believe that the overall manpower availability = goes up through this change, so all the > inefficiencies introduced go straight against the available cycles. >=20 > Some of these issues can be solved by joint WG meetings and/or = careful chair selection. However, both options have > drawbacks as well. A joint session would be counter-productive to the = allocation of more meeting minutes. And when you > have, say, 8 chairs for four WG, all of which know the RTP = architecture well enough, then you have pretty much exhausted, if > not overdrawn already, the pool of "key knowledgable people", and = burdened them with (in many cases: additional) chair > duties. >=20 > No matter how I see it, splitting the group is not a good idea. >=20 > Other options to alleviate problems could come to mind: >=20 > If the problem to be solved is chair-workload: add more chairs (but = not 6 of them). > If the problem to be solved is meeting-second shortages: have interim = meetings, conf calls, etc. In other words, > stretch out the AVT meeting in the interval between IETF meetings. = Require a web-ex presentation of every draft to be > discussed in the AVT session at least 4 weeks before the meeting, with = a two hour timeslot for Q/A. Should I continue with > this brainstorm? >=20 > If the problem is something else, I would like to know=85 >=20 > Thanks for your consideration, and apologies for the wordcount, >=20 > Stephan >=20 >=20 >=20 >=20 From Even.roni@huawei.com Thu Jan 13 19:30:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA803A6BBD; Thu, 13 Jan 2011 19:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+PXcquDnSyD; Thu, 13 Jan 2011 19:30:33 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 82F083A6818; Thu, 13 Jan 2011 19:30:31 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ00I3VTS80V@szxga04-in.huawei.com>; Fri, 14 Jan 2011 11:31:20 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ005B4TS8W2@szxga04-in.huawei.com>; Fri, 14 Jan 2011 11:31:20 +0800 (CST) Received: from YOUR6108 ([64.168.229.50]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ00LAVTS5XP@szxml01-in.huawei.com>; Fri, 14 Jan 2011 11:31:20 +0800 (CST) Date: Fri, 14 Jan 2011 05:30:52 +0200 From: Roni Even In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540E16D87A@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" , 'Robert Sparks' , 'Stephan Wenger' Message-id: <002a01cbb39b$869e1180$93da3480$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: he Content-transfer-encoding: 7BIT Thread-index: AcuzaMrFtVAqa0tvT+uIvuKiJDLY8QAJoRwQAALyCCA= References: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16D87A@xmb-sjc-215.amer.cisco.com> Cc: 'IETF AVT WG' , 'IESG IESG' Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 03:30:34 -0000 Hi Ali, I think that some work can be spawned as a separate group using the dispatch WG to do so. As for the time it took I suggest you look at the port mapping draft, when it started and how the discussion led to changes even late in the process. This draft and the cname and ssrc ports were the ones delaying the RAMS work and not the main body Roni Even > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Ali C. Begen (abegen) > Sent: Friday, January 14, 2011 4:20 AM > To: Robert Sparks; Stephan Wenger > Cc: IETF AVT WG; IESG IESG > Subject: Re: [AVT] proposed AVT WG split > > I do believe that some re-organization along the lines proposed by the > ADs might help with the unnecessarily long delays for important specs > like RAMS. > > If you ask my opinion, RAMS draft was finished rather slowly: my > personal target was to finish it in a year. While we had urgency since > other organizations were waiting for us, starting the wglc process and > completing it took almost a year. We did more than 20 revisions btw. > So, editors were not the blocking factor here. > > Yet, many avt-seasoned people told me that 2 years was actually quite a > big success for a spec like RAMS. They are probably right, but often a > late spec is almost as good as no spec, if not worse, especially if > another organization does something that would break something like > RTP. It is often impossible to clean up the mess once the damage is > done. > > I don't think the process can get much slower if some form of splitting > happens. I am sure you know this better than I do but many other > organizations are afraid to bring their work to the IETF in general or > seek approval because they are concerned about the delays. If AVT wants > to stay relevant in related standards, I think we need to address this > problem. > > -acbegen > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Robert Sparks > > Sent: Thursday, January 13, 2011 10:28 PM > > To: Stephan Wenger > > Cc: IETF AVT WG; IESG IESG > > Subject: Re: [AVT] proposed AVT WG split > > > > Stephan - > > > > As I noted in response to your comments in Maastricht, I disagree. > > > > There are separable streams of work in AVT - it is really multiple > working groups in one shell at the moment. > > > > While there are key people currently in AVT that would overlap these > groups, they are not the majority of the contributors to > > the different types of activities. > > The intended positive effect of this explicit division is to allow > these different streams to better parallelize, on list between > > meetings, not just during the IETF > > in-person meeting time. > > > > We'd like to try to channel these streams separately for a while. > That will require some additional coordination work from > > the area directors and chairs, but > > it will bring significant benefits, especially in being able to > better prioritize work items within the streams. I realize that for > > folks like you, who will actively participate > > in all of the efforts, the benefits are more limited. > > > > I have had several participants express frustration, for example, > with the way the RAMs work eclipsed basic architectural > > work in AVT. > > While that could be managed in place (we could have only one > working group per area in the extreme), it has shown itself > > to be difficult > > with the set of things this group is working on. > > > > I also expect the separation will make it easier to evaluate when > the energy for a particular effort (such as the XR metrics > > you point to below) exists, > > and when that level of energy changes. > > > > Yes, conflicts between these working groups when they do meet in > person will have to be managed carefully, but we have > > mechanisms for that. As Keith noted > > separately, we do not anticipate this significantly increasing the > number-of-minutes footprint on any given in-person IETF > > meeting. Also, your comments assume all > > four of these groups would have a session at each in-person meeting. > I don't expect that to be the case. > > > > > > RjS > > > > > > On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: > > > > > > Hi IESG, > > > > As already communicated in Maastricht, I continue to believe that > this step is a bad idea. I didn't attend Beijing, and > > don't know whether there was any discussion about the subject. I > didn't see anything mentioned in the AVT minutes, though, > > nor did I see any discussion since Beijing on ietf@ietf. If there > was, some of the points below may be redundant, and I > > apologize in advance. > > > > Essentially, you guys are suggesting to split one "eternal" WG > into four. I'm writing "eternal", because I don't see that > > any of the WGs can fulfill its charter before other work items will > likely get chartered with a similar scope, and in the same > > WG. For RTP core, RTP extensions, and RTP payloads that is probably > self-evident. For the XR stuff: metrics pop up all the > > time, like payload formats. Metrics are also known to make people > quick bucks on patent licensing. There will be more > > metric proposals. If the RTCP-XR metrics ever get momentum in the > marketplace, that is. Somehow, I have my doubts. But > > that's a different discussion. > > > > The positive effects of the split could be > > -chair workload is split among more people, and > > -there are more meeting seconds for RTP related work at any given > IETF meeting. > > > > Assuming unlimited resources, both are good things. > Unfortunately, resources are not unlimited. > > > > The negative effects are IMO: > > -the key knowledgeable people in AVT ideally would have to sit in > all four meetings so that all four groups can tap > > their experience. But they may not want to do so, because it leaves > less time for cross-area involvement, coordination, and > > draft-writing outside the AVT sessions, and whatnot. Also, the > burden for remote participants in far-away time zones goes > > up. In other words, the resource meeting-seconds for those people is > not unlimited, and they will have to prioritize > > differently. The result could be that what I called "key > knowledgable people" would perhaps not attend the mere RTCP-XR > > or Payload session; and the guys there may be wasting their time > doing work that does not make sense architecturally, just to > > see the hammer coming down at IETF last call. > > -more people get chair positions and are burdened with > administrative stuff -> less time to do real work > > -WG scheduling gets more difficult > > -AD load potentially goes up (someone needs to coordinate between > those groups, and the AD would seem to me the > > natural choice) > > -there is no reason to believe that the overall manpower > availability goes up through this change, so all the > > inefficiencies introduced go straight against the available cycles. > > > > Some of these issues can be solved by joint WG meetings and/or > careful chair selection. However, both options have > > drawbacks as well. A joint session would be counter-productive to > the allocation of more meeting minutes. And when you > > have, say, 8 chairs for four WG, all of which know the RTP > architecture well enough, then you have pretty much exhausted, if > > not overdrawn already, the pool of "key knowledgable people", and > burdened them with (in many cases: additional) chair > > duties. > > > > No matter how I see it, splitting the group is not a good idea. > > > > Other options to alleviate problems could come to mind: > > > > If the problem to be solved is chair-workload: add more chairs > (but not 6 of them). > > If the problem to be solved is meeting-second shortages: have > interim meetings, conf calls, etc. In other words, > > stretch out the AVT meeting in the interval between IETF meetings. > Require a web-ex presentation of every draft to be > > discussed in the AVT session at least 4 weeks before the meeting, > with a two hour timeslot for Q/A. Should I continue with > > this brainstorm? > > > > If the problem is something else, I would like to know. > > > > Thanks for your consideration, and apologies for the wordcount, > > > > Stephan > > > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > __________ Information from ESET NOD32 Antivirus, version of virus signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From magnus.westerlund@ericsson.com Fri Jan 14 01:24:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F382E3A6A98; Fri, 14 Jan 2011 01:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDCoptbtiVz6; Fri, 14 Jan 2011 01:24:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 815E13A6AA6; Fri, 14 Jan 2011 01:24:47 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-05-4d3016ef5fb1 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F3.74.23694.FE6103D4; Fri, 14 Jan 2011 10:27:12 +0100 (CET) Received: from [147.214.210.12] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 10:27:11 +0100 Message-ID: <4D3016EF.4010902@ericsson.com> Date: Fri, 14 Jan 2011 10:27:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "iesg@ietf.org" , "avt@ietf.org" Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 09:24:50 -0000 Stephan Wenger skrev 2011-01-14 02:18: >> >> >>> But they may not want to do so, because it leaves less time for >>> cross-area involvement, coordination, and draft-writing outside the AVT >>> sessions, and whatnot. Also, the burden for remote participants in >>> far-away time zones goes up. In other words, the resource >>> meeting-seconds for those people is not unlimited, and they will have to >>> prioritize differently. The result could be that what I called "key >>> knowledgable people" would perhaps not attend the mere RTCP-XR or >>> Payload session; and the guys there may be wasting their time doing work >>> that does not make sense architecturally, just to see the hammer coming >>> down at IETF last call. >>> -more people get chair positions and are burdened with administrative >>> stuff -> less time to do real work >> >> Given the current chair bottlenecks, and the fact we have people that >> would like to do this, I view the bunch more chairs a pro not a con > > Really? At almost every plenary I hear folks whining about how difficult > it is to get *qualified* chairs. (Some would say that AVT, in its present > incarnation, clearly shows that difficulty) In this regard I do think splitting it does help. I will publicly state that I have volunteered to be a candidate to chair AVTCORE and AVTEXT. For me this is easier to take on as I at least don't need to handle also the documents of PAYLOAD and XR. I do still remember my 3 years as AVT chair. When we for a number of meeting had around 600000 words of AVT documents. I would be much more hesitant to take on the non-split AVT. In general I think this split is clearly worth trying out. We might realize down the road that it is over splitting things, and that some groups can merge or simply close. But lets gather some experience on this. Yes, it will have downsides, it also will have positive effects. Lets try this somewhat different trade-off. I do think smaller groups with less content might allow for a more focused work in the groups. But it will require the chairs to use the smaller scope of each group to speed up things. I also agree that when there is contention on how to do things, things take longer time. And that needs to be taken into account, and for example do more virtual interim meetings etc to give the subject more focus. In conclusion, I think this proposal is well worth trying out. And if it becomes misery and pain with no gain, then the AD can change things again. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 05:13:43 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235A13A6C59 for ; Fri, 14 Jan 2011 05:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.721 X-Spam-Level: X-Spam-Status: No, score=-104.721 tagged_above=-999 required=5 tests=[AWL=-1.722, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07gAwWfv+vtF for ; Fri, 14 Jan 2011 05:13:41 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 664233A6C5F for ; Fri, 14 Jan 2011 05:13:40 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-02-4d304c946d84 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.66.13987.49C403D4; Fri, 14 Jan 2011 14:16:04 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 14:16:03 +0100 Message-ID: <4D304C94.7030505@ericsson.com> Date: Fri, 14 Jan 2011 14:16:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D07746D.9000202@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540DE2E2EA@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2E2EA@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] Review of draft-ietf-avt-ports-for-ucast-mcast-rtp-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 13:13:43 -0000 Hi, I haven't re-reveiew the latest version of document yet. But I do want to respond to a few issues here. Or try to clarify what I meant. Ali C. Begen (abegen) skrev 2010-12-14 15:32: >> 1. Section 3.1: "By default, Tokens are server specific. However, the >> client >> can use the same Token to communicate with different servers if these >> servers are provided with the same secret key and algorithm used to >> generate the Token and are at least loosely clock-synchronized." >> >> How a client determine this is the case still doesn't appear to be defined. > > The client does not need to know anything besides it is the same address (explicit or implicit from the c line) and the port. > >> My suggestion is that a client determines if it has a valid token based >> on the port and address of where to send the token request. But this >> needs to be spelled out somewhere. > > I think this is pretty obvious. Well, it does affect client implementation and behavior for this. And I think there is a point to make it clear what is expected to be done. So that if we find a reason to need to make some adjustments around this, we can be fairly certain about behavior. > >> 2. Section 3.1: >> "The >> Token becomes invalid if client's public IP address changes or when >> the server expires the Token. In these cases, the client has to >> request a new Token." >> >> This might be misleading as the client in a number of cases can't >> determine if an address change happens to them. Thus only determining >> this when failure happens. > > If you read carefully, the text does not imply that the client knows when its address changes. It simply says "when client's address changes". Well, it is implied through "In these cases, the client has to request a new Token." Instead of writing. "If this occurs, then the token will be invalid and after receiving an error message on a request the client needs to request a new token". > >> 5. Section 3.2.1: "Ports *c0, *c1 and *c2 " bullet: >> >> There is no discussion of if C2 should be equal to C1 or not. I think > > They could be the same as the text says. > >> there might be actually considerations here. This have to do with the >> binding of the RTCP reports to the unicast session transmission >> happening P3 -> C1. If that isn't possible then the server doesn't know > > C2 is the port client uses to send the RTCP reports for the unicast session. They go to port P4, which is different than P3. Since P4 cannot be the same as P3, it does not matter what you choose for c2. > >> for which outgoing transmission the reports are for. I think also C3 has >> to be equal to C2, or the server can't match on anything on transport >> level. However, if the NAT is not address and port independent mapping >> also that breaks down due the NAT properties. > > We don’t have a c3 in the figure or text. Sorry, C2 = C1, and C3 = C2. The issue as I say is that you can't bind the "burst" or RTX transmission to the RTCP feedback message on those. > >> >> If one are going to enable to mapp on heuristics then I think the only >> possibility for the server is to mapp on reported SSRC's and ensure to >> use unique SSRC identifiers across all unicast RTP session going out >> from P3. >> >> Or have I forgotten something here? > > See my response above and let me know whether it addresses your concerns (which I probably did not get). Yes, unless you have done something about this I think it something that needs clarification. > >> 6. Section 3.2.2: >> >> I am missing an RTP session definitions. I would like to have something >> along the following lines included. This I think is the main part of how >> a unicast session is established. >> >> Port mapping starts with a primary RTP session, where the server acting >> on a port mapping request has an unidirectional flow of RTCP messages >> from the client port (C1) to the server on a designated port (P3). There >> MUST be no RTCP traffic related to the primary RTP session being sent >> from P3 on the server to the client on port (C1). > > This agrees with figure 2. > >> >> Upon a port mapping request RTCP message in the primary session from the >> client on local port (C1) to the server port (P3) a new RTP point to >> point unicast RTP session is created, unless active RTP session within >> this context already exist. This new session consist of one leg of >> multiplex RTP and RTCP messages from the Server (P3) to the client (C1). > > Correct. > >> The client to server leg in this unicast RTP session is going from >> client local port (C2 perhaps C1 if mandated to be equal) to the Server >> port (P4). The server port for the unicast needs to be signaled to the >> client. > > Correct. > >> >> The point I am trying to get across in the above is the need to make it >> clear what flows of messages are considered to be different RTP sessions. > > This is what we convey with Figure 2. If you look at it, the sessions are properly separated and each session has a number of flows with directions and port numbers clearly identified. It is concrete and clear. > > If further text is needed, we can put additional wording. Yes, the problem is that you don't spell out which legs are which RTP sessions. As you do have two, and you don't have the regular symmetric session. This is important when it comes to using other functionality on these sessions. > >> Another thing that I think is unclear is when an existing RTP session is >> reused correctly. Like that a sequence of NACK messages for the same >> primary RTP session shall of course continue to use the same RTP session. > > Indeed, here we introduce nothing new. The regular RTP rules are still valid. If the session has timed out or was ended by a BYE, it ended. A subsequent NACK will open a new session. Ow, the existing session will continue. This is far from obvious when you have this functionality. This is new functionality not previously existing. Before a session was existing and any request was within that sessions context. Or in certain cases where multiple sessions exist, the relation between them is clearly stated. > >> A third thing is the connection of the SSRC spaces that happens between >> these two sessions. That as RTCP response to requests in the primary are >> going into the unicast sessions packet flow. >> >> I have to say that this is starting more and more to trouble me as I >> peel away the layers of implications. Can I please have a time machine >> and go back 1.5 years and change things? > > Probably you cannot. However, IMO, you are overthinking things in the sense some of the issues you raise above do not even belong to this spec. The SSRC behavior for example will be defined with the unicast application you are running. It could be RAMS, retransmission, multi-layer video, etc. They define their behavior individually. Maybe you are correct that this is part of the RAMS, etc specification. But is an question that needs to be considered. Getting all the quirks of RTP is not easy, despite now having 10 years of experience with it. Thus, you need to think through a lot of cases to be certain things work. When doing that you should document how it is intended to work. Otherwise we will have issues down the line. But you might be right that this is an issue that belongs in RAMS and any other mechanism using this mechanism. But this port mapping do mandate this relation, and thus should point out this detail. > >> >> 7. Section 3.2.2, bullet 4: >> >> Until a unicast >> session is established, neither the server nor the client needs >> to send RTCP reports for the unicast session. >> >> Well, my question based on this, is when it is considered to not any >> longer be established. I see two issues around that needs to be made clear. > > Requesting and receiving Tokens does not create the unicast session. That is it. Correct, but it is this spec that defines how the different legs of the different RTP sessions exist. > >> 1. How long are the client and server going to send RTCP receiver >> reports related to the RTP transmissions happening in the session. Are >> this 5 reporting interval since last RTP traffic in the session, or >> something else? > > Why define new rules here? This is just another RTP session and is supposed to follow the RTP rules. Actually this is something new for RAMS/RTX with port mapping. We never had RTP sessions that was dynamically created from one RTP session. We always had external signalling that defined when an RTP session could exist. > >> 2. Secondly, what about RTCP BYE signaling? If either ends has sent >> this, must the client select a new local port and never send any new >> requests in the primary that ends up in this unicast session? > > No, why would it mean that? BYE does not have such semantics. > The issue is what is creating this session. It is the combination of a request needing a unicast session, and the port mapping parts. But we have completely failed to go into details when a session is terminated. Yes, BYE's normal semantics is that this SSRC leaves the RTP session now. So in a context where a request with a certain SSRC leaves a session, does that imply that the created RTP session goes away? It is a question, and as I see it a hole in the spec. >> >> >> 8. Section 3.2.2: RTP session question. >> >> Are RTP packets in the direction C2->P4 forbidden? Currently there >> doesn't appear to be any wording on this. Secondly, should it be >> forbidden? Because I can see there is potential applications that needs >> a client to server RTP stream, rather than the opposite. And as this is >> a general RTP tool I think we need to work these questions out. > > Yes, they are forbidden. This was the choice since the beginning. If you need a full bi-directional RTP session on the unicast side, you can do a full offer/answer exchange to set up that session. It does not fit into this context anyway. > > To make this crystal clear, we can say that no rtp traffic must flow from client to server. Hope this has made clear. > >> 9. Section 4: >> When a client sends a >> Port Mapping Request or Token Verification Request message but it >> does not receive a response back from the server (either a Port >> Mapping Response or Token Verification Failure message), it MAY >> resend its request by following the timer rules defined for RTCP >> feedback messages in Section 3.5 of [RFC4585] as a good practice. >> >> What are the criteria the client shall use to determine when a packet it >> sent is lost? > > Seriously? The client is ruled by the timer rules. It has a min waiting time. Then, it can resend or give up. What is there to define here? Ok, this is serious nitpicking. And in most cases this isn't a problem becuase the RTCP sending intervall allowed will be longer than the RTT. But what happens if the one has "unlimited" RTCP bandwidth and can always send immediately. You still need to wait to request until a time that is long enough for the RTT + server response time. > >> 15. Section 6: >> A >> client that received a Token Verification Failure message can request >> a new Token from the server. >> >> I am missing discussion one when there is persistent errors. I think >> there should be some recommendation about exponentially backing off ones >> tries to retrieve a new token and then use it. > > Would not 4585 scheduling algorithms take care of this? This is not different than sending broken NACKs for example. Not really. The 4585 scheduling algorithm allows one to reschedule the same NACK for every transmission and never give up. For knowing expected behavior there is a point of making clear what the behavior here is. > >> One may also need to consider if one after a period should try to >> retrieve fresh declaration information for the service one tries to >> access to see if the error is there? > > If a server has given me a token valid for the next 12 hours, I can use it for the next 12 hours. If the service gets disabled in the mean time say after 6 hours, I will eventually get an error. So what? I can try to get a new token. Or, as you suggest I can be conservative and check with the server every hour to see whether I can get a valid token (because if the service got disabled, I won't get a valid token). This behavior is something up to the implementation. Either is fine and has pros/cons for different scenarios. > That is not what I am saying. I asking for the service declartion, like SDP or XML. Basically saying that is you have a persistent error at this part, you better pop up to the application layer and have them check their information. > >> 15. Section 7.1: >> >> If used at a media level, the attribute MUST be used in a unicast >> media block. >> >> I think this sentence should go. Because this is in conflict with the >> current semantics. I think it is better to include the a=portmapping-req >> attribute at the places where one needs to send token verification >> requests in RTCP. Rather than consider this to be derived implicitly. > > It is already gone since we currently switched to media-level attributes only. And the text simply says "The 'portmapping-req' attribute SHALL be used as a media-level attribute." > > >> This would make the SDP example in Figure 7 look like this: >> >> v=0 >> o=ali 1122334455 1122334466 IN IP4 nack.example.com >> s=Local Retransmissions >> t=0 0 >> a=group:FID 1 2 >> a=rtcp-unicast:rsi >> m=video 41000 RTP/AVPF 98 >> i=Multicast Stream >> c=IN IP4 233.252.0.2/255 >> a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1 >> a=rtpmap:98 MP2T/90000 >> a=multicast-rtcp:41500 ; Note 1 >> a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2 >> a=rtcp-fb:98 nack ; Note 2 >> a=portmapping-req:30000 ; Note 6 > > As I explained a few times before, putting this attribute here is a mistake. It needs to be in the unicast session associated with the multicast session. > I still strongly disagree on this. >> a=mid:1 >> m=video 42000 RTP/AVPF 99 ; Note 3 >> i=Unicast Retransmission Stream >> c=IN IP4 192.0.2.1 >> a=sendonly >> a=rtpmap:99 rtx/90000 >> a=rtcp-mux ; Note 4 >> a=rtcp:42500 ; Note 5 >> a=fmtp:99 apt=98; rtx-time=5000 >> a=portmapping-req:30000 ; Note 7 >> a=mid:2 >> >> The line with Note 7 would only be needed if we actually use RTCP bye in >> the nack context to kill of the unicast session. Otherwise I don't think >> it is needed here in Nack. But if the unicast session was for RAMS, then >> it would be needed. > > I respectfully disagree that the attribute will be repeated in the multicast block. It does not make sense. No, I think it makes total sense to indicate the RTP sessions and there corresponding RTCP flows where you will need a token for submitting some requests. Rather than placing it in the m= for an RTP session where you don't needed, only need a token to create this session. I guess this is different views on how one should signal this. I will review draft-11 now and see if you then made the definition distinct enough that it is clear when the attribute should be used. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 05:24:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F833A6BA9 for ; Fri, 14 Jan 2011 05:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDKA92UlueEI for ; Fri, 14 Jan 2011 05:24:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B6DA63A6B83 for ; Fri, 14 Jan 2011 05:24:11 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-74-4d304f0cb1ea Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0D.87.13987.C0F403D4; Fri, 14 Jan 2011 14:26:36 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 14:26:35 +0100 Message-ID: <4D304F0B.4030703@ericsson.com> Date: Fri, 14 Jan 2011 14:26:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <000001cb9db1$49576e70$dc064b50$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF39A5@xmb-sjc-215.amer.cisco.com> <000301cb9e6d$540b1f30$fc215d90$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF3C30@xmb-sjc-215.amer.cisco.com> <001601cb9f1f$d7a9c0a0$86fd41e0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF3C71@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DEF3C71@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 13:24:13 -0000 Hi, I would say that adding gives you nothing, even if detected. They you get token failure, and anyway request a new token. Thus detecting it or not the server will anyway eat the increased load. I don't see that one can mitigate this attack without integrity checking the token response message Cheers Magnus Ali C. Begen (abegen) skrev 2010-12-19 15:39: > > >> -----Original Message----- >> From: Glen Zorn [mailto:gwz@net-zen.net] >> Sent: Saturday, December 18, 2010 8:56 PM >> To: Ali C. Begen (abegen) >> Cc: avt@ietf.org >> Subject: RE: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt >> >> Ali C. Begen (abegen) [mailto://abegen@cisco.com] writes: >> >> >>>> SHA1 isn't free, or even particularly cheap; to me, this has DoS >>> written all >>>> over it. Further, AFAICT, the attack is undetectable except through >>> traffic >>>> monitoring. >>> >>> If there is a concern that this may overload the server, then, yes, >>> getting this into the token will fix it. However, if I were the >>> attacker, I would rather mess with the token or other fields, so that >>> both the service would fail and the client would try getting a new token >>> right away (even without waiting for 2 mins). >> >> OK, but again, the difference between that and what I'm describing is that >> the latter is AFAICT indistinguishable (by the parties involved) from the >> normal operation of the protocol, while the former is easily recognizable as >> an attack. > > I think there is an interesting point here, which is the following: > > If an attacker messes with the relative exp time value, this can still go unnoticed very easily if the attacker "fixes" its value on the reverse path. For example, the attacker reduces the value from 2 hours to 2 mins. The client will think that the token is valid only for two minutes, and will request a new token before the 2-min deadline expires. In the meantime, if the token is used by the client, the attacker can revert 2 minutes to 2 hours in the Token Verification Request messages and make everything look perfect from server's viewpoint. > > Two seconds later, the client will request a new Token. This will go unnoticed by the server no matter whether we include this field in the token or not. Here, the cost, if any, will be on the server (for extra token generations). This attack AFAIK can only be avoided if the RTCP messages are protected or maybe the server is monitored for redundant token requests from a particular client. > > Oppositely, if the attacker changes the value from 2 hours to 4 hours and the client uses the token after 2 hours, this will cause a failure message from the server. But, again the server may not necessarily notice this attack as the attacker can undo its changes on the reverse path. In this case, the server will assume the client is trying to use expired tokens. Here, the cost (which is delay) is to the client not the server. I think this also requires protected RTCP messages. > > So, I think we can mention this and say that if there is such a risk (MITM), monitoring activity on the server or protecting RTCP messages may help. > > -acbegen > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Fri Jan 14 08:12:55 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566CD3A6BAA for ; Fri, 14 Jan 2011 08:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.028 X-Spam-Level: X-Spam-Status: No, score=-0.028 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AgVMqcROtmj for ; Fri, 14 Jan 2011 08:12:51 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 150913A6BA7 for ; Fri, 14 Jan 2011 08:12:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,323,1291590000"; d="scan'208";a="11181969" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 14 Jan 2011 17:15:13 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0270.001; Fri, 14 Jan 2011 17:15:13 +0100 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgw== Date: Fri, 14 Jan 2011 16:15:13 +0000 Message-ID: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <0E35F504A7A0A447AC5279D41DAA692B@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:12:55 -0000 Hi all, We have just submitted a new version of our internet draft describing an RT= CP XR block for Inter-Destination Media Synchronization (IDMS). http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 We have tried to include all feedback received both from the mailing list a= s well as from IETF 79 in Beijing. Major changes include, apart from numerous clarifications and rewrites: - an example/tutorial section that we hope will help make clear how IDMS ca= n be used in practice. - an 'Implementation Considerations' section that adresses a number of issu= es that were raised on the mailing list, including how to deal with NTP syn= chronization in different use cases, echo cancellation and the issue of rep= orting versus controlling. - the removal of the mixer functionality In the past there have been some concerns about whether RTCP XR blocks are = the best solution for IDMS and if a new RTCP block wouldn't be better. Also= , some questions were raised about the advantage of having both client->ser= ver and server->client communication with the same XR block. On these issue= s we feel it is important to understand that the proposed IDMS system is no= t a control protocol; client are not told how to synchronize their playback= to others. The proposed XR block only informs clients of the slowest playb= ack within their synchronization group, how they deal with this information= , if at all, is up to themselves. In this way, IDMS is not that different f= rom how RTCP is used to deal with synchronization between audio and video s= treams on the same terminal. I look forward to your comments. Kind regards, Ray van Brandenburg This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From magnus.westerlund@ericsson.com Fri Jan 14 08:19:52 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC93C3A6B9A for ; Fri, 14 Jan 2011 08:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8yKJw4EiFYX for ; Fri, 14 Jan 2011 08:19:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 983343A6849 for ; Fri, 14 Jan 2011 08:19:51 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-ca-4d3078385962 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.2F.23694.838703D4; Fri, 14 Jan 2011 17:22:16 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 17:22:16 +0100 Message-ID: <4D307838.4030509@ericsson.com> Date: Fri, 14 Jan 2011 17:22:16 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:19:52 -0000 Hi, This is one of several issues I still see remaining in the document. It has clearly improved. I am sorry that I become sick before Christmas and couldn't continue the discussion then. There is an issue with SSRC usage in this document related to the different RTP sessions. Please remember that the most fundamental part of the RTP session definition is that each RTP session has its own SSRC space. So there is one SSRC number space for the multicast RTP session. An SSRC from this space is used in the Token Verification Request to identify the requesting client. In the Token Verification response message this SSRC identifier is included in the Token response message. The problem is that this message is conveyed in the unicast RTP session that has its own SSRC space. Thus we have potentially create a coupling between the two RTP sessions. As I see it this can be fixed in two ways. Either one explicitly notes that this RTCP Token Response message field carries a value that refers to the SSRC space in another RTP session then one currently are in. This is likely the simplest solution. The alternative is to accept the coupling. But then one has to make clear on how to handle SSRC collisions. This seems problematic as the coupled session is a multicast session. A multicast session has bigger difficulties with changes due to its number of receivers and also that if one forces an active sender to change it may causes widespread disruption. I also observe that it is not clear what SSRC space the Port Mapping request and response messages uses. Does this need to be synchronized with any other space or can it be its own unique one. A unique one is probably easiest. I don't see any direct coupling to the other sessions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From keith.drage@alcatel-lucent.com Fri Jan 14 08:31:01 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1283A6C4E for ; Fri, 14 Jan 2011 08:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.639 X-Spam-Level: X-Spam-Status: No, score=-103.639 tagged_above=-999 required=5 tests=[AWL=-1.390, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFZw+3Tvnoi9 for ; Fri, 14 Jan 2011 08:31:00 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 2C6363A6B9A for ; Fri, 14 Jan 2011 08:31:00 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0EGXJCu015784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:33:24 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 14 Jan 2011 17:33:20 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Fri, 14 Jan 2011 17:33:19 +0100 Thread-Topic: WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 Thread-Index: Acus+XcFC0D9cga/RRCdy+Ao8da8RQAAgErwAcMV6wA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" Subject: Re: [AVT] WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:31:01 -0000 (As WG co-chair) A reminder of the WGLC on this document. Please provide your comments by the 19th January 2011. If you believe you need more time, then please mail the chairs, with an exp= ected date you believe you can meet. If you have read it, and believe the document addresses all issues appropri= ately as it is, then please send the chairs a mail as well. This helps cons= iderably in identifying the degree of review for the document. regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: Wednesday, January 05, 2011 5:11 PM > To: DRAGE, Keith (Keith); avt@ietf.org > Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: RE: WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 >=20 > (As WG co-chair) >=20 > I should add that the document is intended as proposed=20 > standard, so please take that into account in your review. >=20 > Keith=20 >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of=20 > > DRAGE, Keith (Keith) > > Sent: Wednesday, January 05, 2011 4:56 PM > > To: avt@ietf.org > > Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > > Subject: [AVT] WGLC for draft-ietf-avt-ports-for-ucast-mcast-rtp-11 > >=20 > > (As WG co-chair) > >=20 > > The WG chairs believe this document now represents working group=20 > > consensus on the technical solution so... > >=20 > > This is to announce a working group last call for > > draft-ietf-avt-ports-for-ucast-mcast-rtp-11 with comments to be=20 > > provided by 19th January. > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-u > > cast-mcast-rtp-11.txt > >=20 > > In providing comments, please identify the level you believe the=20 > > comment is (editorial, minor technical, major technical) in=20 > order to=20 > > give some guidance to prioritizing the show stoppers. > >=20 > > Please provide your comments in reply to this message. > >=20 > > If you read it and have no comments, and believe the document is=20 > > therefore OK, then please send a message to the WG chairs > > - this is extremely helpful in determining level of review the=20 > > document has had. > >=20 > > regards > >=20 > > Keith > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > = From magnus.westerlund@ericsson.com Fri Jan 14 08:31:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60693A6C4E for ; Fri, 14 Jan 2011 08:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRBbsQHcEEnV for ; Fri, 14 Jan 2011 08:31:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A53D93A6B9A for ; Fri, 14 Jan 2011 08:31:18 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-7a-4d307ae72bab Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 98.51.13987.7EA703D4; Fri, 14 Jan 2011 17:33:43 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 17:33:43 +0100 Message-ID: <4D307AE7.9090308@ericsson.com> Date: Fri, 14 Jan 2011 17:33:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:31:19 -0000 Hi, The second issue is getting back to the unicast RTP session termination. Having re-read this document it is very clear on when an Unicast RTP session is created. Section 3.2, bullet 4 makes this clear. However, there is no discussion on what the criterias are for when the session can be considered terminated. This has previously been discussed in my review comments for 08 version but we didn't conclude on the discussion due to me being unable to respond then. To follow up on one thing. Yes, if we had an architectural and usage requirements document for unicast sessions created in relation to multicast then that document would make sense to discuss this issue. As I see it now, that will not be created. This is the usage independent component so I think it makes sense to discuss it here, even if not perfectly fit. But I like to point out that creation and some other treatment things are discussed. So lets include how it is terminated. The reason i think it is important to discuss is that the end-points need to know when the other side will consider it terminated and create a new session in its eyes rather than continue using the current one. Also, the other signaling mechanisms do have some way of terminating. SIP Dialog termination kills the media RTP sessions, they can also become terminated in SDP by re-invites. RTSP has its Teardown method. SAP relies on SDP t= attribute to tell when the session is valid. But for this solution it is unclear. That becomes a bit more problematic as this is a protocol that is intended for highly dynamic cases, like RAMS. So I would really like to know what the criteria are. Otherwise we can have clients sending RTCP to a server for a session it considers closed. It also become a point of resource handling. One should clean up what one create. I am fine making this timeout based, like 5 regular report interval (or TRR-int) without RTP activity. But I think we need to consider what it means if one peer sends BYE. Can you time out earlier then? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Fri Jan 14 08:39:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF9F3A6BBA; Fri, 14 Jan 2011 08:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMw+03aDXD5s; Fri, 14 Jan 2011 08:39:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDDE3A6C63; Fri, 14 Jan 2011 08:39:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110114163921.22778.69677.idtracker@localhost> Date: Fri, 14 Jan 2011 08:39:21 -0800 Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'The use of AES-192 and AES-256 in Secure RTP' to Proposed Standard (draft-ietf-avt-srtp-big-aes-06.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:39:23 -0000 The IESG has approved the following document: - 'The use of AES-192 and AES-256 in Secure RTP' (draft-ietf-avt-srtp-big-aes-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-big-aes/ Technical Summary This document describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It details Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. Working Group Summary The document achieved consensus in the AVT working group. Document Quality David McGrew, Jonathan Lennox (in the the open-source libsrtp project) and Philip Zimmermann (in libZRTP) have indicated implementations of this internet-draft. John Mattsson independently verified the tests. Personnel Keith Drage is the document shepherd. Robert Sparks is the responsible AD. From magnus.westerlund@ericsson.com Fri Jan 14 08:40:07 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E22C3A6B9A for ; Fri, 14 Jan 2011 08:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.054 X-Spam-Level: X-Spam-Status: No, score=-105.054 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRtLStIgHQdf for ; Fri, 14 Jan 2011 08:40:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 08DED3A6BA4 for ; Fri, 14 Jan 2011 08:40:05 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-ae-4d307cf76ca3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.12.13987.7FC703D4; Fri, 14 Jan 2011 17:42:31 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 17:42:31 +0100 Message-ID: <4D307CF7.6040508@ericsson.com> Date: Fri, 14 Jan 2011 17:42:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 3 Binding of C2->P4 RTCP to correct RTP session X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:40:07 -0000 Hi, This third issue was also brought up before and also Tom Van Caenegem comment on it. The RTCP reports going from C2->P4 from a receiver is not obvious on how to correlate with the Unicast RTP session it is reporting on that are sent P3->C1. The issues that may arise are the following. First there might be a NAT with port and address dependent mapping between them. Thus, even if C2=C1, the externally seen address+port can be different between traffic going to P3 and P4. In addition we shall not forget that there might be multiple clients behind the same NAT that participate in the same multicast session. So several RTCP flow might go to P4 from this IP address. I think some details on how to correlate this RTCP flow needs to be included in the document. What are the determining factors? SSRC can't be it unless we couple the multicast and unicast session. Which I think is a bad idea. CNAME is likely the only method that is directly applicable and would match from the C1->P3 request to the C2->P4 one. But this needs to be stated as a requirement. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tom.van_caenegem@alcatel-lucent.com Fri Jan 14 08:42:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7E93A6C69 for ; Fri, 14 Jan 2011 08:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.347 X-Spam-Level: X-Spam-Status: No, score=-5.347 tagged_above=-999 required=5 tests=[AWL=0.902, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl1V7KS9neen for ; Fri, 14 Jan 2011 08:42:22 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id F031C3A6BA3 for ; Fri, 14 Jan 2011 08:42:21 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0EGijTJ011633 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 14 Jan 2011 17:44:45 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 14 Jan 2011 17:44:45 +0100 From: "Van Caenegem, Tom (Tom)" To: Magnus Westerlund , IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" Date: Fri, 14 Jan 2011 17:44:43 +0100 Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces Thread-Index: Acu0BzmElrZbJO9gRr6DrDiJVwK6IQAAXh8A Message-ID: References: <4D307838.4030509@ericsson.com> In-Reply-To: <4D307838.4030509@ericsson.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:42:23 -0000 Magnus, Thx for the comment, see below=20 Tom -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: vrijdag 14 januari 2011 17:22 To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11= : Part 1 SSRC spaces Hi, This is one of several issues I still see remaining in the document. It has= clearly improved. I am sorry that I become sick before Christmas and could= n't continue the discussion then. There is an issue with SSRC usage in this document related to the different= RTP sessions. Please remember that the most fundamental part of the RTP se= ssion definition is that each RTP session has its own SSRC space. So there is one SSRC number space for the multicast RTP session. An SSRC fr= om this space is used in the Token Verification Request to identify the req= uesting client. In the Token Verification response message this SSRC identi= fier is included in the Token response message. The problem is that this me= ssage is conveyed in the unicast RTP session that has its own SSRC space. T= hus we have potentially create a coupling between the two RTP sessions. As I see it this can be fixed in two ways. Either one explicitly notes that= this RTCP Token Response message field carries a value that refers to the = SSRC space in another RTP session then one currently are in.=20 This is likely the simplest solution. The alternative is to accept the coupling. But then one has to make clear o= n how to handle SSRC collisions. This seems problematic as the coupled sess= ion is a multicast session. A multicast session has bigger difficulties wit= h changes due to its number of receivers and also that if one forces an act= ive sender to change it may causes widespread disruption. I also observe that it is not clear what SSRC space the Port Mapping reques= t and response messages uses. Does this need to be synchronized with any ot= her space or can it be its own unique one. A unique one is probably easiest= . I don't see any direct coupling to the other sessions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Fri Jan 14 08:54:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A4028C10A for ; Fri, 14 Jan 2011 08:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDvSoX1ffDgu for ; Fri, 14 Jan 2011 08:54:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9E99528C104 for ; Fri, 14 Jan 2011 08:54:48 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-c2-4d30806976c5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.C2.23694.960803D4; Fri, 14 Jan 2011 17:57:13 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 17:57:07 +0100 Message-ID: <4D308063.3020906@ericsson.com> Date: Fri, 14 Jan 2011 17:57:07 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:54:50 -0000 Hi, I think the change for the SDP attributes "portmapping" and "portmapping-req" was an improvement. However, I think the semantics and usage of these SDP Attributes needs clarification. Lets start with "portmapping", currently it seems vague and not match the generalize requirements needed. The current semantics appears to be: Include in the multicast m= block which in relation there might be need for token verification request. For example if one looks at Section 4.3.1 where BYE messages related to RAMS bursts may need tokens. That is within the unicast session created if I understand correctly. Thus there is no indication in this media block. Only in the Multicast session block. This appears to be rather fuzzy and unclear. I would like to resuggest the semantics I was considering before: The "portmapping" attribute SHALL be included in any SDP media block (m=) that define an RTP session that require the usage of token verification requests for one or more RTCP message. Then I frankly have to say that I don't grasp what the semantics are related to the placement of the "portmapping-req" attribute. Yes, it conveys the port and possibly address for where to send the Mapping request. But what is the meaning of its placement on a particular media block? Why is it placed in unicast blocks? Even if no Token is required in this RTP session? To me it appears that this attribute would be better served by becoming an Session + possibly override in media blocks. At session level it would server as the port mapping port and possibly address, unless c= at session level is unicast to the mapping server, that is used for all tokens used in the RTP sessions indicated by the "portmapping" attribute. Then it may be included at media level in an media block containing a=portmapping to override this port and address within that particular media block. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 08:58:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5553628C10A for ; Fri, 14 Jan 2011 08:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bs4G7vhYamh for ; Fri, 14 Jan 2011 08:58:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4DFE028C104 for ; Fri, 14 Jan 2011 08:58:17 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-ac-4d30813a9dce Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 10.C3.13987.A31803D4; Fri, 14 Jan 2011 18:00:42 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 18:00:42 +0100 Message-ID: <4D30813A.3010606@ericsson.com> Date: Fri, 14 Jan 2011 18:00:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal time recommendation for re-use X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 16:58:18 -0000 Hi, On page 11 last paragraph the following is written: After a sufficient time, a previously used receive port could be used again. It doesn't define what a sufficiently time is. I would suggest that a value that is extremely likely to be sufficent would be to use one TCP Maximum Segment Lifetime which is 2 minutes. I think some recommendation is in order. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 09:06:16 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EB928C0E9 for ; Fri, 14 Jan 2011 09:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiB2vfVJW0mg for ; Fri, 14 Jan 2011 09:06:16 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BA82C28C10F for ; Fri, 14 Jan 2011 09:06:15 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-26-4d308318bfb0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D4.44.13987.813803D4; Fri, 14 Jan 2011 18:08:41 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 18:08:40 +0100 Message-ID: <4D308318.7010100@ericsson.com> Date: Fri, 14 Jan 2011 18:08:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:06:17 -0000 Hi, In Section 4, there is some statement about resending. I want to come to some conclusion on this topic that was brought up before. The basic issue is the question on how one detects packet loss for RTCP. There is no other mechanism than detecting lack of response / action from the corresponding peer. The issue I have is that the RTT + server delay in responding can easily be many times the minimal sending interval that RTCP configure to serve even 1 mbit/s stream. Thus the formulation in the draft: "When a client sends a Port Mapping Request or Token Verification Request message but it does not receive a response back from the server (either a Port Mapping Response or Token Verification Failure message), it MAY resend its request by following the timer rules defined for RTCP feedback messages in Section 3.5 of [RFC4585] as a good practice." Might not be sufficient. Because the issue is how one detects the packet loss and how quickly the packet is considered lost. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 09:11:31 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89E528C10F for ; Fri, 14 Jan 2011 09:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.489 X-Spam-Level: X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf0oDKJiCKDJ for ; Fri, 14 Jan 2011 09:11:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5438028C0E9 for ; Fri, 14 Jan 2011 09:11:26 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-98-4d30844fe7e6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EF.14.23694.F44803D4; Fri, 14 Jan 2011 18:13:51 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 18:13:51 +0100 Message-ID: <4D30844F.8020508@ericsson.com> Date: Fri, 14 Jan 2011 18:13:51 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG , "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:11:32 -0000 Hi, This is a continuation of the issue 15A from the 08 review. The issue is when a client should consider an error to be persistent, or at least not short time temporarily or resolvable. If a client continues to get Mapping responses with errors after having tried several times. Maybe it should do exponential back-off. Maybe it should update its session description. Similar for Verification Requests. Some recommendation about such behavior I think has clear benefit and reduced uncertainty in behavior by clients. This was my last issue I have found in this review. A clear improvement from the previous review of the document. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 14 09:15:32 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B5B3A6C67 for ; Fri, 14 Jan 2011 09:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+kxzLiZUs2p for ; Fri, 14 Jan 2011 09:15:31 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E98823A6BA4 for ; Fri, 14 Jan 2011 09:15:30 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-57-4d308544d041 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F8.B4.13987.445803D4; Fri, 14 Jan 2011 18:17:56 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Fri, 14 Jan 2011 18:17:56 +0100 Message-ID: <4D308544.7000507@ericsson.com> Date: Fri, 14 Jan 2011 18:17:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Van Caenegem, Tom (Tom)" References: <4D307838.4030509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 17:15:32 -0000 Van Caenegem, Tom (Tom) skrev 2011-01-14 17:44: > Magnus, > > Thx for the comment, see below > Tom > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: vrijdag 14 januari 2011 17:22 > To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces > > Hi, > > This is one of several issues I still see remaining in the document. It has clearly improved. I am sorry that I become sick before Christmas and couldn't continue the discussion then. > > There is an issue with SSRC usage in this document related to the different RTP sessions. Please remember that the most fundamental part of the RTP session definition is that each RTP session has its own SSRC space. > > So there is one SSRC number space for the multicast RTP session. An SSRC from this space is used in the Token Verification Request to identify the requesting client. In the Token Verification response message this SSRC identifier is included in the Token response message. The problem is that this message is conveyed in the unicast RTP session that has its own SSRC space. Thus we have potentially create a coupling between the two RTP sessions. > > > SSRC of Requesting Client (32 bits): Field that contains the SSRC > of the client who sent the verification request. > > ..but this does not mean it equals the SSRC in the token verification request message. The port mapping "client" has its SSRC in the SSM session, its SSRC in the port mapping exchange messages with the server and its SSRC in the unicast sessioon. It needs to use the correct SSRC in the messages sent in all these sessions. Of course, a relaxing implementation may use the same client SSRC across > these sessions.. (but in conflict with RFC 3550)> > > As I see it this can be fixed in two ways. Either one explicitly notes that this RTCP Token Response message field carries a value that refers to the SSRC space in another RTP session then one currently are in. > > Yes, just being a bit more explict about that this SSRC value are in another RTP session SSRC space resolve this. > > This is likely the simplest solution. > > > The alternative is to accept the coupling. But then one has to make clear on how to handle SSRC collisions. This seems problematic as the coupled session is a multicast session. A multicast session has bigger difficulties with changes due to its number of receivers and also that if one forces an active sender to change it may causes widespread disruption. > > I also observe that it is not clear what SSRC space the Port Mapping request and response messages uses. Does this need to be synchronized with any other space or can it be its own unique one. A unique one is probably easiest. I don't see any direct coupling to the other sessions. > > Ok, it is not obvious. And I have to say that this session is far from a common RTP session. It is only RTCP messages, and also in fact not sent using normal timer rules. Only when needed, which might actually need to be pointed out also. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Fri Jan 14 10:31:14 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E503A6C1D; Fri, 14 Jan 2011 10:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk8vzp84VPTD; Fri, 14 Jan 2011 10:31:12 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A205A3A6ABE; Fri, 14 Jan 2011 10:31:12 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOYlME2rR7Hu/2dsb2JhbACkWXOiLpkLhU8EhGuJUw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2011 18:33:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXcUP000110; Fri, 14 Jan 2011 18:33:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:32:56 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA37@xmb-sjc-215.amer.cisco.com> In-Reply-To: <002a01cbb39b$869e1180$93da3480$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] proposed AVT WG split Thread-Index: AcuzaMrFtVAqa0tvT+uIvuKiJDLY8QAJoRwQAALyCCAAHhlcgA== References: <1309606D-29BD-4CA1-B231-BBDA2ADE1607@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16D87A@xmb-sjc-215.amer.cisco.com> <002a01cbb39b$869e1180$93da3480$%roni@huawei.com> From: "Ali C. Begen (abegen)" To: "Roni Even" , "Robert Sparks" , "Stephan Wenger" X-OriginalArrivalTime: 14 Jan 2011 18:33:38.0720 (UTC) FILETIME=[8FA30A00:01CBB419] Cc: IETF AVT WG , IESG IESG Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:14 -0000 I guess you missed my point. Dependencies do cause delay and RAMS is = only now being delayed due to the drafts you mentioned. I was not = referring to those delays in my email below. -acbegen > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Friday, January 14, 2011 4:31 AM > To: Ali C. Begen (abegen); 'Robert Sparks'; 'Stephan Wenger' > Cc: 'IETF AVT WG'; 'IESG IESG' > Subject: RE: [AVT] proposed AVT WG split >=20 > Hi Ali, > I think that some work can be spawned as a separate group using the = dispatch > WG to do so. > As for the time it took I suggest you look at the port mapping draft, = when > it started and how the discussion led to changes even late in the = process. > This draft and the cname and ssrc ports were the ones delaying the = RAMS work > and not the main body > Roni Even >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > > Ali C. Begen (abegen) > > Sent: Friday, January 14, 2011 4:20 AM > > To: Robert Sparks; Stephan Wenger > > Cc: IETF AVT WG; IESG IESG > > Subject: Re: [AVT] proposed AVT WG split > > > > I do believe that some re-organization along the lines proposed by = the > > ADs might help with the unnecessarily long delays for important = specs > > like RAMS. > > > > If you ask my opinion, RAMS draft was finished rather slowly: my > > personal target was to finish it in a year. While we had urgency = since > > other organizations were waiting for us, starting the wglc process = and > > completing it took almost a year. We did more than 20 revisions btw. > > So, editors were not the blocking factor here. > > > > Yet, many avt-seasoned people told me that 2 years was actually = quite a > > big success for a spec like RAMS. They are probably right, but often = a > > late spec is almost as good as no spec, if not worse, especially if > > another organization does something that would break something like > > RTP. It is often impossible to clean up the mess once the damage is > > done. > > > > I don't think the process can get much slower if some form of = splitting > > happens. I am sure you know this better than I do but many other > > organizations are afraid to bring their work to the IETF in general = or > > seek approval because they are concerned about the delays. If AVT = wants > > to stay relevant in related standards, I think we need to address = this > > problem. > > > > -acbegen > > > > > -----Original Message----- > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > > Robert Sparks > > > Sent: Thursday, January 13, 2011 10:28 PM > > > To: Stephan Wenger > > > Cc: IETF AVT WG; IESG IESG > > > Subject: Re: [AVT] proposed AVT WG split > > > > > > Stephan - > > > > > > As I noted in response to your comments in Maastricht, I disagree. > > > > > > There are separable streams of work in AVT - it is really multiple > > working groups in one shell at the moment. > > > > > > While there are key people currently in AVT that would overlap = these > > groups, they are not the majority of the contributors to > > > the different types of activities. > > > The intended positive effect of this explicit division is to allow > > these different streams to better parallelize, on list between > > > meetings, not just during the IETF > > > in-person meeting time. > > > > > > We'd like to try to channel these streams separately for a while. > > That will require some additional coordination work from > > > the area directors and chairs, but > > > it will bring significant benefits, especially in being able to > > better prioritize work items within the streams. I realize that for > > > folks like you, who will actively participate > > > in all of the efforts, the benefits are more limited. > > > > > > I have had several participants express frustration, for example, > > with the way the RAMs work eclipsed basic architectural > > > work in AVT. > > > While that could be managed in place (we could have only one > > working group per area in the extreme), it has shown itself > > > to be difficult > > > with the set of things this group is working on. > > > > > > I also expect the separation will make it easier to evaluate when > > the energy for a particular effort (such as the XR metrics > > > you point to below) exists, > > > and when that level of energy changes. > > > > > > Yes, conflicts between these working groups when they do meet in > > person will have to be managed carefully, but we have > > > mechanisms for that. As Keith noted > > > separately, we do not anticipate this significantly increasing the > > number-of-minutes footprint on any given in-person IETF > > > meeting. Also, your comments assume all > > > four of these groups would have a session at each in-person = meeting. > > I don't expect that to be the case. > > > > > > > > > RjS > > > > > > > > > On Jan 12, 2011, at 6:11 PM, Stephan Wenger wrote: > > > > > > > > > Hi IESG, > > > > > > As already communicated in Maastricht, I continue to believe that > > this step is a bad idea. I didn't attend Beijing, and > > > don't know whether there was any discussion about the subject. I > > didn't see anything mentioned in the AVT minutes, though, > > > nor did I see any discussion since Beijing on ietf@ietf. If there > > was, some of the points below may be redundant, and I > > > apologize in advance. > > > > > > Essentially, you guys are suggesting to split one "eternal" WG > > into four. I'm writing "eternal", because I don't see that > > > any of the WGs can fulfill its charter before other work items = will > > likely get chartered with a similar scope, and in the same > > > WG. For RTP core, RTP extensions, and RTP payloads that is = probably > > self-evident. For the XR stuff: metrics pop up all the > > > time, like payload formats. Metrics are also known to make people > > quick bucks on patent licensing. There will be more > > > metric proposals. If the RTCP-XR metrics ever get momentum in the > > marketplace, that is. Somehow, I have my doubts. But > > > that's a different discussion. > > > > > > The positive effects of the split could be > > > -chair workload is split among more people, and > > > -there are more meeting seconds for RTP related work at any given > > IETF meeting. > > > > > > Assuming unlimited resources, both are good things. > > Unfortunately, resources are not unlimited. > > > > > > The negative effects are IMO: > > > -the key knowledgeable people in AVT ideally would have to sit in > > all four meetings so that all four groups can tap > > > their experience. But they may not want to do so, because it = leaves > > less time for cross-area involvement, coordination, and > > > draft-writing outside the AVT sessions, and whatnot. Also, the > > burden for remote participants in far-away time zones goes > > > up. In other words, the resource meeting-seconds for those people = is > > not unlimited, and they will have to prioritize > > > differently. The result could be that what I called "key > > knowledgable people" would perhaps not attend the mere RTCP-XR > > > or Payload session; and the guys there may be wasting their time > > doing work that does not make sense architecturally, just to > > > see the hammer coming down at IETF last call. > > > -more people get chair positions and are burdened with > > administrative stuff -> less time to do real work > > > -WG scheduling gets more difficult > > > -AD load potentially goes up (someone needs to coordinate between > > those groups, and the AD would seem to me the > > > natural choice) > > > -there is no reason to believe that the overall manpower > > availability goes up through this change, so all the > > > inefficiencies introduced go straight against the available = cycles. > > > > > > Some of these issues can be solved by joint WG meetings and/or > > careful chair selection. However, both options have > > > drawbacks as well. A joint session would be counter-productive to > > the allocation of more meeting minutes. And when you > > > have, say, 8 chairs for four WG, all of which know the RTP > > architecture well enough, then you have pretty much exhausted, if > > > not overdrawn already, the pool of "key knowledgable people", and > > burdened them with (in many cases: additional) chair > > > duties. > > > > > > No matter how I see it, splitting the group is not a good idea. > > > > > > Other options to alleviate problems could come to mind: > > > > > > If the problem to be solved is chair-workload: add more chairs > > (but not 6 of them). > > > If the problem to be solved is meeting-second shortages: have > > interim meetings, conf calls, etc. In other words, > > > stretch out the AVT meeting in the interval between IETF meetings. > > Require a web-ex presentation of every draft to be > > > discussed in the AVT session at least 4 weeks before the meeting, > > with a two hour timeslot for Q/A. Should I continue with > > > this brainstorm? > > > > > > If the problem is something else, I would like to know. > > > > > > Thanks for your consideration, and apologies for the wordcount, > > > > > > Stephan > > > > > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 5785 (20110113) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 5785 (20110113) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > >=20 >=20 > __________ Information from ESET NOD32 Antivirus, version of virus = signature > database 5785 (20110113) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 From abegen@cisco.com Fri Jan 14 10:31:15 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958173A6C1D for ; Fri, 14 Jan 2011 10:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH9bCJ3nuBJd for ; Fri, 14 Jan 2011 10:31:14 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6A3C83A6BCD for ; Fri, 14 Jan 2011 10:31:14 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKwlME2rRN+J/2dsb2JhbACkWXOiLpkLAoJ1glgEhGuJUw Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 14 Jan 2011 18:33:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXeBc004732; Fri, 14 Jan 2011 18:33:40 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:32:59 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D307838.4030509@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces Thread-Index: Acu0BzsJRw+uBD+MQTeKSsYJJ2316QADOpVQ References: <4D307838.4030509@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:40.0379 (UTC) FILETIME=[90A02EB0:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:15 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, January 14, 2011 5:22 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces >=20 > Hi, >=20 > This is one of several issues I still see remaining in the document. = It > has clearly improved. I am sorry that I become sick before Christmas = and > couldn't continue the discussion then. >=20 > There is an issue with SSRC usage in this document related to the > different RTP sessions. Please remember that the most fundamental part > of the RTP session definition is that each RTP session has its own = SSRC > space. >=20 > So there is one SSRC number space for the multicast RTP session. An = SSRC > from this space is used in the Token Verification Request to identify > the requesting client. In the Token Verification response message this > SSRC identifier is included in the Token response message. The problem Are you referring to the port mapping request/response messages? In that = request, client chooses an SSRC randomly. This exchange does not belong = to either session (not necessarily) since the same token can be used in = different unicast sessions. In the token verification request message, the client uses whatever SSRC = it needs to use for that particular unicast session. > is that this message is conveyed in the unicast RTP session that has = its > own SSRC space. Thus we have potentially create a coupling between the > two RTP sessions. Nope, this is not correct. =20 > As I see it this can be fixed in two ways. Either one explicitly notes > that this RTCP Token Response message field carries a value that = refers > to the SSRC space in another RTP session then one currently are in. = This > is likely the simplest solution. This is already mentioned in section 4.1 where we say the ssrc is chosen = randomly.=20 =20 > The alternative is to accept the coupling. But then one has to make > clear on how to handle SSRC collisions. This seems problematic as the > coupled session is a multicast session. A multicast session has bigger > difficulties with changes due to its number of receivers and also that > if one forces an active sender to change it may causes widespread > disruption. >=20 > I also observe that it is not clear what SSRC space the Port Mapping > request and response messages uses. Does this need to be synchronized > with any other space or can it be its own unique one. A unique one is > probably easiest. I don't see any direct coupling to the other = sessions. That SSRC is not used anywhere for a purpose, so that's why we decided = to say "choose it randomly and forget about it". -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri Jan 14 10:31:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875743A6C91 for ; Fri, 14 Jan 2011 10:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J1heXcRLyFV for ; Fri, 14 Jan 2011 10:31:16 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3F8803A6C3D for ; Fri, 14 Jan 2011 10:31:16 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOYlME2rR7Ht/2dsb2JhbACkWXOiLpkLAoVNBIRriVM Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 14 Jan 2011 18:33:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXgHE003773; Fri, 14 Jan 2011 18:33:42 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:33:01 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D307AE7.9090308@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination Thread-Index: Acu0CNV9V6X+6Z3BSNSDT76IDBQ5HwADBlNA References: <4D307AE7.9090308@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:42.0330 (UTC) FILETIME=[91C9E1A0:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:17 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, January 14, 2011 5:34 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: = Part 2 Unicast RTP session Termination >=20 > Hi, >=20 > The second issue is getting back to the unicast RTP session = termination. >=20 > Having re-read this document it is very clear on when an Unicast RTP > session is created. Section 3.2, bullet 4 makes this clear. However, > there is no discussion on what the criterias are for when the session > can be considered terminated. Of course, this draft is about how to achieve port mapping and = establish/control a unicast session. For termination, the 3550 rules = apply as usual. It is because it is the unicast session that is the = important here. This draft cannot say anything at all how the sessions = established by using this draft should be terminated. =20 > This has previously been discussed in my review comments for 08 = version > but we didn't conclude on the discussion due to me being unable to > respond then. >=20 > To follow up on one thing. Yes, if we had an architectural and usage > requirements document for unicast sessions created in relation to > multicast then that document would make sense to discuss this issue. = As > I see it now, that will not be created. This is the usage independent > component so I think it makes sense to discuss it here, even if not > perfectly fit. But I like to point out that creation and some other > treatment things are discussed. So lets include how it is terminated. I disagree. It is up to the unicast session how long it lasts or when it = ends. E.g., if it is a retransmission session, it could be used for one = rtx and then may never get used, eventually it will time out. Or, the = client keeps asking for rtx and it will stay open. It has nothing to do = with the token or port mapping. =20 > The reason i think it is important to discuss is that the end-points > need to know when the other side will consider it terminated and = create > a new session in its eyes rather than continue using the current one. Server does not need to know anything other than usual RTP rules. When = the session times out, it is done.=20 > Also, the other signaling mechanisms do have some way of terminating. > SIP Dialog termination kills the media RTP sessions, they can also > become terminated in SDP by re-invites. RTSP has its Teardown method. > SAP relies on SDP t=3D attribute to tell when the session is valid. >=20 > But for this solution it is unclear. That becomes a bit more = problematic > as this is a protocol that is intended for highly dynamic cases, like > RAMS. So I would really like to know what the criteria are. Otherwise = we > can have clients sending RTCP to a server for a session it considers > closed. It also become a point of resource handling. One should clean = up > what one create. >=20 > I am fine making this timeout based, like 5 regular report interval = (or > TRR-int) without RTP activity. But I think we need to consider what it > means if one peer sends BYE. Can you time out earlier then? If there is a BYE in the unicast, of course, it will end without waiting = for the 5xinterval timeout duration. I don't see why we need to say = something about this on top of what is already in the text. -acbegen >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Fri Jan 14 10:31:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7053A6C2A for ; Fri, 14 Jan 2011 10:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.006 X-Spam-Level: X-Spam-Status: No, score=-9.006 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLoTnwh7LQW3 for ; Fri, 14 Jan 2011 10:31:18 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EBB673A6C3D for ; Fri, 14 Jan 2011 10:31:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOYlME2rR7H+/2dsb2JhbACkWXOiLpkLAoVNBIRriVM Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Jan 2011 18:33:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXiK3022105; Fri, 14 Jan 2011 18:33:44 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:33:03 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D307CF7.6040508@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 3 Binding of C2->P4 RTCP to correct RTP session Thread-Index: Acu0Cg4HuFZP+NotRq+eEK6A1Px+YgAC7uDw References: <4D307CF7.6040508@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:44.0098 (UTC) FILETIME=[92D7A820:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 3 Binding of C2->P4 RTCP to correct RTP session X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:19 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, January 14, 2011 5:43 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: = Part 3 Binding of C2->P4 RTCP to correct RTP > session >=20 > Hi, >=20 > This third issue was also brought up before and also Tom Van Caenegem > comment on it. >=20 > The RTCP reports going from C2->P4 from a receiver is not obvious on = how > to correlate with the Unicast RTP session it is reporting on that are > sent P3->C1. >=20 > The issues that may arise are the following. First there might be a = NAT > with port and address dependent mapping between them. Thus, even if > C2=3DC1, the externally seen address+port can be different between = traffic > going to P3 and P4. In addition we shall not forget that there might = be > multiple clients behind the same NAT that participate in the same > multicast session. So several RTCP flow might go to P4 from this IP > address. Correct, there could exist multiple clients sending rtcp to p4. =20 > I think some details on how to correlate this RTCP flow needs to be > included in the document. What are the determining factors? SSRC can't > be it unless we couple the multicast and unicast session. Which I = think > is a bad idea. CNAME is likely the only method that is directly > applicable and would match from the C1->P3 request to the C2->P4 one. Yes, via a CNAME. And since we now have a good CNAME guideline document, = this should work just fine. Report correlation is about the individual unicast sessions, but I agree = it is a good idea to state this explicitly in this draft, too and also = require the new CNAME guideline document so that cnames are unique. > But this needs to be stated as a requirement. +1. -acbegen =20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Fri Jan 14 10:31:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8853A6C95 for ; Fri, 14 Jan 2011 10:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcsdncRvC8J7 for ; Fri, 14 Jan 2011 10:31:20 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 651113A6C2A for ; Fri, 14 Jan 2011 10:31:20 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF8mME2rR7H+/2dsb2JhbACkWXOiLJkLAoVNBIRriVM Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2011 18:33:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXkO2022174; Fri, 14 Jan 2011 18:33:46 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:33:07 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D30813A.3010606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal time recommendation for re-use Thread-Index: Acu0DJ1ZY/yixzUrSq+sjcp/zPJkJAACkH5Q References: <4D30813A.3010606@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:46.0504 (UTC) FILETIME=[9446C880:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal time recommendation for re-use X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:21 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, January 14, 2011 6:01 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal = time > recommendation for re-use >=20 > Hi, >=20 > On page 11 last paragraph the following is written: >=20 > After a sufficient > time, a previously used receive port could be used again. >=20 > It doesn't define what a sufficiently time is. I would suggest that a > value that is extremely likely to be sufficent would be to use one TCP > Maximum Segment Lifetime which is 2 minutes. I think some = recommendation > is in order. Sure, any reference we can use for this? -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri Jan 14 10:31:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E1C28C104 for ; Fri, 14 Jan 2011 10:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keKn09xafg2V for ; Fri, 14 Jan 2011 10:31:22 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 42FB828C0D9 for ; Fri, 14 Jan 2011 10:31:22 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF8mME2rR7Ht/2dsb2JhbACkWXOiLJkLAoVNBIRriVM Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2011 18:33:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXgHG003773; Fri, 14 Jan 2011 18:33:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:33:05 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D308063.3020906@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics Thread-Index: Acu0DBtgk3yxIzGfSFe/iWyAyK7ZQQACfodw References: <4D308063.3020906@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:45.0080 (UTC) FILETIME=[936D7F80:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:23 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, January 14, 2011 5:57 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: = Part 4 SDP attribute semantics >=20 > Hi, >=20 > I think the change for the SDP attributes "portmapping" and > "portmapping-req" was an improvement. However, I think the semantics = and > usage of these SDP Attributes needs clarification. >=20 > Lets start with "portmapping", currently it seems vague and not match > the generalize requirements needed. The current semantics appears to = be: > Include in the multicast m=3D block which in relation there might be = need > for token verification request. For example if one looks at Section > 4.3.1 where BYE messages related to RAMS bursts may need tokens. That = is > within the unicast session created if I understand correctly. Thus = there > is no indication in this media block. Only in the Multicast session There is indication in the unicast block. a=3Dportmapping-req:30000 > block. This appears to be rather fuzzy and unclear. >=20 > I would like to resuggest the semantics I was considering before: >=20 > The "portmapping" attribute SHALL be included in any SDP media block > (m=3D) that define an RTP session that require the usage of token > verification requests for one or more RTCP message. We discussed this at length in the call and the group decided to propose = what we have in the draft now. Your proposal, repeating the same = attribute in two blocks, is actually worse, and even more confusing. =20 > Then I frankly have to say that I don't grasp what the semantics are > related to the placement of the "portmapping-req" attribute. Yes, it > conveys the port and possibly address for where to send the Mapping > request. But what is the meaning of its placement on a particular = media > block? Why is it placed in unicast blocks? Even if no Token is = required > in this RTP session? I don=92t know what else to add on top of what I have written before.=20 =20 > To me it appears that this attribute would be better served by = becoming > an Session + possibly override in media blocks. At session level it > would server as the port mapping port and possibly address, unless = c=3D at > session level is unicast to the mapping server, that is used for all > tokens used in the RTP sessions indicated by the "portmapping" > attribute. Then it may be included at media level in an media block > containing a=3Dportmapping to override this port and address within = that > particular media block. We decided to have both attributes media-level only. Session-level = attributes created a lot of corner cases and confusion, some of which = was raised by Roni.=20 Overall, I think the current SDP stuff works just fine. -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Fri Jan 14 10:31:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4DE928C0D9 for ; Fri, 14 Jan 2011 10:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjHhXQKQVkk1 for ; Fri, 14 Jan 2011 10:31:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 407FE28B23E for ; Fri, 14 Jan 2011 10:31:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKwlME2rR7Ht/2dsb2JhbACkWXOiLpkLAoVNBIRriVM Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2011 18:33:48 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIXmWq003876; Fri, 14 Jan 2011 18:33:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:33:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:33:09 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D308318.7010100@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior Thread-Index: Acu0Dbd9SjfhJCUYRhanTqesrDeIjgACTs/w References: <4D308318.7010100@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:33:48.0477 (UTC) FILETIME=[9573D6D0:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:31:23 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, January 14, 2011 6:09 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >=20 > Hi, >=20 > In Section 4, there is some statement about resending. I want to come = to > some conclusion on this topic that was brought up before. >=20 > The basic issue is the question on how one detects packet loss for = RTCP. > There is no other mechanism than detecting lack of response / action > from the corresponding peer. Indeed and that is what we do. =20 > The issue I have is that the RTT + server delay in responding can = easily > be many times the minimal sending interval that RTCP configure to = serve Hmm, why unless you have an awfully slow server? If the server is really = that slow, then I guess the system has more major issues than just = losing the token request messages. > even 1 mbit/s stream. Thus the formulation in the draft: >=20 > "When a client sends a > Port Mapping Request or Token Verification Request message but it > does not receive a response back from the server (either a Port > Mapping Response or Token Verification Failure message), it MAY > resend its request by following the timer rules defined for RTCP > feedback messages in Section 3.5 of [RFC4585] as a good practice." >=20 > Might not be sufficient. Because the issue is how one detects the = packet > loss and how quickly the packet is considered lost. Well, we cannot say "wait X seconds before you ask again" unless you = wanna propose a value of X. I understand this is not perfect but I don=92t think there exists = anything better than the rules we have in place. Re-using them is easy = for implementation as well. =20 BTW, the same problem exists with NACKs or other RTCP packets that can = actually create a lot of traffic. Ours is merely a corner case IMO. -acbegen > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Fri Jan 14 10:33:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8413A6C7E for ; Fri, 14 Jan 2011 10:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfOu-glgapmC for ; Fri, 14 Jan 2011 10:33:20 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6158B3A6BCD for ; Fri, 14 Jan 2011 10:33:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN4mME2rR7Hu/2dsb2JhbACkWXOiLZkMAoVNBIRriVM Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2011 18:35:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0EIZcdZ002264; Fri, 14 Jan 2011 18:35:38 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 10:35:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Jan 2011 10:34:55 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D30844F.8020508@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors Thread-Index: Acu0DnFSIV2GuMLrTA6dCkcrHzTPnwACT/tQ References: <4D30844F.8020508@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" , X-OriginalArrivalTime: 14 Jan 2011 18:35:38.0486 (UTC) FILETIME=[D705E160:01CBB419] Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2011 18:33:21 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, January 14, 2011 6:14 PM > To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: = Part 7 Persistent Errors >=20 > Hi, >=20 > This is a continuation of the issue 15A from the 08 review. >=20 > The issue is when a client should consider an error to be persistent, = or > at least not short time temporarily or resolvable. If a client = continues > to get Mapping responses with errors after having tried several times. > Maybe it should do exponential back-off. Maybe it should update its > session description. Similar for Verification Requests. >=20 > Some recommendation about such behavior I think has clear benefit and > reduced uncertainty in behavior by clients. This sounds like a good suggestion. How about adding the following to = the end of section 6: If a client receives a Port Mapping Response message with an invalid = Token (i.e., the relative expiration time is set to zero) two or more = times for a particular Port Mapping Request message, or the client = receives a Token Verification Failure message two or more times for the = same Token Verification Request message, the client SHOULD do the = following: 1- Check whether the session description has been updated or not. If it = was updated, act according to the new session description. 2- Exponentially back-off for the third and subsequent attempts. Exponential back-off does not apply when the client sends a Port Mapping = Request or Token Verification Request message to a new address and/or = port. Let me know if this text is good or you wanna modify it. -acbegen =20 > This was my last issue I have found in this review. A clear = improvement > from the previous review of the document. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From gwz@net-zen.net Fri Jan 14 20:40:36 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B34A28C0CF for ; Fri, 14 Jan 2011 20:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.928 X-Spam-Level: X-Spam-Status: No, score=-101.928 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRXGhyxqkd2l for ; Fri, 14 Jan 2011 20:40:35 -0800 (PST) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 33C2728C0CE for ; Fri, 14 Jan 2011 20:40:34 -0800 (PST) Received: (qmail 6828 invoked from network); 15 Jan 2011 04:43:00 -0000 Received: from unknown (124.120.102.157) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 15 Jan 2011 04:43:00 -0000 From: "Glen Zorn" To: "'Magnus Westerlund'" References: <000001cb9db1$49576e70$dc064b50$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF39A5@xmb-sjc-215.amer.cisco.com> <000301cb9e6d$540b1f30$fc215d90$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF3C30@xmb-sjc-215.amer.cisco.com> <001601cb9f1f$d7a9c0a0$86fd41e0$@net> <04CAD96D4C5A3D48B1919248A8FE0D540DEF3C71@xmb-sjc-215.amer.cisco.com> <4D304F0B.4030703@ericsson.com> In-Reply-To: <4D304F0B.4030703@ericsson.com> Date: Sat, 15 Jan 2011 11:42:36 +0700 Organization: Network Zen Message-ID: <000001cbb46e$a48457d0$ed8d0770$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acuz7qygqcrsbkkJQ7SXfZG0VuPY5wAfhB7A Content-Language: en-us Cc: avt@ietf.org Subject: Re: [AVT] Comment on Section 5 ofdraft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 04:40:36 -0000 Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] writes: > Hi, > > I would say that adding gives you nothing, even if detected. They you > get token failure, and anyway request a new token. Thus detecting it or > not the server will anyway eat the increased load. > > I don't see that one can mitigate this attack without integrity checking > the token response message That would depend upon your definition of "mitigate", I suppose. If you take it to mean "fully & completely foil" the attack then you are correct, but if you take the word at its more usual meaning of "lessen or to try to lessen the seriousness or extent of" the attack, then the attack can be mitigated (if detected) at little cost. Note that in my description I didn't assume perfect behavior on the part of the attacker, just some consistency, while Ali's reworking does assume that the attacker behaves perfectly & is in the path for every packet; I would say that Ali's version is not only much harder to defeat but also much more difficult to pull off. "Perfect security or none at all" is a dangerous false dichotomy... ... From Even.roni@huawei.com Sat Jan 15 05:05:40 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF323A6C5D; Sat, 15 Jan 2011 05:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lclMrwryd2Oi; Sat, 15 Jan 2011 05:05:38 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C0FFB3A6C25; Sat, 15 Jan 2011 05:05:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF20086AF58NF@szxga04-in.huawei.com>; Sat, 15 Jan 2011 21:07:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF20094YF58WS@szxga04-in.huawei.com>; Sat, 15 Jan 2011 21:07:56 +0800 (CST) Received: from YOUR6108 (user-0ccehtm.cable.mindspring.com [24.199.71.182]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF200ERXF5546@szxml02-in.huawei.com>; Sat, 15 Jan 2011 21:07:56 +0800 (CST) Date: Sat, 15 Jan 2011 15:08:04 +0200 From: Roni Even In-reply-to: <4D3016EF.4010902@ericsson.com> To: 'Magnus Westerlund' , 'Stephan Wenger' Message-id: <00d101cbb4b5$42127fe0$c6377fa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=ISO-8859-1 Content-language: he Content-transfer-encoding: quoted-printable Thread-index: AcuzzVegLe0FOraKTnqNic5hXTr6fAA53znw References: <4D3016EF.4010902@ericsson.com> Cc: 'Cullen Jennings' , iesg@ietf.org, avt@ietf.org Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 13:05:40 -0000 Magnus, I understand your position but what you stated is reflecting my concern about who will review payloads. You know that most payload drafts = authors are not IETF participants and they may attend only where their documents = are in a review stages to progress the work and afterwards they dropout Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Friday, January 14, 2011 11:27 AM > To: Stephan Wenger > Cc: Cullen Jennings; iesg@ietf.org; avt@ietf.org > Subject: Re: [AVT] proposed AVT WG split >=20 > Stephan Wenger skrev 2011-01-14 02:18: > >> > >> > >>> But they may not want to do so, because it leaves less time for > >>> cross-area involvement, coordination, and draft-writing outside = the > AVT > >>> sessions, and whatnot. Also, the burden for remote participants = in > >>> far-away time zones goes up. In other words, the resource > >>> meeting-seconds for those people is not unlimited, and they will > have to > >>> prioritize differently. The result could be that what I called > "key > >>> knowledgable people" would perhaps not attend the mere RTCP-XR or > >>> Payload session; and the guys there may be wasting their time = doing > work > >>> that does not make sense architecturally, just to see the hammer > coming > >>> down at IETF last call. > >>> -more people get chair positions and are burdened with > administrative > >>> stuff -> less time to do real work > >> > >> Given the current chair bottlenecks, and the fact we have people > that > >> would like to do this, I view the bunch more chairs a pro not a con > > > > Really? At almost every plenary I hear folks whining about how > difficult > > it is to get *qualified* chairs. (Some would say that AVT, in its > present > > incarnation, clearly shows that difficulty) >=20 > In this regard I do think splitting it does help. I will publicly = state > that I have volunteered to be a candidate to chair AVTCORE and AVTEXT. > For me this is easier to take on as I at least don't need to handle > also > the documents of PAYLOAD and XR. I do still remember my 3 years as AVT > chair. When we for a number of meeting had around 600000 words of AVT > documents. I would be much more hesitant to take on the non-split AVT. >=20 >=20 > In general I think this split is clearly worth trying out. We might > realize down the road that it is over splitting things, and that some > groups can merge or simply close. But lets gather some experience on > this. >=20 > Yes, it will have downsides, it also will have positive effects. Lets > try this somewhat different trade-off. >=20 > I do think smaller groups with less content might allow for a more > focused work in the groups. But it will require the chairs to use the > smaller scope of each group to speed up things. I also agree that when > there is contention on how to do things, things take longer time. And > that needs to be taken into account, and for example do more virtual > interim meetings etc to give the subject more focus. >=20 > In conclusion, I think this proposal is well worth trying out. And if > it > becomes misery and pain with no gain, then the AD can change things > again. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 >=20 >=20 >=20 > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 5785 (20110113) __________ >=20 > The message was checked by ESET NOD32 Antivirus. >=20 > http://www.eset.com >=20 =20 __________ Information from ESET NOD32 Antivirus, version of virus = signature database 5785 (20110113) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com =20 From gonzalo.camarillo@ericsson.com Mon Jan 17 01:02:49 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635583A6ECC; Mon, 17 Jan 2011 01:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.614 X-Spam-Level: X-Spam-Status: No, score=-106.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I7VPc6r71xH; Mon, 17 Jan 2011 01:02:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 30B7C3A6EC8; Mon, 17 Jan 2011 01:02:47 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-aa-4d340650734e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A3.F3.13987.056043D4; Mon, 17 Jan 2011 10:05:21 +0100 (CET) Received: from [131.160.126.246] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 10:05:20 +0100 Message-ID: <4D340650.2020908@ericsson.com> Date: Mon, 17 Jan 2011 11:05:20 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Roni Even References: <006e01cbb36c$b0eb6d90$12c248b0$%roni@huawei.com> In-Reply-To: <006e01cbb36c$b0eb6d90$12c248b0$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: 'Cullen Jennings' , 'Stephan Wenger' , "iesg@ietf.org" , "avt@ietf.org" Subject: Re: [AVT] proposed AVT WG split X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 09:02:49 -0000 Hi, > I would like to point out that the AVT work was split between the two Ads so > maybe we need a third AD to help with the work. yes, I have been taking care of a few AVT documents... but AD load is not the main reason for this split. I think we have already discussed all the main arguments and counter arguments before and again in this thread. We probably need running code to understand all the actual prons and cons of the split... and we will only get it by actually trying this out. Cheers, Gonzalo From magnus.westerlund@ericsson.com Mon Jan 17 02:17:16 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B271C3A6E48 for ; Mon, 17 Jan 2011 02:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vohzd23dKl3X for ; Mon, 17 Jan 2011 02:17:15 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 921EE3A6D44 for ; Mon, 17 Jan 2011 02:17:15 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-bb-4d3417c4a457 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.F1.13987.4C7143D4; Mon, 17 Jan 2011 11:19:48 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:19:48 +0100 Message-ID: <4D3417C3.4090100@ericsson.com> Date: Mon, 17 Jan 2011 11:19:47 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D30844F.8020508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3F@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:17:16 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:34: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, January 14, 2011 6:14 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors >> >> Hi, >> >> This is a continuation of the issue 15A from the 08 review. >> >> The issue is when a client should consider an error to be persistent, or >> at least not short time temporarily or resolvable. If a client continues >> to get Mapping responses with errors after having tried several times. >> Maybe it should do exponential back-off. Maybe it should update its >> session description. Similar for Verification Requests. >> >> Some recommendation about such behavior I think has clear benefit and >> reduced uncertainty in behavior by clients. > > This sounds like a good suggestion. How about adding the following to the end of section 6: > > If a client receives a Port Mapping Response message with an invalid Token (i.e., the relative expiration time is set to zero) two or more times for a particular Port Mapping Request message, or the client receives a Token Verification Failure message two or more times for the same Token Verification Request message, the client SHOULD do the following: > 1- Check whether the session description has been updated or not. If it was updated, act according to the new session description. > 2- Exponentially back-off for the third and subsequent attempts. > > Exponential back-off does not apply when the client sends a Port Mapping Request or Token Verification Request message to a new address and/or port. > > Let me know if this text is good or you wanna modify it. Good enough I think. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:28:06 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E2628C11C for ; Mon, 17 Jan 2011 02:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXuWzu3wp-eK for ; Mon, 17 Jan 2011 02:28:04 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 79AB528C124 for ; Mon, 17 Jan 2011 02:28:03 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-77-4d341a4c760c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.F3.13987.C4A143D4; Mon, 17 Jan 2011 11:30:37 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:30:35 +0100 Message-ID: <4D341A4C.7050303@ericsson.com> Date: Mon, 17 Jan 2011 11:30:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D308318.7010100@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3D@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:28:06 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Friday, January 14, 2011 6:09 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >> >> Hi, >> >> In Section 4, there is some statement about resending. I want to come to >> some conclusion on this topic that was brought up before. >> >> The basic issue is the question on how one detects packet loss for RTCP. >> There is no other mechanism than detecting lack of response / action >> from the corresponding peer. > > Indeed and that is what we do. > >> The issue I have is that the RTT + server delay in responding can easily >> be many times the minimal sending interval that RTCP configure to serve > > Hmm, why unless you have an awfully slow server? If the server is really that slow, then I guess the system has more major issues than just losing the token request messages. The problem isn't really in that. The issue is that the minimum interval period for sending RTCP can be configured to not exist, "immediate" mode. Also even in early mode AVPF can you configure an RTCP bandwidth that allows you to send packets very often and rapidly. > >> even 1 mbit/s stream. Thus the formulation in the draft: >> >> "When a client sends a >> Port Mapping Request or Token Verification Request message but it >> does not receive a response back from the server (either a Port >> Mapping Response or Token Verification Failure message), it MAY >> resend its request by following the timer rules defined for RTCP >> feedback messages in Section 3.5 of [RFC4585] as a good practice." >> >> Might not be sufficient. Because the issue is how one detects the packet >> loss and how quickly the packet is considered lost. > > Well, we cannot say "wait X seconds before you ask again" unless you wanna propose a value of X. > The algorithm I have in mind would be 1.5*RTT to the server in question + Y server processing delay. I think Y can be fairly small a few ms, like 5 ms. Unless you know that the processing delay is going to be bigger. Then add exponential backoff for detecting additional consecutive packet losses. If you don't know RTT, then at least 100 ms in a managed network situation, otherwise I would go with TCP's 500 ms as initial backoff. And for the initial mapping request, using 500 ms may not be a big issue. However, it is problematic to measure the RTT using RTCP in this setting. This as the client can't include an SR that the server can respond to. One would need to use XR's extensions for RTT measurement to achieve that. > I understand this is not perfect but I don’t think there exists anything better than the rules we have in place. Re-using them is easy for implementation as well. The issue is that with RTCP bandwidth values configured differently, then you can have a lot of spurious retransmissions. > > BTW, the same problem exists with NACKs or other RTCP packets that can actually create a lot of traffic. Ours is merely a corner case IMO. > Agreed, and this is probably something that a future update should strongly consider to discuss. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:40:08 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E3628C0F6 for ; Mon, 17 Jan 2011 02:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IvRPio893Y8 for ; Mon, 17 Jan 2011 02:40:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 853DE28C10A for ; Mon, 17 Jan 2011 02:40:06 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-1f-4d341d1f627f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.56.13987.F1D143D4; Mon, 17 Jan 2011 11:42:39 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:42:38 +0100 Message-ID: <4D341D1F.9020509@ericsson.com> Date: Mon, 17 Jan 2011 11:42:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307838.4030509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:40:08 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:32: > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Friday, January 14, 2011 5:22 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces >> >> Hi, >> >> This is one of several issues I still see remaining in the document. It >> has clearly improved. I am sorry that I become sick before Christmas and >> couldn't continue the discussion then. >> >> There is an issue with SSRC usage in this document related to the >> different RTP sessions. Please remember that the most fundamental part >> of the RTP session definition is that each RTP session has its own SSRC >> space. >> >> So there is one SSRC number space for the multicast RTP session. An SSRC >> from this space is used in the Token Verification Request to identify >> the requesting client. In the Token Verification response message this >> SSRC identifier is included in the Token response message. The problem > > Are you referring to the port mapping request/response messages? In that request, client chooses an SSRC randomly. This exchange does not belong to either session (not necessarily) since the same token can be used in different unicast sessions. > > In the token verification request message, the client uses whatever SSRC it needs to use for that particular unicast session. > >> is that this message is conveyed in the unicast RTP session that has its >> own SSRC space. Thus we have potentially create a coupling between the >> two RTP sessions. > > Nope, this is not correct. Lets try again to describe the above paragraph, as we clearly missunderstanding each other. The client has an SSRC that is uses for regular RTCP feedback to the Retransmission server. If is want to send a NACK, then it include a Token Verification Request. In that message it include the SSRC of the client. This SSRC comes from the Multicast RTP sessions SSRC space. Then the Retransmission server may send an RTCP message back to the client in a form of the Token Verification Failure message. This message include the SSRC of the requesting client. As this Token Verification Failure message is sent in the RS -> Client leg of the created unicast session, but is in reality a response to the message in the multicast RTP session. This creates a case where it is uncertain which SSRC space the SSRCs in the failure message belong to. Based on network selectors, e.g. UDP ports this message is in the unicast space. But semantically it belongs to the Multicast channel. Please make it clear in the description in 4.4 what space the SSRC values belongs to. > >> As I see it this can be fixed in two ways. Either one explicitly notes >> that this RTCP Token Response message field carries a value that refers >> to the SSRC space in another RTP session then one currently are in. This >> is likely the simplest solution. > > This is already mentioned in section 4.1 where we say the ssrc is chosen randomly. > >> The alternative is to accept the coupling. But then one has to make >> clear on how to handle SSRC collisions. This seems problematic as the >> coupled session is a multicast session. A multicast session has bigger >> difficulties with changes due to its number of receivers and also that >> if one forces an active sender to change it may causes widespread >> disruption. >> >> I also observe that it is not clear what SSRC space the Port Mapping >> request and response messages uses. Does this need to be synchronized >> with any other space or can it be its own unique one. A unique one is >> probably easiest. I don't see any direct coupling to the other sessions. > > That SSRC is not used anywhere for a purpose, so that's why we decided to say "choose it randomly and forget about it". Yes, for mapping message that is fine. The thing I can complain about is why the SSRC fields aren't there own bullets and instead hidden in the pre-facing text to the figures? -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:51:52 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F229B3A6D44 for ; Mon, 17 Jan 2011 02:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF0JJHf7Iqn0 for ; Mon, 17 Jan 2011 02:51:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E36103A6E87 for ; Mon, 17 Jan 2011 02:51:46 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-0c-4d341fdb21ea Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0A.D4.23694.BDF143D4; Mon, 17 Jan 2011 11:54:19 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:54:19 +0100 Message-ID: <4D341FDB.2050507@ericsson.com> Date: Mon, 17 Jan 2011 11:54:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:51:52 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, January 14, 2011 5:34 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination >> >> Hi, >> >> The second issue is getting back to the unicast RTP session termination. >> >> Having re-read this document it is very clear on when an Unicast RTP >> session is created. Section 3.2, bullet 4 makes this clear. However, >> there is no discussion on what the criterias are for when the session >> can be considered terminated. > > Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the 3550 rules apply as usual. It is because it is the unicast session that is the important here. This draft cannot say anything at all how the sessions established by using this draft should be terminated. The issue, I have is that you say RFC 3550 rules. I don't see how RFC 3550 applies to RTP session termination. Because that happening through external mechanism. RFC 3550 discusses when to consider an SSRC timed out. But that is not the same as terminating the session. It might be that you need to tell any using specification to declare how a unicast session is terminated. But currently this is a gapping whole in the specification. Based on the below comments it appears that you have decided that RTP session termination is when all external SSRCs has timed out. But, I wonder if the servers really are fine with that. If I as a client continue to send RTCP RR to a server in a RAMS scenario for the unicast session, then the server is not allowed to terminate the session? I think they will consider the session terminated when the burst is completed. For NACK I think one can take two approaches. One more aggressive, but both appear to work. A. Lazy, server and client consider the session terminated when the far side SSRC times out completely. This will not happen as long as both end-points sees each other RTCP RR even if no data traffic is present. B. More aggressive: The RTP session is timed out when no RTP data traffic has been sent in the RTP session for 2 or 5 regular RTCP reporting intervals. Once more my summary of this topic is: This is not defined nor obvious as this is an issue that has not existed prior to using RTP/RTCP for creating new RTP sessions. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:52:44 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05883A6D44 for ; Mon, 17 Jan 2011 02:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.046 X-Spam-Level: X-Spam-Status: No, score=-105.046 tagged_above=-999 required=5 tests=[AWL=-1.347, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-da-HcUJDjA for ; Mon, 17 Jan 2011 02:52:44 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C368A3A6F2D for ; Mon, 17 Jan 2011 02:52:43 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-81-4d342015a6fe Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.15.23694.510243D4; Mon, 17 Jan 2011 11:55:17 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:55:08 +0100 Message-ID: <4D34200C.9020706@ericsson.com> Date: Mon, 17 Jan 2011 11:55:08 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307CF7.6040508@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3A@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 3 Binding of C2->P4 RTCP to correct RTP session X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:52:45 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, January 14, 2011 5:43 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 3 Binding of C2->P4 RTCP to correct RTP >> session >> >> Hi, >> >> This third issue was also brought up before and also Tom Van Caenegem >> comment on it. >> >> The RTCP reports going from C2->P4 from a receiver is not obvious on how >> to correlate with the Unicast RTP session it is reporting on that are >> sent P3->C1. >> >> The issues that may arise are the following. First there might be a NAT >> with port and address dependent mapping between them. Thus, even if >> C2=C1, the externally seen address+port can be different between traffic >> going to P3 and P4. In addition we shall not forget that there might be >> multiple clients behind the same NAT that participate in the same >> multicast session. So several RTCP flow might go to P4 from this IP >> address. > > Correct, there could exist multiple clients sending rtcp to p4. > >> I think some details on how to correlate this RTCP flow needs to be >> included in the document. What are the determining factors? SSRC can't >> be it unless we couple the multicast and unicast session. Which I think >> is a bad idea. CNAME is likely the only method that is directly >> applicable and would match from the C1->P3 request to the C2->P4 one. > > Yes, via a CNAME. And since we now have a good CNAME guideline document, this should work just fine. > > Report correlation is about the individual unicast sessions, but I agree it is a good idea to state this explicitly in this draft, too and also require the new CNAME guideline document so that cnames are unique. > >> But this needs to be stated as a requirement. > > +1. Great, that seems to close on this issue. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:56:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC8693A6DBE for ; Mon, 17 Jan 2011 02:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFf6q+RycgTd for ; Mon, 17 Jan 2011 02:56:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 827E23A6D44 for ; Mon, 17 Jan 2011 02:56:18 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-38-4d3420eb52be Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.09.13987.BE0243D4; Mon, 17 Jan 2011 11:58:51 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 11:58:50 +0100 Message-ID: <4D3420EA.9040806@ericsson.com> Date: Mon, 17 Jan 2011 11:58:50 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:56:19 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, January 14, 2011 5:57 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics >> >> Hi, >> >> I think the change for the SDP attributes "portmapping" and >> "portmapping-req" was an improvement. However, I think the semantics and >> usage of these SDP Attributes needs clarification. >> >> Lets start with "portmapping", currently it seems vague and not match >> the generalize requirements needed. The current semantics appears to be: >> Include in the multicast m= block which in relation there might be need >> for token verification request. For example if one looks at Section >> 4.3.1 where BYE messages related to RAMS bursts may need tokens. That is >> within the unicast session created if I understand correctly. Thus there >> is no indication in this media block. Only in the Multicast session > > There is indication in the unicast block. > > a=portmapping-req:30000 > >> block. This appears to be rather fuzzy and unclear. >> >> I would like to resuggest the semantics I was considering before: >> >> The "portmapping" attribute SHALL be included in any SDP media block >> (m=) that define an RTP session that require the usage of token >> verification requests for one or more RTCP message. > > We discussed this at length in the call and the group decided to propose what we have in the draft now. Your proposal, repeating the same attribute in two blocks, is actually worse, and even more confusing. > Ok, can you then write down the exact semantics of the portmapping-req and portmapping attribute? Because to me their semantics aren't clear. And without clear semantics this is going to cause confusion when used the next time. >> Then I frankly have to say that I don't grasp what the semantics are >> related to the placement of the "portmapping-req" attribute. Yes, it >> conveys the port and possibly address for where to send the Mapping >> request. But what is the meaning of its placement on a particular media >> block? Why is it placed in unicast blocks? Even if no Token is required >> in this RTP session? > > I don’t know what else to add on top of what I have written before. > >> To me it appears that this attribute would be better served by becoming >> an Session + possibly override in media blocks. At session level it >> would server as the port mapping port and possibly address, unless c= at >> session level is unicast to the mapping server, that is used for all >> tokens used in the RTP sessions indicated by the "portmapping" >> attribute. Then it may be included at media level in an media block >> containing a=portmapping to override this port and address within that >> particular media block. > > We decided to have both attributes media-level only. Session-level attributes created a lot of corner cases and confusion, some of which was raised by Roni. Fine, I can live with that. > > Overall, I think the current SDP stuff works just fine. I disagree, because in cases where you need token verification requests also in the unicast client to server RTCP leg C2->P4, then I don't understand how that is separated from when it is only needed in C1->P3. This as I don't understand the semantics of the SDP attributes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 02:59:08 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05FF728C0E8 for ; Mon, 17 Jan 2011 02:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHT4ZA+DBoyL for ; Mon, 17 Jan 2011 02:59:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D31FB28C0D9 for ; Mon, 17 Jan 2011 02:59:06 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-cb-4d342194621b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.79.13987.491243D4; Mon, 17 Jan 2011 12:01:40 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 12:01:39 +0100 Message-ID: <4D342193.1070005@ericsson.com> Date: Mon, 17 Jan 2011 12:01:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D30813A.3010606@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3C@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal time recommendation for re-use X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 10:59:08 -0000 Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Friday, January 14, 2011 6:01 PM >> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 5 Page 11, minimal time >> recommendation for re-use >> >> Hi, >> >> On page 11 last paragraph the following is written: >> >> After a sufficient >> time, a previously used receive port could be used again. >> >> It doesn't define what a sufficiently time is. I would suggest that a >> value that is extremely likely to be sufficent would be to use one TCP >> Maximum Segment Lifetime which is 2 minutes. I think some recommendation >> is in order. > > Sure, any reference we can use for this? > RFC 793 defines MSL to be 2 minutes for that spec. I think you should specify the timer, and then informally reference the TCP spec. > -acbegen > >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Mon Jan 17 05:21:46 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C55C28C0D6 for ; Mon, 17 Jan 2011 05:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP6i22jNxjAt for ; Mon, 17 Jan 2011 05:21:45 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5A9EE3A6E49 for ; Mon, 17 Jan 2011 05:21:45 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL7RM02rRN+J/2dsb2JhbACkU3OnKJh3AoVOBIRwiVk Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2011 13:24:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0HDOJSX011866; Mon, 17 Jan 2011 13:24:19 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 05:24:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 05:23:51 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D341FDB.2050507@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination Thread-Index: Acu2NOqY6icvAGPoT/qrmJhdzxjtWAAD28Hw References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Jan 2011 13:24:19.0541 (UTC) FILETIME=[D8BE5050:01CBB649] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:21:46 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, January 17, 2011 5:54 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session = Termination >=20 > Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Friday, January 14, 2011 5:34 PM > >> To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > >> Subject: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session = Termination > >> > >> Hi, > >> > >> The second issue is getting back to the unicast RTP session = termination. > >> > >> Having re-read this document it is very clear on when an Unicast = RTP > >> session is created. Section 3.2, bullet 4 makes this clear. = However, > >> there is no discussion on what the criterias are for when the = session > >> can be considered terminated. > > > > Of course, this draft is about how to achieve port mapping and = establish/control a unicast session. For termination, the > 3550 rules apply as usual. It is because it is the unicast session = that is the important here. This draft cannot say anything at all > how the sessions established by using this draft should be terminated. >=20 > The issue, I have is that you say RFC 3550 rules. I don't see how RFC > 3550 applies to RTP session termination. Because that happening = through > external mechanism. RFC 3550 discusses when to consider an SSRC timed > out. But that is not the same as terminating the session. As a good citizen, the client can send a BYE to end the unicast session. = It is not just when SSRC times out. =20 > It might be that you need to tell any using specification to declare = how > a unicast session is terminated. But currently this is a gapping whole > in the specification. Actually, we clearly specified how a RAMS session is terminated or when = it ends. Repeating all that text here is not needed. So, maybe we should = simply say the spec using the Token approach needs to discuss the = session termination and ending sessions.=20 =20 > Based on the below comments it appears that you have decided that RTP > session termination is when all external SSRCs has timed out. But, I > wonder if the servers really are fine with that. If I as a client > continue to send RTCP RR to a server in a RAMS scenario for the = unicast > session, then the server is not allowed to terminate the session? I In RAMS, the client will continue sending RRs if and only if the client = does retransmissions in that unicast session. If that is the case, of = course, the server is fine since the session is still active. If the client does not do any further retransmissions after the burst is = completed, the RRs will not be sent so the session will end after the = timeout. > think they will consider the session terminated when the burst is > completed. Not necessarily. RAMS server is not just a burst server, it is a = retransmission server, too. =20 > For NACK I think one can take two approaches. One more aggressive, but > both appear to work. >=20 > A. Lazy, server and client consider the session terminated when the = far > side SSRC times out completely. This will not happen as long as both > end-points sees each other RTCP RR even if no data traffic is present. >=20 > B. More aggressive: The RTP session is timed out when no RTP data > traffic has been sent in the RTP session for 2 or 5 regular RTCP > reporting intervals. >=20 > Once more my summary of this topic is: This is not defined nor obvious > as this is an issue that has not existed prior to using RTP/RTCP for > creating new RTP sessions. The difference is in creating the RTP session not ending it. Just = because a session is dynamically created via RTCP does not mean that it = must have a different termination method from the regularly established = RTP sessions (3550). Once a session is up, it is up - no difference from = any other regular RTP session. Following the KISS principle here makes = sense IMO. Cheers, -acbegen =20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Mon Jan 17 05:21:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3A93A6E49 for ; Mon, 17 Jan 2011 05:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPTMhl1NAqF7 for ; Mon, 17 Jan 2011 05:21:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id F26633A6EED for ; Mon, 17 Jan 2011 05:21:45 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEbRM02rR7H+/2dsb2JhbACkU3OnOZh3AoVOBIRwiVk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2011 13:24:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0HDOKml029236; Mon, 17 Jan 2011 13:24:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 05:24:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 05:23:54 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D341D1F.9020509@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces Thread-Index: Acu2M0ngAZ+kg5TwSl6YAVDCLC8XIAAERqIw References: <4D307838.4030509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> <4D341D1F.9020509@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Jan 2011 13:24:20.0071 (UTC) FILETIME=[D90F2F70:01CBB649] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:21:47 -0000 > Lets try again to describe the above paragraph, as we clearly > missunderstanding each other. >=20 > The client has an SSRC that is uses for regular RTCP feedback to the > Retransmission server. If is want to send a NACK, then it include a > Token Verification Request. In that message it include the SSRC of the > client. This SSRC comes from the Multicast RTP sessions SSRC space. Right. =20 > Then the Retransmission server may send an RTCP message back to the > client in a form of the Token Verification Failure message. This = message > include the SSRC of the requesting client. As this Token Verification > Failure message is sent in the RS -> Client leg of the created unicast Yes, and the server simply gets this SSRC from the request message.=20 > session, but is in reality a response to the message in the multicast Yes, maybe it was a NACK sent for the multicast session. > RTP session. This creates a case where it is uncertain which SSRC = space > the SSRCs in the failure message belong to. Based on network = selectors, > e.g. UDP ports this message is in the unicast space. But semantically = it > belongs to the Multicast channel. >=20 > Please make it clear in the description in 4.4 what space the SSRC > values belongs to. In the failure message: SSRC of Packet Sender: This is server's SSRC, which equals the SSRC of = the respective primary multicast stream. SSRC of Requesting Client: This SSRC is directly copied from the Token = Verification Request message (this text already exists in 4.4). =20 Is the "packet sender SSRC" definition fine with you? =20 > >> As I see it this can be fixed in two ways. Either one explicitly = notes > >> that this RTCP Token Response message field carries a value that = refers > >> to the SSRC space in another RTP session then one currently are in. = This > >> is likely the simplest solution. > > > > This is already mentioned in section 4.1 where we say the ssrc is = chosen randomly. > > > >> The alternative is to accept the coupling. But then one has to make > >> clear on how to handle SSRC collisions. This seems problematic as = the > >> coupled session is a multicast session. A multicast session has = bigger > >> difficulties with changes due to its number of receivers and also = that > >> if one forces an active sender to change it may causes widespread > >> disruption. > >> > >> I also observe that it is not clear what SSRC space the Port = Mapping > >> request and response messages uses. Does this need to be = synchronized > >> with any other space or can it be its own unique one. A unique one = is > >> probably easiest. I don't see any direct coupling to the other = sessions. > > > > That SSRC is not used anywhere for a purpose, so that's why we = decided to say "choose it randomly and forget about it". >=20 > Yes, for mapping message that is fine. The thing I can complain about = is > why the SSRC fields aren't there own bullets and instead hidden in the > pre-facing text to the figures? We can move them to the bullets. We probably did not so because, they = are pretty much part of the baseline format. -acbegen =20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Mon Jan 17 05:21:48 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7293A6F0F for ; Mon, 17 Jan 2011 05:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ICMDhrEU0g6 for ; Mon, 17 Jan 2011 05:21:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8DB6728B797 for ; Mon, 17 Jan 2011 05:21:46 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEbRM02rRN+K/2dsb2JhbACkU3OnOZh3AoVOBIRwiVk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2011 13:24:20 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0HDOKuR019490; Mon, 17 Jan 2011 13:24:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 05:24:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 05:24:00 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior Thread-Index: Acu2MZjkYg6lkCO7QXuoGzRXvgd42AAEt4FgAABuGXA= From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Jan 2011 13:24:20.0853 (UTC) FILETIME=[D9868250:01CBB649] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:21:48 -0000 OK, I see your concern, however, should not we still follow 4585 as it = is and once it gets updated, it will be reflected here? If the immediate = mode is chosen, the NACK/RAMS could result in many more spurious = transmissions whereas the token stuff only results in one such = transmission. So putting some extra rules here for the tokens only will = not get us much. Maybe, we can add some text to disallow the immediate mode? -acbegen > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, January 17, 2011 5:31 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >=20 > Ali C. Begen (abegen) skrev 2011-01-14 19:33: > > > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of Magnus Westerlund > >> Sent: Friday, January 14, 2011 6:09 PM > >> To: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > >> Subject: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior > >> > >> Hi, > >> > >> In Section 4, there is some statement about resending. I want to = come to > >> some conclusion on this topic that was brought up before. > >> > >> The basic issue is the question on how one detects packet loss for = RTCP. > >> There is no other mechanism than detecting lack of response / = action > >> from the corresponding peer. > > > > Indeed and that is what we do. > > > >> The issue I have is that the RTT + server delay in responding can = easily > >> be many times the minimal sending interval that RTCP configure to = serve > > > > Hmm, why unless you have an awfully slow server? If the server is = really that slow, then I guess the system has more major > issues than just losing the token request messages. >=20 > The problem isn't really in that. The issue is that the minimum = interval > period for sending RTCP can be configured to not exist, "immediate" > mode. Also even in early mode AVPF can you configure an RTCP bandwidth > that allows you to send packets very often and rapidly. >=20 >=20 > > > >> even 1 mbit/s stream. Thus the formulation in the draft: > >> > >> "When a client sends a > >> Port Mapping Request or Token Verification Request message but = it > >> does not receive a response back from the server (either a Port > >> Mapping Response or Token Verification Failure message), it MAY > >> resend its request by following the timer rules defined for RTCP > >> feedback messages in Section 3.5 of [RFC4585] as a good = practice." > >> > >> Might not be sufficient. Because the issue is how one detects the = packet > >> loss and how quickly the packet is considered lost. > > > > Well, we cannot say "wait X seconds before you ask again" unless you = wanna propose a value of X. > > >=20 > The algorithm I have in mind would be 1.5*RTT to the server in = question > + Y server processing delay. I think Y can be fairly small a few ms, > like 5 ms. Unless you know that the processing delay is going to be > bigger. Then add exponential backoff for detecting additional > consecutive packet losses. >=20 >=20 >=20 > If you don't know RTT, then at least 100 ms in a managed network > situation, otherwise I would go with TCP's 500 ms as initial backoff. > And for the initial mapping request, using 500 ms may not be a big = issue. >=20 > However, it is problematic to measure the RTT using RTCP in this > setting. This as the client can't include an SR that the server can > respond to. One would need to use XR's extensions for RTT measurement = to > achieve that. >=20 > > I understand this is not perfect but I don=92t think there exists = anything better than the rules we have in place. Re-using them > is easy for implementation as well. >=20 > The issue is that with RTCP bandwidth values configured differently, > then you can have a lot of spurious retransmissions. >=20 > > > > BTW, the same problem exists with NACKs or other RTCP packets that = can actually create a lot of traffic. Ours is merely a > corner case IMO. > > >=20 > Agreed, and this is probably something that a future update should > strongly consider to discuss. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Mon Jan 17 05:55:37 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E61A28C0D9 for ; Mon, 17 Jan 2011 05:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKGC1iO1T7N0 for ; Mon, 17 Jan 2011 05:55:36 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2B54D28C0D7 for ; Mon, 17 Jan 2011 05:55:36 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD7ZM02rR7Hu/2dsb2JhbACkU3OnOph6AoVOBIRwiVk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2011 13:58:10 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0HDwALt001780; Mon, 17 Jan 2011 13:58:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 05:58:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 05:58:09 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D3420EA.9040806@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics Thread-Index: Acu2NYuLK3ZA77+FTAmP9CngnnCBcAADscaQ References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> <4D3420EA.9040806@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 17 Jan 2011 13:58:09.0962 (UTC) FILETIME=[92F7F8A0:01CBB64E] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:55:37 -0000 > Ok, can you then write down the exact semantics of the portmapping-req > and portmapping attribute? Because to me their semantics aren't clear. > And without clear semantics this is going to cause confusion when used > the next time. I am not sure what you are looking for in addition to what section 7 = says. they are used in pairs. portmapping is used in the multicast = block and portmapping-req is used in the unicast block. Together they = mean, certain rtcp messages will require the token. The portmapping-req = will tell you where to get the token from. Any confusion or question = here? =20 > >> Then I frankly have to say that I don't grasp what the semantics = are > >> related to the placement of the "portmapping-req" attribute. Yes, = it > >> conveys the port and possibly address for where to send the Mapping > >> request. But what is the meaning of its placement on a particular = media > >> block? Why is it placed in unicast blocks? Even if no Token is = required > >> in this RTP session? > > > > I don=92t know what else to add on top of what I have written = before. > > > >> To me it appears that this attribute would be better served by = becoming > >> an Session + possibly override in media blocks. At session level it > >> would server as the port mapping port and possibly address, unless = c=3D at > >> session level is unicast to the mapping server, that is used for = all > >> tokens used in the RTP sessions indicated by the "portmapping" > >> attribute. Then it may be included at media level in an media block > >> containing a=3Dportmapping to override this port and address within = that > >> particular media block. > > > > We decided to have both attributes media-level only. Session-level = attributes created a lot of corner cases and confusion, > some of which was raised by Roni. >=20 > Fine, I can live with that. >=20 > > > > Overall, I think the current SDP stuff works just fine. >=20 > I disagree, because in cases where you need token verification = requests > also in the unicast client to server RTCP leg C2->P4, then I don't The only thing that travels from c2->p4 is the receiver reports for the = unicast session. How would you send a token verification request message = on that path? The verification request message goes from c1 to p3. -acbegen > understand how that is separated from when it is only needed in = C1->P3. > This as I don't understand the semantics of the SDP attributes. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 06:52:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF2F3A6C25 for ; Mon, 17 Jan 2011 06:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.182 X-Spam-Level: X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 684q7R9Y7BKd for ; Mon, 17 Jan 2011 06:52:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2F3593A6B61 for ; Mon, 17 Jan 2011 06:52:17 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-b1-4d34583ad2cf Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EF.10.13987.A38543D4; Mon, 17 Jan 2011 15:54:50 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 15:54:48 +0100 Message-ID: <4D345838.2050805@ericsson.com> Date: Mon, 17 Jan 2011 15:54:48 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> <4D3420EA.9040806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 14:52:19 -0000 Ali C. Begen (abegen) skrev 2011-01-17 14:58: >> Ok, can you then write down the exact semantics of the portmapping-req >> and portmapping attribute? Because to me their semantics aren't clear. >> And without clear semantics this is going to cause confusion when used >> the next time. > > I am not sure what you are looking for in addition to what section 7 says. they are used in pairs. portmapping is used in the multicast block and portmapping-req is used in the unicast block. Together they mean, certain rtcp messages will require the token. The portmapping-req will tell you where to get the token from. Any confusion or question here? I think the confusion is that I believe it will be cases where Token Verification Requests are going to be need to be sent on C2->P4. If that is the case one needs semantics to say that token may also be included in RTCP message related to this session. In addition the semantics for the portmapping-req that now is mandated to be on the declaration of the unicast RTP session. If we take your argument there is no need for token verification in that session. Thus, can you please explain why it is part of that session declaration? In my world there could be token verification messages in the RTCP for the unicast session. However, the declaration of where the Token server should then either be in all RTP sessions that uses Token Verification Messages, or at session level and applies to all "portmapping". > >>>> Then I frankly have to say that I don't grasp what the semantics are >>>> related to the placement of the "portmapping-req" attribute. Yes, it >>>> conveys the port and possibly address for where to send the Mapping >>>> request. But what is the meaning of its placement on a particular media >>>> block? Why is it placed in unicast blocks? Even if no Token is required >>>> in this RTP session? >>> >>> I don’t know what else to add on top of what I have written before. >>> >>>> To me it appears that this attribute would be better served by becoming >>>> an Session + possibly override in media blocks. At session level it >>>> would server as the port mapping port and possibly address, unless c= at >>>> session level is unicast to the mapping server, that is used for all >>>> tokens used in the RTP sessions indicated by the "portmapping" >>>> attribute. Then it may be included at media level in an media block >>>> containing a=portmapping to override this port and address within that >>>> particular media block. >>> >>> We decided to have both attributes media-level only. Session-level attributes created a lot of corner cases and confusion, >> some of which was raised by Roni. >> >> Fine, I can live with that. >> >>> >>> Overall, I think the current SDP stuff works just fine. >> >> I disagree, because in cases where you need token verification requests >> also in the unicast client to server RTCP leg C2->P4, then I don't > > The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token verification request message on that path? The verification request message goes from c1 to p3. Here we seem to disagree. If one looks at the list in section 4.3.1, i think that this does contain messages where you would like to attach token, such as BYE or CCM messages. It might be me taking the generalized look on this specification. Then I do see a need to make sure that it can be used in any RTP session where indicated. If the intention to not have any session level attribute, then I don't understand why we have two SDP attributes, then only portmapping-req is needed. And I think it should be defined as having the meaning. Shall be included in the SDP media blocks that define an RTP session that needs Token Verification messages. Which means that portmapping-req are needed in the multicast m= block, not the unicast. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 07:01:53 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFB53A6E62 for ; Mon, 17 Jan 2011 07:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIczSC5-n0NO for ; Mon, 17 Jan 2011 07:01:52 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id C1A6D3A6E3F for ; Mon, 17 Jan 2011 07:01:51 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-e7-4d345a790d2b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.2E.23694.97A543D4; Mon, 17 Jan 2011 16:04:25 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 16:04:24 +0100 Message-ID: <4D345A78.2020008@ericsson.com> Date: Mon, 17 Jan 2011 16:04:24 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:01:53 -0000 Ali C. Begen (abegen) skrev 2011-01-17 14:24: > OK, I see your concern, however, should not we still follow 4585 as it is and once it gets updated, it will be reflected here? If the immediate mode is chosen, the NACK/RAMS could result in many more spurious transmissions whereas the token stuff only results in one such transmission. So putting some extra rules here for the tokens only will not get us much. > > Maybe, we can add some text to disallow the immediate mode? You seem to be punting on this issue. I think Immediate mode needs to be allowed, it makes all the sense for these type of applications in certain environments. However, what is needed is a separation of the "packet loss" / "failure for server to act on event" detection mechanism and the RTCP transmission rate limiting. I think despite our discussion of these things in CCM (RFC 5104) we did fail to take all the AVPF cases into account. I have to say that 3.5.1.1 do rely on repeating FIR messages until you get an result. It does fail to say in which mode and what type of transmission should be used for the repetitions. This as one in early mode, this is either classified as an event that are allowed to send early, or as a regular transmission. There need to be some sanity checking in this, and going forward being aware that what we specify can be seriously broken is not the best thing. In addition RAMS can be fixed. And the NACK still doesn't have a spec for this use case. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 07:10:10 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C2B28C145 for ; Mon, 17 Jan 2011 07:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL7Er7ZR-cHA for ; Mon, 17 Jan 2011 07:10:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 86DD328C10A for ; Mon, 17 Jan 2011 07:10:07 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-d0-4d345c6913c0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D2.3F.23694.96C543D4; Mon, 17 Jan 2011 16:12:41 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 16:12:41 +0100 Message-ID: <4D345C68.5030402@ericsson.com> Date: Mon, 17 Jan 2011 16:12:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:10:10 -0000 Ali C. Begen (abegen) skrev 2011-01-17 14:23: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Monday, January 17, 2011 5:54 AM >> To: Ali C. Begen (abegen) >> Cc: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination >> >> Ali C. Begen (abegen) skrev 2011-01-14 19:33: >>> >>> >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>> Sent: Friday, January 14, 2011 5:34 PM >>>> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >>>> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination >>>> >>>> Hi, >>>> >>>> The second issue is getting back to the unicast RTP session termination. >>>> >>>> Having re-read this document it is very clear on when an Unicast RTP >>>> session is created. Section 3.2, bullet 4 makes this clear. However, >>>> there is no discussion on what the criterias are for when the session >>>> can be considered terminated. >>> >>> Of course, this draft is about how to achieve port mapping and establish/control a unicast session. For termination, the >> 3550 rules apply as usual. It is because it is the unicast session that is the important here. This draft cannot say anything at all >> how the sessions established by using this draft should be terminated. >> >> The issue, I have is that you say RFC 3550 rules. I don't see how RFC >> 3550 applies to RTP session termination. Because that happening through >> external mechanism. RFC 3550 discusses when to consider an SSRC timed >> out. But that is not the same as terminating the session. > > As a good citizen, the client can send a BYE to end the unicast session. It is not just when SSRC times out. Sure, but it is the criteria that is the question. > >> It might be that you need to tell any using specification to declare how >> a unicast session is terminated. But currently this is a gapping whole >> in the specification. > > Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed. So, maybe we should simply say the spec using the Token approach needs to discuss the session termination and ending sessions. No, if that requirement is put on application of this, then I am mostly happy. > >> Based on the below comments it appears that you have decided that RTP >> session termination is when all external SSRCs has timed out. But, I >> wonder if the servers really are fine with that. If I as a client >> continue to send RTCP RR to a server in a RAMS scenario for the unicast >> session, then the server is not allowed to terminate the session? I > > In RAMS, the client will continue sending RRs if and only if the client does retransmissions in that unicast session. If that is the case, of course, the server is fine since the session is still active. > > If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session will end after the timeout. But, basically you are saying that unless the client keeps the session alive, the server will terminate it. Which gives non symmetric behavior between the client and the retransmission server. > >> think they will consider the session terminated when the burst is >> completed. > > Not necessarily. RAMS server is not just a burst server, it is a retransmission server, too. > >> For NACK I think one can take two approaches. One more aggressive, but >> both appear to work. >> >> A. Lazy, server and client consider the session terminated when the far >> side SSRC times out completely. This will not happen as long as both >> end-points sees each other RTCP RR even if no data traffic is present. >> >> B. More aggressive: The RTP session is timed out when no RTP data >> traffic has been sent in the RTP session for 2 or 5 regular RTCP >> reporting intervals. >> >> Once more my summary of this topic is: This is not defined nor obvious >> as this is an issue that has not existed prior to using RTP/RTCP for >> creating new RTP sessions. > > The difference is in creating the RTP session not ending it. Just because a session is dynamically created via RTCP does not mean that it must have a different termination method from the regularly established RTP sessions (3550). Once a session is up, it is up - no difference from any other regular RTP session. Following the KISS principle here makes sense IMO. Well, you have above described a system for retransmissions where there is a difference between the client and the server. And where there is cases for when the session is considered terminated. That is not the same as saying that it isn't terminated. I haven't argued that they must be an explicit message. Only that the rules are made clear. I am not certain that the restransmission case is well described here. And this document is the generalized form of when the unicasat session is created. I think describing this general case of termiantion has its point. And with the general case I mean: If the client stops sending RTCP regularly and the client SSRC times out from the unicast RTP session, the server is allowed to terminate/close the session. New message for creating it is needed. If the client sends BYE in the unicast session, the session can also be considered terminated (Needs Token verification or there is a DOS angle). Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jan 17 07:12:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAA628C11D for ; Mon, 17 Jan 2011 07:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP2MvRCvpPdD for ; Mon, 17 Jan 2011 07:12:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CF0F828C0D7 for ; Mon, 17 Jan 2011 07:12:46 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-8e-4d345d08bcfe Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.43.13987.80D543D4; Mon, 17 Jan 2011 16:15:20 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Mon, 17 Jan 2011 16:15:18 +0100 Message-ID: <4D345D05.104@ericsson.com> Date: Mon, 17 Jan 2011 16:15:17 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307838.4030509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> <4D341D1F.9020509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA4@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 15:12:48 -0000 Ali C. Begen (abegen) skrev 2011-01-17 14:23: >> Lets try again to describe the above paragraph, as we clearly >> missunderstanding each other. >> >> The client has an SSRC that is uses for regular RTCP feedback to the >> Retransmission server. If is want to send a NACK, then it include a >> Token Verification Request. In that message it include the SSRC of the >> client. This SSRC comes from the Multicast RTP sessions SSRC space. > > Right. > >> Then the Retransmission server may send an RTCP message back to the >> client in a form of the Token Verification Failure message. This message >> include the SSRC of the requesting client. As this Token Verification >> Failure message is sent in the RS -> Client leg of the created unicast > > Yes, and the server simply gets this SSRC from the request message. > >> session, but is in reality a response to the message in the multicast > > Yes, maybe it was a NACK sent for the multicast session. > >> RTP session. This creates a case where it is uncertain which SSRC space >> the SSRCs in the failure message belong to. Based on network selectors, >> e.g. UDP ports this message is in the unicast space. But semantically it >> belongs to the Multicast channel. >> >> Please make it clear in the description in 4.4 what space the SSRC >> values belongs to. > > In the failure message: > > SSRC of Packet Sender: This is server's SSRC, which equals the SSRC of the respective primary multicast stream. > SSRC of Requesting Client: This SSRC is directly copied from the Token Verification Request message (this text already exists in 4.4). > > Is the "packet sender SSRC" definition fine with you? I think I would like to have extra warning: "Note, theis SSRC value are from a different SSRC space than the one used in the Unicast RTP session." >> Yes, for mapping message that is fine. The thing I can complain about is >> why the SSRC fields aren't there own bullets and instead hidden in the >> pre-facing text to the figures? > > We can move them to the bullets. We probably did not so because, they are pretty much part of the baseline format. I think it has its point when we do have some irregularities here in some cases. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Tue Jan 18 01:43:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C08623A6EBC for ; Tue, 18 Jan 2011 01:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGl3BL7c6JCX for ; Tue, 18 Jan 2011 01:43:50 -0800 (PST) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id D9F953A6E77 for ; Tue, 18 Jan 2011 01:43:49 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Pf88w-00064X-Wp; Tue, 18 Jan 2011 09:46:26 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> Date: Tue, 18 Jan 2011 09:46:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 09:43:50 -0000 On 14 Jan 2011, at 16:15, Brandenburg, R. (Ray) van wrote: > We have just submitted a new version of our internet draft describing = an RTCP XR block for Inter-Destination Media Synchronization (IDMS). >=20 > http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 ... > In the past there have been some concerns about whether RTCP XR blocks = are the best solution for IDMS and if a new RTCP block wouldn't be = better. Also, some questions were raised about the advantage of having = both client->server and server->client communication with the same XR = block. On these issues we feel it is important to understand that the = proposed IDMS system is not a control protocol; client are not told how = to synchronize their playback to others. The proposed XR block only = informs clients of the slowest playback within their synchronization = group, how they deal with this information, if at all, is up to = themselves. In this way, IDMS is not that different from how RTCP is = used to deal with synchronization between audio and video streams on the = same terminal. RTCP uses a special-purpose packet type (SR) to information receivers of = the synchronisation parameters, separate to the reception reports.=20 RTCP XR is appropriate for receivers to report on their synchronisation = state. If IDMS were a peer-to-peer protocol, with each receiver directly = determining its playout based on the reported state from receivers, then = this would be sufficient for controlling playout too. However, if there = is a server-to-client control message that informs receivers of their = synchronisation point, that should, I believe, follow the previous RTCP = approach, and be coded as a separate packet type. --=20 Colin Perkins http://csperkins.org/ From abegen@cisco.com Tue Jan 18 05:07:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A0C3A6FBB for ; Tue, 18 Jan 2011 05:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7KIDnnChvEs for ; Tue, 18 Jan 2011 05:07:17 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2090D3A6E98 for ; Tue, 18 Jan 2011 05:07:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcfNU2rR7H+/2dsb2JhbACkWHOoH5lxAoVOBIRviVk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 18 Jan 2011 13:09:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0ID9sg7003981; Tue, 18 Jan 2011 13:09:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 05:09:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 05:09:38 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD64@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D345D05.104@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces Thread-Index: Acu2WV+QBh7wG9GDQ8u7S1vo5ijZUQAWcN+A References: <4D307838.4030509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA38@xmb-sjc-215.amer.cisco.com> <4D341D1F.9020509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA4@xmb-sjc-215.amer.cisco.com> <4D345D05.104@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jan 2011 13:09:54.0296 (UTC) FILETIME=[FF6E2780:01CBB710] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:07:18 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, January 17, 2011 10:15 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces >=20 > Ali C. Begen (abegen) skrev 2011-01-17 14:23: > >> Lets try again to describe the above paragraph, as we clearly > >> missunderstanding each other. > >> > >> The client has an SSRC that is uses for regular RTCP feedback to = the > >> Retransmission server. If is want to send a NACK, then it include a > >> Token Verification Request. In that message it include the SSRC of = the > >> client. This SSRC comes from the Multicast RTP sessions SSRC space. > > > > Right. > > > >> Then the Retransmission server may send an RTCP message back to the > >> client in a form of the Token Verification Failure message. This = message > >> include the SSRC of the requesting client. As this Token = Verification > >> Failure message is sent in the RS -> Client leg of the created = unicast > > > > Yes, and the server simply gets this SSRC from the request message. > > > >> session, but is in reality a response to the message in the = multicast > > > > Yes, maybe it was a NACK sent for the multicast session. > > > >> RTP session. This creates a case where it is uncertain which SSRC = space > >> the SSRCs in the failure message belong to. Based on network = selectors, > >> e.g. UDP ports this message is in the unicast space. But = semantically it > >> belongs to the Multicast channel. > >> > >> Please make it clear in the description in 4.4 what space the SSRC > >> values belongs to. > > > > In the failure message: > > > > SSRC of Packet Sender: This is server's SSRC, which equals the SSRC = of the respective primary multicast stream. > > SSRC of Requesting Client: This SSRC is directly copied from the = Token Verification Request message (this text already > exists in 4.4). > > > > Is the "packet sender SSRC" definition fine with you? >=20 > I think I would like to have extra warning: "Note, theis SSRC value = are > from a different SSRC space than the one used in the Unicast RTP = session." OK. -acbegen =20 > >> Yes, for mapping message that is fine. The thing I can complain = about is > >> why the SSRC fields aren't there own bullets and instead hidden in = the > >> pre-facing text to the figures? > > > > We can move them to the bullets. We probably did not so because, = they are pretty much part of the baseline format. >=20 > I think it has its point when we do have some irregularities here in > some cases. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Tue Jan 18 05:08:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29823A6FD7 for ; Tue, 18 Jan 2011 05:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDOkzOTnke1q for ; Tue, 18 Jan 2011 05:08:17 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C86763A6E98 for ; Tue, 18 Jan 2011 05:08:17 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADMgNU2rRN+K/2dsb2JhbACkWHOoIplxAoVOBIRviVk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2011 13:10:55 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0IDAsIL004941; Tue, 18 Jan 2011 13:10:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 05:10:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 05:10:38 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D345C68.5030402@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination Thread-Index: Acu2WQEmnF758pkZRmKwPiqhWK1GPAAWDiNA References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> <4D345C68.5030402@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jan 2011 13:10:54.0947 (UTC) FILETIME=[2394C330:01CBB711] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:08:18 -0000 > >> It might be that you need to tell any using specification to = declare how > >> a unicast session is terminated. But currently this is a gapping = whole > >> in the specification. > > > > Actually, we clearly specified how a RAMS session is terminated or = when it ends. Repeating all that text here is not needed. > So, maybe we should simply say the spec using the Token approach needs = to discuss the session termination and ending > sessions. >=20 > No, if that requirement is put on application of this, then I am = mostly > happy. Just to be clear: are you satisfied if we say " the spec using the Token = approach needs to discuss the session termination and ending Sessions"? If so, do you think we need a 2119 language here? > > > >> Based on the below comments it appears that you have decided that = RTP > >> session termination is when all external SSRCs has timed out. But, = I > >> wonder if the servers really are fine with that. If I as a client > >> continue to send RTCP RR to a server in a RAMS scenario for the = unicast > >> session, then the server is not allowed to terminate the session? I > > > > In RAMS, the client will continue sending RRs if and only if the = client does retransmissions in that unicast session. If that is > the case, of course, the server is fine since the session is still = active. > > > > If the client does not do any further retransmissions after the = burst is completed, the RRs will not be sent so the session will > end after the timeout. >=20 > But, basically you are saying that unless the client keeps the session > alive, the server will terminate it. Which gives non symmetric = behavior > between the client and the retransmission server. In practice, in an IPTV system, this is how it works to the best of my = knowledge: The client once it completes a retransmission does not BYE = the unicast ret session right after the ret packets were received. It = will send the periodic RR/XR reports, if a new NACK is sent, the server = is ready to go. When the client switches to another channel, it will BYE = that unicast session so the session will end for both sides. Yet, some = clients may stop sending reports, so the SSRC will time out on the = server side. =20 ... > >> Once more my summary of this topic is: This is not defined nor = obvious > >> as this is an issue that has not existed prior to using RTP/RTCP = for > >> creating new RTP sessions. > > > > The difference is in creating the RTP session not ending it. Just = because a session is dynamically created via RTCP does not > mean that it must have a different termination method from the = regularly established RTP sessions (3550). Once a session is > up, it is up - no difference from any other regular RTP session. = Following the KISS principle here makes sense IMO. >=20 > Well, you have above described a system for retransmissions where = there > is a difference between the client and the server. And where there is > cases for when the session is considered terminated. That is not the > same as saying that it isn't terminated. I haven't argued that they = must > be an explicit message. Only that the rules are made clear. >=20 > I am not certain that the restransmission case is well described here. > And this document is the generalized form of when the unicasat session > is created. I think describing this general case of termiantion has = its > point. And with the general case I mean: >=20 > If the client stops sending RTCP regularly and the client SSRC times = out > from the unicast RTP session, the server is allowed to terminate/close > the session. New message for creating it is needed. If the client = sends Agreed. > BYE in the unicast session, the session can also be considered > terminated (Needs Token verification or there is a DOS angle). Also agreed. More on this in an upcoming mail. =20 -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Tue Jan 18 05:08:19 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AFD53A6FAD for ; Tue, 18 Jan 2011 05:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.454 X-Spam-Level: X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln19Yykk5pig for ; Tue, 18 Jan 2011 05:08:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 545373A6F35 for ; Tue, 18 Jan 2011 05:08:18 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADMgNU2rR7H+/2dsb2JhbACkWHOoIo1WjBsCgwmCRQSEb4lZ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2011 13:10:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0IDAtmT005302; Tue, 18 Jan 2011 13:10:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 05:10:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 05:10:47 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD66@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D345A78.2020008@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior Thread-Index: Acu2V9ocHHn5m9LwQ7in7t46LwXAkgAWLN+w References: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> <4D345A78.2020008@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jan 2011 13:10:55.0546 (UTC) FILETIME=[23F029A0:01CBB711] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:08:19 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, January 17, 2011 10:04 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >=20 > Ali C. Begen (abegen) skrev 2011-01-17 14:24: > > OK, I see your concern, however, should not we still follow 4585 as = it is and once it gets updated, it will be reflected here? > If the immediate mode is chosen, the NACK/RAMS could result in many = more spurious transmissions whereas the token stuff > only results in one such transmission. So putting some extra rules = here for the tokens only will not get us much. > > > > Maybe, we can add some text to disallow the immediate mode? >=20 > You seem to be punting on this issue. I think Immediate mode needs to = be Did not even cross my mind :) > allowed, it makes all the sense for these type of applications in > certain environments. However, what is needed is a separation of the > "packet loss" / "failure for server to act on event" detection = mechanism > and the RTCP transmission rate limiting. Well said, but with RTCP one can do so much. =20 > I think despite our discussion of these things in CCM (RFC 5104) we = did > fail to take all the AVPF cases into account. I have to say that = 3.5.1.1 > do rely on repeating FIR messages until you get an result. It does = fail > to say in which mode and what type of transmission should be used for > the repetitions. This as one in early mode, this is either classified = as > an event that are allowed to send early, or as a regular transmission. >=20 > There need to be some sanity checking in this, and going forward being > aware that what we specify can be seriously broken is not the best > thing. In addition RAMS can be fixed. And the NACK still doesn't have = a > spec for this use case. OK, let me ask you this. Even if we come up with a miracle solution for = the token stuff, that still does not fix the bigger issue that one might = have with NACKs (I am omitting RAMS here since RAMS has some other = natural limits, e.g., a client would not really have multiple = outstanding RAMS requests unless it is attacking the system). So, maybe we should actually talk about fixing this in general for 4585? -acbegen =20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Tue Jan 18 05:27:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96133A6FBE for ; Tue, 18 Jan 2011 05:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjLtRRfpHHar for ; Tue, 18 Jan 2011 05:27:46 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A71B33A6FDD for ; Tue, 18 Jan 2011 05:27:46 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGskNU2rRN+K/2dsb2JhbACkWXOoMpl0AoVOBIRviVk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 13:30:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0IDUN2K014748; Tue, 18 Jan 2011 13:30:23 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 05:30:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 05:29:39 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD68@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D345838.2050805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics Thread-Index: Acu2VoYQm588ieTrRFegy2T9UAy+UwAup+BQ References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> <4D3420EA.9040806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> <4D345838.2050805@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 18 Jan 2011 13:30:23.0874 (UTC) FILETIME=[DC50DE20:01CBB713] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:27:47 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, January 17, 2011 9:55 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute = semantics >=20 > Ali C. Begen (abegen) skrev 2011-01-17 14:58: > >> Ok, can you then write down the exact semantics of the = portmapping-req > >> and portmapping attribute? Because to me their semantics aren't = clear. > >> And without clear semantics this is going to cause confusion when = used > >> the next time. > > > > I am not sure what you are looking for in addition to what section 7 = says. they are used in pairs. portmapping is used in the > multicast block and portmapping-req is used in the unicast block. = Together they mean, certain rtcp messages will require the > token. The portmapping-req will tell you where to get the token from. = Any confusion or question here? >=20 > I think the confusion is that I believe it will be cases where Token > Verification Requests are going to be need to be sent on C2->P4. If = that > is the case one needs semantics to say that token may also be included > in RTCP message related to this session. Right, the messages that control the unicast session and that are sent = in the unicast session (like BYE and CCM) need to be authenticated (as = written in 4.3.1). =20 > In addition the semantics for the portmapping-req that now is mandated > to be on the declaration of the unicast RTP session. If we take your > argument there is no need for token verification in that session. = Thus, > can you please explain why it is part of that session declaration? >=20 > In my world there could be token verification messages in the RTCP for > the unicast session. However, the declaration of where the Token = server > should then either be in all RTP sessions that uses Token Verification > Messages, or at session level and applies to all "portmapping". Ok. I guess your concern is that the "portmapping" attribute is defined = media level and used in multicast block, yet it means messages = triggering or controlling the unicast session might need token = authentication. Is this your concern? I don't think we should define it as session level as I mentioned = earlier, it opens other corner cases. So, let's see how we can address = this while keeping it media level.=20 I guess we have two options here. We either repeat the "portmapping" = attribute in both blocks and keep the "portmapping-req:port" in the = unicast block only, or repeat "portmapping-req:port" in both blocks and = remove the "portmapping" altogether. The latter saves one line from the = SDP. =20 BTW, the last part of the 3rd paragraph in section 7.1 needs to be = changed to: ... (ii) the client MUST receive the unicast session's RTP and RTCP packets from the server on the port from which it sent the RTCP message triggering the unicast session. (Removed "or controlling" since that would mean port c2). ... > > The only thing that travels from c2->p4 is the receiver reports for = the unicast session. How would you send a token > verification request message on that path? The verification request = message goes from c1 to p3. >=20 > Here we seem to disagree. If one looks at the list in section 4.3.1, i > think that this does contain messages where you would like to attach > token, such as BYE or CCM messages. Correct. =20 > It might be me taking the generalized look on this specification. Then = I > do see a need to make sure that it can be used in any RTP session = where > indicated. >=20 > If the intention to not have any session level attribute, then I don't > understand why we have two SDP attributes, then only portmapping-req = is > needed. And I think it should be defined as having the meaning. Shall = be > included in the SDP media blocks that define an RTP session that needs > Token Verification messages. Which means that portmapping-req are = needed > in the multicast m=3D block, not the unicast. Does putting the attribute only in the mcast block resolve your = concerns? I don't think so as it will not cover the unicast session for = which the rtcp messages are sent for. =20 -acbegen =20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Tue Jan 18 05:40:42 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCEA3A6FF0 for ; Tue, 18 Jan 2011 05:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oqYrBTVoh7Q for ; Tue, 18 Jan 2011 05:40:41 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 31CBE3A6FDD for ; Tue, 18 Jan 2011 05:40:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,339,1291590000"; d="scan'208";a="11205676" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 18 Jan 2011 14:43:17 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0270.001; Tue, 18 Jan 2011 14:43:16 +0100 From: "Brandenburg, R. (Ray) van" To: 'Colin Perkins' Thread-Topic: [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwC5facAAAmZdiA= Date: Tue, 18 Jan 2011 13:43:17 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 13:40:42 -0000 Hi Colin, Thanks for your comments. > RTCP XR is appropriate for receivers to report on their synchronisation s= tate. If IDMS were a peer-to-peer protocol, with each receiver directly det= ermining its playout based on the reported state from receivers, then this = would be sufficient for controlling playout too. However, if there is a ser= ver-to-client control message that informs receivers of their synchronisati= on point, that should, I believe, follow the previous RTCP approach, and be= coded as a separate packet type. What exactly do you mean by 'previous RTCP approach'? The main reason we went with an RTCP-XR report block was that we believed i= t would be less controversial to add an XR block type than a completely new= RTCP packet type. In RFC5968 (which I believe you authored) it says that t= he only valid reason to create a new RTCP packet type is if the required fu= nctionality would not be appropriate as part of one of the current packet t= ypes (such as XR-). In the description of the XR- packet type in the same d= ocument it says the XR blocks are appropriate for "for transporting new met= rics regarding media transmission or reception quality". So I think we shou= ld have a discussion about whether the IDMS block fits this description.=20 I believe the DLRR XR report block introduced in RFC3611, is somewhat simil= ar in nature to the server->client IDMS block in that it is also a server-t= o-client block that helps receivers get information on network delay.=20 Regards, Ray van Brandenburg This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From Even.roni@huawei.com Tue Jan 18 14:17:41 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C3A3A6F5E for ; Tue, 18 Jan 2011 14:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.827 X-Spam-Level: X-Spam-Status: No, score=-103.827 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4khpuR8b18E for ; Tue, 18 Jan 2011 14:17:40 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5C4B93A6D82 for ; Tue, 18 Jan 2011 14:17:40 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF800799OPJGM@szxga03-in.huawei.com> for avt@ietf.org; Wed, 19 Jan 2011 06:20:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LF8006YYOPJLV@szxga03-in.huawei.com> for avt@ietf.org; Wed, 19 Jan 2011 06:20:07 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-13-207.red.bezeqint.net [79.179.13.207]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF8000L8OPECK@szxml02-in.huawei.com>; Wed, 19 Jan 2011 06:20:07 +0800 (CST) Date: Wed, 19 Jan 2011 00:16:26 +0200 From: Roni Even To: avt@ietf.org Message-id: <00e401cbb75d$5d2ad200$17807600$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_V0ZVZ9vixZS7kcxhrHbmRg)" Content-language: en-us Thread-index: Acu3XVcrRty6S/NjST6qzJqF2hPvwA== Cc: "'DRAGE, Keith \(Keith\)'" Subject: [AVT] Review of evrc-nw, mvc and sbc payloads - plesae X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:17:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_V0ZVZ9vixZS7kcxhrHbmRg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The AVT chairs will like to do a WGLC very soon on the following three payload specifications. http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-02 http://tools.ietf.org/html/draft-ietf-avt-rtp-mvc-01 http://tools.ietf.org/html/draft-ietf-avt-rtp-sbc-01 We will appreciate a preliminary review in order to see if the documents are ready for last call. Please look at them and send comments to the list Regards Roni Even AVT co-chair --Boundary_(ID_V0ZVZ9vixZS7kcxhrHbmRg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

The AVT chairs will like to do a WGLC very soon on the following three payload specifications.

 

http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-02

 

http://tools.ietf.org/html/draft-ietf-avt-rtp-mvc-01

 

http://tools.ietf.org/html/draft-ietf-avt-rtp-sbc-01

 

We will appreciate a preliminary review in order to see if the documents a re ready p>

 

Please look at them and send comments to the list

 

Regards

Roni Even AVT co-chair

 

 

 

 

--Boundary_(ID_V0ZVZ9vixZS7kcxhrHbmRg)-- From peter.musgrave@magorcorp.com Tue Jan 18 15:46:41 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64DC28C15C for ; Tue, 18 Jan 2011 15:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beCgl2hiV5Nf for ; Tue, 18 Jan 2011 15:46:40 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A7E6E28C128 for ; Tue, 18 Jan 2011 15:46:40 -0800 (PST) Received: by iwn40 with SMTP id 40so219030iwn.31 for ; Tue, 18 Jan 2011 15:49:18 -0800 (PST) Received: by 10.231.37.12 with SMTP id v12mr6888010ibd.83.1295394558583; Tue, 18 Jan 2011 15:49:18 -0800 (PST) Received: from [192.168.1.100] ([204.237.32.134]) by mx.google.com with ESMTPS id 34sm5372414ibi.8.2011.01.18.15.49.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 15:49:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> Date: Tue, 18 Jan 2011 18:49:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:46:42 -0000 Hi Ray,=20 I think the draft is in good shape and provides a lot of additional = information.=20 I have one suggestion for adding some flexibility.=20 I continue to be concerned about using device NTP time as the basis for = system playout sync. A device playout stack may not normally have a = mechanism to force an NTP update prior to a session - and this draft = recommends that it do an NTP update. Secondly the NTP local time is not = in general a monotonic increasing clock. It will (after some amount of = playout) drift in one direction or the other and shift when the next NTP = update arrives.=20 One way to avoid this concern would be to use local free-running = monotonically increasing clocks and use some other mechanism to = determine the path delay from source to each player. NTP may work well = enough most of the time - but in cases where that is not good enough - = providing the local free running clock in the XR would provide the added = information needed for a synch source which could determine path delays = to make the necessary sync decisions.=20 I am therefore suggesting that an additional data element be added to = the end of the report - a free running local device time.=20 Regards,=20 Peter Musgrave On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > We have just submitted a new version of our internet draft describing = an RTCP XR block for Inter-Destination Media Synchronization (IDMS). >=20 > http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 >=20 > We have tried to include all feedback received both from the mailing = list as well as from IETF 79 in Beijing. >=20 > Major changes include, apart from numerous clarifications and = rewrites: >=20 > - an example/tutorial section that we hope will help make clear how = IDMS can be used in practice. > - an 'Implementation Considerations' section that adresses a number of = issues that were raised on the mailing list, including how to deal with = NTP synchronization in different use cases, echo cancellation and the = issue of reporting versus controlling. > - the removal of the mixer functionality >=20 > In the past there have been some concerns about whether RTCP XR blocks = are the best solution for IDMS and if a new RTCP block wouldn't be = better. Also, some questions were raised about the advantage of having = both client->server and server->client communication with the same XR = block. On these issues we feel it is important to understand that the = proposed IDMS system is not a control protocol; client are not told how = to synchronize their playback to others. The proposed XR block only = informs clients of the slowest playback within their synchronization = group, how they deal with this information, if at all, is up to = themselves. In this way, IDMS is not that different from how RTCP is = used to deal with synchronization between audio and video streams on the = same terminal. >=20 > I look forward to your comments. >=20 > Kind regards, >=20 > Ray van Brandenburg > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Wed Jan 19 02:43:33 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB57A3A70DD for ; Wed, 19 Jan 2011 02:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZVO2sYUZO3t for ; Wed, 19 Jan 2011 02:43:33 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B7B353A70F0 for ; Wed, 19 Jan 2011 02:43:32 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-13-4d36c0f3cecb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.F0.23694.3F0C63D4; Wed, 19 Jan 2011 11:46:11 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 11:46:10 +0100 Message-ID: <4D36C0F3.6050408@ericsson.com> Date: Wed, 19 Jan 2011 11:46:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> <744A66DF31B5B34EA8B08BBD8187A722032C2C08@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722032C2C08@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "ext Jarvinen Kari.Ju \(Nokia-NRC/Tampere\)" , Tomas Frankkila , "Mutikainen Jari \(Nokia-MS/Helsinki\)" , "ext Leung, Nikolai" , IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required forleap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 10:43:33 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2011-01-18 11:37: > Dear Magnus > > > > I compiled the attached update proposal to the draft (with changemarks), > adding support for a=rtcp-fb and a=rtcp-xr. > > Could you please consider those changes? Hi, I have looked at the changes and I have the following comments: SDP parameters. Yes, on the general level I agree this is what is intended. On a more detailed level, I think there is a bit to much respecification of things that are already defined. When it comes to AVPF usage, I will go through that to try to generalize it. I will respond separately on that. We also have some conistency issues that needs to be fixed around normative levels of mechanisms. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ray.vanbrandenburg@tno.nl Wed Jan 19 03:27:30 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2DA3A6FD3 for ; Wed, 19 Jan 2011 03:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK3iJD8lYJZY for ; Wed, 19 Jan 2011 03:27:29 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 007D23A6ECD for ; Wed, 19 Jan 2011 03:27:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,343,1291590000"; d="scan'208";a="11215848" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 19 Jan 2011 12:30:07 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 12:30:06 +0100 From: "Brandenburg, R. (Ray) van" To: 'Peter Musgrave' Thread-Topic: [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwDW7SwAABpe7FA= Date: Wed, 19 Jan 2011 11:30:06 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> In-Reply-To: <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 11:27:30 -0000 Hi Peter, > I think the draft is in good shape and provides a lot of additional infor= mation.=20 Thanks! > I am therefore suggesting that an additional data element be added to the= end of the report - a free running local device time.=20 I understand your concern and agree that free-running clocks would be a pos= sible solution. Would it be OK with you if we rename the 7th and 8th words = of the XR block to '64bit timestamp' instead of 'NTP timestamp'? Applicatio= ns can then decide whether this timestamp should be filled using NTP, local= device times or another timing solution such as GPS or PTP (precision time= protocol). This way the block becomes NTP-independent while not having to = add additional elements making it unnecessarily big.=20 Regards, Ray van Brandenburg -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: woensdag 19 januari 2011 0:49 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org Subject: Re: [AVT] New version of RTCP for IDMS Hi Ray,=20 I think the draft is in good shape and provides a lot of additional informa= tion.=20 I have one suggestion for adding some flexibility.=20 I continue to be concerned about using device NTP time as the basis for sys= tem playout sync. A device playout stack may not normally have a mechanism = to force an NTP update prior to a session - and this draft recommends that = it do an NTP update. Secondly the NTP local time is not in general a monoto= nic increasing clock. It will (after some amount of playout) drift in one d= irection or the other and shift when the next NTP update arrives.=20 One way to avoid this concern would be to use local free-running monotonica= lly increasing clocks and use some other mechanism to determine the path de= lay from source to each player. NTP may work well enough most of the time -= but in cases where that is not good enough - providing the local free runn= ing clock in the XR would provide the added information needed for a synch = source which could determine path delays to make the necessary sync decisio= ns.=20 I am therefore suggesting that an additional data element be added to the e= nd of the report - a free running local device time.=20 Regards,=20 Peter Musgrave On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > We have just submitted a new version of our internet draft describing an = RTCP XR block for Inter-Destination Media Synchronization (IDMS). >=20 > http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 >=20 > We have tried to include all feedback received both from the mailing list= as well as from IETF 79 in Beijing. >=20 > Major changes include, apart from numerous clarifications and rewrites: >=20 > - an example/tutorial section that we hope will help make clear how IDMS = can be used in practice. > - an 'Implementation Considerations' section that adresses a number of is= sues that were raised on the mailing list, including how to deal with NTP s= ynchronization in different use cases, echo cancellation and the issue of r= eporting versus controlling. > - the removal of the mixer functionality >=20 > In the past there have been some concerns about whether RTCP XR blocks ar= e the best solution for IDMS and if a new RTCP block wouldn't be better. Al= so, some questions were raised about the advantage of having both client->s= erver and server->client communication with the same XR block. On these iss= ues we feel it is important to understand that the proposed IDMS system is = not a control protocol; client are not told how to synchronize their playba= ck to others. The proposed XR block only informs clients of the slowest pla= yback within their synchronization group, how they deal with this informati= on, if at all, is up to themselves. In this way, IDMS is not that different= from how RTCP is used to deal with synchronization between audio and video= streams on the same terminal. >=20 > I look forward to your comments. >=20 > Kind regards, >=20 > Ray van Brandenburg > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/disclaimer/email.html >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From peter.musgrave@magorcorp.com Wed Jan 19 03:40:10 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0887D3A70F8 for ; Wed, 19 Jan 2011 03:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSD5M0igBZ-u for ; Wed, 19 Jan 2011 03:40:08 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AE6B33A70E2 for ; Wed, 19 Jan 2011 03:40:08 -0800 (PST) Received: by iyi42 with SMTP id 42so729729iyi.31 for ; Wed, 19 Jan 2011 03:42:48 -0800 (PST) Received: by 10.42.169.74 with SMTP id a10mr705418icz.23.1295437368397; Wed, 19 Jan 2011 03:42:48 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id u5sm5276177ics.6.2011.01.19.03.42.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Jan 2011 03:42:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Wed, 19 Jan 2011 06:42:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A5816BE-7E77-49D0-9754-BD8DCFEA7BF5@magorcorp.com> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 11:40:10 -0000 Hi Ray,=20 I like that idea, but then I think having a flag field to indicate if it = is e.g. NTP or "vendor specific" might be useful from an interop = perspective. Peter On 2011-01-19, at 6:30 AM, Brandenburg, R. (Ray) van wrote: > Hi Peter, >=20 >> I think the draft is in good shape and provides a lot of additional = information.=20 >=20 > Thanks! >=20 >> I am therefore suggesting that an additional data element be added to = the end of the report - a free running local device time.=20 >=20 > I understand your concern and agree that free-running clocks would be = a possible solution. Would it be OK with you if we rename the 7th and = 8th words of the XR block to '64bit timestamp' instead of 'NTP = timestamp'? Applications can then decide whether this timestamp should = be filled using NTP, local device times or another timing solution such = as GPS or PTP (precision time protocol). This way the block becomes = NTP-independent while not having to add additional elements making it = unnecessarily big.=20 >=20 > Regards, >=20 > Ray van Brandenburg >=20 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: woensdag 19 januari 2011 0:49 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org > Subject: Re: [AVT] New version of RTCP for IDMS >=20 > Hi Ray,=20 >=20 > I think the draft is in good shape and provides a lot of additional = information.=20 >=20 > I have one suggestion for adding some flexibility.=20 >=20 > I continue to be concerned about using device NTP time as the basis = for system playout sync. A device playout stack may not normally have a = mechanism to force an NTP update prior to a session - and this draft = recommends that it do an NTP update. Secondly the NTP local time is not = in general a monotonic increasing clock. It will (after some amount of = playout) drift in one direction or the other and shift when the next NTP = update arrives.=20 >=20 > One way to avoid this concern would be to use local free-running = monotonically increasing clocks and use some other mechanism to = determine the path delay from source to each player. NTP may work well = enough most of the time - but in cases where that is not good enough - = providing the local free running clock in the XR would provide the added = information needed for a synch source which could determine path delays = to make the necessary sync decisions.=20 >=20 > I am therefore suggesting that an additional data element be added to = the end of the report - a free running local device time.=20 >=20 > Regards,=20 >=20 > Peter Musgrave >=20 >=20 >=20 >=20 > On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote: >=20 >> Hi all, >>=20 >> We have just submitted a new version of our internet draft describing = an RTCP XR block for Inter-Destination Media Synchronization (IDMS). >>=20 >> http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 >>=20 >> We have tried to include all feedback received both from the mailing = list as well as from IETF 79 in Beijing. >>=20 >> Major changes include, apart from numerous clarifications and = rewrites: >>=20 >> - an example/tutorial section that we hope will help make clear how = IDMS can be used in practice. >> - an 'Implementation Considerations' section that adresses a number = of issues that were raised on the mailing list, including how to deal = with NTP synchronization in different use cases, echo cancellation and = the issue of reporting versus controlling. >> - the removal of the mixer functionality >>=20 >> In the past there have been some concerns about whether RTCP XR = blocks are the best solution for IDMS and if a new RTCP block wouldn't = be better. Also, some questions were raised about the advantage of = having both client->server and server->client communication with the = same XR block. On these issues we feel it is important to understand = that the proposed IDMS system is not a control protocol; client are not = told how to synchronize their playback to others. The proposed XR block = only informs clients of the slowest playback within their = synchronization group, how they deal with this information, if at all, = is up to themselves. In this way, IDMS is not that different from how = RTCP is used to deal with synchronization between audio and video = streams on the same terminal. >>=20 >> I look forward to your comments. >>=20 >> Kind regards, >>=20 >> Ray van Brandenburg >> This e-mail and its contents are subject to the DISCLAIMER at=20 >> http://www.tno.nl/disclaimer/email.html >>=20 >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >=20 From ray.vanbrandenburg@tno.nl Wed Jan 19 03:54:58 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF2B3A6FD5 for ; Wed, 19 Jan 2011 03:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.232 X-Spam-Level: X-Spam-Status: No, score=-0.232 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ych7rqLVEXru for ; Wed, 19 Jan 2011 03:54:57 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 7B51B3A6ED2 for ; Wed, 19 Jan 2011 03:54:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,343,1291590000"; d="scan'208";a="11216151" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 19 Jan 2011 12:57:35 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 12:57:35 +0100 From: "Brandenburg, R. (Ray) van" To: 'Peter Musgrave' Thread-Topic: [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwDW7SwAABpe7FD///RkAP//7Ecg Date: Wed, 19 Jan 2011 11:57:35 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> <4A5816BE-7E77-49D0-9754-BD8DCFEA7BF5@magorcorp.com> In-Reply-To: <4A5816BE-7E77-49D0-9754-BD8DCFEA7BF5@magorcorp.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 11:54:58 -0000 Hi Peter, I agree there should be some way to indicate what type of timestamp is used= . Apart from a flag field, for which there are some bits left, another opti= on would be to have this information in an SDP parameter, since we also use= that to indicate the chosen group-sync identifier. =20 Ray -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: woensdag 19 januari 2011 12:43 To: Brandenburg, R. (Ray) van Cc: avt@ietf.org Subject: Re: [AVT] New version of RTCP for IDMS Hi Ray,=20 I like that idea, but then I think having a flag field to indicate if it is= e.g. NTP or "vendor specific" might be useful from an interop perspective. Peter On 2011-01-19, at 6:30 AM, Brandenburg, R. (Ray) van wrote: > Hi Peter, >=20 >> I think the draft is in good shape and provides a lot of additional info= rmation.=20 >=20 > Thanks! >=20 >> I am therefore suggesting that an additional data element be added to th= e end of the report - a free running local device time.=20 >=20 > I understand your concern and agree that free-running clocks would be a p= ossible solution. Would it be OK with you if we rename the 7th and 8th word= s of the XR block to '64bit timestamp' instead of 'NTP timestamp'? Applicat= ions can then decide whether this timestamp should be filled using NTP, loc= al device times or another timing solution such as GPS or PTP (precision ti= me protocol). This way the block becomes NTP-independent while not having t= o add additional elements making it unnecessarily big.=20 >=20 > Regards, >=20 > Ray van Brandenburg >=20 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: woensdag 19 januari 2011 0:49 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org > Subject: Re: [AVT] New version of RTCP for IDMS >=20 > Hi Ray, >=20 > I think the draft is in good shape and provides a lot of additional infor= mation.=20 >=20 > I have one suggestion for adding some flexibility.=20 >=20 > I continue to be concerned about using device NTP time as the basis for s= ystem playout sync. A device playout stack may not normally have a mechanis= m to force an NTP update prior to a session - and this draft recommends tha= t it do an NTP update. Secondly the NTP local time is not in general a mono= tonic increasing clock. It will (after some amount of playout) drift in one= direction or the other and shift when the next NTP update arrives.=20 >=20 > One way to avoid this concern would be to use local free-running monotoni= cally increasing clocks and use some other mechanism to determine the path = delay from source to each player. NTP may work well enough most of the time= - but in cases where that is not good enough - providing the local free ru= nning clock in the XR would provide the added information needed for a sync= h source which could determine path delays to make the necessary sync decis= ions.=20 >=20 > I am therefore suggesting that an additional data element be added to the= end of the report - a free running local device time.=20 >=20 > Regards, >=20 > Peter Musgrave >=20 >=20 >=20 >=20 > On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote: >=20 >> Hi all, >>=20 >> We have just submitted a new version of our internet draft describing an= RTCP XR block for Inter-Destination Media Synchronization (IDMS). >>=20 >> http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 >>=20 >> We have tried to include all feedback received both from the mailing lis= t as well as from IETF 79 in Beijing. >>=20 >> Major changes include, apart from numerous clarifications and rewrites: >>=20 >> - an example/tutorial section that we hope will help make clear how IDMS= can be used in practice. >> - an 'Implementation Considerations' section that adresses a number of i= ssues that were raised on the mailing list, including how to deal with NTP = synchronization in different use cases, echo cancellation and the issue of = reporting versus controlling. >> - the removal of the mixer functionality >>=20 >> In the past there have been some concerns about whether RTCP XR blocks a= re the best solution for IDMS and if a new RTCP block wouldn't be better. A= lso, some questions were raised about the advantage of having both client->= server and server->client communication with the same XR block. On these is= sues we feel it is important to understand that the proposed IDMS system is= not a control protocol; client are not told how to synchronize their playb= ack to others. The proposed XR block only informs clients of the slowest pl= ayback within their synchronization group, how they deal with this informat= ion, if at all, is up to themselves. In this way, IDMS is not that differen= t from how RTCP is used to deal with synchronization between audio and vide= o streams on the same terminal. >>=20 >> I look forward to your comments. >>=20 >> Kind regards, >>=20 >> Ray van Brandenburg >> This e-mail and its contents are subject to the DISCLAIMER at=20 >> http://www.tno.nl/disclaimer/email.html >>=20 >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/disclaimer/email.html >=20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From peter.musgrave@magorcorp.com Wed Jan 19 04:00:29 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6005A3A6ED2 for ; Wed, 19 Jan 2011 04:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3EAikgEKlVj for ; Wed, 19 Jan 2011 04:00:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id EB3583A6FC2 for ; Wed, 19 Jan 2011 04:00:27 -0800 (PST) Received: by iyi42 with SMTP id 42so749633iyi.31 for ; Wed, 19 Jan 2011 04:03:07 -0800 (PST) Received: by 10.42.179.193 with SMTP id br1mr680837icb.457.1295438587792; Wed, 19 Jan 2011 04:03:07 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id he5sm5288943icb.10.2011.01.19.04.03.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 19 Jan 2011 04:03:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Wed, 19 Jan 2011 07:03:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <769DF027-3604-4E20-9465-0EA918C424B4@magorcorp.com> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> <4A5816BE-7E77-49D0-9754-BD8DCFEA7BF5@magorcorp.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 12:00:29 -0000 You're right, an SDP parameter is way better....for now I think all we = need are values ntp and local. This does however open up a negotiation issue which will require = clarification. If a device supports both - how does it say so, who = decides etc. Peter On 2011-01-19, at 6:57 AM, Brandenburg, R. (Ray) van wrote: > Hi Peter, >=20 > I agree there should be some way to indicate what type of timestamp is = used. Apart from a flag field, for which there are some bits left, = another option would be to have this information in an SDP parameter, = since we also use that to indicate the chosen group-sync identifier. =20 >=20 > Ray >=20 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: woensdag 19 januari 2011 12:43 > To: Brandenburg, R. (Ray) van > Cc: avt@ietf.org > Subject: Re: [AVT] New version of RTCP for IDMS >=20 > Hi Ray,=20 >=20 > I like that idea, but then I think having a flag field to indicate if = it is e.g. NTP or "vendor specific" might be useful from an interop = perspective. >=20 > Peter >=20 > On 2011-01-19, at 6:30 AM, Brandenburg, R. (Ray) van wrote: >=20 >> Hi Peter, >>=20 >>> I think the draft is in good shape and provides a lot of additional = information.=20 >>=20 >> Thanks! >>=20 >>> I am therefore suggesting that an additional data element be added = to the end of the report - a free running local device time.=20 >>=20 >> I understand your concern and agree that free-running clocks would be = a possible solution. Would it be OK with you if we rename the 7th and = 8th words of the XR block to '64bit timestamp' instead of 'NTP = timestamp'? Applications can then decide whether this timestamp should = be filled using NTP, local device times or another timing solution such = as GPS or PTP (precision time protocol). This way the block becomes = NTP-independent while not having to add additional elements making it = unnecessarily big.=20 >>=20 >> Regards, >>=20 >> Ray van Brandenburg >>=20 >> -----Original Message----- >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> Sent: woensdag 19 januari 2011 0:49 >> To: Brandenburg, R. (Ray) van >> Cc: avt@ietf.org >> Subject: Re: [AVT] New version of RTCP for IDMS >>=20 >> Hi Ray, >>=20 >> I think the draft is in good shape and provides a lot of additional = information.=20 >>=20 >> I have one suggestion for adding some flexibility.=20 >>=20 >> I continue to be concerned about using device NTP time as the basis = for system playout sync. A device playout stack may not normally have a = mechanism to force an NTP update prior to a session - and this draft = recommends that it do an NTP update. Secondly the NTP local time is not = in general a monotonic increasing clock. It will (after some amount of = playout) drift in one direction or the other and shift when the next NTP = update arrives.=20 >>=20 >> One way to avoid this concern would be to use local free-running = monotonically increasing clocks and use some other mechanism to = determine the path delay from source to each player. NTP may work well = enough most of the time - but in cases where that is not good enough - = providing the local free running clock in the XR would provide the added = information needed for a synch source which could determine path delays = to make the necessary sync decisions.=20 >>=20 >> I am therefore suggesting that an additional data element be added to = the end of the report - a free running local device time.=20 >>=20 >> Regards, >>=20 >> Peter Musgrave >>=20 >>=20 >>=20 >>=20 >> On 2011-01-14, at 11:15 AM, Brandenburg, R. (Ray) van wrote: >>=20 >>> Hi all, >>>=20 >>> We have just submitted a new version of our internet draft = describing an RTCP XR block for Inter-Destination Media Synchronization = (IDMS). >>>=20 >>> http://tools.ietf.org/html/draft-brandenburg-avt-rtcp-for-idms-03 >>>=20 >>> We have tried to include all feedback received both from the mailing = list as well as from IETF 79 in Beijing. >>>=20 >>> Major changes include, apart from numerous clarifications and = rewrites: >>>=20 >>> - an example/tutorial section that we hope will help make clear how = IDMS can be used in practice. >>> - an 'Implementation Considerations' section that adresses a number = of issues that were raised on the mailing list, including how to deal = with NTP synchronization in different use cases, echo cancellation and = the issue of reporting versus controlling. >>> - the removal of the mixer functionality >>>=20 >>> In the past there have been some concerns about whether RTCP XR = blocks are the best solution for IDMS and if a new RTCP block wouldn't = be better. Also, some questions were raised about the advantage of = having both client->server and server->client communication with the = same XR block. On these issues we feel it is important to understand = that the proposed IDMS system is not a control protocol; client are not = told how to synchronize their playback to others. The proposed XR block = only informs clients of the slowest playback within their = synchronization group, how they deal with this information, if at all, = is up to themselves. In this way, IDMS is not that different from how = RTCP is used to deal with synchronization between audio and video = streams on the same terminal. >>>=20 >>> I look forward to your comments. >>>=20 >>> Kind regards, >>>=20 >>> Ray van Brandenburg >>> This e-mail and its contents are subject to the DISCLAIMER at=20 >>> http://www.tno.nl/disclaimer/email.html >>>=20 >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>=20 >> This e-mail and its contents are subject to the DISCLAIMER at=20 >> http://www.tno.nl/disclaimer/email.html >>=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >=20 From thomas.belling@nsn.com Wed Jan 19 04:22:45 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED783A7102 for ; Wed, 19 Jan 2011 04:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=2.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCPsUhFnxL9n for ; Wed, 19 Jan 2011 04:22:45 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 2CF643A6FCD for ; Wed, 19 Jan 2011 04:22:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0JCPINU022684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 13:25:18 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0JCPHCA025529; Wed, 19 Jan 2011 13:25:18 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 13:25:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBB7D3.EE0A478B" Date: Wed, 19 Jan 2011 13:25:15 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722032F8F8B@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D36C0F3.6050408@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required forleap-of-faith initialisation? Thread-Index: Acu3xhjiSpiAUCVJSDyQtsOxmtEWFwADVDQQ References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> <744A66DF31B5B34EA8B08BBD8187A722032C2C08@DEMUEXC014.nsn-intra.net> <4D36C0F3.6050408@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" X-OriginalArrivalTime: 19 Jan 2011 12:25:16.0970 (UTC) FILETIME=[EE0860A0:01CBB7D3] Cc: "ext Jarvinen Kari.Ju \(Nokia-NRC/Tampere\)" , Tomas Frankkila , "Mutikainen Jari \(Nokia-MS/Helsinki\)" , "ext Leung, Nikolai" , IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required forleap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 12:22:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBB7D3.EE0A478B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Magnus. My original email got blocked on the AVT exploder due to its size. I thus resend it with a shortened attachment, showing only the parts of = the draft where I propose changes. The changes are still exactly the = same. Thomas -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, January 19, 2011 11:46 AM To: Belling, Thomas (NSN - DE/Munich) Cc: IETF AVT WG; ext Jarvinen Kari.Ju (Nokia-NRC/Tampere); Mutikainen = Jari (Nokia-MS/Helsinki); ext Leung, Nikolai; Tomas Frankkila Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required = forleap-of-faith initialisation? Belling, Thomas (NSN - DE/Munich) skrev 2011-01-18 11:37: > Dear Magnus >=20 > =20 >=20 > I compiled the attached update proposal to the draft (with=20 > changemarks), adding support for a=3Drtcp-fb and a=3Drtcp-xr. >=20 > Could you please consider those changes? Hi, I have looked at the changes and I have the following comments: SDP parameters. Yes, on the general level I agree this is what is = intended. On a more detailed level, I think there is a bit to much = respecification of things that are already defined. When it comes to AVPF usage, I will go through that to try to generalize = it. I will respond separately on that. We also have some conistency issues that needs to be fixed around = normative levels of mechanisms. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------_=_NextPart_001_01CBB7D3.EE0A478B Content-Type: application/x-zip-compressed; name="change proposals to draft-ietf-avt-ecn-for-rtp-03.zip" Content-Transfer-Encoding: base64 Content-Description: change proposals to draft-ietf-avt-ecn-for-rtp-03.zip Content-Disposition: attachment; filename="change proposals to draft-ietf-avt-ecn-for-rtp-03.zip" UEsDBBQAAgAIAKJqMz4kiLulkVwAAABcAQA1AAAAY2hhbmdlIHByb3Bvc2FscyB0byBkcmFmdC1p ZXRmLWF2dC1lY24tZm9yLXJ0cC0wMy5kb2PsfQdgVFXa9gnSJVKkYxkjSAKTQAhFEJVepUixIeLN zE1yYZpzJwlx7VhRVsWGXVy7qKhYQcWylrVXUFZRsS727rrK/7yn3XNnJsng+u3Ht39GH5KZuffc c877nrefk5de7Pjuyjt7vsfSXgewndhv29qwlsZnzYCb1ZsOjN2KH3nAb9u2baOPbgRuArY1vf7P vD67/lG200ltmjP2VadHBGUH8n9bMzZ1KWO7sPKF5QvXHLLmEJbxatW8Kxv8AWNvjMzjiJ3s//7v addv29a+0d/V6z7+b782TP+MdRW/q5/n4Ock/PypK2dG1robY519TxNcuVs38T7bzyvw8378fM74 fPUg/A5WP7W7eN/YzwU9sv9sMUismFaD5Gzl8LM3fj43mLFrcWNsGGPT8b4/Pu+SOfl8HvaQz9sj y/fp/Tm+h5if8/GznWw3vT3zpxqfetH7Tfg5Cvehi2xGqfg8/eeV9JzWme2kv2+R9nx1//a+zPlu qL3f2359L9WeGo/it5fWTTjk1fuezVPXKb66cy/GXtslsx9flwq6pND/kZL/zPbXDRM/T8O6/Jvx /o8aD7Wzj9Guer3WVfBjNb4/Lgs/qeenf54rvdJ/Kn5M58vG5v/3Pk/Nc33fp49H0Tf9Z2Pf/0/9 VPRqrP/bS5/tnUeSzW0hUAZDSI0A17dgnfJINzRvndecNb128Fd+flnJoJJAYHQiEXFCVrkTcVJ1 +fmBQGBOlR2odu1AvCIwfuz0QK2TqgrMmjMzEK+xk4G542YGHDcQthN2LGzHUoF4LBCzK+Mpx0o5 +F3cRM2ErIRsNVBup2ptOxZIoWWX7ksGrFg4kLRDtoNGC92iIP+gxoo44fR23OpEIp5MBZxYwIpE AnbEjuK5Ll1B7cXQdjy5KJCwUlVoKJBKWmjStcMYG/XacakRjCfMWwhU2Sk7Ga+0Y3a82g0krVgl H6lqxo7VOMl4TDyC+pSKJ+KReKVju0FqiM9GjZV06O6wU1FhJ2kWXKcyht45scpAIhlPxUPxiBvk /UXbtVVOqApPsKk1TAa1gz46FY74RI2QZrvcrogn7YCTwvzF8I73vMSgi1WpKQM6VFQnMQlJPz0s c+7lNGEqqI2oHXasQEUkXksPTtpWKEW/hOKYBpdPvBwJelZex58StZKL8C5hhRbZKbeEWhnHn0aD jQuiWoKJqIGgfEYoHrZDgqxqbuVU1gVxjyCLFbYSKUFwGm48FKpOEpnUBGMuooIMVkp/GEPLLnEu fUOt2IutaCJiB03+ouZCVZy69Knokx1Dr9DtYCCe5B8rDhT86rvDrS53Q0knwTuHKbICEasOxA77 W7EdPv98JnGlagiEs0KhOLrluFViLi1izZgr7g1EnXA4YpfHFxObThgbGFJaOizgEAWJLfjkuHYN rRnNfzQxgpWIr13bdfFAF/ShBUYkrHAqq9FBMen8Sk5yfG+BT4nSRCrJFxgSLXJQeITgLjyneGbc iaWKU/KXEcRzYDL8bwXcFFq1kuFAdQyUdlOcidB5wSJ1kq3VUtNCw4lxYmva80VI/1t4R9SMWrEY JhDdcbDicLNshrcQ55Ornsjnj68UY43JJ42dSTNQY9fR5ErJgVcFFl05OBcM4NLScUu8wU6rjqR4 w8Y4JTl5D+sCbrw6GQLzqAsDhaNnTysKVCbj1Qmzm4l4igiHZVPHqZa0IgHihxrFjoKHvXaov2k9 5NxkqUe6CTsERgiZz56tny2eiosx2IiaMEOwqgnj06KnoCIZj2qOd7l4HCuFOS16OywbIokUsiI2 /RKxklgP4qGucyyYEHyFr6yauMP5WLfugNfjrlwCeBW6th2YbfNVERhaMogE0TxwetmQIQPnB/mv g4fsO2S+4FZ6O2TY0IHzpSYIWaodKQLFCpJjRMfCJMajTgyisoLLWeIePTjRCEgpGzGVBPEivoq7 tnm9KYPTu15UIpuZnKLpcuNRu7YKAilKkpp0gBMClbL2yvdgRXGiA32peIOkC97q3pidITkHQZKk yY5ActaqIeEOCHHqLtcp3iTFpHjgM1XtcmGjmYjUNxZPDSSNJrcnNKss11BMNET6Uk+amuZFsXht zOuu4j+v02L6nWTSJj7m64CrQZsvLq9NPhN8jft4WFLIdpL1zsl0rDjRQ3MxRu1oOa6tchJcJElp Hq5O0iTQYyNOhZ1yorw7lm89ztQ94GI16FvTkIXJeLg6RM3E7FqjV7wLFtggFk8ZYofr34iNjs6W I4pW4zEkcIU2oq45bpSvPWiZcmGdeDw32FuL0XjMSXF9RY/y8QkkXsqJVdtpRoTm/jrN/sLQqMDt fLHi91g8VkzcQ30iZiVxJ/sapm9ThqScQ4I3YqEXEJWjBYOl9GdcP/APiyMQfhFPt4k+O4pDHNhW rlMuJAvNgxDvCSsJMjgJi0wuJ6bMFUWKQKEVwXKtrqxSzfBVWO1Wc9qoJuWNluvGQ7BFMWDDJpNN 6YUMUwo0I7pheQZSdQmb25P+cY2QUkJMB+iApV5nCBVhU7gp6P6omHJqEDQJ2cmY0oGGzrKSVpTk A6QN7BrZiLRdfNxIqllK8EqMpNaq209SNO5Krg/HZX+MRezvTwUZJ7Jx0/BQtrhnu/L7FOOS1caN K6lcfJRQtrXLn+fNVLq4NXiD833Srk06KVsoHKWJMSGuKxZmkqhLdCV2t1KhKmNUYhG79G3UWmQr 2cD7BV/B0oYp9TliV1ohSEkwdrEyR2JWLegSzMK09mKSTmJpgFdImlPL3AwnOad1mVxx2giW48Wi s1P+W/jCSmFhzSFxF+NLCmOU7ejbXZjclpDNdKvPgYppAcnXt+XEpPTKnFy+pJ0IVghWLwmmtDFK VrFdzsC1MEVxS6a45sISHIVeuU7Ugc6P1BWV8JVO3/L5S28atyhFFOK+WTxmC18jCeUJlnWFWYlX PyjOijSO8XrlLas0BgbBXSz7iNJTnDsTdf75ro4J/ggLXULfOTDPo3zKpJCpTlXGPRrgRWxTicUI QlTHImBHKVLIwY3ELahGTl9ij6QDa58a8zykoNeQNsixVm3BoXXcX/I92HuetNv4tBaPHe81RPeQ sqgOVSk/QUwTrRFMlN+Q04MuaXCK+cw6crGacys8vmg52Sm4zoWTkvL6QoTWjFpebTAQF9fgIk+g GM4VEcwYEC17mPZWZdqa4j54Lbkk2gPgdCJGVarQN8FKJw4pKdMmZOnQfeePEFor00XlJpp/SNDf cZL03EOEcxYnwWxSSI5XdLvcNho1GuHOWYgrHcVaSafSwTj2o74owz/TZya9YDIxn/mw6BWWTTBb X3RXpEeSjWPQBq2kZDyRoOaEEpf+vl4FRh/qaaREM4/ug+6jN6XSwMH98jZjHfBZBftPmzt7jpi+ OaqDjfSq1janxrsPfTqUGuWMTzOqmV/dWagZo8g/v0pY82mt0/ModFCKe9RCyQje5YtEhC5cc2bC 2krxLR2fbzCspLSo4TXIXWfRgF4zSU3wRDU3PX0amESzeBQJkyoo3EDSCku+85Q2JEASkhcCCkIp xA3RmKEkONP7mpetksduYewu2FlRJV1dEzm9dkRsga6n4IfFYwE2GTMp27BucElMzIp0ybkCrY2Z xJ1OrkfI5lq/RPrcSfuYaieZYVHQ4rCTiTgXq64dqUhfzFKmmJpTNh4M2DzaAR4gd5wkQcqvQfki VN3VwoHboVJEC+eDvBzjAejyDNh2XiPmw8l1Kie7igd9YOYJ/suYWwo80tSZ8jadxZWJzj0zEQ8o t8i9o96mTyuxe0LMu4gxcHsLRBEWSmbr2pghjelbw2ZANp3RB3mMLrxgXBuvhA+jPEVuKeCZ/IEe nWW8x289aPPOSjWgpbjQiRWnkk4N3DAzcOMstrknAk8DvzXmf1iVlUmbDGm1vrmlnVC2LX8YuAZt STYhBVkpfdW4phj4XppY+eYyLRGBWd2T7XFx0n1O7jVjMBE3vl3+jb8d2SMaHMXoyI4N2OlrXvSX e0AYRUorOiemQ8l4ODkRfN1W87Wowm1eA3JyOKF9nJnBd0EZ8uecKc0zH1/Ss7hBrzU3Gc9k18+G 2rCNJeua/fb3mJuNtWQ14m47qu13y43HLEkWETnRi5OLr7gwYDNnSIRJ87UIC8oAWMbtHrEzG/HU pz8+ECT1mJKhR4rCJXWsn/j8EDQUL3Yx5aGq4mlj53KWp9AN7HT+IU0jPlfr1tU2iMdbnAOEHYcJ hiUfJn4AabW9TjJW8Yn43mRd7bkYDExrKkBhFMlpIp0gXH31FBBGeW4i/uKLNkl+j1eQPtayrSbu hGwROHVSdZrwvLsWD8jbijW8rIY2CNQ69YcKiVO8LomR+b06Hi3MOq08kA/eWZShagq9VtzqEIk6 1aP0K7lrxflTMYl/lLjPmBljmgMy+ubEKPKekrkur+EUd4YTEQuNFXNPSc0NeKouXg0jO8ZZjjy5 ySkhVPhoXDPdo5cfVqeeF1qjLrjT5fNvTjJNpzI4y4UvRjMVNhJCspW0YYIyIvZnxXRQ1OuGsga8 LIGr4+thUuMqfyccfNIv4eqQclBw4/QZcwKzxo+dMW3a+Onjxo/jwgTSWs0IqWRK6VlSfIgIM61J FTnlco1ii97yIxFWLOK5XMLJJThZZjTckB2jjFRQCFeTdMlqbUtK3ZdQiRX+iw6oqGCMsHFUFIWm VNlpJnu4tpf1ocnKJgD5yDkrSZFtZFJ5d8J+Z9If6OSzQPHtgBecoFv4R/6Y4Gi3Lhq1oZxDI5RJ gMfGk7bykfB0rQnLqx1IZMvTzKYFwG1k4XHo3K+cNik+hXAOQzwKc4TH2mKGlPMZjp7wIraKB46p pmCxTrIVpHMaRqekXDKODsM5cEJCF8t4Pyjs1glbICXljt/IqU2ClYO+QWVlSwo0KV7058VKClSO l9xrL+ens3vSISMKcR86MzznZYm5C6pizFicFdLfFI+M2tE4n3SZ+ZckIqdYCM18yShKQPI4VDLO k8KG6LAilXCAU1VRV9lA+pF2zK1OCnuLz4bRuOtrmuztSIRnFAJWOWSY6WNihK6SS+RESmc0EqeY CH9mtTAbIWVgLGGgIYcvK7HI1ErwupwvLH8ai9LJSRs2I9ZsiZnrrKSVhWmPYeZS5PJw45hsQM6a +TJKolaxTPhSflpVGcSqKRPBsx5WneuPxloquusl5KWyijqVVSJLMGfCrLEiKVY2eN/5PEpDS1AY GHripTHC58eIH+t+cTuImtNPELrWDcHItUX23YuUUTPQ5JgqYrco1QKIGCHuoMHLDKXmijAMc8gu j+pcZvBWZKZchpyN7ARPmflLMHgqSAkWyTncuiBhprQTJlIHHrzolGRn+fx8rrukO6keqJgA9Bow +pCZE2jVVpABpxOQfFQiRAExTI1gopwaixxInhikmJzLG5jNW+BkKR00eL4OH3ILheeXbCtRLER2 hcW94JhDotVxpTUAryIuootGyYSX7fWyqa4s/JArWmff5TjyhbTSIykbMqR0vhepEyYujcqmYC4N 0YlyVlNOe9RxVbKWJz58KoH6V8U9feg+J8oNSkoVk09eg3e1Ii9iV1iU98Qn1Zx5CoeAzbC+wnAf HZ7Zr+OEFOsnFk+KluZotZelFsgTYmqh6gKa9Ig/N0YkS6Cz48fOUZUPtrJc8VnhwKIA92LmFJYW qXkNcoO7WntpoiMqJa7ap3AWtUJS3BfVCupcps/olMOJG2lLDCd/MAUO8KbGgfuI0czNrK0aMHfc zAGTZ+qxu/FItTDP4klDFWeUYuEeEZxxRUFURbyaj9uLEyUcdEXmKbVXS4kUGV2QzyF7TATsSym7 6i/o4kLUqyjyKkey9p+KyiZztte6Wq4CmVsOmRVeyhXynCneSBkPtohgZFotmhdQkHKO30CTPAnP 4uk+XB2ui1lRrCieHnZ1jonSJSRfKFEf8kXzfX2jTqtkaSZRYBVHquGuyYjA7HEzYazDEoItantx yaElpSWlRUElWbkWdtTI6T57MQwvYc2pQI0vqIk+zJ4zl1tuRqODdChmjCgV80+GUkYhYRwGuaWQ UZum1kG+SDGHHTfEWaqeiIUo4hI8oW1QI6GZn1nvUVrEKagdYe9iwYuym7rVsDT503iN5+lN0zqt XK6iOsafaNHVpKC4QFN5Cl+hAKXOfaOqsmpUXYDviUbRoVp4WrDGaDW5UPRUFQBtXucFv/iUWjJU k2EkKGcqxTPP0qrT5rDt+vJ+Rr1kfrrzLWRhOB7rm+LZIW4wpeUbCg1zAxzA1RG0Yi1NgbDHIvHQ IvIgLCpe8YI6Ok0DT7tImUTheKiaDFbNxVKgOzEqz5PeKLVKZQauLEfxCCuEsiw6cUVvotB+0jKg 1SOkHJ84binCkItQgJkKR+jmOEmzAZAPtdIYxdKRJgPPEmjzZiEEhghQCxalhsWEZVAfT3CimbWq PIDEg6hcINSJCA1nWM0imtIlRiWBYF6V/PRSg9xG8QkXSfww+TTmwi4SAjgupY00CXGxEYEsdKFD I0UyGCJtlgzNaNamKbJWODYPiqVE4M2vF5W3qW07ssrzjeQO9UZIGjMRqbJDsTAfm1xMOiIt135+ enLHjCjgyXMT8Vj6TRRI8tWtkY+dFrchSpHjQJovs/ZTpizSpIRRecHT9WIB6KSIuJ+v9ky6+f1s 7Zhz71+5m5MrpFLQnZQsGcN6pFSNV4zCI5XeNCftGpubVkJFU/wizt1IKYpcoQBlpo2HRvkQsLD9 BYVJm0vHVFwGfXkCwcvxcQrKa7Qi8wIExqIO+ofPHTWej+IhL1BH5snFE1yjZs9Xl0ScQ7T3CI6e YGxpzZNmFprGILUkCM8ruvCKPVuoRK2V0REolZgl0j288kMrCOWXqYo2WQhmxbRBguaLdaVVsS01 LkglS8fSBKnLRQhx6GR4I15AWnECrPRyKvglackLKCpSvKqO6xndDXUfj4vRGpVurxkbFoKGcw14 1N8r6ffwOrbMJa5nLutC54Zvwk4SkVXmV0YwK6ojWgP1dTM7I8rEa+xsVeEBxysc5IU43C6Sxgt5 p9o84oFuEY/wGtRLXdccGsLCaIa8O3JPay3XS2P5DI/hJYOpgjQSp6CMLLaYrFPehiUUF8Km0Ltx SFGJJ3+dZDhS5xMqorRjEQlh8vK4tW2J2ZcGAF8gZEh7VWYioMDdQ8qXwQWL0aohrjL8P2kS8SAI z1l7+exkdSwms2hGEMa3SaGWa6AMY4gcOF1CC6Fh1HUKU1jYeVEbarXEi2pGqahDBK9gXEDvh82o Fh8mRugV2AbcOjdlR0UBvKsqksjEllohDovPMfUAbzahMrZEQR49K/FtPJGePfeWk3bEEQaSFahy dBkgL3iHMA7ZXt/iCZ6NUtKq3DaYW4Qv1Fo13W8xg7rfwtJzbb7bQHYLth7VOcVjWYqKuYUiCtVd Xerpz5pzsQ3u4eJH8Y/K0BAX8ZKwlK5KjDhRRwWrRQdjvinhSUKK1RhbQ4Qi0NGQoJSVpGu9GnnP x6+SYS0rTOEvq9KWoQAaEi/sptmKRHx7DUS4ne6Cx6Bv5J6njiJzcyriCPvOqTCFRUYiAW6HyMvA eTZs4aAK+rkUxcjmNEoJL4lDEqJYRLa8YBRZEBZYMyl9HGnOGXeL0fDFyXlaBEgpsqFC+64RASvn 9W6kMAxN4YWHPM+UVIMS1bKDKZInvNSHR8dEkKhYEj6DENzpUfX1VjjsSNMlZXMvX2xW4VUGi/GV LZUmpTeVuyJ2CemKOMUZFGkU8y/6xQ36eC3nUhG/p8C1MBOMgZqliK7PZ5H1hdQOLRnljgi56Vsy vvUm9TJPVtojZMSeb66KU0epmE7snVI7iSiMiRsicZf3z0rP8EtG0nZMpnJKJG3I8ZQsEnVlptSW pSKCE2Cd8epqiiDKQKba1hOU6Q3ZTkgVkPu7kbS5I+Ya2ivfq/r0iq7nBFVypE7Fub2CKLGzQwY7 ibPoHhnLUh4ZTSDWp3AntRzihSxVtlVTZ0bpZZRLtSKTexS55bUy3IATok64tEQzMe/HVHNFIiQM Vb74jCtd8KIVSyFJDKEziuiRvFNSjOSn51u1VqX5UhsLfALCNa1GI9LtpQ6SVsIJm1FiCjjKmXP9 oT0pDEUxXb6qT9BB4Tk6k38Qha75QCekeTm+NIrwywVT6fCtchOk6y+a9uKuZEryaKy3KQnKNiji hcKwscILoTyEXheVutAe1ZLO5aBVrRMGf4jBNBxB9jY8BWTNvum5CQeAvqIEFw3CokQX6VjXy9zJ DK8ZMIZFgvXDyaoa01kei2t9kZNWrJr2RGUVyBACp2UiJSNi1JAmnw6XBCKU08hSAyhr7imvDRHB p0zQJRVPQVx6KZiMzIG2gSBcqqPVERFpAOd6WaB8XVSvFAr4SQYxhFAl5YKO6cnyjNi4SnXxxAzP aqlh8aCYOWwro3dB06wiW0ILorSdmpZbDGFoJMW8NSkmm9viXoChTARwRJGtmP949hBrWkxR2RiO XHK+NAUvDIY5F+WlYBWcmSOOjqZwm0bGKcWOT63PeP4UPpksgNUVQ6ADJqRODsINqmAld2l5eojL eGpTPIp8MxLgXLCLzFFQ3i2jwcpDMrzbEjNZ6n+kp+w4JayoP9Yl9bXUNWb9Ei4ICoOCUyXsxeFl Yr7cTpFHaFPQgSrLhf8nUma00U4OuURvNaOVyROKpPDB5GEzQ2E6OoJJKsHLSeXiq4CK1+iYOik6 DK7nS4ekqYyMuMQ/Y8cHRT5FbWbgITyD09KiLd6+N9oYxw2lGlvGWG38k0jYMV6x5lvTomPBjMAK l+MqoqGWrPSiOXuTISCYkg9VhTF5mCAjWaNTgBVxMpmpEVEPxjevzjHsBdWOCtB5hdU6MutVcgkT zBGp49Gu7ozBrEpcePqJywK+d1AvVSlcUykRTeFmkHJndBJci1evuFn4aFDYmEJRHyRcZ1dHI7WH TM6j5fK9m3bMnBk1YDmqSltVynLpqF0L6ZRAoNpJvmmeTx81V+fNTHo5FtUnaRM034vlSLWs42Pe Rr1gwC6pLAliZSvhAYN2kfLL+FqLC6eHFBOMLXSG99dK8pXhpPQWipjgP944lDRlKQ21Lfi43BbB OD53Sh3ExJ4GUZXCa7lgN2lKk6Di4y9WXMPli6zBzzDjaKZdYWwTM4guidimLL0V9pYKnJoKnZiW FrdXMyUSDzIo4Tm6wo+UCQhyOYkbyLAU2wZlOZy325TEQFzTS4hckfHwSV3t32ctvvdKKDVVlVdi yV1UnvoVMaigjkDxbJIwhNP0so9rdWhLtsSpQvsFOM1UHSZX/56sF6EelRTGg7jP4As9ijUiGlV7 HQNWZdK2g96xC/kiFGonk+k7Yb1ckFQ+dfWlYdISd4NLBnFHpZrv6KkSJzCIMvekrbxqXd5P65WH EI2lI5OWPIagzY50Jg2RK+fC6Bebp2T4PhVPqIaEkzgnwyRK272scmYUXxdjV9flq00BSarHol0J mAjypoydJLwLrk5GioinkIrKQYwpvhXeKmm7ajchAmRc3SgXSZK42EspUVY9n+dXeZGoDupRa2O9 iKXQdbPHzVQX0+UUmSyw9rdDmDKRei5OphIF/iyudHnszPxuMNvNQSOsaRYSeQU+ojDdaEUkh0yN xbWGZDSVIuC3cUtlst6E41aXL7SFMSj3R4qNIDzkG6L4haoApwSXjKXl+6OfvPBM2+JZkq71nNTi ymBK5mbjuJEgFnYzD1Spk0q8egB9Aooq6TTGq/qto8WiyBXT57gi2aXbEVNLz3DJgxJhNocsEcp8 uyLZbfPVFFJhGOXB8YIVbfCIVKbunyrRSdoiHQf6jggE5upYmq6gtFzTJTQT9KVCczohW9/JA/gy RkQBovpvHiRupiCRvluVFnlBZ9XLepspE81MjmmLO+grS5sxc87kGdNHH2Qm5qXdI7NCpqebbcF4 VLJcqZnlnk9ya9WZGrp5yX6uii7xGr2+blqGgXjYrES2wtoQ4vE5fn6Bt+E3xpMzRt2oPCNGVYkn 1OYE4U4JDwmCsVZmrCnKJT0ts2DMS8ZoHV9hPlrNlC6B5aFl/U5Y2lzR13qbxS35TF7Ip/rDD2fh ypRH2mhO3Kwbi52YV1Cst+l5XeL+j1BKFpf5qjZQRKaNB2XGv115FFDY/0TVouyK8o1VrotHUgbE k2LvKzUvirJ5QYo3F+nzKu0KTSKppYSSqLHrPJlAYtcTWXIJFxBv7Y8uUX8L9EYcK2WrCB0MbviW VIXmGMF9sgglzwmlJApSszKb2qfq5zXf08nHK1DPVRENM1GS/jyPnnOofeGvyhL0jKk3zwnR5pDJ fum6ujoht0z5S11pBdCJSkmpldQA6IFZR+BZOqrzOg0Yy8Ih6d3gseT0jhh5KNUZWbWvJyBtcvjk Z+FxV+XVDq2SZ4mJ4RQYQoaybdKZ8iWxvJGRhS/bIWFQoHjJE0SOLC6mthI6YK2dOZ5FEpE8b8+U Mtt1Jipte4Eo2Ta0HMkGyfl6jl1beGje/mRuDiZlvTtVv0g1n3Xw3pEhBZpF0dkCTW4eauRP8B8S Q4mbVJ3OV2ly0dOJBF4LZHjR4g+lMuW7OJ3BSfkK/+3FFCTVsXNpUEu325OvJRknMBXALQ7Ho+hz wUDR8YLSArn9DJ8I783Y3uEIR52zk4iFekyP7po84oXArPSKEs9k0JvxQD7KjEuhpIgknRzz/DC8 RDWKYLxyG7o+zG0XOLHCFJ08k+LzPGgCaz2pKsO8lKIRGNJlr4pNjDA93IhkdSIlhuxIr0if7CA7 5fdFxXRG6qSFqD0A7hQ5xiEtvu0Kgpt5CYHShBlH0o0eM13WRA8qGzw/QAcd4FoddWnYdJDHwKUZ EJzFYsXeZYH9s7QzAkb7TG66FXP7cDYJimSUv9ErU33JX/uLD7j9F+hXWBAsMD4oMu8Rl4h7Cnif BwQKYNDxn2SK0S/8Snux72F4G1APS8UX6Y3UumfqS/6B7sl+Bbr7vs4YV4nbeH5+AK1A/Mu/9TrA v/Ne+2sRUegJhAGGxBtgrOwiPe+pgL8NfMKbGMhvKC3wdc0cLv8gRtHSAiGWZM+NHnqX1DdF+g71 JR7KN/DAUEsZ+wh9n1FL4w6eO2PO+EC/Y8JUHSjfqovFZ96g+iweNLB4UCnaxm9lxcPG89/2HVg8 YUJ+IPtrPx6V3Le4nO8ICTkOJXntRCowsuAAxbT78ZreJAW3tSABS3tN8BGNEJqdNiQNHjJ0qPH1 bOFeyKHoq2hhecWOs8d5QUYdI/FVSBLVI2JbwKChtE1BbS3kCsvYsqvMLH63cEadGMQMt18aXLj5 5kZ8tYclZBaMe+3iA16JpjYkG1WZYqsvHUwjDvaRdeUZfqAuVIuLI0t48N/vWBoOoY6YR72jCsLC h/R7iNxv5NULntzXh3yKPW/aYRKmgBUxHSYdUVYd5vMvmZRPuAqJufL4sXQ31uyypqMia1xsPDZr AMkyyuy0jruI8hVLnG8hVZiuvTGKO9V8Y4btaCJllvT7PXIRZ9b17rHGnUHjzCJeSCy2qXm6H/rH Calik0y/Wz7ex1J6c62YX2O0MoEZkyd6iEqp9CbN4l7aCFPhD0BTPE9VMMgjknKcFx0JlBOU0/w4 4gyHtKFkqMSkHY3XeM6QXNkpEcCfnhk4csSJld4eSR3dsFLGqa8+RpVOoRvXA8jC5FT2KLaUiNAl mSLUkLAEZe/THCOfPa6y5HIkWWYn31chKGktVoKKQuuVJZeVPCWBT7fv2fKIH70WYnG1mU1vNpGs YBxZJqdDT6qajkbtF+6RzFDbDYKKt0Tf8fS0edHko4nneUIVaXbUJoiYDARrMqoiHm2NiwmQojdT 4pRk0sXz97aDMDL2VbD9lPGIYngeOx5VvFn5d8iSPnx1doKkVkNk0XbYf2S5FKStEF0qpYf8O8er Yqh+BjUOlfIzrrkqxPBlTaFH8iwXp3NSGrV8XVcd2v5FZHSdJznID/cmVvIjJbj8I0jrk9kdwUZy V4vqj+vbl5Q2GyKpy/3Zcn3apFVuVJ1liXqYxoP0u6SC0W6atOMzbmrMPwvIQzf8SXrfE/1cx4sX XBFk912X74VKeFDfs1+0swin2aqBk5v0a3xNGl0Z6qQ/QRJnO9qvn29TunrYS4O40nDhwiQeqIrH RJP+ijTjkWIDR0l2u50bqOYuJ3EKtn+fOL9I7+rO9w74kdEEbmXLT0bHYvFqPJYfLDBT7fIrnD16 pjhqedDwYYPnF3HjNu20ftWmiIrIumzPxJVJJxXT8QpHG+abaaMP52egh71TV7I9SaaTjESUToDx yBSnQ5oFZhYm6d4YTxZejDTIlP3ppaM8+xB3zzR2hFEzWtfQrh1Z2+vNutjszSv0eV1Lxr5Yntbi 3ELbtc2UsBHFDPqOgDC6ZqgcfRoURR719q/Ms7wKY1qMeLsZ8zP2bagZJIOV9g3Ws4uResO7H6mT qss8vrqhXdu+TUpF6jgIGWn1RI7kCp1gkranbyXwbHDQ5ApREiOO2TT34Mm9/vogGopfUomK4YFS ejiuTGHfupo9e5p3rK3/5B3XOEtflsN5uzB5gRUtZc6alhATYqVyI1sF37hiEvWdPNuhE2NalXn7 RVRFmT8FaxSwxcyCM10UJNeDV+bjisohY2oM8Z/LcvUf3a98MFH7L1K2MiJP+871hm0hMjM8EhJl vj9UoI+HABsHA7PHzpnJ/bFxY8cajfGP+Ok98VixeXuJSuIPEjl8If3lQ0SpLcaYTIUSxRXlael8 3DvauAmqMFZgBiiz32UcEeHftSSyUlm2xVfRBnR7u8qKR+Tnz+FEFMeQyEMIJQfz0Kr8PYduigIx mYYLB8SuFn4kji5eVMEo2VSxWwdvfbEIr8rPRhTobxM8qKre0ckPY2cdNCE/rY2EGVkr6FfAQ1lg 7jDV5I8QmUZbHyAvuuLWF2YLBAYEKqIpEXDzZ7cpH5iwQ+mPp255j8ekev3Hm2IufRp6WkHMd08s t5tSyWSxE0vxsG1pv3GTJ06e09D1qnUn7E0bf0baYPC9N5jSfoVWJFFlFfPKOydEzy3mUdgFBUUZ VKDm1J3oVAHmvSAwD7+V16VsGSid31AfcamIuG7PTfsFKFBSR1yMRcIZlp+snZKFPEZk//8g2bik +H105Xu4fScviGJnNwfBY3C9J4NoHZEb+e8HgeuNAM+eNGPuQeMCLXxBYN1Hr3/yjyB5svQPCQWn xYF9p/bkIElLuJ4Tjl2WEcppkUP8HxihfMD/5BDVwWc59tnYDuBVAmtGKSEHnR6iLzMO47DU3xzh ew4iFvVW1tAFZWVIzjPnqphwejgz2MgWFnWctHSZ3BQsJywAcp1HkMkhHFI32xazzMZ43j5QyY+s EnXKdXTWu8yg6nOjLLG2RL2e4SoFpSYlyz5kGx5Y1lkwA83675elO/aiglKfh2p0isy2/NydRtln aZcbR5dsN3+J1dHCdMgcX4lWeZ203uVG+tx4oESXa5bx04X81hvMv8Nm6ZYWJ9OlYQ62W+ZNXPAN LS3dfttNdGeW2AnCD0rRtUuqRtpnUG2n/dZAV3Oy3/I9Lbo4KVPkwn4roEy1fEIBrLh5+F7cGOhX CH2n3xbNN+0476r9A4lFqWLa31GcjNj5GcqOvg1XJ+r/MhlKpIr5iV+Z3ydDNUm4HanMb6gIqVhO bea3NXEnUSxqybK0KnrOM8yNGyD/BeMlH67eW43JyNdFFIpn95fGTA6GSXXMiWDx00HCslS2UR5O s1jEyhMWS+B/1GRRsceser9enc+FiIofkmMS843NzNZJte89kYfoctHwKhSQTaS4DcmUf0v8/1GD /Y8MU2qFwW3oITPFeYYiVDK63j+NVVZSFswSWPApOx5lyEHfSbUvtjXmZz+2XKfc04OTsigyJA9a UX9aI+3vZYpjSgUv68Mt7MB4JaCMkWt9yJNvY/iBBrrHhWpsRf6jK+VxbbIFsXUpho9kHSnd0dc1 FzzfwBvUxpX39z4zKa5qZ2W8N0drj0f1dLN8r0Y+kY0OBpxlm8eq6cHVwKTmG/70ZuWZXmxR7q2X R5yrIwzS/pYOn3b5dz0teVQZ7ZYxbiBBL8dNB6CGq81j3NX2ZnX2sLcxKv20q2wbpQvTN2XQPqyk 5Yi/U0utGH6c/HOH/A8hFokVJE5sIgXm+9sPnM/0KaNyA20ju77VduVsVr3c55a2GYSHWWCfR8RK G2ta+4PUEWf5vlrtWFzvVQqJY9tEYiUpT/wo1tu4+d8wEvvnk/GEqPbT5y/qEk3df2N3q9iaN3vS 6IMOUmdccuqk5PYIehvLuj/Nd4xiRhg1216zXDebS+Eq/Rl9yh/6PHsWDXXWLN8BG5mnzjqxLCey +riMF/HJ5+iQLF+HituCgmf0uQDqWFaxL4vvtdat6aM2YnIbonEf/T1PJY7Mvfzy5ICgvDYsLuSj 5GWeQwYOne+LGNMfPzLOSVE5CNpcIXY0qD2HejpE7iC9dSWSPI6V6VMze+TaqWL+x0g1/8ox87xM xh9NHg8JIk6h5UcXiw3S2TZTyz1R5ba5IzcoSUwsrQ4q9ckmf7YpppVg5qZyWeeaVakNKRlkHi4m JIjsouQnHcj3jnnO/NOr6gDzoJCZvN7eVYcPxer8uUrXoaYsfghzRBxe6zvDQOfOlBji5xrxqpv8 9D8LlM7uWU6M4NkOfq6RMM2itO9cloH5z/8yeDboHYQjj5TxD5SHIlQhEIxHq873N2nBizWgAP8b bDbt8JR/cjQWT/FaMfARH2hFdSSiN5x7AkMtLPm3puVOYqHK+S3cy5DHOPi3XrhOqto77ZHvheb1 hJwR5V/ervIJefVHLvl1Pokgxa6VpPO2hRmo/6BJnTopWxuDao97xq5rYarEjbPjeUSkgh9WKE4I UDHl0capFtUpOhRLnvAgh8SPKS+3xQYQMvzF4MiyM8610v2HbJC17v7jNAxZZJxK6NX40pG0VC/P LRPxN4ipaoifnp7y8uD6NMDJYp97ljPKje0o6lhpfYi6Pj6h0RO5vT+0q07I10qW7x8Og6G4khG7 yetXsSKgRo1ILSt4yusSpCsnHu+FkZ31DpORFgw1Xsj3OZPD5lt3Rd7WcFLH5lHqVCmodZ+hrr1D 8WVmVZ3DVYVxqNOw5bYWcXypUJyO3pyqt6lzmmVOO0+kqr9MoVLserPz5JiSAG6aYkfzpHGM4ixX nkgreCDt6AuRi6Yu+E4Pk0+WZ1LrP3QiqxDSNoLKP+8QKOT1/0Vq3igUZR7a78r6SL3rJNtu0PwW s21bFE7mtxgtjRqxsUO5IHLbWJ006JVDPWGM0sf8z9Tq3WU+LeSPKousuqlqlKnsM+KN9GhgNDpQ a+sj9ajg2ElxbScDAMJm0z4+JfI41Q6Ed5/Pml7/B1+tGcsDzu3A2EVA1W6MHQMs78vYBcDFwNj+ jB0JHA1cD9wA3AT0KmVsD2DlSMauA74fxdgvwG/ANqD5aMYGAgcC377/8vvr31//8vurrlr1/lK8 efn9mqU17y+YmrVTffNan9x8Uh5rUXX4sq/36Vp1Qs9xbMaUndjBwFFAdFKb1i5Q7LuuS9WZw65k 9V/ttXpYg616172+/OsJXaueKzs163U96//KGMHcBp8VUJ3+y85vpV3QsrkLMFxxaah51ivksxpo Q17RvUvVi7NLs1zRQ9G/GdAV6AYcBdwAbAUGt2HsOOB24A7gW2B4W8ZOAZ4GdtmZsUOBq4GPgHbt GMsHZgOXAe8CPwP/BEZDRJwCPAv80yR305v/3Bt6NW/PKsPEEGx3okXnXRg7ArgW+Bgoac9YCngQ 2AkyYWoHIR9eADp2BL2Ba4CPgL07MdYbiAJrgB+BkbsydjLwNNChM2OHAFcB7wP7dGEs1qWJFDsK /YkWdxM9gLFdGQsBYeBW4Btgv26MnQo8CTwFdOjO2FzgCmALUNiDsQRwL/ALMLYnY2cDLwFdejE2 BZgKLAc2AoHdhI5pIsWOQX+ixWrge2DE7oydBDwCtNqDsTJgMHA8cBdwN/A9MHJPxk4Dngc6Bhg7 HLgS+Ago2YuxWuAy4HLgPaCwADYFcD/wL2DM3k2k2FHoT7Q4G3gN6NwbegBYCXwE9OjDWE/AAm4B vgKG7cPYvsCJwFPALrAP5/T17MXXgNeB3QoZs4FVwPfAyCLIEeA5YNd+TaTYUehPtDgcOA84H3gV 6A7bfj5wI/AI0CrI2EzgUuAy4H2gsBhyHHCAhcBFwMXAW0DnEsh+YC5wCHAZcDnwLPAc0GZAEyl2 FPoTLfoB/YEocAvwMPAI0HIgY9OAC4GNA4W/ZwE3AZ8BZYMYOxZ4HHgCaFvG2MHARcDFwNvA3oMZ WwSsAX4Bxg5hbOmQJlLsKPQnWrwKdByKtQpcDTwKPAa0HQb6AxcAbwKBfRmrBG4HvgC6DIfPCMwH rgE+BPqNYMwF1gI/AyP3Y2wJ8AzwN6DTSMibkU2k2FHoT7Sg+M0/gLL9YbsBa4HmBzB2EHA+8CZQ cCBoD9wOfAf0H8VYEIgD9wL/AkaNZuxI4DrgH0CLMbD9gQuBjUBgLGyCsf/l8/t9bm/+k+Q2qU5x KIP+u1FsbgxwOHAmcBHwF+AGYC3wCfApsJXieJNxLbD+IKx/4Bvge+AnYPdpuGbDk3ddtfWqu57c +uSyJ4+zD7b3byjw6EXIfjqHImSXD/+5kWjcj/y6U5u3aiQWSNd1qfq0T4TVf3VAXdBQVK2RuJvX s3k5xhOP+L2xwIwnHp7jE99oMILJOtF6vBX4DigGa5QAKeAhoNl4xsYD5wAvAV0mYH0D1wOPAY8D bSbCNgRWAJuB3pMY6wPEgDuBHycJvjkFeBbInwIbYUqTKN5R5D/R4iLgTWDPqYyFgJuBb4D9sK6X AA8Djxwk1v2jwOdy/e+BNb8nYAOrgC+BYdMZOwFYD7ScAX4A+gBHAQuAy2f89wn2r3ZkcnNakxQU v5GUNeU/yW1Fx8+OYGzgPNjoRzM2AXg4hDUcYewu4G7gPuBBYB3wN+AV4FXglwiX/fc8ed2Tlyyp WTB1wdRhC4Y1IvMbluW56obtk/ndlURPvyCjX/UJ4O716QTSFrvv+Uoj+qQ+jdO1uQuwxnVSej9v bHtTI/N3Lpf/9c0I60jr8QrgfWAL0G8mY4cChwFXAe8AgYPh5wN3AT8Dw2cxdjLwV2Dn2YzNBq4A 3gX6zoEfCdwD/AqMn8vY2cCrwG6HQD4A+x7SJIp3FPlPtBgOnAT8FWh5KGPTgXOB14BOhzE2GhgD nAWsAC4FNgO7Hg4fAXCAa4DngY6QIfsBceAc4AHgI6AH5Mo0YDqwaF4TKXYU+hMtlgKrgTuBH4AD j4QvALwM9JgP3Q3cCHwJDDuKsROBJ4FdFkBWAFcAHwDF0BmjgTFHCx1yDvAk0MZibCJwFvAS8JbV RIodhf5Ei03AXuWMzQOuBt4GAtD9lcAxQBJYC+wUxq3AZGAKcD6wHHgL2ATsaeM+oAKoBG4GbgE+ Bj4BPgWCFeCTiiZS7Cj0J1okARd4EFgL5FXC9wMmApOASqAKcIDVwJ3A98APwMgqxvYHTgNOB/4G PAt0dKA7gDnAXGA5cAHwFrDJaSLFjkJ/osVeCxkrACqASuAW4FbgC+BLoHgRYyVADIgDCeAY4B7g XuAj4GPgE2AgfIFSoBZYbPgOXwBfRppI8Me7ol+xBl8N+3+9yHfLi8JmA0YCY4CJwExgHnAG8BO9 T0BOAG2OgY8ALACuAG4E7gPuBx44hvzAx1fhv4s2LN6w+KjFG6ZsGDoli/f3S47e3y8Nen9lWbzJ sVM682tn8jiTuN7CZ+qe4WkeI92T252er/nzOV6tYeOe6c+GZ9p4jPPnPyQW6l33zwbbY7vSmjwL 9F0q6bxfDHwAnAQ8CKwFvgD2jsPPA84AzgQeBR4DfgSC4IsZCY9HrgfeAtqCH34wefHzet8881/2 5vcMTr56M5b/5CDW4cKdClutaztzlw86Lu7Srsc1uw0OPL33kX2/6ndqSfdBq4aMGp5+X6fwVyyP db6OqfXeuj1rf+oteUcB2T7hkqAb0ai/XM9HG+v4F/qZAg8AV1XDLgRWArEa6AAgAdwKTK6FLQhs Mrvie/NKbm98U7G+3jf3mW9ur7eB+r+5ud4315hvLskuTX0zWFa2Mu2TE/rfYkpc33f/WvCN/GT2 TkcBleGicLe0ayiek4VKGZT8w3ikI9G6c5KxnkAvYDdgH2AQMBI4CJgGLAcuAFYC1wMvA68ArwKf vPbJI5/cesmtSz6Jz4uPmzcwe8SvDc9Y0Cw0LC9bG5Xc9V3ttdqiwVb7+lrN5bpWOV6Xn+N1LRu8 rhDX7bSQq2l+dTG/mvhq4JRdcUdz3NGczW2dZ8yjd03D89iCzyPxTwPyvwPR7zXg78DbwFfAD8CP wK9Aaxf8AewBFAJFwADgYOBQoBo4E1gDPAisBdYBDwFPA68AeZAhzYCdgLbA1tfkf+tXreA/T966 fuv66Pro1sOjrNGXNxPtcqTBzjlyXtvt4rzlPLLaeAS27bLcIrX529VLQdfGe9m2wVbZbkSPTsBw YAQwBhgLHAZcCPwFuBG4P+Xpg6+A1tAF7YB8YFo12X2w/O54/PIzttYtOnTsoQMOTaPVWj5bJPEa 7u/6HK97gF+XOLSuvp0Z9X3FejYwHdtP3V34/N4/o/APkhe7/CE87V3Xt8H+sY5Eu9nAHOB44ATg ympP518j9f4nQOcabt8TlRNHTiplub08zm22rHG72et53rLcLOEWy3LLEOUiD3OV2+nrqz5m236+ Xrtd1zX+3AcbvI7tTDTtBewGzARmAUfW+O28FFALHAucCZwLnAfcIm3ALcQXb2x97PbHLjsdFsDE 0+OnTyyrR2YPbFB7edcNyPG6khy1YS75we33rn7M0VvLdfU3b5CX062FIr2267cWmjXYIutItPsY +An4DdgJtnw7oBswEVgMHAv8GVgO3AfcD5y5GDYg8C3wHbC4jrHrgOvrSEasx383QyNctOHk2oUX LZxPlWSZr166l4M1FVXP9vJ914V/57+iR9oVIjFLV3jflKV9s6vvG/HZ9vNcWY48N3GZx3PkGTR8 9UDj6sb7kOs6GtTgdazzFEnPB4CdQMfmQAFwILAAqAMuAe5Jo3cn0HkAMANwgDMk7R8D3gE2Az8B PwOLjk2LA3z9v/5mB+vOZ+abj8037zSkWn1+Yaxgmi/a152pz+i3TF+Vf9KDaPaopNvbknY/GrTr BdoNBuYDFuAAC4EI8BTw9bsvPnr3u1efXXt26OwZZ++7HdbAUEMfUz8b5uNxot6tnlXkXTeMX9d4 e2NybG9oju01LDs8STdEt1ffd9snBbNfkb39wRnPZu0XSVreDlz5J9h9wDXAqccxdhpwOnAZcDlw BfAO0Ol4xnYF5gKHAFcCVwFbgA+A4hPAI8AiIHJC2mKrPyBY/2UfmG821/vmrXq/ed1881Jub17/ Q9/8nud48XsqCDKi9vw3vn7riTXxKt/MyFSmvOhOa3grrWPgX0AH0L470BPYB+gPDAdGAPsBI4FD gXJgIXACcCJwEnC55J+rgY1/4nbAqg0rNpy6/lS49xu2wr0fA7ugIZkwNQeN2dd3dS6adcp2tTop R8kwNsfrJubYy+2Th7nKpSkNPp11JTq9A3xKdMfaDgB7AQXA3sABwEzgYMAGKoFTgCXH+WXEUmCZ lBM6vvPQDctv2HrCwtkLD1zYWCznf9eOz3U2Z+d4GsVsk+NyvJquy+XqWQafNF7/PavBHrPORK+X gdeBt4F3ga+B74HmkOUtgK5AR8jxTkBvoAjoB3y7+ek1T994Xt2N39oH72+z7Xx5fSxf1lDNpXed leN1Rzd4XbHvusZKLtOvbrhAv3sXXmqfpT4014r87M9rnM5HN0jneutWdyE6BoEBwEDgCKAKcNJ0 eBS4+UTG7jyRx/vXr4LJN+/Aq/s3RtuqBmkxjLU+2exaN/67eWUIrYSrqE3170uYP/M+khm53per vEm/7t+h9x/N3bnyj2XIiXoLitsp2saAi4CLgUuAt4F3gD6g9z7AIiAC3AP8CxhwEvgFqAFqgQeB tQA7mbE8YAIwETgbOAd4BXgV6HrKjl2+X/+b/5XtW39Q/T+tjqyW5G60nu8C1gD3Ab8AvwFtQMt9 gL7AptPBDwA7g7G2wC5AR6AvMOAMkgfr8d+qFWfHz47PmzivrCF50CfHePnGBrncu+55fl366vfL F2+Jdst4cqacoB7msq5faPDJ3nWP5xjR3ZDjiKty1G5VfP3TdQ2s/w60HrsBRwELgOuBG4D3gS3A B0DREuh7IAEcA9wBrAbuBL4FvgP2OxW+AbA/cBpwOvAC8CLQ5TSse+AIYB5w5WlNZVw7Sv0f0eIq YAvwAdAZ67wL0BU4ApgHXAFcCbwAvAi8BLTHuj8AWAKsBD4EPgKKzmSsFBgK1AC1wEPAE2f+V9TX ba33ze95zke5XfZevW+yRQh4VUma1CepIn4j+WfQvyfJ74FAKTAOiABR4BTgNOB0YCmwDDgXuBMo BC37A0Hgs5fW3HjBiYtOnHPijfveuOjGRq3+3yORCyDJPLn2BOSkstobl6q56pEncpTSezeov+rX G79n3L3xrMz70seSeR+NuY9P46oW0p/J2gfleh0C3A7cCawB7gEeBNYBjwDrgehZsBOBOFAHHAuc Cmx58bEblp/42KJDFz02beyBQ/p1VmFIepxXaihSV17Cam7rvJbCBPe+U6Uv+K5TV35mYT3a980c 6dq7QXr18V1X3yx5rTk5eDPbT+NcrI2/NsifmU9OvzLzydQi60By+a/AzqBjO+AgYBqwCIic5dGc 6D15KWNTgKlLf9+ZB//2m2/NN1/Um0D5njW9WB5phs4qTpzXOSN+zDVGPq3f+4C3gM3Ad8D3QB5o nA9MWuqn+/ef47/N33/+2ktPNs3xH/zKJvEgIWlfMcsuU3s2kNrdxZ8o8lowP915ECs9rypvRIIe vOfqU0oCq58cvdfqoS0KVg9rsfd5Z7XofV6seZ/V8BFWP9GsO9DuvCeaNVGq6dX0ano1vZpeTa+m V9Or6dX0ano1vZpeTa+mV9Pr/84r1rwn68Ty2M557Vkr1py1AJoBrfHdCuCqRjC0ZeOoadY46rv3 gGa5PeOPwk3GmLrmML772fY/oyqPsUl5/9lx7ahYvZP4OQjojrlcj/cvAe8CXwFgRdYBCAADgVHA TOBoIAGcBJzXvP77qN1C8NBGzPcneb+/nf/f79sXc3cY8BPQGvPZHTgEOKEZP7GC7z6bOaUF34F2 1JRmbMGkvObRSa2axyY1b+3iZwo/Sd7MQtNfb2uGn+06MOaG6MPWbDZLMYvFWBj/JvEvY+0YnVbQ OY9OK3ia7cbGTunK27TwM1u7/tcUNvrob7atxM928s8SdmA92GhWzlw8IcWOZcUZz3RZiFXhN4dV 8G+S+Jdeh+GTb7fdjZ/tdhdtDWzZnk1ncVwRxXURZrMAm4PfyvFbhL9n6HG3HzC9g99oyfLa7hQR v7TAJxZ93IztTO2wRYHvtj2Knyxftbwzm4r7HfSLWj0Iv7noB7XYjM8JYxPYEaPy2Df42Q5TSHH7 gS1boz/V6A/1w2aLec/bsfbGeQ8dMINdQKWWoFBLZuH3Mey39teyvLwx/ErRTn5GOwF2BJ+XGMvW xhHsUrTfKe8IzHMnRjn5gS07YGYTaMPm95VjPiyMwUYLKaNvHY2+dUa7HdBuK7TbCtzTCm13YIfw /u2Vdwhrl9dRtt2l0bbN/mZvdxTrO+paVpo3ivOG6vNU0DOK/0RbRP1jOR2oLZu31pq3Ri0cwPYA BcbkHYAWusgW8rO04I23GfrSmp8wRCcKjeQjOzhvJEbWWd7fqYH7zTFBI7KFbHSeeHo3efcuWe+m nhOH0vO7spZsSOuTj2x98jg8fVbeMXnj8PSu8v5dG7zffD61kndk67wVzMYcnIKf7dr0YFRhT2OY BL6ZBq4NgHq0Pir0KklhLm25pkZD0v+bx5eghfrOaxJ8cz7nm+6yZ91y6pmf19Pbnjl1p+adMX4S N3uxU5au25Vy4LtB/u2Kn/PGxmP0V6AXzKlL2O78ksXRyKrzn134+MAO43887bclL927Mflg4fUb X7h2cu3xwVfad//gzuKF5546uM0zm2s/u3/mg62LU3t3KH/h0j/Nvf3cLdfs0v2Cb+d8OveoqtPC x2+56dbvfvmiaO2GfqUzd1rSd9V3bS44asOGQz/8ovPAoktvmPPpVcNHdr8gcu7e1/29Ve865/jd Tv6w5367rj9h1Bkf3Vv4xTnfPzHpiq+feKn65347j9twzbFLnh4wcOlTq6/56pef2/U+acXOh936 VJl1xLWvdHjs3eDqcQNbLTzhk7LN975QvuXzEzo7ByzptvH55mWPHHn09wf+Y8DHLedtbL/q3omf vn/kiU/s9WvxplmLSi5wf3tt7Xkl3UsuuW+N9dEjtx0I5bBtW/pUXf/GjR+vJzMJ35LYW5C0I+6A Evr31HNfxBS1O+PL0x5a8vLxB7/yePc+NQOuP2/sgL8cz94rPLGqoNemXls3zXiqZdu1rU+97ssf b97/t9vP/vm9Cz8OdL3slpaPvz/2wGer3qvZ/5ETT3nmtOtu7NN63uLE6X/506Z7Fqyb+fJfRj5f 2uv6SfcOvKhT+zPfnLFu1u1jwi8/0+GVKeM3DS7vfeKN5x+zYMOeK67q8e7Qg179vuusDcOOvv3c m57ZdvfjA5+7asajJ94R/HB889iwCw9yPihfedOALbMfOu8m+5bX9njpnvt/fuPXrANdVHdx1yX4 bSmX/4ylquyoPcD4d5oVsyrtJDFHu+emtX080GHUe8evrD3vzWGhtYXjy+969va1P7CxV/Qc/dQ1 r1y9acOHW5YMe2Fz59cvn5p/ePCKVvlL7edLzrzvq+OCN/a66a1Ju/01GHnvqS4ffbq4+zNrlu26 efLT7sHH7/36eafdds/bgTfu6f/6Xl8G3z7qgd4L9z974qGfvPpj0fvjt/bfp22zfbN3fssRk/te AmNpbi9h+GZ0vpS6/dnh0+K9xnd/eO+v95zwp3iob03PidW3bLyzV9WsazcW/+OYdfu9c2VFTeWQ sun/6LXw3EmTzjxl35ln9WrVfM7CPiUfbmi+9JpJv+68ruzute+ctaG3s/cRo4+ftO7uF9dtXlD2 8LGfH/XcS3t1XP7NdZ+/PmDDyHGdrm41uM2md26ztr1y2RnXPTb5pB4zJm26vNOn8zct3vbQrYvn j++9T+sf+iZ3v++hSTenjncm/3P1OR/aVy1v/s6yB86885SJHUtaNNsz7+0VxcUbFt46tfSGs87o tNtOb+4evOnCn17pev7gg9Ytu+K4c/POHTf5oXfLSl964qy1T520ZMmDpz9982eDTt6ldNGf1vd7 d+LY5Iy6M62b3x2/6dZLz71vzTHVbe6ovHzFEavvW3NH/IA3H46MTayOLF6amDPwth973dZ/Xovj dzp64R4btn7/4EPHjn6Rrf5yyS2HXDzo+Qkn3vbOM87Fo37YOvLz2G2HL7r/p06/XjT80nlXTr/x zb+F7xyX//QJ0efeQy+XPW+3io/quvmKx4eNuPztL25ZMixw9oIrH//xjjWH9Cp556SCCRcsGb6m puqRqw8eEAi9cG//9xaxBbfaX/Voe+3K1gOeL39u13sGbiw/7pKzDwgMXm6N3/W6G4p6hPYseODs Ledfc5i7fmvzS97Z2GfBC8VOxaR/nnLDLZ8fv6L86aU9HrrkxRMW//xZmxEPb/vup99efKr9Hrtt 3vZMp2RNdEvv4JfHfv32xyfu/8/mv/78waZu7R9Z9eSzg367b88Df/3+kgG3nHzegWXHXHXi9z/9 eOO5V5/465t7bj5w1UnxtiP7PX7G4H06vd17YtXVT12z4s6l/Yf3OOvbz7tPWHFxbWSflU+0eePI fp/8OOeDa+LTS59dt+Xpl/e6vUV855v2nLt+6wVr/7x+yaSDOt/27nF7L9393ZKPVz0+/vousaqj +pS17zv5sOePPOhv9x9/TvtbF9ce8/5P9w2bvDL5kfVp4TvLztz7oz0eP+uxvSafOeafux8YuG7M 2v0uHFHz9vUPv7v83C4Pjj241atTLmj36dNn3fDmDdGeSxbcMHfEkkd23/TZOxN2f+GWNe8UnFHS 6a5md7d974xTh1es+3Pftk/N7X3GvhX2ki+P7jK3zfAVbR85Z+vkFlft0mbLTd06VEW7zDqu96jN y1+NH114+EWxzfarG8e3Hd/+lqovjn7h2aeLT3hpWeKKQ6xWg8/628b2H+SdWjjhT0fOfbT2gcv3 +mePf510wWlfPDztrC1fvHrro8U9RxQ832zcI5e2jo6/6fXpLf7sfDPjwxUH3/TUG//sduifV7ID tn108GkzNr8xZl2b/W/ut+u9My7cPP7+C8bf9+z4UZt/u2ztaX2f2ePkgVfHR3455Yu1y7f++vHU L6497oBFK698/ZDCtcfGVs++89Lzt/x1729WDBo6c/aEmusuXd5n8NJr2p997F+GFyx//7kLJ3w1 pP9nu5R03vjZ6FNuPffmpS07Trceu/1Pl00qLHtl5biiSxJryp69aM2QPW5I2e1Pn3Z8eHWL0eX3 PLvT2nXXXvLtBaNHP7nm8peuONCd0P+y9YdfetuRz5x5ylt3PLbq9tNGlN33YMfnXxtxxryVg/Y9 5qghhwVXtdm19SkPtFi1ru0Zqed7Tt9nxfmjNr09dPPfi5/cudunBT3eOyl8wCvHvvjLTbErLnxq 6QPtTtp481fnH/DRleX3dLrv4n1+6fn3F96/btDaJ5vVPPDjUU9NrWv+4rrrdv1x3Ii7rrviiuDo idE7Xj8yduzTTzmbej2+suvDTxYtnv+Ple3v7hA747g+kY1XX/bcPs9WvhP5cOkDk2eecXbbRT8O P+3KEee1vfne1edEqlYcenjr1ePcu74ZMOzRVd2uP2nZd4eeV27nn/Lessl5Nan5U58MvX/rXXdP 7f9WzQ+l/a8/7tozu497tGPPO8/a+NS7J+x+yzUzRvX5+7QVS6/Z8919ps3btC55tntx6sNf+i+5 e+uK6zu+8Lfbpr888oLiv39wzF5L6vqd9f/auxO4qMq9gePPzDAKiIiIopiIo7mLLO6G4oaYiqho N8sFAQVZRgFXUsEll1xzTwvTUrNcbnpLKU0tfTXrqpmVmmVl+WYuaJaaC/f3P+eMIGHXuvd+Pu99 m6fPtxnPMOeZOcszz/+c5/xP6bw+76ctbP1O/drfNo5clF654FDMkdsuG937mi+Yql9Mt0a0GnjS 37f+19FTP5r+y3jTgsmvVPNqNLxqmU011p2OOH7L90x0wZsthyYt3fp0hdwTa2t4+/wyf6ZLjazo xd2uPt/+tRd+Cuz6bMKUbh0XvbfolYpZHT3dqp7z27Y+661pNteRvbu/HjJoeJ1vDo3/e0iiz7ka a1fYo8rWG7fpw5yJWVf+esDj0e0jP/Nosv12mfIN8tafsr9xdsebr02fEFx1i9/YvmpLrwaJCUkF M20rthw7MbPp2svpob6eb7fYFNywkqWnu2+byIKcO52nHpruFncqetpT1Yc1mJTr1yTYter0c11H 5YfnhZ/YW94jatSRUgtqJ3RfPjvqxLCxW3ae7vLm6aw9n/V7fcv1myv2BT4duuT5Bc/4Jp3/YM+c DRdOtO89eWiPNXUbzv5xwawRs270f/XWuxWqn7J2tu+2FkyplzTJbUIf78oRh3IOWCInHDyScup6 1ZJ+ysoemZf7hpL8IkrVKfZTpnc+iv8aG52R7u57gnymXJs02tVuP5rnNb/2qemHN3xsmXKmadlm bWv1PH+h7MaGroHTYncuS3pryfMHKsSFfBGcuN7PtdX3i0Y8tzt12/k54b0qRc043jp+86BJc+zN L1QcOr9r3e61a/WqGxi8NN2zzqMLVhyeGXMje2OL1XP7nrGtXtNu/1uHI6+NHL/y8nLTU3tr7Rjs lXVMVVkc/VzBltst/GYMbVy9Uv87PdtlHJ9qrbtq3wenay5f383l/Sfy8t6T69v1r24yN1L375je W0rophafQfHuWmFpYLqn81b8jcW7P4XFx/zbnaHicyreFyksR8z365kUn0fxjaCwrHB74E0iuqu1 lLzFyn/9mdESd/nXI215PWBUQnpGkj0tzBYcGGQLSEiLs8cnpQ0Ns/WJiWjUwhaQkRmbFh+bYk9L CLONTciwtW1T1v2R2FZxKendY4cHMIO0jFaxYbbEzMzhrRo3zoij+tiMQPvwhDReG2JPT43N5J/p QxvHp8eOZsapKY1DgoKaNU6NTUqzBQweGhxmS8kMtgVkjuFZfHKwTAuRaSEyLUSm8Sw2Lo61zV8Y TxxTQhxT7v5NqGNKqGNKE8eUJo4pTR1TmjqmNHNMaWYLSExJSkvmG8mDLWCIPSVSn+B4ZmvcxpMo LFGLNCVuD1DtjSMmcrxjqKo6jNVF8NV1kkSsMbxaUrla90uv+796q86XXsNmX65979RfT5EiW7ek KnXkWJF6yxnZJgoosiXJ/dHkHjmSJ1lyZUq+RMmZ193Ihyb5kySHiuRRkGvp5XpquaZWrquTaytk fL2MsZWxsxHMNxq90Q/9MUACIgyCROqDIce/hmAoZLB2EpLlWD3sGKG0wxHaffTl/t1yD2e5j6/c y1Xu5yn3dJT7+sm9veT+TnKPF7nPh9zrQfL9S853yfstuX8l/6vkANLygEzQr8+Ua4JkXLh85s5U FYku2lE1pqEbWCQqSo77oad+XI91wi4LqlKPaUfO+BzS6OBJxEGOZMlYf6pWkuxxuNKWeb6eOaZU vhwDNrvK+teHMDvIv8OV/2Uvbd1oa0hlZ2eraxKql1Pm/Ge1oN0139XxJheZsSU/SKvAJb+uNt0t 36uEjcas3LX3ycFQq/H3snl5G9NlXspTVlyZfH+evmOSug6atI8hB0SVi4VGRbW1mLS6y+e7GJ+i oIB5y5+ZZLPVNiqey0Yqz31YEhVZq8Nz9M8h73DsBI5pszBb6ZlBPsFEi1LTLfpBWx/chokPXYdq GuAJxOOmpzbOWyUbN/MfwY9BFqrRoPrjDeThJM7ghSpKrUK1arSeaM0XbYuRmOCv37x5LloHKtUJ 85qwYaFFM6U6YAf2oaNx09CCjiyyTjSW6Iq6bEkNECQ3hMPbbE3vohVbVDvchIUty5UtqxxO4QzO 4QoasrU1wSNoix9wEWXYozyRjHHIxSpswR4cw3E0YCsNhB0ZyMYULMRSrMF67MRuvIf9uIif8AtM bOWl4Alf+KEeGqIdOqEX+spRbsRjJMbiWSzGZ/gC51GRluARtEMt9p5QhLH3dEN/9qAU9GYv6ocs zMQhfIIG7FmtkIx0/IAf4UPL4otaqIN4pGA3DsPE3uiGSZiB9diOy7iOp9hTs5Fj3ATmFWzARryB NrRa7dEBj2Im5mAuFuMyrqIMLZsf2tC6dRio3xCmFzJpBcZgLHJwBSZavE9wCrdQAA9aigrYgjzc gQcNlzeq4CHURn00RXt0w3K8gN34AJ/iBD7HBbjTqnrCCza0RQTSMAZj8TTmYCn245i8Rks8GXMw HwvwEnZjL/4Hx/EzbqM2DWw9RCAaPTEAUzFLXmM/D0IkuqIMLbw36ifrN1x4B/vwBQj1VSdazG6I x1B0pfXshS60FdFIRDIW4DlsM5K378chZPDLMQ478QGO4XN8g/O4gptwo0X2RkXUQCjaGMndB2A4 xmAdtuIGzPyIWFEeNRGIcEQZScUTsdS4YcAbRoLxMziLHyVJPJrzw9rGSDpM30BVgB/O4UKG9OKV Ko3q/PDWwVlcQCg/wK2MxJV9jMSVixE1hv0QDWhHA5GGDIzBdRSgGz92pemr/nlY/2Tf9//Luip8 pocj7J9Gh1E6hpLGfrPSL4m7guZ0JFpjIqbhZ9zEVHpRc3EQH6E8/Qgf9EN/rMJafI/zeJy+RX+s xEv4DhdRjQ9QE53RFdMxD0fwKfwImh5CLOJlUAXW4wKuYhxfYwJ2YS/c6GR5oCf+gkVYgY/xBXzp XPmjP+KxButwHvnIoL/zFPLwNtrTs++MaZiDv+MIKnnwufAkhuAlrMX/4hIa0qFugkxkYTveLav3 /UqjC7phGOzYim2ehX2tjojAbMzHh/gIA+h0DsbLWIvzkI5ocHl+/zEWOXgHe+Hize8UuiEax/EV /Om/2dATfbEcL+IrfId6PrR3GIFsbMcO3IErG0wHRGE/jsCLfl8FTMY03ITFl+WHSDyDZ3EUJ+BL 77wWEjECq7EO5/EzxtN/nIKzOI9AP9pmjMY47MQumInryyASPTAfC3ECn8OPgMaGQUjAWmzAedzE UPqnSdiMv+Fn3MBU+qkz8CE+hU91fi/QDwNQMYC+NarDhkSkYBNex3UUYFoNfqNxCIdRycZ2gycR h0/wBaoSdNXGICRgDw7AvRbbM77F92j8MOsap/AdvOowPwzHOGzADrgRpJRBT8RgCZ7DSZyBP/3v ungVb+ISrqEZgV8YxmMKyjZgXSEGj2MZJFXTNziLeg3pYyAPe2BqxDaHLuiOeViM4/gSvvT3bXgS 8XgZr2IvjsGLoLMSemMQlmE1vsTXqE0QFoRUjMJWvIWruIMqwbQnWIMN+AGXEBTC/oixmIzdOIgC uIeynaILZmAOKhKP+OJJxOMlrMMFXEIzAuNwjMM07MT7KE3cUg490AsLsQyf42s8TDzTCMMwAn/F 33ANViLXdGRhO/agQ0v6xliLDXBtxedFFHrhJE6jZmuWDRKRio3Ygmut5SgT+w1ysAvvITKM9gBz sRBHcQKV27A9YSASsA6b4NGWvhyWIxdf4xxGhDNvbMXb+CVcOyuv3Qi+C6ZiDrwIgn0RgyewFCvx Ob6GrQP9VbyG1/ETbqENsV849uEofsJNJBIHpuIKbqFVBF8TOZhq3FD8feOm4h6dC2PGwUhALlbj CeLHgXgJ63AGF1C7C+sJdmRgG/JQgDLEmm0RgWmYjYM4jPLEnhXxOPpjFdbgO1xEI+LSIGQgCxbi 0VLoij6Yj0U4jpOwEZfWLxKrPo3ZOIiP4NGDtgkxeByLkIsT+Ar1iFcbYRbmYDU24VtcRBVi0Zro hX5GTDvGiGE34yg+7VkYo0ps2sWIRScYsehK7MMhIxatTAwagqboiwEYiXG4AQuxaXtE4BnMx8c4 iYf6KBWAWAzBeryGK/gFk4hnp+AADqI8ca0PcrEGZ/EDgohrW2KucaPZ941414O41huzsAhH8dnj hTHuQCPOXYV1qEkc2xDDYMcW4sl38BEx5CdFYsn7xYzFY79OxHORiYUx4GjiqfF4lnhpsV2PZS4h j7hjlyTDx+VRemLtd1EAN2KR5XgRvpJYGd4T6UtN1GOTy/j5bkwS6uTk5PRPWP/LP7/+f2Uc4Jdj 7YnEKpOw1uhPyyjAgThn9KN20484gOuo1klvs0vTRr9M+3tkhH78ZxTCjMTF5WhfO2EyXkS9bH5j sAP7s/W2d+zddtf6LzKrihN+rHf3xILJzJR9fj4d7p1SRT/VoH3fb40X5DynJOySAYsyLPorAl1J 4vPiozWV5PyQAbqS3lWSFG/u31cbuCm3dZGkP5IkVrJ6lE5Zq+SWRZLu2TVmg5LMIZLmRW48Yuv4 k9JuJqf071z0nENBuCXbpFKZItTKZdp5jFTjLxyPZq8i58nGyBmQcP0Ehyy4PipNJcOuRvP/3z7P J+8pYdA2VepzU8Y5HrPjTE+R53KapbP/PD612VzKYnWxmi0u0+pTBRGvY54FJv0xhvpkRKt8gige R/PYy/hUci6tKfMxK6vVZDaVLmW2llaOoeKFJVtp5+vG8p7BvFPOWoUGarWXKeVilnLf2ttpY8lj tfe0DdPeU9riZjZbzS73fU8H6hipvS9BG4Wtf2qlmut1lrNKhRazyyWzWpkVIMtfL7nK8f5YbSkP 1uahVGvPeaanS5tNpZTFJMWi/ZWnq9fdJe6i9G8oS6o3dctyeeaJ3nRCW4YZ39OtsM6uJdZp510Z 2tKRtc1yvbuEWEEu2hKKvffbmoz1E3t3K2F56WvVxcqbShn1/RBQeJq36HdMNb6hjE3uro3hlfOk Nr7NCNdZlVW+5Kh5Raukz/LLQ4SjiaGTVp7Axy5j0Ntru6Fl3sVfTXXklqph0Y7TKJPzQrE/UJpZ Z1i3qq0qJyck6N5XGubo/pVSmIbILXRyeVlPrurW7fuuKdfIv2h/m19QzuRaK9rYlmpqZ/onlkS7 NkWuICpxdjVcfj3N6yFVpF0bY3CUlVapy7vYe1zYx3sj5J+0mf+pcodWlQawhLZYqdNTc6/c6JHo 9ep8V9WgzpbjshIHmfQGUl6fbqyFeZCWZYXxs7bOOES9TbteQKn3tF8I/bYXsnzOGO34Le0UO9NM +vU+dU36hTBNTNoRVxVu0sYGaNfKSZ3RJn1Ik1yHJPWeoTJ/o04pxZ9LXVG9o0JKeq3oc6k7Skbc pATG2zNTtWlSX0yiPTU2I6B9QkpKkpwedLwvxHifjFXonhSXbs+wD8kM6DFkSFJcQsBj9vR4bayC DCw5FXP0zYOmos8tRn0Wo82RR2l3LM7mwlmcxVmcxVmcxVmcxVmcxVmcxVn+g+W34n/zsQ+PrQis 6rVgCfF/wxsbg4yY3cN4XY65SXw+3Ij35xnxvuQNKi9HPOBrHA+Qay02G3G1HBeQOH6X0g9771d6 3H/YmPcpdW98X1mLz5OTYgN6JyWkJqRlBEQlZI62pydn6HHzRSOebm88ypElPZ72uHsF0/0e/b0K rzHQUpKYjeBevkhMUmZCijYr5wFAZ3EWZ3EWZ3EWZ3EWZ3EWZ3EWZ/mvLo5r641UoFocL6GvnK+X 8+dynt7diJc9jDjd04j7vYw439uI532UfllaJSPul7hdhrr5oarSk4JUM8Lr6ghQkqhDxu0oVVPp eUQfhqRqkJQdcsm+jKWrD7nReEM0QiAaK8mfqVSw0s/Hy02Hm6Apmim536JSklNAcgi2gnFFhQpT kkFRqbZKP0ffzjhuICP0OqKT0vM0PEjeAxlE4sh9IDkd7pf/QHI9OHIg3C/ng+RGkHEDkh+heO4H yZcgl/k5ciY48kDIcRfJBZGuHccpKJDciiMxCjJqTEafjMU44/WneByPCZio9MFtMghnEiRxyxRM hXGrZ218xwylJ3R5RhWmIpiDucbxnvmQ1AsLsBCLsNioT44DLcNzWK708SHPKz1vtLwux4dexCqs huR1fBlrjNdvG9Yb/3Zwln9fkfGQdi33ZSct82e6tsU8eKmkrCbHvKQNKeWmH0vcpb8cUfRvVw54 rK+MgXnN2PaUts/FavlG/2hxV2ZT0e/zIO+RMYqOUZ7BRuZePWvv7y+e1G8y2swHrT8LbzfXnz+m 5SGNZznYaQNG3s3A+qDFj/rNRrv9oPVLaXJGf7Rqoz5TtVFnsu67UPu9uVHtRt7ZkkvdP7D8lxRZ /tZfffPf93laUL+L8d0ftP7cIvWbtPGrqbSlPdgKhv3u9e+tjUz+fd9fGe3yv6v8kfqL/v4729Q/ bzGx9i3u+jZUvO2WPliJ4xsDWjZvFBIUFNqooz15ZGpCWqbWRezeW17raI/T9i15Hsg/tNcDW6ir LV8f4exu/58r/wBQSwECFAAUAAIACACiajM+JIi7pZFcAAAAXAEANQAAAAAAAAAAACAAAAAAAAAA Y2hhbmdlIHByb3Bvc2FscyB0byBkcmFmdC1pZXRmLWF2dC1lY24tZm9yLXJ0cC0wMy5kb2NQSwUG AAAAAAEAAQBjAAAA5FwAAAAA ------_=_NextPart_001_01CBB7D3.EE0A478B-- From magnus.westerlund@ericsson.com Wed Jan 19 06:18:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233063A712A for ; Wed, 19 Jan 2011 06:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnrYGOkrAXW for ; Wed, 19 Jan 2011 06:18:49 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C158B3A7112 for ; Wed, 19 Jan 2011 06:18:48 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-49-4d36f367ac90 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FD.B9.13987.763F63D4; Wed, 19 Jan 2011 15:21:27 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 15:21:26 +0100 Message-ID: <4D36F366.8090304@ericsson.com> Date: Wed, 19 Jan 2011 15:21:26 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> <4D345C68.5030402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:18:50 -0000 Ali C. Begen (abegen) skrev 2011-01-18 14:10: >>>> It might be that you need to tell any using specification to declare how >>>> a unicast session is terminated. But currently this is a gapping whole >>>> in the specification. >>> >>> Actually, we clearly specified how a RAMS session is terminated or when it ends. Repeating all that text here is not needed. >> So, maybe we should simply say the spec using the Token approach needs to discuss the session termination and ending >> sessions. >> >> No, if that requirement is put on application of this, then I am mostly >> happy. > > Just to be clear: are you satisfied if we say " the spec using the Token approach needs to discuss the session termination and ending > Sessions"? If so, do you think we need a 2119 language here? > I have a preference for it, so that it is clear that it can't be skipped. >>> >>>> Based on the below comments it appears that you have decided that RTP >>>> session termination is when all external SSRCs has timed out. But, I >>>> wonder if the servers really are fine with that. If I as a client >>>> continue to send RTCP RR to a server in a RAMS scenario for the unicast >>>> session, then the server is not allowed to terminate the session? I >>> >>> In RAMS, the client will continue sending RRs if and only if the client does retransmissions in that unicast session. If that is >> the case, of course, the server is fine since the session is still active. >>> >>> If the client does not do any further retransmissions after the burst is completed, the RRs will not be sent so the session will >> end after the timeout. >> >> But, basically you are saying that unless the client keeps the session >> alive, the server will terminate it. Which gives non symmetric behavior >> between the client and the retransmission server. > > In practice, in an IPTV system, this is how it works to the best of my knowledge: The client once it completes a retransmission does not BYE the unicast ret session right after the ret packets were received. It will send the periodic RR/XR reports, if a new NACK is sent, the server is ready to go. When the client switches to another channel, it will BYE that unicast session so the session will end for both sides. Yet, some clients may stop sending reports, so the SSRC will time out on the server side. Yes, I agree that is the reasonable usage in that scenario. But, I don't know if everyone will see it in the same light when implementing. Thus resulting in interoperability issues. That is why I do wonder if we shouldn't describe this reasonble base case, and say that applications may modify or specify additional methods of termination. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jan 19 06:25:06 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2723D3A70F5 for ; Wed, 19 Jan 2011 06:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-+0NLE+VVLP for ; Wed, 19 Jan 2011 06:25:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9CB5F3A6FE7 for ; Wed, 19 Jan 2011 06:25:01 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-ae-4d36f4dc0aa0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F4.9A.13987.CD4F63D4; Wed, 19 Jan 2011 15:27:41 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 15:27:25 +0100 Message-ID: <4D36F4CD.5030709@ericsson.com> Date: Wed, 19 Jan 2011 15:27:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> <4D345A78.2020008@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD66@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD66@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:25:06 -0000 Ali C. Begen (abegen) skrev 2011-01-18 14:10: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Monday, January 17, 2011 10:04 AM >> To: Ali C. Begen (abegen) >> Cc: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >> >> Ali C. Begen (abegen) skrev 2011-01-17 14:24: >>> OK, I see your concern, however, should not we still follow 4585 as it is and once it gets updated, it will be reflected here? >> If the immediate mode is chosen, the NACK/RAMS could result in many more spurious transmissions whereas the token stuff >> only results in one such transmission. So putting some extra rules here for the tokens only will not get us much. >>> >>> Maybe, we can add some text to disallow the immediate mode? >> >> You seem to be punting on this issue. I think Immediate mode needs to be > > Did not even cross my mind :) > >> allowed, it makes all the sense for these type of applications in >> certain environments. However, what is needed is a separation of the >> "packet loss" / "failure for server to act on event" detection mechanism >> and the RTCP transmission rate limiting. > > Well said, but with RTCP one can do so much. Ok, can we at least point out that this issue exist and that implementations needs to do something reasonable about detecting loss, and not soley rely on sane configuration values of the RTCP bandwidth. > >> I think despite our discussion of these things in CCM (RFC 5104) we did >> fail to take all the AVPF cases into account. I have to say that 3.5.1.1 >> do rely on repeating FIR messages until you get an result. It does fail >> to say in which mode and what type of transmission should be used for >> the repetitions. This as one in early mode, this is either classified as >> an event that are allowed to send early, or as a regular transmission. >> >> There need to be some sanity checking in this, and going forward being >> aware that what we specify can be seriously broken is not the best >> thing. In addition RAMS can be fixed. And the NACK still doesn't have a >> spec for this use case. > > OK, let me ask you this. Even if we come up with a miracle solution for the token stuff, that still does not fix the bigger issue that one might have with NACKs (I am omitting RAMS here since RAMS has some other natural limits, e.g., a client would not really have multiple outstanding RAMS requests unless it is attacking the system). > > So, maybe we should actually talk about fixing this in general for 4585? I do agree that RFC 4585 should be updated to take this issue into consideration. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jan 19 07:18:26 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426583A7167 for ; Wed, 19 Jan 2011 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L872FvTlFEhn for ; Wed, 19 Jan 2011 07:18:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A3A833A7162 for ; Wed, 19 Jan 2011 07:18:24 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-3a-4d370160af82 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C0.C2.13987.061073D4; Wed, 19 Jan 2011 16:21:04 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 16:21:03 +0100 Message-ID: <4D370160.6060002@ericsson.com> Date: Wed, 19 Jan 2011 16:21:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> <4D3420EA.9040806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> <4D345838.2050805@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD68@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD68@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:18:26 -0000 Ali C. Begen (abegen) skrev 2011-01-18 14:29: > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Monday, January 17, 2011 9:55 AM >> To: Ali C. Begen (abegen) >> Cc: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org >> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics >> >> Ali C. Begen (abegen) skrev 2011-01-17 14:58: >>>> Ok, can you then write down the exact semantics of the portmapping-req >>>> and portmapping attribute? Because to me their semantics aren't clear. >>>> And without clear semantics this is going to cause confusion when used >>>> the next time. >>> >>> I am not sure what you are looking for in addition to what section 7 says. they are used in pairs. portmapping is used in the >> multicast block and portmapping-req is used in the unicast block. Together they mean, certain rtcp messages will require the >> token. The portmapping-req will tell you where to get the token from. Any confusion or question here? >> >> I think the confusion is that I believe it will be cases where Token >> Verification Requests are going to be need to be sent on C2->P4. If that >> is the case one needs semantics to say that token may also be included >> in RTCP message related to this session. > > Right, the messages that control the unicast session and that are sent in the unicast session (like BYE and CCM) need to be authenticated (as written in 4.3.1). Yes, > >> In addition the semantics for the portmapping-req that now is mandated >> to be on the declaration of the unicast RTP session. If we take your >> argument there is no need for token verification in that session. Thus, >> can you please explain why it is part of that session declaration? >> >> In my world there could be token verification messages in the RTCP for >> the unicast session. However, the declaration of where the Token server >> should then either be in all RTP sessions that uses Token Verification >> Messages, or at session level and applies to all "portmapping". > > Ok. I guess your concern is that the "portmapping" attribute is defined media level and used in multicast block, yet it means messages triggering or controlling the unicast session might need token authentication. Is this your concern? Yes, lets indicate in which RTP session where token verification request truly are needed. > > I don't think we should define it as session level as I mentioned earlier, it opens other corner cases. So, let's see how we can address this while keeping it media level. Media level only is fine. > > I guess we have two options here. We either repeat the "portmapping" attribute in both blocks and keep the "portmapping-req:port" in the unicast block only, or repeat "portmapping-req:port" in both blocks and remove the "portmapping" altogether. The latter saves one line from the SDP. I would do the later. Keep portmapping-req and put it in all media blocks that defines RTP session that uses Token Verification. > > BTW, the last part of the 3rd paragraph in section 7.1 needs to be changed to: > > ... (ii) the client MUST receive the > unicast session's RTP and RTCP packets from the server on the port > from which it sent the RTCP message triggering the unicast session. > > (Removed "or controlling" since that would mean port c2). > Yes, I think you might have to explicit call out where the verification failed message is sent from the server to the client for any verification message sent from client at C2->P4. > ... >>> The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token >> verification request message on that path? The verification request message goes from c1 to p3. >> >> Here we seem to disagree. If one looks at the list in section 4.3.1, i >> think that this does contain messages where you would like to attach >> token, such as BYE or CCM messages. > > Correct. > >> It might be me taking the generalized look on this specification. Then I >> do see a need to make sure that it can be used in any RTP session where >> indicated. >> >> If the intention to not have any session level attribute, then I don't >> understand why we have two SDP attributes, then only portmapping-req is >> needed. And I think it should be defined as having the meaning. Shall be >> included in the SDP media blocks that define an RTP session that needs >> Token Verification messages. Which means that portmapping-req are needed >> in the multicast m= block, not the unicast. > > Does putting the attribute only in the mcast block resolve your concerns? I don't think so as it will not cover the unicast session for which the rtcp messages are sent for. Correct, I want it the semantics of the attribute to be. In this RTP session, there is need to use Token Verification for some RTCP messages. And here is the server port and address where you can get a token. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Wed Jan 19 07:20:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF7F93A700E for ; Wed, 19 Jan 2011 07:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HktmJJCSKct for ; Wed, 19 Jan 2011 07:20:09 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E0A533A6FAD for ; Wed, 19 Jan 2011 07:20:09 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGaQNk2rR7Hu/2dsb2JhbACkR3OlZJoxAoVOBIRviVk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 15:22:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0JFMoGJ005188; Wed, 19 Jan 2011 15:22:50 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 07:22:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 07:22:40 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16E1C0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D36F366.8090304@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination Thread-Index: Acu35CyeyZHGyUouQzK423iZ5kKh5QABoKJw References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> <4D345C68.5030402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> <4D36F366.8090304@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 19 Jan 2011 15:22:50.0022 (UTC) FILETIME=[BBBF1C60:01CBB7EC] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:20:13 -0000 OK, let's not describe a specific method, and the following text: A specification using the Token-based authentication described in this = document is REQUIRED to discuss the methods and rules for = terminating/ending the unicast session. I propose to add the text above to the 5th parag. of section 3 as = follows: Upon successful validation and once the unicast session is established, all the RTP and RTCP rules specified in [RFC3550] and other relevant specifications also apply in this session until it is terminated. >>> -acbegen > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, January 19, 2011 9:21 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session = Termination >=20 > Ali C. Begen (abegen) skrev 2011-01-18 14:10: > >>>> It might be that you need to tell any using specification to = declare how > >>>> a unicast session is terminated. But currently this is a gapping = whole > >>>> in the specification. > >>> > >>> Actually, we clearly specified how a RAMS session is terminated or = when it ends. Repeating all that text here is not > needed. > >> So, maybe we should simply say the spec using the Token approach = needs to discuss the session termination and ending > >> sessions. > >> > >> No, if that requirement is put on application of this, then I am = mostly > >> happy. > > > > Just to be clear: are you satisfied if we say " the spec using the = Token approach needs to discuss the session termination > and ending > > Sessions"? If so, do you think we need a 2119 language here? > > >=20 > I have a preference for it, so that it is clear that it can't be = skipped. >=20 > >>> > >>>> Based on the below comments it appears that you have decided that = RTP > >>>> session termination is when all external SSRCs has timed out. = But, I > >>>> wonder if the servers really are fine with that. If I as a client > >>>> continue to send RTCP RR to a server in a RAMS scenario for the = unicast > >>>> session, then the server is not allowed to terminate the session? = I > >>> > >>> In RAMS, the client will continue sending RRs if and only if the = client does retransmissions in that unicast session. If that > is > >> the case, of course, the server is fine since the session is still = active. > >>> > >>> If the client does not do any further retransmissions after the = burst is completed, the RRs will not be sent so the session > will > >> end after the timeout. > >> > >> But, basically you are saying that unless the client keeps the = session > >> alive, the server will terminate it. Which gives non symmetric = behavior > >> between the client and the retransmission server. > > > > In practice, in an IPTV system, this is how it works to the best of = my knowledge: The client once it completes a > retransmission does not BYE the unicast ret session right after the = ret packets were received. It will send the periodic RR/XR > reports, if a new NACK is sent, the server is ready to go. When the = client switches to another channel, it will BYE that unicast > session so the session will end for both sides. Yet, some clients may = stop sending reports, so the SSRC will time out on the > server side. >=20 > Yes, I agree that is the reasonable usage in that scenario. But, I = don't > know if everyone will see it in the same light when implementing. Thus > resulting in interoperability issues. >=20 > That is why I do wonder if we shouldn't describe this reasonble base > case, and say that applications may modify or specify additional = methods > of termination. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Wed Jan 19 07:22:26 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A10B3A716E for ; Wed, 19 Jan 2011 07:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKwIlMGJYrzx for ; Wed, 19 Jan 2011 07:22:25 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14B053A716A for ; Wed, 19 Jan 2011 07:22:24 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABuRNk2rR7Ht/2dsb2JhbACkR3OlZ41WjFsCgwmCRQSEb4lZ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2011 15:25:04 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JFP4HY005702; Wed, 19 Jan 2011 15:25:04 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 07:25:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 07:24:06 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16E1C2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D36F4CD.5030709@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior Thread-Index: Acu35QthkuXW04DbQHqo2u/m+CLFRAAB8Ojg References: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA5@xmb-sjc-215.amer.cisco.com> <4D345A78.2020008@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD66@xmb-sjc-215.amer.cisco.com> <4D36F4CD.5030709@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 19 Jan 2011 15:25:04.0445 (UTC) FILETIME=[0BDE6ED0:01CBB7ED] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:22:26 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, January 19, 2011 9:27 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior >=20 > Ali C. Begen (abegen) skrev 2011-01-18 14:10: > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Monday, January 17, 2011 10:04 AM > >> To: Ali C. Begen (abegen) > >> Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > >> Subject: Re: [AVT] WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 6: Resend behavior > >> > >> Ali C. Begen (abegen) skrev 2011-01-17 14:24: > >>> OK, I see your concern, however, should not we still follow 4585 = as it is and once it gets updated, it will be reflected > here? > >> If the immediate mode is chosen, the NACK/RAMS could result in many = more spurious transmissions whereas the token > stuff > >> only results in one such transmission. So putting some extra rules = here for the tokens only will not get us much. > >>> > >>> Maybe, we can add some text to disallow the immediate mode? > >> > >> You seem to be punting on this issue. I think Immediate mode needs = to be > > > > Did not even cross my mind :) > > > >> allowed, it makes all the sense for these type of applications in > >> certain environments. However, what is needed is a separation of = the > >> "packet loss" / "failure for server to act on event" detection = mechanism > >> and the RTCP transmission rate limiting. > > > > Well said, but with RTCP one can do so much. >=20 > Ok, can we at least point out that this issue exist and that > implementations needs to do something reasonable about detecting loss, > and not soley rely on sane configuration values of the RTCP bandwidth. OK, we will mention this and add a warning. =20 > > > >> I think despite our discussion of these things in CCM (RFC 5104) we = did > >> fail to take all the AVPF cases into account. I have to say that = 3.5.1.1 > >> do rely on repeating FIR messages until you get an result. It does = fail > >> to say in which mode and what type of transmission should be used = for > >> the repetitions. This as one in early mode, this is either = classified as > >> an event that are allowed to send early, or as a regular = transmission. > >> > >> There need to be some sanity checking in this, and going forward = being > >> aware that what we specify can be seriously broken is not the best > >> thing. In addition RAMS can be fixed. And the NACK still doesn't = have a > >> spec for this use case. > > > > OK, let me ask you this. Even if we come up with a miracle solution = for the token stuff, that still does not fix the bigger issue > that one might have with NACKs (I am omitting RAMS here since RAMS has = some other natural limits, e.g., a client would not > really have multiple outstanding RAMS requests unless it is attacking = the system). > > > > So, maybe we should actually talk about fixing this in general for = 4585? >=20 > I do agree that RFC 4585 should be updated to take this issue into > consideration. Cool. That will help us in the long term. -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From abegen@cisco.com Wed Jan 19 07:31:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656243A716C for ; Wed, 19 Jan 2011 07:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siYeNQpxqo8H for ; Wed, 19 Jan 2011 07:31:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 44D023A7164 for ; Wed, 19 Jan 2011 07:31:12 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL6SNk2rR7H+/2dsb2JhbACkR3OlbJouAoVOBIRviVk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2011 15:33:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0JFXq94012012; Wed, 19 Jan 2011 15:33:52 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 07:33:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 07:32:47 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16E1CE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D370160.6060002@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics Thread-Index: Acu37IFdEwvZMiTURRC9Q5MaK47kKgAAYULw References: <4D308063.3020906@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA3B@xmb-sjc-215.amer.cisco.com> <4D3420EA.9040806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA7@xmb-sjc-215.amer.cisco.com> <4D345838.2050805@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD68@xmb-sjc-215.amer.cisco.com> <4D370160.6060002@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 19 Jan 2011 15:33:52.0552 (UTC) FILETIME=[46A52A80:01CBB7EE] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:31:13 -0000 OK, we will work on these changes and submit a revision after the = chairs' go-ahead. I believe wglc ends today anyway. Thanks again for the detailed review. -acbegen > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, January 19, 2011 10:21 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute = semantics >=20 > Ali C. Begen (abegen) skrev 2011-01-18 14:29: > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Monday, January 17, 2011 9:55 AM > >> To: Ali C. Begen (abegen) > >> Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > >> Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute = semantics > >> > >> Ali C. Begen (abegen) skrev 2011-01-17 14:58: > >>>> Ok, can you then write down the exact semantics of the = portmapping-req > >>>> and portmapping attribute? Because to me their semantics aren't = clear. > >>>> And without clear semantics this is going to cause confusion when = used > >>>> the next time. > >>> > >>> I am not sure what you are looking for in addition to what section = 7 says. they are used in pairs. portmapping is used in > the > >> multicast block and portmapping-req is used in the unicast block. = Together they mean, certain rtcp messages will require > the > >> token. The portmapping-req will tell you where to get the token = from. Any confusion or question here? > >> > >> I think the confusion is that I believe it will be cases where = Token > >> Verification Requests are going to be need to be sent on C2->P4. If = that > >> is the case one needs semantics to say that token may also be = included > >> in RTCP message related to this session. > > > > Right, the messages that control the unicast session and that are = sent in the unicast session (like BYE and CCM) need to be > authenticated (as written in 4.3.1). >=20 > Yes, >=20 > > > >> In addition the semantics for the portmapping-req that now is = mandated > >> to be on the declaration of the unicast RTP session. If we take = your > >> argument there is no need for token verification in that session. = Thus, > >> can you please explain why it is part of that session declaration? > >> > >> In my world there could be token verification messages in the RTCP = for > >> the unicast session. However, the declaration of where the Token = server > >> should then either be in all RTP sessions that uses Token = Verification > >> Messages, or at session level and applies to all "portmapping". > > > > Ok. I guess your concern is that the "portmapping" attribute is = defined media level and used in multicast block, yet it means > messages triggering or controlling the unicast session might need = token authentication. Is this your concern? >=20 > Yes, lets indicate in which RTP session where token verification = request > truly are needed. >=20 > > > > I don't think we should define it as session level as I mentioned = earlier, it opens other corner cases. So, let's see how we can > address this while keeping it media level. >=20 > Media level only is fine. >=20 > > > > I guess we have two options here. We either repeat the "portmapping" = attribute in both blocks and keep the "portmapping- > req:port" in the unicast block only, or repeat "portmapping-req:port" = in both blocks and remove the "portmapping" > altogether. The latter saves one line from the SDP. >=20 > I would do the later. Keep portmapping-req and put it in all media > blocks that defines RTP session that uses Token Verification. >=20 > > > > BTW, the last part of the 3rd paragraph in section 7.1 needs to be = changed to: > > > > ... (ii) the client MUST receive the > > unicast session's RTP and RTCP packets from the server on the = port > > from which it sent the RTCP message triggering the unicast = session. > > > > (Removed "or controlling" since that would mean port c2). > > >=20 > Yes, I think you might have to explicit call out where the = verification > failed message is sent from the server to the client for any > verification message sent from client at C2->P4. >=20 > > ... > >>> The only thing that travels from c2->p4 is the receiver reports = for the unicast session. How would you send a token > >> verification request message on that path? The verification request = message goes from c1 to p3. > >> > >> Here we seem to disagree. If one looks at the list in section = 4.3.1, i > >> think that this does contain messages where you would like to = attach > >> token, such as BYE or CCM messages. > > > > Correct. > > > >> It might be me taking the generalized look on this specification. = Then I > >> do see a need to make sure that it can be used in any RTP session = where > >> indicated. > >> > >> If the intention to not have any session level attribute, then I = don't > >> understand why we have two SDP attributes, then only = portmapping-req is > >> needed. And I think it should be defined as having the meaning. = Shall be > >> included in the SDP media blocks that define an RTP session that = needs > >> Token Verification messages. Which means that portmapping-req are = needed > >> in the multicast m=3D block, not the unicast. > > > > Does putting the attribute only in the mcast block resolve your = concerns? I don't think so as it will not cover the unicast > session for which the rtcp messages are sent for. >=20 > Correct, I want it the semantics of the attribute to be. In this RTP > session, there is need to use Token Verification for some RTCP = messages. > And here is the server port and address where you can get a token. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jan 19 07:51:20 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD493A6FEF for ; Wed, 19 Jan 2011 07:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YidhgQcOR38S for ; Wed, 19 Jan 2011 07:51:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4CD973A7011 for ; Wed, 19 Jan 2011 07:51:18 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-c6-4d370915b171 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 38.E6.13987.519073D4; Wed, 19 Jan 2011 16:53:58 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 16:53:44 +0100 Message-ID: <4D370908.2050103@ericsson.com> Date: Wed, 19 Jan 2011 16:53:44 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> <4D345C68.5030402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> <4D36F366.8090304@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16E1C0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16E1C0@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org" , IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:51:20 -0000 Ali C. Begen (abegen) skrev 2011-01-19 16:22: > OK, let's not describe a specific method, and the following text: > > A specification using the Token-based authentication described in this document is REQUIRED to discuss the methods and rules for terminating/ending the unicast session. > > I propose to add the text above to the 5th parag. of section 3 as follows: > > Upon successful validation and once the unicast session is > established, all the RTP and RTCP rules specified in [RFC3550] and > other relevant specifications also apply in this session until it is > terminated. >>> > Well based on this, I wouldn't come to the conclusion that one can stop sending RTCP as server at all unless there has been some explicit signalling for termination. this is Probably fine for the general introduction. And it do leave the question of termination wide open. So, I don't see other than that you have to discuss the termination in the draft. "The Unicast RTP session created using the port mapping method can be explicitly terminated by procedures specified by the using application or extension. Any unicast RTP session created using this method may be terminated by a timeout procedure. If either client or Retransmission Server has not seen any RTCP from any SSRC used by a peer for 5 regular transmission intervals, the client or server SHOULD consider the RTP session as terminated, and in that case not send any RTP or RTCP traffic in the future. The client will have to establish a new unicast session if required. If no procedure for explicit termination exist, the client MAY stop sending RTCP to the Retransmission Server to accomplish session termination. The Server SHALL NOT stop sending RTCP until the unicast RTP session is terminated. If Token Verification is signaled to be allowed also on in the unicast RTP session, i.e. the RTCP messages sent from c2 to P4, the client SHOULD prefer to terminate by sending RTCP BYE on all SSRCs it has used in this unicast RTP session." I think this works fine, and is way better than having no specification at all. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Wed Jan 19 08:27:07 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B463A7173 for ; Wed, 19 Jan 2011 08:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxCKGH+Hvixx for ; Wed, 19 Jan 2011 08:27:06 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7E4E728C0DF for ; Wed, 19 Jan 2011 08:27:05 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFegNk2rR7Hu/2dsb2JhbACkR3OlOJonAoVOBIRviVk Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2011 16:29:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0JGTgww001944; Wed, 19 Jan 2011 16:29:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jan 2011 08:29:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jan 2011 08:29:40 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16E217@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D370908.2050103@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination Thread-Index: Acu38RhfmRZKKO7PTpaTj8qEcfxNFQABI1Ng References: <4D307AE7.9090308@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DA39@xmb-sjc-215.amer.cisco.com> <4D341FDB.2050507@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCA3@xmb-sjc-215.amer.cisco.com> <4D345C68.5030402@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16DD65@xmb-sjc-215.amer.cisco.com> <4D36F366.8090304@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E16E1C0@xmb-sjc-215.amer.cisco.com> <4D370908.2050103@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 19 Jan 2011 16:29:41.0932 (UTC) FILETIME=[1307FEC0:01CBB7F6] Cc: draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org, IETF AVT WG Subject: Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session Termination X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 16:27:07 -0000 OK, this looks good. It maybe needs some 2119 adjustment, though: e.g., = if something we say here is already specified in 3550 with a 2119 = keyword, I think we better repeat them without a 2119 keyword but do = point to 3550. -acbegen > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, January 19, 2011 10:54 AM > To: Ali C. Begen (abegen) > Cc: IETF AVT WG; = draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: WGLC comments on = draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 2 Unicast RTP session = Termination >=20 > Ali C. Begen (abegen) skrev 2011-01-19 16:22: > > OK, let's not describe a specific method, and the following text: > > > > A specification using the Token-based authentication described in = this document is REQUIRED to discuss the methods and > rules for terminating/ending the unicast session. > > > > I propose to add the text above to the 5th parag. of section 3 as = follows: > > > > Upon successful validation and once the unicast session is > > established, all the RTP and RTCP rules specified in [RFC3550] = and > > other relevant specifications also apply in this session until it = is > > terminated. >>> > > >=20 > Well based on this, I wouldn't come to the conclusion that one can = stop > sending RTCP as server at all unless there has been some explicit > signalling for termination. this is Probably fine for the general > introduction. And it do leave the question of termination wide open. >=20 > So, I don't see other than that you have to discuss the termination in > the draft. >=20 > "The Unicast RTP session created using the port mapping method can be > explicitly terminated by procedures specified by the using application > or extension. Any unicast RTP session created using this method may be > terminated by a timeout procedure. If either client or Retransmission > Server has not seen any RTCP from any SSRC used by a peer for 5 = regular > transmission intervals, the client or server SHOULD consider the RTP > session as terminated, and in that case not send any RTP or RTCP = traffic > in the future. The client will have to establish a new unicast session > if required. >=20 > If no procedure for explicit termination exist, the client MAY stop > sending RTCP to the Retransmission Server to accomplish session > termination. The Server SHALL NOT stop sending RTCP until the unicast > RTP session is terminated. If Token Verification is signaled to be > allowed also on in the unicast RTP session, i.e. the RTCP messages = sent > from c2 to P4, the client SHOULD prefer to terminate by sending RTCP = BYE > on all SSRCs it has used in this unicast RTP session." >=20 > I think this works fine, and is way better than having no = specification > at all. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Jan 19 09:03:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA92028C0E7 for ; Wed, 19 Jan 2011 09:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tcXPAY5MQyD for ; Wed, 19 Jan 2011 09:03:22 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4BAEB28C0D9 for ; Wed, 19 Jan 2011 09:03:21 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-6d-4d3719f90aaf Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.97.23694.9F9173D4; Wed, 19 Jan 2011 18:06:01 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Wed, 19 Jan 2011 18:06:01 +0100 Message-ID: <4D3719F9.8000004@ericsson.com> Date: Wed, 19 Jan 2011 18:06:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 17:03:23 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2010-12-21 18:25: > Dear Magnus, > > allow me to continue a discussion we hadabout a month ago. > > Youwere suggesting that the leap of faith initialisation method requires > AVPF becausethis allows XR ECN summary reports can then be sent quicker > and shorter reportingintervalthan the average 5secs canbe > negotiated.Correct? > > The draft contains the following relatedprocedurein6.2.3: > > If the sender marks all packets as ECT while transmitting on a path > > that contains an ECN-blocking middlebox, then receivers downstream of > > that middlebox will not receive any RTP data packets from the sender, > > and hence will not consider it to be an active RTP SSRC. The sender > > can detect this and revert to sending packets without ECT marks, > > since RTCP SR/RR packets from such receivers will either not include > > a report for sender's SSRC, or will report that no packets have been > > received, but this takes at least one RTCP reporting interval. It > > should be noted that a receiver might generate its first RTCP packet > > immediately on joining a unicast session, or very shortly after > > joining a RTP/AVPF session, before it has had chance to receive any > > data packets. A sender that receives RTCP SR/RR packet indicating > > lack of reception by a receiver SHOULD therefore wait for a second > > RTCP report from that receiver to be sure that the lack of reception > > is due to ECT-marking. Since this recovery process can take several > > tens of seconds, during which time the RTP session is unusable for > > media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation > > method be used in environments where ECN-blocking middleboxes are > > likely to be present. > > So there is noparticulartrigger for the receiver to sentSR/RR > reportsthat would allow it to benefitfrom the more flexible timing rules > of AVPF. That is true for the case where you use leap-of-faith and have packet dropping box in the path. > > One could think about usingthe AVPFearly RTCP feedback if the sender > does not receiveany packets for a whileat call setup, but the duration > is quite open and it might also bepart of normal operationthat no > packets are received–considerearly media that are usually only > transmitted in backward direction as an example. No, that would be a strange special case. > > You suggested to negotiate a higher RTCP transmission rate as aremedy.In > my understanding this would work both with AVP and AVPF usingSDP RTCP > bandwidth modifiers. Well, it is the minium interval value that needs to be set to something else than 5 seconds to get better results. For AVP that is allowed but no signalling exist. Using the formula for calculating the min interval according to RFC 3550 could work. o The RECOMMENDED value for the reduced minimum in seconds is 360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s. AVPF allows one to set trr-int to a reasonable interval through signalling for this case. And that is without any extreme setting of the RTCP bandwidth. The whole point with AVPF here is to use the signalling and improved rules to provide better RTCP functionality without increasing the bandwidth. > > But I am not convinced this is a good idea given the extra required > bandwidth.There is a clear wordingalreadythat theleap of faith method > isnot recommendedin environments whereECN-blocking middleboxes arelikely > to be present. It is really meant for operator controlled environments > where such problemswill hardly occur.Isit really worth spending more > bandwidthto improve the handling of a very unlikelyevent?If there is a > real risk that ECN-marked packets are blocked ina network, other > initialisation methods are preferable anyway. No, I agree that increasing the RTCP bandwidth is not the best method here. Better utilization of the assigned resource is what should happen. Thus AVPF. > > As said, I alsostilldoubt that you would have any benefit from AVPFfor > thatinitialisationmethod.ButevenIonly failto understand the advantages > you had in mind (do youassume some particular receiverbehaviourdescribed > nowhere up to now?), I doubt this would beworth the extra complexity, > only to improve the handling of a very unlikely error. Again, in > annetworkwherethere is a real risk that ECN-marked packets are blocked, > other initialisation methods are preferable anyway. > Even with leap-of-faith you need to send the ECN indications for sender driven, thus you need it. For receiver driven reactions, you still need to send the control message to the sender. If that is using RTCP, it still needs AVPF for allowing for earliest possible transmission. The only cases where I will agree that you don't need AVPF are: - Codec mode adaptation for AMR But, in 3GPP I would argue that AVPF is still needed in this case as you have an APP packet for adjusting redundancy or number of frames in the packet. I will look into the formulations here. If there is a large number of things that are needed to be fulfilled before AVPF is not requried, it is simpler to require it always. But, I will look into that we have accurate statements in the draft. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Wed Jan 19 14:11:16 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A58728C0CE for ; Wed, 19 Jan 2011 14:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARXgUq0VmHGU for ; Wed, 19 Jan 2011 14:11:12 -0800 (PST) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id 2DA7B3A6E58 for ; Wed, 19 Jan 2011 14:11:11 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PfgHn-0002Qg-pF; Wed, 19 Jan 2011 22:13:51 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 19 Jan 2011 22:13:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <342C8CE4-9DD7-4E8B-9D9F-040BF0B08D9F@csperkins.org> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:11:17 -0000 On 19 Jan 2011, at 11:30, Brandenburg, R. (Ray) van wrote: > Hi Peter, >=20 >> I think the draft is in good shape and provides a lot of additional = information.=20 >=20 > Thanks! >=20 >> I am therefore suggesting that an additional data element be added to = the end of the report - a free running local device time.=20 >=20 > I understand your concern and agree that free-running clocks would be = a possible solution. Would it be OK with you if we rename the 7th and = 8th words of the XR block to '64bit timestamp' instead of 'NTP = timestamp'? In RFC3550, absolute timestamps of this sort are represented using the = format of NTP, even though implementations are not required to run NTP = [RFC3550 section 4]. I'd suggest this draft follow the same approach: = use an NTP-format timestamp in the RTCP packets, with signalling to = specify what clock is used to populate that timestamp. Saves receivers = having to learn how to parse different timestamp formats. > Applications can then decide whether this timestamp should be filled = using NTP, local device times or another timing solution such as GPS or = PTP (precision time protocol). This way the block becomes = NTP-independent while not having to add additional elements making it = unnecessarily big.=20 --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Jan 19 14:24:26 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A9803A6F51 for ; Wed, 19 Jan 2011 14:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.555 X-Spam-Level: X-Spam-Status: No, score=-103.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yR8lPqqTMjZ for ; Wed, 19 Jan 2011 14:24:25 -0800 (PST) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by core3.amsl.com (Postfix) with ESMTP id E15B53A6F5B for ; Wed, 19 Jan 2011 14:24:22 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PfgUZ-0005wI-og; Wed, 19 Jan 2011 22:27:03 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 19 Jan 2011 22:27:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 22:24:26 -0000 Hi, On 18 Jan 2011, at 13:43, Brandenburg, R. (Ray) van wrote: ... >> RTCP XR is appropriate for receivers to report on their = synchronisation state. If IDMS were a peer-to-peer protocol, with each = receiver directly determining its playout based on the reported state = from receivers, then this would be sufficient for controlling playout = too. However, if there is a server-to-client control message that = informs receivers of their synchronisation point, that should, I = believe, follow the previous RTCP approach, and be coded as a separate = packet type. >=20 > What exactly do you mean by 'previous RTCP approach'? A separate RTCP packet type, in the same way RTCP SR packets are their = own packet type. > The main reason we went with an RTCP-XR report block was that we = believed it would be less controversial to add an XR block type than a = completely new RTCP packet type. In RFC5968 (which I believe you = authored) it says that the only valid reason to create a new RTCP packet = type is if the required functionality would not be appropriate as part = of one of the current packet types (such as XR-). In the description of = the XR- packet type in the same document it says the XR blocks are = appropriate for "for transporting new metrics regarding media = transmission or reception quality". So I think we should have a = discussion about whether the IDMS block fits this description.=20 As I said, I think using RTCP XR is appropriate for receivers to provide = feedback to the sender on receipt and presentation times for RTP = packets.=20 I don't think an RTCP XR block is appropriate to, as your draft phrases = it, "indicate synchronization settings instructions to a receiver". That = seems to be providing guidance on when to playout the media, rather than = conveying a metric on how well media playout is doing. This message from = MSAS to SC would be better expressed as a new RTCP packet type, I think. --=20 Colin Perkins http://csperkins.org/ From ray.vanbrandenburg@tno.nl Thu Jan 20 00:27:06 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EAE3A70AF for ; Thu, 20 Jan 2011 00:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nST3IlYskHik for ; Thu, 20 Jan 2011 00:27:05 -0800 (PST) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by core3.amsl.com (Postfix) with ESMTP id 01A073A7097 for ; Thu, 20 Jan 2011 00:27:04 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,350,1291590000"; d="scan'208";a="45524838" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 20 Jan 2011 09:29:45 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0270.001; Thu, 20 Jan 2011 09:29:45 +0100 From: "Brandenburg, R. (Ray) van" To: 'Colin Perkins' Thread-Topic: [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwDW7SwAABpe7FAAFJa9AAAXei+g Date: Thu, 20 Jan 2011 08:29:45 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <6ACC740C-ABD2-484D-B715-4401DACC6444@magorcorp.com> <342C8CE4-9DD7-4E8B-9D9F-040BF0B08D9F@csperkins.org> In-Reply-To: <342C8CE4-9DD7-4E8B-9D9F-040BF0B08D9F@csperkins.org> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:27:06 -0000 On 19 Jan 2011, at 23:14, Colin Perkins wrote:=20 > In RFC3550, absolute timestamps of this sort are represented using the fo= rmat of NTP, even though implementations are not required to run NTP [RFC35= 50 section 4]. I'd suggest this draft follow the same approach: use an NTP-= format timestamp in the RTCP packets, with signalling to specify what clock= is used to populate that timestamp. Saves receivers having to learn how to= parse different timestamp formats. I agree, that would make sense. I will start work on some SDP parameters to= specify which clock, both type and source (such as which NTP server), is u= sed.=20 Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From ray.vanbrandenburg@tno.nl Thu Jan 20 00:40:29 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878243A71F8 for ; Thu, 20 Jan 2011 00:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.406 X-Spam-Level: X-Spam-Status: No, score=0.406 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBMcXJvpocab for ; Thu, 20 Jan 2011 00:40:28 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 4B3BB3A7208 for ; Thu, 20 Jan 2011 00:40:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,350,1291590000"; d="scan'208";a="11224978" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 20 Jan 2011 09:43:09 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Thu, 20 Jan 2011 09:43:09 +0100 From: "Brandenburg, R. (Ray) van" To: 'Colin Perkins' Thread-Topic: [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwC5facAAAmZdiAAQ0HigAAXJdAQ Date: Thu, 20 Jan 2011 08:43:10 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:40:29 -0000 Hi, On 19 Jan 2011, at 23:27, Colin Perkins wrote: ... >> The main reason we went with an RTCP-XR report block was that we believe= d it would be less controversial to add an XR block type than a completely = new RTCP packet type. In RFC5968 (which I believe you authored) it says tha= t the only valid reason to create a new RTCP packet type is if the required= functionality would not be appropriate as part of one of the current packe= t types (such as XR-). In the description of the XR- packet type in the sam= e document it says the XR blocks are appropriate for "for transporting new = metrics regarding media transmission or reception quality". So I think we s= hould have a discussion about whether the IDMS block fits this description.=20 >As I said, I think using RTCP XR is appropriate for receivers to provide f= eedback to the sender on receipt and presentation times for RTP packets.=20 >I don't think an RTCP XR block is appropriate to, as your draft phrases it= , "indicate synchronization settings instructions to a receiver". That seem= s to be providing guidance on when to playout the media, rather than convey= ing a metric on how well media playout is doing. This message from MSAS to = SC would be better expressed as a new RTCP packet type, I think. I agree that this sentence is somewhat misleading and leads one to believe = that this IDMS message is some sort of control/command protocol. That is no= t our goal. The message is used to inform receivers of how media playout is= doing on their slowest peer receiver. They can then use this information t= o possibly synchronize their own playout to this peer, although this is not= required. In practice, a receiver would probably only synchronize when the= playout difference crosses some threshold (e.g. for Social TV >150ms), to = not cause unnecessary stutters for the user. Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From thomas.belling@nsn.com Thu Jan 20 06:48:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84103A7115 for ; Thu, 20 Jan 2011 06:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=1.757, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foHs8sFUXoJk for ; Thu, 20 Jan 2011 06:48:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 85CEC3A6F6D for ; Thu, 20 Jan 2011 06:48:17 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p0KEowen004261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 15:50:58 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p0KEouwW025116; Thu, 20 Jan 2011 15:50:58 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 15:50:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-CR-Hashedpuzzle: Adzu BkTX C/rn FHiO Fp0Z GTYb HM0y ITi+ IsLm LEbc NdC1 PrOx RAgt RV5u UEpl Un8c; 2; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBtAGEAZwBuAHUAcwAuAHcAZQBzAHQAZQByAGwAdQBuAGQAQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA=; Sosha1_v1; 7; {9DD8C82B-47F6-4FDF-9760-CD25E86730F8}; dABoAG8AbQBhAHMALgBiAGUAbABsAGkAbgBnAEAAbgBzAG4ALgBjAG8AbQA=; Thu, 20 Jan 2011 14:50:47 GMT; UgBFADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AYQB2AHQALQBlAGMAbgAtAGYAbwByAC0AcgB0AHAAOgAgAEkAcwAgAEEAVgBQAEYAIAByAGUAcQB1AGkAcgBlAGQAIABmAG8AcgAgAGwAZQBhAHAALQBvAGYALQBmAGEAaQB0AGgAIABpAG4AaQB0AGkAYQBsAGkAcwBhAHQAaQBvAG4APwA= X-CR-Puzzleid: {9DD8C82B-47F6-4FDF-9760-CD25E86730F8} Content-class: urn:content-classes:message Date: Thu, 20 Jan 2011 15:50:47 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A7220333449D@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D3719F9.8000004@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? Thread-Index: Acu3+ycqsO83gV6vTTq9jAsBmqo+GgAsNdqg References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> <4D3719F9.8000004@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" X-OriginalArrivalTime: 20 Jan 2011 14:50:53.0062 (UTC) FILETIME=[6F8FFA60:01CBB8B1] Cc: IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 14:48:18 -0000 Dear Magnus, below > >=20 > > You suggested to negotiate a higher RTCP transmission rate as aremedy.In > > my understanding this would work both with AVP and AVPF usingSDP RTCP > > bandwidth modifiers. > > Well, it is the minium interval value that needs to be set to something > else than 5 seconds to get better results. For AVP that is allowed but > no signalling exist. Using the formula for calculating the min interval > according to RFC 3550 could work. >=20 > o The RECOMMENDED value for the reduced minimum in seconds is 360 > divided by the session bandwidth in kilobits/second. This minimum > is smaller than 5 seconds for bandwidths greater than 72 kb/s. > > AVPF allows one to set trr-int to a reasonable interval through > signalling for this case. And that is without any extreme setting of the > RTCP bandwidth. The whole point with AVPF here is to use the signalling > and improved rules to provide better RTCP functionality without > increasing the bandwidth. I believe the "calculated interval" is important rather than the "minimum interval" which is only a lower bound for the calculated interval. The calculated Interval depends on number of participants and available bandwidth. Remember that there are no specific triggers to send RTCP reports earlier. > >=20 > > As said, I alsostilldoubt that you would have any benefit from AVPFfor > > thatinitialisationmethod.ButevenIonly failto understand the advantages > > you had in mind (do youassume some particular receiverbehaviourdescribed > > nowhere up to now?), I doubt this would beworth the extra complexity, > > only to improve the handling of a very unlikely error. Again, in > > annetworkwherethere is a real risk that ECN-marked packets are blocked, > > other initialisation methods are preferable anyway. > >=20 > > Even with leap-of-faith you need to send the ECN indications for sender > driven, thus you need it. For receiver driven reactions, you still need > to send the control message to the sender. If that is using RTCP, it > still needs AVPF for allowing for earliest possible transmission. >=20 > The only cases where I will agree that you don't need AVPF are: >=20 > - Codec mode adaptation for AMR This case may not be the exception but the rule in 3GPP, where it is agreed to send CMR in response to ECT bits for speech. AMR is used for speech. And speech is still more frequent than video. Thus this case deserves special attention. > But, in 3GPP I would argue that AVPF is still needed in this case as you > have an APP packet for adjusting redundancy or number of frames in the > packet. This will not be used in response to ECT markings being received according to agreements in 3GPP SA4. In my understanding the rational is that ECT markings in 3GPP will be set in the radio network where IP header compression is in place. Here, changing the codec mode reduces the bandwidth considerably without extra delay. > I will look into the formulations here. If there is a large number of > things that are needed to be fulfilled before AVPF is not requried, it > is simpler to require it always. But, I will look into that we have > accurate statements in the draft. Thanks a lot. My current proposal is to link it to the ECN RTCP FB message. Obviously initialisation methods using the ECN FB message then will also require AVPF, and this can be stated in addition. In a sense particular application specific feedback is out-of-scope of the draft but a NOTE stating that many application specific feedback methods also require AVPF may be helpful. Regards, Thomas From magnus.westerlund@ericsson.com Thu Jan 20 08:07:09 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E533A7132 for ; Thu, 20 Jan 2011 08:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.193 X-Spam-Level: X-Spam-Status: No, score=-106.193 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRszjPuGgCNB for ; Thu, 20 Jan 2011 08:07:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 491233A70F5 for ; Thu, 20 Jan 2011 08:07:08 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-2b-4d385e4efb27 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7C.20.23694.E4E583D4; Thu, 20 Jan 2011 17:09:50 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Thu, 20 Jan 2011 17:09:50 +0100 Message-ID: <4D385E4E.6060101@ericsson.com> Date: Thu, 20 Jan 2011 17:09:50 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203050629@DEMUEXC014.nsn-intra.net> <4D3719F9.8000004@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A7220333449D@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A7220333449D@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp: Is AVPF required for leap-of-faith initialisation? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:07:10 -0000 Hi Thomas, Belling, Thomas (NSN - DE/Munich) skrev 2011-01-20 15:50: >> >> Well, it is the minium interval value that needs to be set to > something >> else than 5 seconds to get better results. For AVP that is allowed but >> no signalling exist. Using the formula for calculating the min > interval >> according to RFC 3550 could work. >> >> o The RECOMMENDED value for the reduced minimum in seconds is 360 >> divided by the session bandwidth in kilobits/second. This > minimum >> is smaller than 5 seconds for bandwidths greater than 72 kb/s. >> >> AVPF allows one to set trr-int to a reasonable interval through >> signalling for this case. And that is without any extreme setting of > the >> RTCP bandwidth. The whole point with AVPF here is to use the > signalling >> and improved rules to provide better RTCP functionality without >> increasing the bandwidth. > > I believe the "calculated interval" is important rather than the > "minimum interval" which is only a lower bound for the calculated > interval. The calculated Interval depends on number of participants and > available bandwidth. > Remember that there are no specific triggers to send RTCP reports > earlier. I wouldn't agree for most sensible settings of the RTCP bandwidth if you are using AVP, then the minimal interval will be the limiting factor unless there is a larger multi party group. For example with a session bandwidht of 24 kbps then 5% bandwidth are 1200 bps. In a two party session, i.e. 2 SSRCs, then the deterministic calculated RTCP interval becomes with the following assumptions: 200 bytes RTCP packets and both SSRCs send data. Which means they share the full RTCP bandwidth, independent of how RS and RR is set. n=2 C=200*8/1200 Td = max(Tmin, n*C = 2,667) If Tmin is the default value of 5 seconds, then we can easily see that for a point to point session we either needs twice as many session members, double the size of the RTCP packet, or half the RTCP bandwidth before Tmin isn't the limiting factor. If one has a higher RTCP bandwidth without increasing the number of session participants, the calculated Td is reduced correspondingly with the RTCP bandwidth increase. The whole point of this is that in MTSI type of use cases it will not be calculated transmission interval that will be the limiting factor, it is the default minimal interval of 5 seconds. > >>> >>> As said, I alsostilldoubt that you would have any benefit from > AVPFfor >>> thatinitialisationmethod.ButevenIonly failto understand the > advantages >>> you had in mind (do youassume some particular > receiverbehaviourdescribed >>> nowhere up to now?), I doubt this would beworth the extra > complexity, >>> only to improve the handling of a very unlikely error. Again, in >>> annetworkwherethere is a real risk that ECN-marked packets are > blocked, >>> other initialisation methods are preferable anyway. >>> >> >> Even with leap-of-faith you need to send the ECN indications for > sender >> driven, thus you need it. For receiver driven reactions, you still > need >> to send the control message to the sender. If that is using RTCP, it >> still needs AVPF for allowing for earliest possible transmission. >> >> The only cases where I will agree that you don't need AVPF are: >> >> - Codec mode adaptation for AMR > > This case may not be the exception but the rule in 3GPP, where it is > agreed to send CMR in response to ECT bits for speech. AMR is used for > speech. And speech is still more frequent than video. Thus this case > deserves special attention. > As I said before, this appears to be a real corner case: 1. It requires one to use Leap-of-faith init, anything else and the init requires AVPF to work well. 2. Any sender based scheme congestion control algorithm needs rapid report of CE marks, so it needs to be receiver based. 3. It needs to have a back channel that isn't RTCP based. I don't know if anything outside of AMR, AMR-WB, EVRC and SMV has such mechanism. I guess there are some points in that under the above restrictions it isn't motivated by this proposal to require AVPF. We might still do it because it is simpler to do and it is such a corner case. >> But, in 3GPP I would argue that AVPF is still needed in this case as > you >> have an APP packet for adjusting redundancy or number of frames in the >> packet. > > This will not be used in response to ECT markings being received > according to agreements in 3GPP SA4. > In my understanding the rational is that ECT markings in 3GPP will be > set in the radio network where IP header compression is in place. Here, > changing the codec mode reduces the bandwidth considerably without extra > delay. > So, what is written in Section 7.3.2 in 26.114 version 9.4.0 at the end of this section is not what is going to be used? So are you backtracking that Rel 9 decision in Rel 10? "For speech, RTCP APP packets are used for adaptation (see clause 10.2)." Don't that include redundancy signalling also? Which do matter independently if one uses cellular network with header compression or not. >> I will look into the formulations here. If there is a large number of >> things that are needed to be fulfilled before AVPF is not requried, it >> is simpler to require it always. But, I will look into that we have >> accurate statements in the draft. > > Thanks a lot. > My current proposal is to link it to the ECN RTCP FB message. Obviously > initialisation methods using the ECN FB message then will also require > AVPF, and this can be stated in addition. > In a sense particular application specific feedback is out-of-scope of > the draft but a NOTE stating that many application specific feedback > methods also require AVPF may be helpful. I will consider this in the editing pass and come back on this change proposal. Maybe we should spare AVT WG from the 3GPP SA4 discussion on this other topic, related to if MTSI can use the above restrictions and if that makes sense. I will however state my view here once: 1. MTSI uses RTCP for its bit-rate adaptation feedback, thus needs AVPF even for speech only sessions. 2. AVPF has low cost and provides benefits for any RTCP handling. The fact that one has explicit configuration of TRR-Int and the possibility to use early mode to send important events is a great benefit. It produces more rapid feedback when needed, and can lower the RTCP bit-rate actually consumed. 3. Considering that you SA4 already has agreed to use AVPF in Rel9 it seems strange to remove it in some cases in Rel 10. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dworley@avaya.com Mon Jan 24 13:13:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39DB33A6B2D for ; Mon, 24 Jan 2011 13:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c8BhHnwRcwL for ; Mon, 24 Jan 2011 13:13:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1B6D83A6AF5 for ; Mon, 24 Jan 2011 13:13:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN56PU3GmAcF/2dsb2JhbACkbHOiaAKYdoMLgkUEhHCJcA X-IronPort-AV: E=Sophos;i="4.60,371,1291611600"; d="scan'208";a="261233318" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Jan 2011 16:16:11 -0500 X-IronPort-AV: E=Sophos;i="4.60,371,1291611600"; d="scan'208";a="574347922" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2011 16:16:10 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.215]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 24 Jan 2011 16:16:10 -0500 From: "Worley, Dale R (Dale)" To: "avt@ietf.org" , Robert Sparks Date: Mon, 24 Jan 2011 16:14:41 -0500 Thread-Topic: Errata report on erratum 2673 on RFC 4695 ("RTP Payload Format for MIDI") and erratum 2119 on RFC 5506 ("Support for Reduced-Size RTCP: Opportunities and Consequences") Thread-Index: AQHLvAvrFWOlJ3BD5EOCxzJrZXb9QA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVT] Errata report on erratum 2673 on RFC 4695 ("RTP Payload Format for MIDI") and erratum 2119 on RFC 5506 ("Support for Reduced-Size RTCP: Opportunities and Consequences") X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:13:17 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC4695, "RTP Payload Format for MIDI" Source of RFC: avt (rai) Errata ID: 2673 Status: Reported Type: Technical Reported By: John Lazzaro Date Reported: 2010-12-18 Section 3 says: If the LEN header field is nonzero, the MIDI list has the structure shown in Figure 3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time 0 (1-4 octets long, or 0 octets if Z =3D 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command 0 (1 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time 1 (1-4 octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command 1 (1 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time N (1-4 octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command N (0 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 -- MIDI list structure It should say: If the LEN header field is nonzero, the MIDI list has the structure shown in Figure 3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time 0 (1-4 octets long, or 0 octets if Z =3D 0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command 0 (1 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time 1 (1-4 octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command 1 (1 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Time N (1-4 octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIDI Command N (0 or more octets long) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 -- MIDI list structure Notes: The sole change here is in the parenthesized text that follows the "Delta Time 0" name in the first bitfield shown in Figure 3. RFC 4695 has "1-4 octets long, or 0 octets if Z =3D 1". This does not match the definition of Z in the main text. The corrected figure text is: "1-4 octets long, or 0 octets if Z =3D 0". Thankfully, all known implementations follow the main text in this regard, so this bug should not have resulted in interoperability issues. This bug has been fixed in the bis I-D intended to obsolete RFC 4695 that is currently in Last Call in AVT. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update The erratum appears to be correct, and given the submitter is an author of both RFC 4695 and draft-ietf-avt-rfc4695-bis, there is no reason to doubt that. I recommend "Hold for document update" only because a -bis I-D is in WGLC, otherwise "Publish" would be needed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RFC5506, "Support for Reduced-Size RTCP: Opportunities and Consequences" Source of RFC: avt (rai) Errata ID: 2119 Status: Reported Type: Editorial Reported By: Alfred Hoenes Date Reported: 2010-04-05 Section 3.4.5 says: | o Compression of RTCP: No IETF-defined header compression method compress RTCP; however, if such methods are developed in the | future, these methods must take Reduced-Size RTCP in account. It should say: | o Compression of RTCP: No IETF-defined header compression methods compress RTCP; however, if such methods are developed in the | future, these methods must take Reduced-Size RTCP into account. Notes: Rationale: singular/plural mismatch; language improvement. ---------------------------------------------------------------------- Recommended status: (correct) Hold for document update Or one might correct the text to "No IETF-defined header compression >>method compresses<< RTCP...". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dale From Internet-Drafts@ietf.org Mon Jan 24 15:15:02 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F923A699F; Mon, 24 Jan 2011 15:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwPMpp+4embn; Mon, 24 Jan 2011 15:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7FF3A697B; Mon, 24 Jan 2011 15:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110124231501.29813.89411.idtracker@localhost> Date: Mon, 24 Jan 2011 15:15:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rfc4695-bis-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-rfc4695-bis-10.txt Pages : 171 Date : 2011-01-24 This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc4695-bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rfc4695-bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-24150821.I-D@ietf.org> --NextPart-- From john.lazzaro@gmail.com Mon Jan 24 15:21:56 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E1E3A6B1F for ; Mon, 24 Jan 2011 15:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccYaN+DdLawx for ; Mon, 24 Jan 2011 15:21:51 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 630AB3A6B3E for ; Mon, 24 Jan 2011 15:21:50 -0800 (PST) Received: by bwz12 with SMTP id 12so4534428bwz.31 for ; Mon, 24 Jan 2011 15:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=lMXxQd87OEeAl+lrv6D1W7SavTeKEYiiQDXp7ww0/aw=; b=Y1ILN80EO4Blrgn+Yp+j52/lng1Eefv+gyMoiGeJv4gq6W+EwFgCYn9P29TuFbtx8Y ekMn1dV1xYpgNWUVk1O8lV6N9vjKLZmjvL5AA0yTnwIrbZGbvUotFu0K9a5jiT+7QGQ1 Od1Hun/A6XLsuOdLtEvEfh5XEpBT6nh+Whhu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PtyQQFU2fUwwXIL8qzxEbCnBm4tE+eai9kvRRCJiKyWXHkoHstOIez3/gfKXZrB9+4 i7VNCnDE6xjh6BA8LHGtmb7MO7jxNJArZeeGSS4IiDuX7IMRN6DVHUPimj90jF+twSF5 hmfCcNa4y5cuqQTrVjTdwVa3nQkkzZgvoCVPg= MIME-Version: 1.0 Received: by 10.204.76.18 with SMTP id a18mr4373068bkk.9.1295911485241; Mon, 24 Jan 2011 15:24:45 -0800 (PST) Received: by 10.204.60.3 with HTTP; Mon, 24 Jan 2011 15:24:45 -0800 (PST) In-Reply-To: <20110124231501.29813.89411.idtracker@localhost> References: <20110124231501.29813.89411.idtracker@localhost> Date: Mon, 24 Jan 2011 15:24:45 -0800 Message-ID: From: John Lazzaro To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVT] I-D Action:draft-ietf-avt-rfc4695-bis-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:21:56 -0000 On Mon, Jan 24, 2011 at 3:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RTP Payload Format for MIDI > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Lazzaro, J. =A0Wawrzynek > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-avt-rfc4695-bis-10.tx= t This fixes some IDnits, per Roni's request. --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From Internet-Drafts@ietf.org Tue Jan 25 13:30:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D12E3A68C6; Tue, 25 Jan 2011 13:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnfokMEJtUMY; Tue, 25 Jan 2011 13:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A103A6852; Tue, 25 Jan 2011 13:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110125213001.11449.8150.idtracker@localhost> Date: Tue, 25 Jan 2011 13:30:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-rtp-cnames-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 21:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author(s) : A. Begen, et al. Filename : draft-ietf-avt-rtp-cnames-05.txt Pages : 10 Date : 2011-01-25 The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-cnames-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-cnames-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-25132008.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Jan 25 15:22:12 2011 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E18D83A68E0; Tue, 25 Jan 2011 15:22:12 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110125232212.E18D83A68E0@core3.amsl.com> Date: Tue, 25 Jan 2011 15:22:12 -0800 (PST) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: [AVT] WG Action: Audio/Video Transport Core Maintenence (AVTCORE) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 23:22:13 -0000 A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Audio/Video Transport Core Maintenence (AVTCORE) --------------------------------------------------- Current Status: Active Working Group Chairs: * Roni Even * Magnus Westerlund Real-time Applications and Infrastructure Area Directors: * Gonzalo Camarillo * Robert Sparks Real-time Applications and Infrastructure Area Advisor: * Robert Sparks Secretary: * Tom Taylor Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. The AVTCORE working group is chartered to maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Done Submit Guideline for Choosing RTCP CNAME as Proposed Standard Done Submit use of AES-192 and AES-256 in Secure RTP for Proposed Standard Jan 2011 Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Feb 2011 Submit Monitoring Architecture for RTP for Informational Feb 2011 Submit Guidelines for the use of Variable Bit Rate Audio with Secure RTP as Informational (or possibly BCP) Apr 2011 Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2011 Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 Submit RTCP indication for retransmission suppression as Proposed Standard Sep 2011 Submit Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard Dec 2011 Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard From Even.roni@huawei.com Wed Jan 26 00:39:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370D83A690E for ; Wed, 26 Jan 2011 00:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR9ORC4zMZwM for ; Wed, 26 Jan 2011 00:39:12 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 46D0F3A6838 for ; Wed, 26 Jan 2011 00:39:12 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM0064VG61MQ@szxga05-in.huawei.com> for avt@ietf.org; Wed, 26 Jan 2011 16:42:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00J27G6091@szxga05-in.huawei.com> for avt@ietf.org; Wed, 26 Jan 2011 16:42:01 +0800 (CST) Received: from windows8d787f9 (bzq-109-65-0-224.red.bezeqint.net [109.65.0.224]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFM00L37G5U6I@szxml02-in.huawei.com>; Wed, 26 Jan 2011 16:42:00 +0800 (CST) Date: Wed, 26 Jan 2011 10:37:59 +0200 From: Roni Even To: avt@ietf.org Message-id: <068101cbbd34$5a8efb20$0facf160$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acu85051xJxOH2XpSEW4jHqd/jS6nAATOULw Subject: [AVT] FW: WG Action: Audio/Video Transport Payloads (PAYLOAD) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:39:13 -0000 Hi, Note the new payload WG. If you are interested in this work please subscribe to the mailing list Roni Even -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Wednesday, January 26, 2011 1:24 AM To: IETF Announcement list Cc: Even.roni@huawei.com; abegen@cisco.com; payload@ietf.org Subject: WG Action: Audio/Video Transport Payloads (PAYLOAD) A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Audio/Video Transport Payloads (PAYLOAD) --------------------------------------------------- Current Status: Active Working Group Chairs: * Roni Even * Ali Begen Real-time Applications and Infrastructure Area Director(s): * Gonzalo Camarillo * Robert Sparks Real-time Applications and Infrastructure Area Advisor: * Robert Sparks Mailing Lists: General Discussion: payload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/payload Archive: http://www.ietf.org/mail-archive/web/payload/index.html Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format" (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Jan 2011 Submit RTP Payload Format for MIDI for Proposed Standard Feb 2011 Submit How to Write an RTP Payload Format for Informational Feb 2011 Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Mar 2011 Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Mar 2011 Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Mar 2011 Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Apr 2011 Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard Apr 2011 Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Apr 2011 Submit RTP Payload Format for the iSAC codec for Proposed Standard Apr 2011 Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Jun 2011 Submit RTP Payload Format for MVC Video for Proposed Standard From Even.roni@huawei.com Wed Jan 26 00:40:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4173A690E for ; Wed, 26 Jan 2011 00:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.495 X-Spam-Level: X-Spam-Status: No, score=-101.495 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HmTCGf28cHe for ; Wed, 26 Jan 2011 00:40:12 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A3A503A6838 for ; Wed, 26 Jan 2011 00:40:12 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00EZJG7QTJ@szxga05-in.huawei.com> for avt@ietf.org; Wed, 26 Jan 2011 16:43:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFM00JDEG7PTL@szxga05-in.huawei.com> for avt@ietf.org; Wed, 26 Jan 2011 16:43:02 +0800 (CST) Received: from windows8d787f9 (bzq-109-65-0-224.red.bezeqint.net [109.65.0.224]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFM00L5EG7J6I@szxml02-in.huawei.com>; Wed, 26 Jan 2011 16:43:01 +0800 (CST) Date: Wed, 26 Jan 2011 10:39:01 +0200 From: Roni Even To: avt@ietf.org Message-id: <068201cbbd34$7eaa9a50$7bffcef0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acu852uqvAGU3suARxKZkMreV48A5wATPEVg Cc: 'peter musgrave' Subject: [AVT] FW: WG Action: Metric Blocks for use with RTCP's Extended Report Framework (XRBLOCK) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:40:13 -0000 Hi, Please note the new XRblock WG. If you have interest in this work please join the mailing list Roni Even -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: Wednesday, January 26, 2011 1:24 AM To: IETF Announcement list Cc: Even.roni@huawei.com; Peter.Musgrave@magorcorp.com; xrblock@ietf.org Subject: WG Action: Metric Blocks for use with RTCP's Extended Report Framework (XRBLOCK) A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Metric Blocks for use with RTCP's Extended Report Framework (XRBLOCK) --------------------------------------------------- Current Status: Active Working Group Chairs: * Roni Even * Peter Musgrave Real-time Applications and Infrastructure Area Director(s): * Gonzalo Camarillo * Robert Sparks Real-time Applications and Infrastructure Area Advisor: * Gonzalo Camarillo Mailing Lists: General Discussion: xrblock@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xrblock Archive: http://www.ietf.org/mail-archive/web/xrblock/index.html Description of Working Group: RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new metrics. The group will follow the guidelines established in RFC5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the AVTCORE working group. The group will consider the guidelines for performance metric development currently being discussed in the PMOL working group. Goals and Milestones: Mar 2011 Submit RTCP XR Report Block for Measurement Identity Mar 2011 Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting Mar 2011 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Jun 2011 Submit RTCP XR Report Block for Concealed Seconds metric Reporting Jun 2011 Submit RTCP XR Report Block for Delay metric Reporting Jun 2011 Submit RTCP XR Report Block for Discard metric Reporting Sep 2011 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Sep 2011 Submit RTCP XR Report Block for Loss Concealment metric Reporting Sep 2011 Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting Dec 2011 Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets Dec 2011 Submit RTCP XR Report Block for QoE Metrics Reporting From keith.drage@alcatel-lucent.com Wed Jan 26 02:11:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5AB3A697E for ; Wed, 26 Jan 2011 02:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.613 X-Spam-Level: X-Spam-Status: No, score=-105.613 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fiKLrXi-zBY for ; Wed, 26 Jan 2011 02:11:10 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 948573A6989 for ; Wed, 26 Jan 2011 02:11:06 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0QABq2a015490 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 11:14:04 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 26 Jan 2011 11:13:54 +0100 From: "DRAGE, Keith (Keith)" To: "avt@ietf.org" Date: Wed, 26 Jan 2011 11:13:52 +0100 Thread-Topic: WG Action: Audio/Video Transport Extensions (AVTEXT) Thread-Index: Acu85zpEuiQ7t/V2QcOYKt2VrT2r8gAWjefA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [AVT] FW: WG Action: Audio/Video Transport Extensions (AVTEXT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 10:11:17 -0000 Please note the new WG. This is one of four created out of the work of the = AVT WG. Noone has been automatically transferred to the new list so please subscrib= e if you are interested in this continuing work. Regards Keith -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 Sent: 25 January 2011 23:23 To: IETF Announcement list Cc: DRAGE, Keith (Keith); magnus.westerlund@ericsson.com; avtext@ietf.org Subject: WG Action: Audio/Video Transport Extensions (AVTEXT)=20 A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Audio/Video Transport Extensions (AVTEXT) --------------------------------------------------- Current Status: Active Working Group Chairs: * Keith Drage * Magnus Westerlund Real-time Applications and Infrastructure Area Director(s): * Gonzalo Camarillo * Robert Sparks Real-time Applications and Infrastructure Area Advisor: * Gonzalo Camarillo Mailing Lists: General Discussion: avtext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avtext Archive: http://www.ietf.org/mail-archive/web/avtext/index.html Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group. The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Jun 2011 Submit Considerations for RAMS Scenarios for Informational Oct 2011 Submit RTP Header extension for mixer to client audio level=20 indication as Proposed Standard Oct 2011 Submit RTP Header extension for client to mixer audio level=20 indication as proposed standard Dec 2011 Submit Support for multiple clock rates in an RTP session for=20 Proposed Standard Dec 2011 Submit SRTP Store-and-Forward Use Cases and Requirements for=20 Informational Dec 2011 Submit Use of the Secure Real-time Transport Protocol (SRTP)=20 in Store-and-Forward Applications for Proposed Standard From magnus.westerlund@ericsson.com Wed Jan 26 07:31:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823333A67F0 for ; Wed, 26 Jan 2011 07:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jHLStgjmq-n for ; Wed, 26 Jan 2011 07:31:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3489E3A67A5 for ; Wed, 26 Jan 2011 07:31:45 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-46-4d403f158049 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FD.DD.23694.51F304D4; Wed, 26 Jan 2011 16:34:45 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 26 Jan 2011 16:34:45 +0100 Message-ID: <4D403F15.5020002@ericsson.com> Date: Wed, 26 Jan 2011 16:34:45 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] AVT split administrative X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 15:31:47 -0000 Hi, Here is a first email about how a some of the things is intended to work going forward with the split of AVT. Usage of email lists: As this list is now AVTcore's, we intended to be strict on referring topics that doesn't belong to AVTcore to the other WG's lists. So please go subscribe to the lists for the WG that you are interested in. AVTEXT: https://www.ietf.org/mailman/listinfo/avtext PAYLOAD: https://www.ietf.org/mailman/listinfo/payload XRBLOCK: https://www.ietf.org/mailman/listinfo/xrblock Document names: Soon, we will get the existing AVT documents assigned in the database to the right WG. However, that is not 100% robust and does not allow for determining the WG from the file name. Thus we intended to get most document to change the WG name from AVT to the assigned WG as they are updated. However, this MUST NOT be done for documents that already have been publication requested. We don't want to confuse the IESG. If you are an editor and are in doubt, ask your chair. If you don't know which WG your document belongs to ask a WG chair. Prague Meeting: The WG chairs for the WGs are discussing how we will do these first meeting. More information will come. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Wed Jan 26 11:35:40 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D246E3A6917; Wed, 26 Jan 2011 11:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJtzRtd7vGsj; Wed, 26 Jan 2011 11:35:40 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3943A6882; Wed, 26 Jan 2011 11:35:39 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110126193539.28923.59371.idtracker@localhost> Date: Wed, 26 Jan 2011 11:35:39 -0800 Cc: Internet Architecture Board , avt mailing list , avt chair , RFC Editor Subject: [AVT] Protocol Action: 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' to Proposed Standard (draft-ietf-avt-rtp-cnames-05.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 19:35:41 -0000 The IESG has approved the following document: - 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' (draft-ietf-avt-rtp-cnames-05.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-cnames/ Technical Summary The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates these guidelines to allow endpoints to choose unique RTCP CNAMEs. Working Group Summary The document achieved consensus in the AVT working group. Personnel Keith Drage is the document shepherd. Robert Sparks is the responsible AD From magnus.westerlund@ericsson.com Thu Jan 27 01:26:14 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A438C28C119 for ; Thu, 27 Jan 2011 01:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.495 X-Spam-Level: X-Spam-Status: No, score=-106.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv9HKV8xcITS for ; Thu, 27 Jan 2011 01:26:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 60A2428C12F for ; Thu, 27 Jan 2011 01:26:13 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-28-4d413aebc4b3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E0.B4.13987.BEA314D4; Thu, 27 Jan 2011 10:29:15 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Thu, 27 Jan 2011 10:29:14 +0100 Message-ID: <4D413AEB.5060104@ericsson.com> Date: Thu, 27 Jan 2011 10:29:15 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVT] Guidelines for the use of Variable Bit Rate Audio with Secure RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 09:26:14 -0000 DRAGE, Keith (Keith) skrev 2011-01-08 19:08: > (As WG co-chair) > > In support of the milestone: > > Feb 2011 Guidelines for the use of Variable Bit Rate Audio with Secure RTP as informational (or possibly BCP) > > This is a WG consensus call to adopt all (or some) of the text of: > > http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-05.txt > > to fulfil that milestone. At this stage the text does not have to be regarded perfect, the question is more "Does this text form a better basis for completing the work in the working group that some text yet to be submitted?" > > Please respond by Monday 18th January with your positions. > > While the prime intention of this call is to adopt the entire text of the author draft, if you consider that some of the text is appropriate, but that some of the text does not form a reasonable start for the work, then please indicate that text and we will make a separate call on it (and adopt the rest). There has been no comments on this call for adoption. Thus we will take draft-perkins-avt-srtp-vbr-audio as basis for the WG document. We also appoint authors of this document as editors. Editors, please submit a new version of the document as AVTcore WG document, i.e. draft-ietf-avtcore-srtp-vbr-audio Regards Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Thu Jan 27 06:30:02 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DEAC3A67EF; Thu, 27 Jan 2011 06:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtrZnCthQMTu; Thu, 27 Jan 2011 06:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62383A684E; Thu, 27 Jan 2011 06:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110127143001.9854.56871.idtracker@localhost> Date: Thu, 27 Jan 2011 06:30:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avtcore-srtp-vbr-audio-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Guidelines for the use of Variable Bit Rate Audio with Secure RTP Author(s) : C. Perkins, J. Valin Filename : draft-ietf-avtcore-srtp-vbr-audio-00.txt Pages : 7 Date : 2011-01-27 This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-vbr-audio-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-srtp-vbr-audio-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-27062847.I-D@ietf.org> --NextPart-- From keith.drage@alcatel-lucent.com Thu Jan 27 06:53:28 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2383B3A68C6; Thu, 27 Jan 2011 06:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.626 X-Spam-Level: X-Spam-Status: No, score=-105.626 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbsBjI06fSZT; Thu, 27 Jan 2011 06:53:27 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 0FCF53A68C0; Thu, 27 Jan 2011 06:53:23 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0REu3xa031355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 27 Jan 2011 15:56:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 27 Jan 2011 15:56:21 +0100 From: "DRAGE, Keith (Keith)" To: IETF AVT WG , "avtext@ietf.org" Date: Thu, 27 Jan 2011 15:56:19 +0100 Thread-Topic: Call for adoption of text for audio level milestones Thread-Index: Acu+MlsFvM0YX6CeQySkhDVDbOUeWQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [AVT] Call for adoption of text for audio level milestones X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:53:28 -0000 (As AVTEXT WG cochair) This message is copied to the AVTCORE list for those who are not yet on the= new list. AVTEXT has two milestones relating to audio levels. Oct 2011 Submit RTP Header extension for mixer to client audio level indic= ation as Proposed Standard=20 =20 Oct 2011 Submit RTP Header extension for client to mixer audio level indic= ation as proposed standard =20 We have the following author drafts providing candidate text for these mile= stones: A Real-Time Transport Protocol (RTP) Extension Header for Mixer-to-client A= udio Level Indication http://www.ietf.org/id/draft-ivov-avt-slic-04.txt A Real-Time Transport Protocol (RTP) Header Extension for Client-to-Mixer A= udio Level Indication http://tools.ietf.org/id/draft-lennox-avt-rtp-audio-level-exthdr-02.txt respectively. This is a WG consensus call to adopt the above text as baseline text for th= ese milestones. At this stage the text does not have to be regarded perfect= , the question is more "Does this text form a better basis for completing t= he work in the working group that some text yet to be submitted?" While the prime intention of this call is to adopt the entire text of the a= uthor draft, if you consider that some of the text is appropriate, but that= some of the text does not form a reasonable start for the work, then pleas= e indicate that text and we will make a separate call on it (and adopt the = rest). Please respond by Thursday 10th February 2011 with your positions.=20 ######### Please respond to the AVTEXT list only ############# Regards Keith From magnus.westerlund@ericsson.com Thu Jan 27 06:54:20 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BA33A68C0 for ; Thu, 27 Jan 2011 06:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbeF7Yu4EArS for ; Thu, 27 Jan 2011 06:54:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0A5B93A6767 for ; Thu, 27 Jan 2011 06:54:18 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-d4-4d4187d1485c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.E9.23694.1D7814D4; Thu, 27 Jan 2011 15:57:22 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Thu, 27 Jan 2011 15:57:22 +0100 Message-ID: <4D4187D1.7080607@ericsson.com> Date: Thu, 27 Jan 2011 15:57:21 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org References: <4D403F15.5020002@ericsson.com> In-Reply-To: <4D403F15.5020002@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVT] AVT split administrative X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:54:20 -0000 Hi, Additional things to consider: Submission of individual documents: The submission of an individual document will now require a bit of thinking from the authors. They should match the documents content against the different charters. And if you are in doubt about where to send a new draft, please contact any of the chairs and they will help you. Cheers Magnus Magnus Westerlund skrev 2011-01-26 16:34: > Hi, > > Here is a first email about how a some of the things is intended to work > going forward with the split of AVT. > > Usage of email lists: As this list is now AVTcore's, we intended to be > strict on referring topics that doesn't belong to AVTcore to the other > WG's lists. So please go subscribe to the lists for the WG that you are > interested in. > > AVTEXT: https://www.ietf.org/mailman/listinfo/avtext > PAYLOAD: https://www.ietf.org/mailman/listinfo/payload > XRBLOCK: https://www.ietf.org/mailman/listinfo/xrblock > > Document names: Soon, we will get the existing AVT documents assigned in > the database to the right WG. However, that is not 100% robust and does > not allow for determining the WG from the file name. Thus we intended to > get most document to change the WG name from AVT to the assigned WG as > they are updated. However, this MUST NOT be done for documents that > already have been publication requested. We don't want to confuse the IESG. > > If you are an editor and are in doubt, ask your chair. If you don't know > which WG your document belongs to ask a WG chair. > > Prague Meeting: The WG chairs for the WGs are discussing how we will do > these first meeting. More information will come. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From peter.musgrave@magorcorp.com Thu Jan 27 06:58:33 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510403A68C0; Thu, 27 Jan 2011 06:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvGC441-ukIH; Thu, 27 Jan 2011 06:58:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id BB4973A68B0; Thu, 27 Jan 2011 06:58:31 -0800 (PST) Received: by iyi42 with SMTP id 42so1709405iyi.31 for ; Thu, 27 Jan 2011 07:01:35 -0800 (PST) Received: by 10.231.35.201 with SMTP id q9mr1037756ibd.185.1296140493815; Thu, 27 Jan 2011 07:01:33 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id z4sm13929511ibg.19.2011.01.27.07.01.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 07:01:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Thu, 27 Jan 2011 10:00:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C6EB1CB-3A15-4A74-9FDE-47EF194454D7@magorcorp.com> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Cc: "avtext@ietf.org" , IETF AVT WG Subject: Re: [AVT] [avtext] Call for adoption of text for audio level milestones X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 14:58:33 -0000 This text is a good starting point.=20 Peter On 2011-01-27, at 9:56 AM, DRAGE, Keith (Keith) wrote: > (As AVTEXT WG cochair) >=20 > This message is copied to the AVTCORE list for those who are not yet = on the new list. >=20 > AVTEXT has two milestones relating to audio levels. >=20 > Oct 2011 Submit RTP Header extension for mixer to client audio level = indication as Proposed Standard=20 >=20 > Oct 2011 Submit RTP Header extension for client to mixer audio level = indication as proposed standard =20 >=20 > We have the following author drafts providing candidate text for these = milestones: >=20 > A Real-Time Transport Protocol (RTP) Extension Header for = Mixer-to-client Audio Level Indication > http://www.ietf.org/id/draft-ivov-avt-slic-04.txt >=20 > A Real-Time Transport Protocol (RTP) Header Extension for = Client-to-Mixer Audio Level Indication > = http://tools.ietf.org/id/draft-lennox-avt-rtp-audio-level-exthdr-02.txt >=20 > respectively. >=20 > This is a WG consensus call to adopt the above text as baseline text = for these milestones. At this stage the text does not have to be = regarded perfect, the question is more "Does this text form a better = basis for completing the work in the working group that some text yet to = be submitted?" >=20 > While the prime intention of this call is to adopt the entire text of = the author draft, if you consider that some of the text is appropriate, = but that some of the text does not form a reasonable start for the work, = then please indicate that text and we will make a separate call on it = (and adopt the rest). >=20 > Please respond by Thursday 10th February 2011 with your positions.=20 >=20 > ######### Please respond to the AVTEXT list only ############# >=20 > Regards >=20 > Keith >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From Internet-Drafts@ietf.org Thu Jan 27 11:30:04 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBD528C16C; Thu, 27 Jan 2011 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5vMHP4wZP7E; Thu, 27 Jan 2011 11:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F160C28C160; Thu, 27 Jan 2011 11:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110127193001.9339.36230.idtracker@localhost> Date: Thu, 27 Jan 2011 11:30:01 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avt-srtp-aes-gcm-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 19:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) Author(s) : D. McGrew Filename : draft-ietf-avt-srtp-aes-gcm-01.txt Pages : 15 Date : 2011-01-27 This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-aes-gcm-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-srtp-aes-gcm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-27111851.I-D@ietf.org> --NextPart-- From ray.vanbrandenburg@tno.nl Fri Jan 28 03:00:14 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177C03A6784; Fri, 28 Jan 2011 03:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+PQvl-CW2wO; Fri, 28 Jan 2011 03:00:13 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id 850BC3A635F; Fri, 28 Jan 2011 03:00:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,391,1291590000"; d="scan'208";a="11302653" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 28 Jan 2011 12:03:14 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0270.001; Fri, 28 Jan 2011 12:03:14 +0100 From: "Brandenburg, R. (Ray) van" To: "DRAGE, Keith (Keith)" Thread-Topic: [avtext] Call for adoption of text for audio level milestones Thread-Index: Acu+MlsFvM0YX6CeQySkhDVDbOUeWf//8ImA//6fc+A= Date: Fri, 28 Jan 2011 11:03:14 +0000 Message-ID: References: <1C6EB1CB-3A15-4A74-9FDE-47EF194454D7@magorcorp.com> In-Reply-To: <1C6EB1CB-3A15-4A74-9FDE-47EF194454D7@magorcorp.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "avtext@ietf.org" , IETF AVT WG Subject: Re: [AVT] [avtext] Call for adoption of text for audio level milestones X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 11:00:14 -0000 I agree.=20 Ray van Brandenburg=20 -----Original Message----- From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On Behalf Of= Peter Musgrave Sent: donderdag 27 januari 2011 16:01 To: DRAGE, Keith (Keith) Cc: avtext@ietf.org; IETF AVT WG Subject: Re: [avtext] Call for adoption of text for audio level milestones This text is a good starting point.=20 Peter On 2011-01-27, at 9:56 AM, DRAGE, Keith (Keith) wrote: > (As AVTEXT WG cochair) >=20 > This message is copied to the AVTCORE list for those who are not yet on t= he new list. >=20 > AVTEXT has two milestones relating to audio levels. >=20 > Oct 2011 Submit RTP Header extension for mixer to client audio level=20 > indication as Proposed Standard >=20 > Oct 2011 Submit RTP Header extension for client to mixer audio level=20 > indication as proposed standard >=20 > We have the following author drafts providing candidate text for these mi= lestones: >=20 > A Real-Time Transport Protocol (RTP) Extension Header for=20 > Mixer-to-client Audio Level Indication=20 > http://www.ietf.org/id/draft-ivov-avt-slic-04.txt >=20 > A Real-Time Transport Protocol (RTP) Header Extension for=20 > Client-to-Mixer Audio Level Indication=20 > http://tools.ietf.org/id/draft-lennox-avt-rtp-audio-level-exthdr-02.tx > t >=20 > respectively. >=20 > This is a WG consensus call to adopt the above text as baseline text for = these milestones. At this stage the text does not have to be regarded perfe= ct, the question is more "Does this text form a better basis for completing= the work in the working group that some text yet to be submitted?" >=20 > While the prime intention of this call is to adopt the entire text of the= author draft, if you consider that some of the text is appropriate, but th= at some of the text does not form a reasonable start for the work, then ple= ase indicate that text and we will make a separate call on it (and adopt th= e rest). >=20 > Please respond by Thursday 10th February 2011 with your positions.=20 >=20 > ######### Please respond to the AVTEXT list only ############# >=20 > Regards >=20 > Keith >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From Internet-Drafts@ietf.org Fri Jan 28 04:45:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358EA3A67B1; Fri, 28 Jan 2011 04:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkRTbcrJVN1f; Fri, 28 Jan 2011 04:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C143A6828; Fri, 28 Jan 2011 04:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128124502.30682.92900.idtracker@localhost> Date: Fri, 28 Jan 2011 04:45:02 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avtcore-ecn-for-rtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 12:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : M. Westerlund, et al. Filename : draft-ietf-avtcore-ecn-for-rtp-00.txt Pages : 52 Date : 2011-01-28 This document specifies how explicit congestion notification (ECN) can be used with RTP/UDP flows that use RTCP as feedback mechanism. It defines one RTCP XR extension for ECN summary, a RTCP transport feedback format for timely reporting of congestion events, and an STUN extension used in the optional initilization method using ICE. Signalling and procedures for negotiation of capabilities and initilization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-ecn-for-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28044400.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Fri Jan 28 06:09:06 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5473A6832 for ; Fri, 28 Jan 2011 06:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbspmCQBYrj2 for ; Fri, 28 Jan 2011 06:09:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 8E50B3A65A6 for ; Fri, 28 Jan 2011 06:09:05 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-37-4d42ceba477f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.5C.13987.ABEC24D4; Fri, 28 Jan 2011 15:12:11 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Fri, 28 Jan 2011 15:12:09 +0100 Message-ID: <4D42CEB8.1090806@ericsson.com> Date: Fri, 28 Jan 2011 15:12:08 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF AVT WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 14:09:06 -0000 WG, This is a call for adopting "RTCP Extension for Feedback Suppression Indication" as the starting point for meeting our milestone. The draft is available here: https://datatracker.ietf.org/doc/draft-wu-avt-retransmission-supression-rtp/ The milestone: May 2011 Submit RTCP indication for retransmission suppression as Proposed Standard Please provide any inut by Friday the 11th of February. Regards Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Fri Jan 28 08:00:05 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC633A68D1; Fri, 28 Jan 2011 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF2+USK9Bkpj; Fri, 28 Jan 2011 08:00:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CB2B3A68CB; Fri, 28 Jan 2011 08:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128160002.25435.40196.idtracker@localhost> Date: Fri, 28 Jan 2011 08:00:02 -0800 Cc: avt@ietf.org Subject: [AVT] I-D Action:draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Port Mapping Between Unicast and Multicast RTP Sessions Author(s) : A. Begen, et al. Filename : draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt Pages : 36 Date : 2011-01-28 This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28075450.I-D@ietf.org> --NextPart-- From abegen@cisco.com Fri Jan 28 08:02:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7001B3A68CC for ; Fri, 28 Jan 2011 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqYj+Xwpv3Ax for ; Fri, 28 Jan 2011 08:02:13 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 83E1B3A689D for ; Fri, 28 Jan 2011 08:02:13 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAHJ4Qk2rR7Hu/2dsb2JhbACEFJIOP40zbHOgK4pjkGeBI4M4dASFGIpZ Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 28 Jan 2011 16:05:17 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0SG5HRc021573 for ; Fri, 28 Jan 2011 16:05:17 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 08:05:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 28 Jan 2011 08:05:07 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E2D19B4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20110128155451.03FCA3A6860@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 Thread-Index: Acu/BCaaYQYhK3XqSNC1bhmFi2duVgAAECpg References: <20110128155451.03FCA3A6860@core3.amsl.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 28 Jan 2011 16:05:17.0393 (UTC) FILETIME=[27D0D410:01CBBF05] Subject: [AVT] FW: New Version Notification for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 16:02:17 -0000 Rm9sbG93aW5nIHRoZSB3Z2xjLCB3ZSByZXZpc2VkIHRoZSB0b2tlbiBkcmFmdCAoYW5kIHJlbmFt ZWQgaXQgYXMgd2VsbCkuIEhlcmUgaXMgdGhlIG5ldyBzcGVjOg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLXBvcnRzLWZvci11Y2FzdC1tY2FzdC1y dHAvDQoNCkZvciBkaWZmLCBwbGVhc2UgdXNlOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMT1odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtYXZ0LXBvcnRzLWZvci11 Y2FzdC1tY2FzdC1ydHAtMTEudHh0JnVybDI9aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLWF2dGNvcmUtcG9ydHMtZm9yLXVjYXN0LW1jYXN0LXJ0cC0wMC50eHQNCg0KV2UgaG9wZSB0 aGlzIGFkZHJlc3NlZCBhbGwgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZhciBhbmQgd2UgYXJl IHJlYWR5IHRvIHNoaXAgdGhpcy4NCg0KQ2hlZXJzLA0KLWFjYmVnZW4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlk c3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjgsIDIwMTEgMTA6 NTUgQU0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCkNjOiBEYW4gV2luZyAoZHdpbmcpOyBU b20uVmFuX0NhZW5lZ2VtQGFsY2F0ZWwtbHVjZW50LmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWF2dGNvcmUtcG9ydHMtZm9yLXVjYXN0LW1jYXN0 LXJ0cC0wMCANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1hdnRjb3JlLXBv cnRzLWZvci11Y2FzdC1tY2FzdC1ydHAtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgQWxpIEJlZ2VuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC1pZXRmLWF2dGNvcmUtcG9ydHMtZm9yLXVjYXN0LW1jYXN0LXJ0cA0K UmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUG9ydCBNYXBwaW5nIEJldHdlZW4gVW5pY2FzdCBhbmQg TXVsdGljYXN0IFJUUCBTZXNzaW9ucw0KQ3JlYXRpb25fZGF0ZToJIDIwMTEtMDEtMjgNCldHIElE OgkJIGF2dGNvcmUNCk51bWJlcl9vZl9wYWdlczogMzYNCg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3Vt ZW50IHByZXNlbnRzIGEgcG9ydCBtYXBwaW5nIHNvbHV0aW9uIHRoYXQgYWxsb3dzIFJUUA0KcmVj ZWl2ZXJzIHRvIGNob29zZSB0aGVpciBvd24gcG9ydHMgZm9yIGFuIGF1eGlsaWFyeSB1bmljYXN0 IHNlc3Npb24NCmluIFJUUCBhcHBsaWNhdGlvbnMgdXNpbmcgYm90aCB1bmljYXN0IGFuZCBtdWx0 aWNhc3Qgc2VydmljZXMuICBUaGUNCnNvbHV0aW9uIHByb3ZpZGVzIHByb3RlY3Rpb24gYWdhaW5z dCBkZW5pYWwtb2Ytc2VydmljZSBvciBwYWNrZXQNCmFtcGxpZmljYXRpb24gYXR0YWNrcyB0aGF0 IGNvdWxkIGJlIHVzZWQgdG8gY2F1c2Ugb25lIG9yIG1vcmUgUlRQDQpwYWNrZXRzIHRvIGJlIHNl bnQgdG8gYSB2aWN0aW0gY2xpZW50Lg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From abegen@cisco.com Sat Jan 29 18:25:44 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8583A69B4 for ; Sat, 29 Jan 2011 18:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDICOT4ua8gq for ; Sat, 29 Jan 2011 18:25:40 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 953873A68A3 for ; Sat, 29 Jan 2011 18:25:40 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwDAEJbRE2rR7H+/2dsb2JhbACWG45ec6BymiYChUwEhROKWQ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 02:28:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0U2SpoN011166; Sun, 30 Jan 2011 02:28:51 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jan 2011 18:28:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 29 Jan 2011 18:28:51 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D42CEB8.1090806@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] WG adoption to meet milestone for indication ofretransmission supression Thread-Index: Acu+9WOJ+mQR8La6S4WUGgfjZZaJ6ABL+RAQ References: <4D42CEB8.1090806@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVT WG" X-OriginalArrivalTime: 30 Jan 2011 02:28:51.0007 (UTC) FILETIME=[6E7B04F0:01CBC025] Subject: Re: [AVT] WG adoption to meet milestone for indication ofretransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 02:25:45 -0000 The draft is on the right track but some of the comments I provided = earlier are still pending. We can them work them out during the document = development. -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, January 28, 2011 9:12 AM > To: IETF AVT WG > Subject: [AVT] WG adoption to meet milestone for indication = ofretransmission supression >=20 > WG, >=20 > This is a call for adopting "RTCP Extension for Feedback Suppression > Indication" as the starting point for meeting our milestone. The draft > is available here: > = https://datatracker.ietf.org/doc/draft-wu-avt-retransmission-supression-r= tp/ >=20 > The milestone: > May 2011 Submit RTCP indication for retransmission suppression as > Proposed Standard >=20 > Please provide any inut by Friday the 11th of February. >=20 > Regards >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gwz@net-zen.net Sat Jan 29 23:53:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198E53A6B16 for ; Sat, 29 Jan 2011 23:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmnuCmLeBGLj for ; Sat, 29 Jan 2011 23:53:33 -0800 (PST) Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id 2EBA93A6B14 for ; Sat, 29 Jan 2011 23:53:33 -0800 (PST) Received: (qmail 5552 invoked from network); 30 Jan 2011 07:56:43 -0000 Received: from unknown (124.122.190.93) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 30 Jan 2011 07:56:41 -0000 From: "Glen Zorn" To: "'Ali C. Begen \(abegen\)'" References: <4D42CEB8.1090806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> Date: Sun, 30 Jan 2011 14:56:18 +0700 Organization: Network Zen Message-ID: <001201cbc053$30ebf620$92c3e260$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu+9WOJ+mQR8La6S4WUGgfjZZaJ6ABL+RAQAAtqMEA= Content-Language: en-us Cc: 'IETF AVT WG' , avt-chairs@tools.ietf.org Subject: Re: [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 07:53:34 -0000 Just to be clear, do you mean that you support the adoption of the = document as a WG item? Hope this helps. ~gwz > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Ali C. Begen (abegen) > Sent: Sunday, January 30, 2011 9:29 AM > To: Magnus Westerlund; IETF AVT WG > Subject: Re: [AVT] WG adoption to meet milestone for indication > ofretransmission supression >=20 > The draft is on the right track but some of the comments I provided > earlier are still pending. We can them work them out during the = document > development. >=20 > -acbegen >=20 > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > Magnus Westerlund > > Sent: Friday, January 28, 2011 9:12 AM > > To: IETF AVT WG > > Subject: [AVT] WG adoption to meet milestone for indication > ofretransmission supression > > > > WG, > > > > This is a call for adopting "RTCP Extension for Feedback Suppression > > Indication" as the starting point for meeting our milestone. The = draft > > is available here: > > https://datatracker.ietf.org/doc/draft-wu-avt-retransmission- > supression-rtp/ > > > > The milestone: > > May 2011 Submit RTCP indication for retransmission suppression as > > Proposed Standard > > > > Please provide any inut by Friday the 11th of February. > > > > Regards > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Sun Jan 30 01:13:45 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405533A68FC for ; Sun, 30 Jan 2011 01:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.834 X-Spam-Level: X-Spam-Status: No, score=-7.834 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjdQEgIS3bSX for ; Sun, 30 Jan 2011 01:13:44 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7472A3A68F5 for ; Sun, 30 Jan 2011 01:13:44 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAGW7RE2rR7Hu/2dsb2JhbACEFZIEjXJsAnOgb4pijzYCgSGDN3QEhRGHEINL Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2011 09:16:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0U9Gsnn025098; Sun, 30 Jan 2011 09:16:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Jan 2011 01:16:54 -0800 Received: from 72.163.63.13 ([72.163.63.13]) by xmb-sjc-215.amer.cisco.com ([171.70.151.169]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Jan 2011 09:16:53 +0000 References: <4D42CEB8.1090806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> <001201cbc053$30ebf620$92c3e260$@net> Content-Transfer-Encoding: base64 From: "Ali C. Begen (abegen)" Content-Type: text/plain; charset="utf-8" In-Reply-To: <001201cbc053$30ebf620$92c3e260$@net> Message-ID: <97E01434-BE8D-4714-B5AF-460E6075ED27@cisco.com> thread-topic: [AVT] WG adoption to meet milestone for indication of retransmission supression thread-index: AcvAXm8A6fOLkwEJT2azhyQOwRBMvQ== Date: Sun, 30 Jan 2011 18:16:48 +0900 To: "Glen Zorn" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 30 Jan 2011 09:16:54.0532 (UTC) FILETIME=[6FCC7440:01CBC05E] Cc: IETF AVT WG , avt-chairs@tools.ietf.org Subject: Re: [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 09:13:45 -0000 U29ycnkgaWYgaXQgd2FzIG5vdCBjbGVhci4gWWVzIEkgZG8gc3VwcG9ydCBhZG9wdGlvbi4gDQoN Ci1hY2JlZ2VuDQoNCk9uIEphbiAzMCwgMjAxMSwgYXQgNDo1NiBQTSwgIkdsZW4gWm9ybiIgPGd3 ekBuZXQtemVuLm5ldD4gd3JvdGU6DQoNCj4gSnVzdCB0byBiZSBjbGVhciwgZG8geW91IG1lYW4g dGhhdCB5b3Ugc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlIGRvY3VtZW50DQo+IGFzIGEgV0cg aXRlbT8NCj4gDQo+IEhvcGUgdGhpcyBoZWxwcy4NCj4gDQo+IH5nd3oNCj4gDQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiBBbGkgQy4gQmVnZW4gKGFi ZWdlbikNCj4+IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAzMCwgMjAxMSA5OjI5IEFNDQo+PiBUbzog TWFnbnVzIFdlc3Rlcmx1bmQ7IElFVEYgQVZUIFdHDQo+PiBTdWJqZWN0OiBSZTogW0FWVF0gV0cg YWRvcHRpb24gdG8gbWVldCBtaWxlc3RvbmUgZm9yIGluZGljYXRpb24NCj4+IG9mcmV0cmFuc21p c3Npb24gc3VwcmVzc2lvbg0KPj4gDQo+PiBUaGUgZHJhZnQgaXMgb24gdGhlIHJpZ2h0IHRyYWNr IGJ1dCBzb21lIG9mIHRoZSBjb21tZW50cyBJIHByb3ZpZGVkDQo+PiBlYXJsaWVyIGFyZSBzdGls bCBwZW5kaW5nLiBXZSBjYW4gdGhlbSB3b3JrIHRoZW0gb3V0IGR1cmluZyB0aGUgZG9jdW1lbnQN Cj4+IGRldmVsb3BtZW50Lg0KPj4gDQo+PiAtYWNiZWdlbg0KPj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBhdnQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2 dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+ Pj4gU2VudDogRnJpZGF5LCBKYW51YXJ5IDI4LCAyMDExIDk6MTIgQU0NCj4+PiBUbzogSUVURiBB VlQgV0cNCj4+PiBTdWJqZWN0OiBbQVZUXSBXRyBhZG9wdGlvbiB0byBtZWV0IG1pbGVzdG9uZSBm b3IgaW5kaWNhdGlvbg0KPj4gb2ZyZXRyYW5zbWlzc2lvbiBzdXByZXNzaW9uDQo+Pj4gDQo+Pj4g V0csDQo+Pj4gDQo+Pj4gVGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW5nICJSVENQIEV4dGVuc2lv biBmb3IgRmVlZGJhY2sgU3VwcHJlc3Npb24NCj4+PiBJbmRpY2F0aW9uIiBhcyB0aGUgc3RhcnRp bmcgcG9pbnQgZm9yIG1lZXRpbmcgb3VyIG1pbGVzdG9uZS4gVGhlIGRyYWZ0DQo+Pj4gaXMgYXZh aWxhYmxlIGhlcmU6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt d3UtYXZ0LXJldHJhbnNtaXNzaW9uLQ0KPj4gc3VwcmVzc2lvbi1ydHAvDQo+Pj4gDQo+Pj4gVGhl IG1pbGVzdG9uZToNCj4+PiBNYXkgMjAxMSBTdWJtaXQgUlRDUCBpbmRpY2F0aW9uIGZvciByZXRy YW5zbWlzc2lvbiBzdXBwcmVzc2lvbiBhcw0KPj4+IFByb3Bvc2VkIFN0YW5kYXJkDQo+Pj4gDQo+ Pj4gUGxlYXNlIHByb3ZpZGUgYW55IGludXQgYnkgRnJpZGF5IHRoZSAxMXRoIG9mIEZlYnJ1YXJ5 Lg0KPj4+IA0KPj4+IFJlZ2FyZHMNCj4+PiANCj4+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4+IA0K Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24g UmVzZWFyY2ggRUFCL1RWTQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBFcmljc3NvbiBBQiAgICAg ICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPj4+IEbDpHLDtmdhdGFuIDYgICAg ICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4+PiBTRS0xNjQgODAgU3RvY2to b2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IFdvcmtpbmcgR3JvdXANCj4+PiBh dnRAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2 dA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBXb3JraW5nIEdyb3VwDQo+PiBhdnRAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+IA0K From gwz@net-zen.net Sun Jan 30 02:04:38 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50693A6935 for ; Sun, 30 Jan 2011 02:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bDqGtxZ27Fh for ; Sun, 30 Jan 2011 02:04:38 -0800 (PST) Received: from p3plsmtpa01-05.prod.phx3.secureserver.net (p3plsmtpa01-05.prod.phx3.secureserver.net [72.167.82.85]) by core3.amsl.com (Postfix) with SMTP id E4D633A691E for ; Sun, 30 Jan 2011 02:04:37 -0800 (PST) Received: (qmail 19603 invoked from network); 30 Jan 2011 10:07:48 -0000 Received: from unknown (124.122.190.93) by p3plsmtpa01-05.prod.phx3.secureserver.net (72.167.82.85) with ESMTP; 30 Jan 2011 10:07:47 -0000 From: "Glen Zorn" To: "'Ali C. Begen \(abegen\)'" References: <4D42CEB8.1090806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> <001201cbc053$30ebf620$92c3e260$@net> <97E01434-BE8D-4714-B5AF-460E6075ED27@cisco.com> In-Reply-To: <97E01434-BE8D-4714-B5AF-460E6075ED27@cisco.com> Date: Sun, 30 Jan 2011 17:07:25 +0700 Organization: Network Zen Message-ID: <003a01cbc065$80c90a40$825b1ec0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvAXm8A6fOLkwEJT2azhyQOwRBMvQABt01w Content-Language: en-us Cc: 'IETF AVT WG' , avt-chairs@tools.ietf.org Subject: Re: [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 10:04:38 -0000 Ali C. Begen (abegen) [mailto://abegen@cisco.com] writes: > Sorry if it was not clear. Yes I do support adoption. Maybe it _was_ clear & I'm just dense ;-). In any case, thanks for = humoring me. >=20 > -acbegen >=20 > On Jan 30, 2011, at 4:56 PM, "Glen Zorn" wrote: >=20 > > Just to be clear, do you mean that you support the adoption of the > document > > as a WG item? > > > > Hope this helps. > > > > ~gwz > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > >> Ali C. Begen (abegen) > >> Sent: Sunday, January 30, 2011 9:29 AM > >> To: Magnus Westerlund; IETF AVT WG > >> Subject: Re: [AVT] WG adoption to meet milestone for indication > >> ofretransmission supression > >> > >> The draft is on the right track but some of the comments I provided > >> earlier are still pending. We can them work them out during the > document > >> development. > >> > >> -acbegen > >> > >>> -----Original Message----- > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf > Of > >> Magnus Westerlund > >>> Sent: Friday, January 28, 2011 9:12 AM > >>> To: IETF AVT WG > >>> Subject: [AVT] WG adoption to meet milestone for indication > >> ofretransmission supression > >>> > >>> WG, > >>> > >>> This is a call for adopting "RTCP Extension for Feedback = Suppression > >>> Indication" as the starting point for meeting our milestone. The > draft > >>> is available here: > >>> https://datatracker.ietf.org/doc/draft-wu-avt-retransmission- > >> supression-rtp/ > >>> > >>> The milestone: > >>> May 2011 Submit RTCP indication for retransmission suppression as > >>> Proposed Standard > >>> > >>> Please provide any inut by Friday the 11th of February. > >>> > >>> Regards > >>> > >>> Magnus Westerlund > >>> > >>> = -------------------------------------------------------------------- > -- > >>> Multimedia Technologies, Ericsson Research EAB/TVM > >>> = -------------------------------------------------------------------- > -- > >>> Ericsson AB | Phone +46 10 7148287 > >>> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > >>> SE-164 80 Stockholm, Sweden| mailto: = magnus.westerlund@ericsson.com > >>> = -------------------------------------------------------------------- > -- > >>> _______________________________________________ > >>> Audio/Video Transport Working Group > >>> avt@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avt > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > From gwz@net-zen.net Sun Jan 30 02:07:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9503A6935 for ; Sun, 30 Jan 2011 02:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tXE+M5d5t9y for ; Sun, 30 Jan 2011 02:07:46 -0800 (PST) Received: from p3plsmtpa01-03.prod.phx3.secureserver.net (p3plsmtpa01-03.prod.phx3.secureserver.net [72.167.82.83]) by core3.amsl.com (Postfix) with SMTP id 42DA73A692E for ; Sun, 30 Jan 2011 02:07:46 -0800 (PST) Received: (qmail 26094 invoked from network); 30 Jan 2011 10:10:57 -0000 Received: from unknown (124.122.190.93) by p3plsmtpa01-03.prod.phx3.secureserver.net (72.167.82.83) with ESMTP; 30 Jan 2011 10:10:56 -0000 From: "Glen Zorn" To: "'Glen Zorn'" , "'Ali C. Begen \(abegen\)'" References: <4D42CEB8.1090806@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540E2D1D32@xmb-sjc-215.amer.cisco.com> <001201cbc053$30ebf620$92c3e260$@net> <97E01434-BE8D-4714-B5AF-460E6075ED27@cisco.com> <003a01cbc065$80c90a40$825b1ec0$@net> In-Reply-To: <003a01cbc065$80c90a40$825b1ec0$@net> Date: Sun, 30 Jan 2011 17:10:34 +0700 Organization: Network Zen Message-ID: <003b01cbc065$f179c3b0$d46d4b10$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvAXm8A6fOLkwEJT2azhyQOwRBMvQABt01wAAAeCqA= Content-Language: en-us Cc: 'IETF AVT WG' , avt-chairs@tools.ietf.org Subject: Re: [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 10:07:47 -0000 Glen Zorn [mailto://gwz@net-zen.net] writes: > Ali C. Begen (abegen) [mailto://abegen@cisco.com] writes: > > > Sorry if it was not clear. Yes I do support adoption. BTW, so do I. ... From Even.roni@huawei.com Sun Jan 30 02:22:44 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E39C3A6940; Sun, 30 Jan 2011 02:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waBF+3bjmY+f; Sun, 30 Jan 2011 02:22:43 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E99773A692E; Sun, 30 Jan 2011 02:22:42 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFT00GKXZMVCJ@szxga03-in.huawei.com>; Sun, 30 Jan 2011 18:25:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFT00ERTZMVVX@szxga03-in.huawei.com>; Sun, 30 Jan 2011 18:25:43 +0800 (CST) Received: from windows8d787f9 ([109.64.31.233]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFT00JDFZMOWC@szxml02-in.huawei.com>; Sun, 30 Jan 2011 18:25:43 +0800 (CST) Date: Sun, 30 Jan 2011 12:21:20 +0200 From: Roni Even In-reply-to: <1C6EB1CB-3A15-4A74-9FDE-47EF194454D7@magorcorp.com> To: 'Peter Musgrave' , "'DRAGE, Keith (Keith)'" Message-id: <097201cbc067$74afbdb0$5e0f3910$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acu+MxtApWZmcHkvRnO/moF7XHF/HACNE1NQ References: <1C6EB1CB-3A15-4A74-9FDE-47EF194454D7@magorcorp.com> Cc: avtext@ietf.org, 'IETF AVT WG' Subject: Re: [AVT] [avtext] Call for adoption of text for audio level milestones X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 10:22:44 -0000 I agree Roni Even > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On > Behalf Of Peter Musgrave > Sent: Thursday, January 27, 2011 5:01 PM > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org; IETF AVT WG > Subject: Re: [avtext] Call for adoption of text for audio level > milestones > > This text is a good starting point. > > Peter > > On 2011-01-27, at 9:56 AM, DRAGE, Keith (Keith) wrote: > > > (As AVTEXT WG cochair) > > > > This message is copied to the AVTCORE list for those who are not yet > on the new list. > > > > AVTEXT has two milestones relating to audio levels. > > > > Oct 2011 Submit RTP Header extension for mixer to client audio level > indication as Proposed Standard > > > > Oct 2011 Submit RTP Header extension for client to mixer audio level > indication as proposed standard > > > > We have the following author drafts providing candidate text for > these milestones: > > > > A Real-Time Transport Protocol (RTP) Extension Header for Mixer-to- > client Audio Level Indication > > http://www.ietf.org/id/draft-ivov-avt-slic-04.txt > > > > A Real-Time Transport Protocol (RTP) Header Extension for Client-to- > Mixer Audio Level Indication > > http://tools.ietf.org/id/draft-lennox-avt-rtp-audio-level-exthdr- > 02.txt > > > > respectively. > > > > This is a WG consensus call to adopt the above text as baseline text > for these milestones. At this stage the text does not have to be > regarded perfect, the question is more "Does this text form a better > basis for completing the work in the working group that some text yet > to be submitted?" > > > > While the prime intention of this call is to adopt the entire text of > the author draft, if you consider that some of the text is appropriate, > but that some of the text does not form a reasonable start for the > work, then please indicate that text and we will make a separate call > on it (and adopt the rest). > > > > Please respond by Thursday 10th February 2011 with your positions. > > > > ######### Please respond to the AVTEXT list only ############# > > > > Regards > > > > Keith > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From magnus.westerlund@ericsson.com Mon Jan 31 04:44:49 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27AF3A6BF0 for ; Mon, 31 Jan 2011 04:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.484 X-Spam-Level: X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy0ZBZcEJ4cf for ; Mon, 31 Jan 2011 04:44:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5603D3A6BF2 for ; Mon, 31 Jan 2011 04:44:47 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-f7-4d46af81bded Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 87.99.13987.18FA64D4; Mon, 31 Jan 2011 13:48:01 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 31 Jan 2011 13:48:01 +0100 Message-ID: <4D46AF81.8030402@ericsson.com> Date: Mon, 31 Jan 2011 13:48:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <20110128155451.03FCA3A6860@core3.amsl.com> <04CAD96D4C5A3D48B1919248A8FE0D540E2D19B4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E2D19B4@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:44:49 -0000 Hi, I have reviewed these changes and think they address all the issues I had raised. Cheers Magnus Ali C. Begen (abegen) skrev 2011-01-28 17:05: > Following the wglc, we revised the token draft (and renamed it as well). Here is the new spec: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ > > For diff, please use: > http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-avt-ports-for-ucast-mcast-rtp-11.txt&url2=http://www.ietf.org/id/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt > > We hope this addressed all the comments received so far and we are ready to ship this. > > Cheers, > -acbegen > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, January 28, 2011 10:55 AM > To: Ali C. Begen (abegen) > Cc: Dan Wing (dwing); Tom.Van_Caenegem@alcatel-lucent.com > Subject: New Version Notification for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 > > > A new version of I-D, draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt has been successfully submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-avtcore-ports-for-ucast-mcast-rtp > Revision: 00 > Title: Port Mapping Between Unicast and Multicast RTP Sessions > Creation_date: 2011-01-28 > WG ID: avtcore > Number_of_pages: 36 > > Abstract: > This document presents a port mapping solution that allows RTP > receivers to choose their own ports for an auxiliary unicast session > in RTP applications using both unicast and multicast services. The > solution provides protection against denial-of-service or packet > amplification attacks that could be used to cause one or more RTP > packets to be sent to a victim client. > > > > The IETF Secretariat. > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Even.roni@huawei.com Mon Jan 31 05:32:35 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3043A6BF4 for ; Mon, 31 Jan 2011 05:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.73 X-Spam-Level: X-Spam-Status: No, score=-103.73 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZQ91mF2yKDB for ; Mon, 31 Jan 2011 05:32:34 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C2AC53A6BED for ; Mon, 31 Jan 2011 05:32:33 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFW0054933D20@szxga04-in.huawei.com> for avt@ietf.org; Mon, 31 Jan 2011 21:35:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFW0099F33C3W@szxga04-in.huawei.com> for avt@ietf.org; Mon, 31 Jan 2011 21:35:37 +0800 (CST) Received: from windows8d787f9 ([109.64.31.233]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFW0062Q337MG@szxml02-in.huawei.com> for avt@ietf.org; Mon, 31 Jan 2011 21:35:36 +0800 (CST) Date: Mon, 31 Jan 2011 15:31:11 +0200 From: Roni Even To: 'IETF AVTCore WG' Message-id: <0a1d01cbc14b$2432d450$6c987cf0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PS2GtABOg7vAu3eELrvj4w)" Content-language: en-us Thread-index: AcvBSxwYV8dNxSwsSpWizxH3SP09VQ== x-cr-hashedpuzzle: AXUs A8Hy Bh7U BvaR B9TW DpTK ELRZ FLwH FNXp F1wb HL1w IYAF Id8l Ip/9 JP3u JZVd; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7CDAC789-BB31-44B8-8A11-65A0AA1A6CE2}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon, 31 Jan 2011 13:31:04 GMT; UwBoAG8AcgB0ACAAVwBHAEwAQwAgAG8AbgAgAFAAbwByAHQAIABNAGEAcABwAGkAbgBnACAAQgBlAHQAdwBlAGUAbgAgAFUAbgBpAGMAYQBzAHQAIABhAG4AZAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAAUgBUAFAAIABTAGUAcwBzAGkAbwBuAHMA x-cr-puzzleid: {7CDAC789-BB31-44B8-8A11-65A0AA1A6CE2} Subject: [AVTCORE] Short WGLC on Port Mapping Between Unicast and Multicast RTP Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:32:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_PS2GtABOg7vAu3eELrvj4w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 . This draft finished a WGLC in the AVT WG before the restructure and the new 00 revision reflects that changes that were done based on email discussion. Please review the draft and send any comment to the AVTCore mailing list (avt@ietf.org) till the end of Monday February 7th 2011. Thanks Roni Even AVTCore co chair --Boundary_(ID_PS2GtABOg7vAu3eELrvj4w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I would like to = start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-= mcast-rtp-00 .

This draft = finished a WGLC in the AVT WG before the restructure and the new 00 = revision reflects that changes that were done based on email = discussion.

 

Please review the draft and send any comment to the = AVTCore mailing list (avt@ietf.org) = till the end of Monday February 7th 2011.

Thanks

Roni = Even

AVTCore co chair =

= --Boundary_(ID_PS2GtABOg7vAu3eELrvj4w)--