Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Tuesday, 12 March 2013 at 13:00-15:00 (Caribbean 4)

13:00	AVTCore Status Update	Chairs
13:20	RTP Considerations for Endpoints sending multiple = media streams	Magnus Westerlund
	draft-lennox-avtcore-rtp-multi-stream-02
13:40	Circuit Breakers for Unicast Sessions	Colin Perkins=20
	draft-ietf-avtcore-rtp-circuit-breakers-02
13:55	RTP Clock Source Signalling	Aidan = Williams
	draft-ietf= -avtcore-clksrc-02
14:05	RTP and Leap Second	Kevin Gross
	draft= -ietf-avtcore-leap-second-02
14:15	End

------=_NextPart_000_0343_01CE18D7.7F584690-- From keith.drage@alcatel-lucent.com Mon Mar 4 03:28:17 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42BF21F8A40 for ; Mon, 4 Mar 2013 03:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.248 X-Spam-Level: X-Spam-Status: No, score=-110.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oAtV3ymUmBS for ; Mon, 4 Mar 2013 03:28:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5813F21F8A0C for ; Mon, 4 Mar 2013 03:28:04 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24BRaq1016473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 12:28:02 +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; Mon, 4 Mar 2013 12:27:50 +0100 From: "DRAGE, Keith (Keith)" To: Roni Even , "avt@ietf.org" Date: Mon, 4 Mar 2013 12:27:50 +0100 Thread-Topic: [AVTCORE] initial agenda for Orlando Thread-Index: Ac4YxftwqEfU3QV4QoS6msWfE/dEngAAgbCA Message-ID: References: <034201ce18c6$bbcf0160$336d0420$@gmail.com> In-Reply-To: <034201ce18c6$bbcf0160$336d0420$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21070267EDCFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] initial agenda for Orlando X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:28:17 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21070267EDCFRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does the absence of a Thursday session on the agenda mean you are cancellin= g that? Keith ________________________________ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni = Even Sent: 04 March 2013 10:55 To: avt@ietf.org Subject: [AVTCORE] initial agenda for Orlando Hi, This is the initial agenda based on the requests I had so far. Let me know if I missed some requests Thanks Roni --_000_EDC0A1AE77C57744B664A310A0B23AE21070267EDCFRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Does the absence of a Thursday session= on the agenda mean you are cancelling that?

Keith

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: 04 March 2013 10:55 To: avt@ietf.org
Subject: [AVTCORE] initial a= genda for Orlando

Hi,

This is the initial agenda based on the requests I had so far.=

Let me know if I missed some requests

Thanks

Roni

X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBD121F8A35 for ; Mon, 4 Mar 2013 03:51:38 -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=2.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvF5mVHMUlgo for ; Mon, 4 Mar 2013 03:51:38 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id C76E021F8A11 for ; Mon, 4 Mar 2013 03:51:37 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3732606eei.7 for ; Mon, 04 Mar 2013 03:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=dXx94b7Hyhn6o9+oTBoU3DfuiRj7Og0QLXxq17veGPs=; b=GtpcZcxXGyCKTEpHUKVZq5+VYEnr76hI9fpNm+6KJSdYYTRBDU2chyXm3YMUdqsLPD TjjAUXPqlbRnn3pmZujtTCQ1ucWbGk63erz8JhwS5YMmGzMPLhjsT75J4vTD6FBX8pCL z2LmeYjvWPfzkH7QC/PqyO8ZdqChsi199zhkoABBjkfX6lROMf7mu0QCbU+J+vbrkqya KMbdIoNZSdD5d9sSsG6ZrOQqYAe37ZP5o5J/PjaDd+35VGTLRb9dMf7Ay/tSBMVFiY21 e4SPJg7lw9SxxdYC8x7MySbf1ZGhN8/11mNWHu81nCSm+ykMP9FTlB6tg67aOLsanZE0 7B1Q== X-Received: by 10.14.209.131 with SMTP id s3mr58042948eeo.26.1362397896926; Mon, 04 Mar 2013 03:51:36 -0800 (PST) Received: from RoniE (bzq-79-176-225-197.red.bezeqint.net. [79.176.225.197]) by mx.google.com with ESMTPS id s3sm31649799eem.4.2013.03.04.03.51.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Mar 2013 03:51:36 -0800 (PST) From: "Roni Even" To: "'DRAGE, Keith $Keith$'" , References: <034201ce18c6$bbcf0160$336d0420$@gmail.com> In-Reply-To: Date: Mon, 4 Mar 2013 13:48:25 +0200 Message-ID: <036801ce18ce$30066c60$90134520$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0369_01CE18DE.F38FD8A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFEm5GdC68cbmGsSdt922tGBjilqAHkqODBmZk/qfA= Content-Language: en-us Subject: Re: [AVTCORE] initial agenda for Orlando X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:51:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0369_01CE18DE.F38FD8A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Keith, I do not know yet since I am trying to see first if I missed some requests. I was on vacation last week. Roni From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: 04 March, 2013 1:28 PM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] initial agenda for Orlando Does the absence of a Thursday session on the agenda mean you are cancelling that? Keith _____ From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: 04 March 2013 10:55 To: avt@ietf.org Subject: [AVTCORE] initial agenda for Orlando Hi, This is the initial agenda based on the requests I had so far. Let me know if I missed some requests Thanks Roni ------=_NextPart_000_0369_01CE18DE.F38FD8A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Keith,

I do not know yet since = I am trying to see first if I missed some = requests.

I was on vacation last = week.

Roni

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] =
Sent: 04 March, 2013 1:28 PM
To: Roni Even; = avt@ietf.org
Subject: RE: [AVTCORE] initial agenda for = Orlando

Do= es the absence of a Thursday session on the agenda mean you are = cancelling that?

Ke= ith

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] = On Behalf Of Roni Even
Sent: 04 March 2013 = 10:55
To: avt@ietf.org
Subject: = [AVTCORE] initial agenda for Orlando

Hi,

This is the = initial agenda based on the requests I had so far.

Let me know if I missed some requests

Thanks

Roni

------=_NextPart_000_0369_01CE18DE.F38FD8A0-- From ietf-ipr@ietf.org Mon Mar 4 22:23:00 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2250C21F890F; Mon, 4 Mar 2013 22:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTJXZCph4iM2; Mon, 4 Mar 2013 22:22:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A225C21F88F1; Mon, 4 Mar 2013 22:22:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: johnw@cs.berkeley.edu,lazzaro@cs.berkeley.edu X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130305062259.31678.91235.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2013 22:22:59 -0800 Cc: avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: SSH Communications Security Corporation's Statement about IPR related to RFC 4696 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 06:23:00 -0000 Dear John Wawrzynek, John Lazzaro: An IPR disclosure that pertains to your RFC entitled "An Implementation Gu= ide for RTP MIDI" (RFC4696) was submitted to the IETF Secretariat on 2013-02-23= and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/1983/). The title of the IPR disclosure is "SSH Communications Security Corporation's Statement about IPR related to R= FC 4696.""); The IETF Secretariat From ron.even.tlv@gmail.com Wed Mar 6 00:49:12 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCDD21F8491 for ; Wed, 6 Mar 2013 00:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1vmn3qtJsjY for ; Wed, 6 Mar 2013 00:49:12 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id CB1E321F84A9 for ; Wed, 6 Mar 2013 00:49:11 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so5227608eei.7 for ; Wed, 06 Mar 2013 00:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=+34L4WuXYDLeNOm1oKYoqfjnI5YAn7xrHAgS/0Oj4Zw=; b=lRz40lE4jfIIGV6Sx4FbE8Cvavt2l160AlNMDNoa4+sbtRXN4uwgmhnqnaubJDgHl4 PaFZaZkq9lMI2unacjW3QXzyfkUQN58ti6o5X6P9pokAPBH0yeSBbC6kb9GIbUWbfAkc n7C5hNeK9e/wO/04jyq9hjq10mLHS0b6DhCmeg+wigSK3iA1B2zSOpdJ4g52e7BwYXMS uXE0b81pmpn0Qd4oYtcMwqOALss8t4lIYEI2xJ1LxfsxUPGlTOZdNUUrZSxZYEVHY1Xp rrvcMLmKuqrUZYM83d8m4QfX3ScZSlQgjWNCqvpPwEXmM3xYpRTQMukBguzO75YT6VYh 0Jbw== X-Received: by 10.14.111.72 with SMTP id v48mr50145039eeg.11.1362559750994; Wed, 06 Mar 2013 00:49:10 -0800 (PST) Received: from RoniE (bzq-109-65-190-187.red.bezeqint.net. [109.65.190.187]) by mx.google.com with ESMTPS id 3sm41200071eej.6.2013.03.06.00.49.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Mar 2013 00:49:09 -0800 (PST) From: "Roni Even" To: Date: Wed, 6 Mar 2013 10:48:49 +0200 Message-ID: <04e401ce1a47$6d25ff50$4771fdf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E5_01CE1A58.30AF1D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4aR0pKxut1lrjPSWWkXmcmJgxnVQ== Content-Language: en-us Subject: [AVTCORE] cancelling second session of AVTcore in Orlando X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 08:49:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04E5_01CE1A58.30AF1D70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Based on the current agenda we will not need the second slot on Thursday and will use only the Tuesday slot. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_04E5_01CE1A58.30AF1D70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

Based on the = current agenda we will not need the second slot on Thursday and will use = only the Tuesday slot.

Thanks

Roni = Even

AVTcore = co-chair

------=_NextPart_000_04E5_01CE1A58.30AF1D70-- From abegen@cisco.com Wed Mar 6 20:03:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382621F8765 for ; Wed, 6 Mar 2013 20:03:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-Bw0h382Nfp for ; Wed, 6 Mar 2013 20:03:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7321F8763 for ; Wed, 6 Mar 2013 20:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1362629027; x=1363838627; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YJ4VjDeahlppd0S6PAYmdbbwMvLOAVEFPdELW0jACYo=; b=C/XC+4pQsdboh4KIbAYnDhcn5JAlZUrPMNgMZWR0M+50eVamchnvP+I3 L93z/lUnt0xpGJXSX6NzzmyeU8cmVdtJCEtIjPecg5lkfoV4zoQ5lokw2 ryHdc10/LJira9olBEwxNoXYsuOXaiXLA8lV9YQ8Ahy55aKCuASLANn8h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFoQOFGtJV2d/2dsb2JhbABDhEDABoFkFnOCKwEBAQMBdwIFBwQCAQgRAwECAQokMh0IAgQOBQiIBQYBC7tHjUCBGQIxBwaCWWEDiDafBYFTgTaCJw X-IronPort-AV: E=Sophos;i="4.84,799,1355097600"; d="scan'208";a="184672990" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 07 Mar 2013 04:03:46 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2743k3C021499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 04:03:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 22:03:45 -0600 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt Thread-Index: AQHOGujDIYjOmUvgB02Y2oS6jNl6MQ== Date: Thu, 7 Mar 2013 04:03:45 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.185] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4B0B05E9322F4C4181F93370C1BF6F93@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:03:49 -0000 Picking up this old thread. On Jan 13, 2013, at 7:14 AM, Kevin Gross wrote: > Sorry for the delay responding. I do think otherwise. (a) is fine because= OUI registration prevents collisions. (b) relies on statistics to prevent = collisions. There's not enough entropy in 48-bit number to statistically pr= event collisions in a larger population of participants. See http://en.wiki= pedia.org/wiki/Birthday_problem. 96-bits is where things are workable. >=20 What about this: ... After obtaining an identifier in case of (a), the 48 bits are converted= to the standard colon-separated hexadecimal format [RFC5342], e.g., "00:23= :32:af:9b:aa", resulting in a 17-octet printable string representation. In = case of (b), the least significant 96 bits are converted to ASCII using Bas= e64 encoding [RFC4648], resulting in a 16-octet string representation. -acbegen > Kevin >=20 > On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) = wrote: > Kevin, >=20 > -----Original Message----- > From: "Ali C. Begen" > Date: Monday, November 5, 2012 7:02 PM > To: Kevin Gross > Cc: "avt@ietf.org" > Subject: Re: [AVTCORE] FW: New Version Notification for > draft-rescorla-avtcore-6222bis-00.txt >=20 > >>Second bullet point in section 4.2 Item (b): Proposes truncating our ni= ce > >>96-bit random CNAME to 48 bits. I think we have an unacceptable > >>opportunity for duplication with this approach. This CNAME should > >>probably use RFC 4648 in which case these CNAMEs > >>take the same form as the per-session CNAMES but differ in the > >>requirement to create once at software initialization. Is it necessary > >>for the different types of CNAMEs to have different appearance? > > > >I don=B9t think there is such a requirement and your suggestion makes se= nse. >=20 > Thinking more about this, I think the current text is good. Item (a) uses > 48-bit MAC addresses. So, even if we use truncating in item (b), its > collision probability will not be any worse than item (a)'s. Note that > both item (a) and (b) use 17-octet string representation whereas the > per-session CNAME uses 16-octet string representation. >=20 > Let me know if you think otherwise. >=20 > -acbegen >=20 >=20 From kevin.gross@avanw.com Thu Mar 7 08:20:34 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE69821F8D3C for ; Thu, 7 Mar 2013 08:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.272 X-Spam-Level: ** X-Spam-Status: No, score=2.272 tagged_above=-999 required=5 tests=[AWL=3.914, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwWdr73vI3iu for ; Thu, 7 Mar 2013 08:20:33 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 251A921F8D39 for ; Thu, 7 Mar 2013 08:20:26 -0800 (PST) Received: (qmail 24974 invoked by uid 0); 7 Mar 2013 16:19:58 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 7 Mar 2013 16:19:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=bDB7wKYzqG0i9XZMt8bMvECntxY+vY/dCS5m82G+DPA=; b=Qom8F8grW9qQPN2u//aMnR1nLu5pA6mXzKANUEXAPxJjd8IVgBy9IX33hN1ZP5PS9tqiUX6n8z+OAgjucSvGl91EA0JhFWpTVXpJsm9paWSRPo3yKZSSoEE0KyhLF4U7; Received: from [209.85.210.170] (port=40082 helo=mail-ia0-f170.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UDdXy-00068l-HI for avt@ietf.org; Thu, 07 Mar 2013 09:19:58 -0700 Received: by mail-ia0-f170.google.com with SMTP id h8so577403iaa.29 for ; Thu, 07 Mar 2013 08:19:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.37.212 with SMTP id a20mr15054378igk.88.1362673197392; Thu, 07 Mar 2013 08:19:57 -0800 (PST) Received: by 10.50.183.163 with HTTP; Thu, 7 Mar 2013 08:19:57 -0800 (PST) In-Reply-To: References:

Date: Thu, 7 Mar 2013 09:19:57 -0700 Message-ID: From: Kevin Gross To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=f46d04446b21e0bdd704d7581335 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.170 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:20:34 -0000 --f46d04446b21e0bdd704d7581335 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's technically sound. Editorially speaking, this new (b) method is already described in the third bullet point in section 4.2. Hopefully the authors can find a way to reference that instead of repeating it. Separately, I note that section 5 allows you to create unique identifiers with more than 96 bits. I now don't see anywhere where you're allowed to use more than 96 bits so I question why we include that flexibility. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Mar 6, 2013 at 9:03 PM, Ali C. Begen (abegen) wro= te: > Picking up this old thread. > > On Jan 13, 2013, at 7:14 AM, Kevin Gross wrote: > > > Sorry for the delay responding. I do think otherwise. (a) is fine > because OUI registration prevents collisions. (b) relies on statistics to > prevent collisions. There's not enough entropy in 48-bit number to > statistically prevent collisions in a larger population of participants. > See http://en.wikipedia.org/wiki/Birthday_problem. 96-bits is where > things are workable. > > > > What about this: > > ... After obtaining an identifier in case of (a), the 48 bits are > converted to the standard colon-separated hexadecimal format [RFC5342], > e.g., "00:23:32:af:9b:aa", resulting in a 17-octet printable string > representation. In case of (b), the least significant 96 bits are convert= ed > to ASCII using Base64 encoding [RFC4648], resulting in a 16-octet string > representation. > > -acbegen > > > Kevin > > > > On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) > wrote: > > Kevin, > > > > -----Original Message----- > > From: "Ali C. Begen" > > Date: Monday, November 5, 2012 7:02 PM > > To: Kevin Gross > > Cc: "avt@ietf.org" > > Subject: Re: [AVTCORE] FW: New Version Notification for > > draft-rescorla-avtcore-6222bis-00.txt > > > > >>Second bullet point in section 4.2 Item (b): Proposes truncating our > nice > > >>96-bit random CNAME to 48 bits. I think we have an unacceptable > > >>opportunity for duplication with this approach. This CNAME should > > >>probably use RFC 4648 in which case these CNAMEs > > >>take the same form as the per-session CNAMES but differ in the > > >>requirement to create once at software initialization. Is it necessar= y > > >>for the different types of CNAMEs to have different appearance? > > > > > >I don=B9t think there is such a requirement and your suggestion makes > sense. > > > > Thinking more about this, I think the current text is good. Item (a) us= es > > 48-bit MAC addresses. So, even if we use truncating in item (b), its > > collision probability will not be any worse than item (a)'s. Note that > > both item (a) and (b) use 17-octet string representation whereas the > > per-session CNAME uses 16-octet string representation. > > > > Let me know if you think otherwise. > > > > -acbegen > > > > > > --f46d04446b21e0bdd704d7581335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's technically sound. Editorially speaking, this new (b) method is = already described in the third bullet point in section 4.2. Hopefully the a= uthors can find a way to reference that instead of repeating it.

Separately, I note that section 5 allows you to create unique id= entifiers with more than 96 bits. I now don't see anywhere where you= 9;re allowed to use more than 96 bits so I question why we include that fle= xibility.

Kevin Gross

+1-303-447-0517

M= edia Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

On Wed, Mar 6, 2013 at 9:03 PM, Ali C. B= egen (abegen) <abegen@cisco.com> wrote:

Picking up this old thread.

On Jan 13, 2013, at 7:14 AM, Kevin Gross <kevin.gross@avanw.com> wrote:

> Sorry for the delay responding. I do think otherwise. (a) is fine beca= use OUI registration prevents collisions. (b) relies on statistics to preve= nt collisions. There's not enough entropy in 48-bit number to statistic= ally prevent collisions in a larger population of participants. See http:/= /en.wikipedia.org/wiki/Birthday_problem. 96-bits is where things are wo= rkable.
>

What about this:

... After obtaining an identifier in case of (a), the 48 bits are converted= to the standard colon-separated hexadecimal format [RFC5342], e.g., "= 00:23:32:af:9b:aa", resulting in a 17-octet printable string represent= ation. In case of (b), the least significant 96 bits are converted to ASCII= using Base64 encoding [RFC4648], resulting in a 16-octet string representa= tion.

-acbegen

> Kevin
>
> On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> Kevin,
>
> -----Original Message-----
> From: "Ali C. Begen" <abegen@cisco.com>
> Date: Monday, November 5, 2012 7:02 PM
> To: Kevin Gross <kevin.gro= ss@avanw.com>
> Cc: "avt@ietf.org" <<= a href=3D"mailto:avt@ietf.org">avt@ietf.org>
> Subject: Re: [AVTCORE] FW: New Version Notification for
> draft-rescorla-avtcore-6222bis-00.txt
>
> >>Second bullet point in section 4.2 Item (b): Proposes truncati= ng our nice
> >>96-bit random CNAME to 48 bits. I think we have an unacceptabl= e
> >>opportunity for duplication with this approach. This CNAME sho= uld
> >>probably use RFC 4648 in which case these CNAMEs
> >>take the same form as the per-session CNAMES but differ in the=
> >>requirement to create once at software initialization. Is it n= ecessary
> >>for the different types of CNAMEs to have different appearance= ?
> >
> >I don=B9t think there is such a requirement and your suggestion ma= kes sense.
>
> Thinking more about this, I think the current text is good. Item (a) u= ses
> 48-bit MAC addresses. So, even if we use truncating in item (b), its > collision probability will not be any worse than item (a)'s. Note = that
> both item (a) and (b) use 17-octet string representation whereas the > per-session CNAME uses 16-octet string representation.
>
> Let me know if you think otherwise.
>
> -acbegen
>
>

--f46d04446b21e0bdd704d7581335-- From abegen@cisco.com Fri Mar 8 14:17:05 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8E21F8598 for ; Fri, 8 Mar 2013 14:17:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdRj0A0Y48tp for ; Fri, 8 Mar 2013 14:17:03 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DAA3C21F8595 for ; Fri, 8 Mar 2013 14:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3431; q=dns/txt; s=iport; t=1362781022; x=1363990622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UDp/w6AFTdThOiExJs6j98G8I9bEp158/gQRU5BiX3U=; b=GMwVW21bjX7JxLzy60N1TAzijxWQF9fa/hMjOvHXwJD3e7NlJLuNuGE3 l73rsWOjET8RWRCXYUJ8acIfJrI5tJLFl7B0D0aA1jmQRXi85WwgQrAcP 5yJzU9kGvX5z9B4pbTrhW0OhkgDy7wiK/8Ygh9isgl85CUJlFOLG9s4yS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAE1iOlGtJV2c/2dsb2JhbABAA4Q4wBeBXRZ0giwBAQEDAUkuAgUHBAIBCBEDAQIBCiQyHQgCBA4FCIgFBgELu3iNQIEZAiEQBwYLgk5hA4g7nwqBVIE2gic X-IronPort-AV: E=Sophos;i="4.84,810,1355097600"; d="scan'208";a="185504412" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 08 Mar 2013 22:17:02 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r28MH2mX023924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 22:17:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 16:17:02 -0600 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt Thread-Index: AQHOGujK1GhhnwNp7kueTxjcPqQXh5iazfuAgADtsYA= Date: Fri, 8 Mar 2013 22:17:01 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.152.107] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6CBB3782AE4D534F87BC043ABEACBE9B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 22:17:05 -0000 On Mar 8, 2013, at 3:19 AM, Kevin Gross wrote: > That's technically sound. Editorially speaking, this new (b) method is al= ready described in the third bullet point in section 4.2. Hopefully the aut= hors can find a way to reference that instead of repeating it. >=20 Editorially, I like the straightforward version, if you don't mind. > Separately, I note that section 5 allows you to create unique identifiers= with more than 96 bits. I now don't see anywhere where you're allowed to u= se more than 96 bits so I question why we include that flexibility. That part says "to compromise between packet size and uniqueness - refer to= Section 6.1". So, I think if one does not care about the packet size, he c= an use longer bits. > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org >=20 >=20 > On Wed, Mar 6, 2013 at 9:03 PM, Ali C. Begen (abegen) = wrote: > Picking up this old thread. >=20 > On Jan 13, 2013, at 7:14 AM, Kevin Gross wrote: >=20 > > Sorry for the delay responding. I do think otherwise. (a) is fine becau= se OUI registration prevents collisions. (b) relies on statistics to preven= t collisions. There's not enough entropy in 48-bit number to statistically = prevent collisions in a larger population of participants. See http://en.wi= kipedia.org/wiki/Birthday_problem. 96-bits is where things are workable. > > >=20 > What about this: >=20 > ... After obtaining an identifier in case of (a), the 48 bits are convert= ed to the standard colon-separated hexadecimal format [RFC5342], e.g., "00:= 23:32:af:9b:aa", resulting in a 17-octet printable string representation. I= n case of (b), the least significant 96 bits are converted to ASCII using B= ase64 encoding [RFC4648], resulting in a 16-octet string representation. >=20 > -acbegen >=20 > > Kevin > > > > On Sat, Dec 29, 2012 at 2:48 PM, Ali C. Begen (abegen) wrote: > > Kevin, > > > > -----Original Message----- > > From: "Ali C. Begen" > > Date: Monday, November 5, 2012 7:02 PM > > To: Kevin Gross > > Cc: "avt@ietf.org" > > Subject: Re: [AVTCORE] FW: New Version Notification for > > draft-rescorla-avtcore-6222bis-00.txt > > > > >>Second bullet point in section 4.2 Item (b): Proposes truncating our = nice > > >>96-bit random CNAME to 48 bits. I think we have an unacceptable > > >>opportunity for duplication with this approach. This CNAME should > > >>probably use RFC 4648 in which case these CNAMEs > > >>take the same form as the per-session CNAMES but differ in the > > >>requirement to create once at software initialization. Is it necessar= y > > >>for the different types of CNAMEs to have different appearance? > > > > > >I don=B9t think there is such a requirement and your suggestion makes = sense. > > > > Thinking more about this, I think the current text is good. Item (a) us= es > > 48-bit MAC addresses. So, even if we use truncating in item (b), its > > collision probability will not be any worse than item (a)'s. Note that > > both item (a) and (b) use 17-octet string representation whereas the > > per-session CNAME uses 16-octet string representation. > > > > Let me know if you think otherwise. > > > > -acbegen > > > > >=20 >=20 From kevin.gross@avanw.com Fri Mar 8 19:35:12 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC07F21F86F2 for ; Fri, 8 Mar 2013 19:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[AWL=3.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeJb4B3Wh0M0 for ; Fri, 8 Mar 2013 19:35:11 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id A75CA21F86C8 for ; Fri, 8 Mar 2013 19:35:05 -0800 (PST) Received: (qmail 25439 invoked by uid 0); 9 Mar 2013 03:34:40 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 9 Mar 2013 03:34:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=SGynIqWrQZkQ3XOMO7DEgF+XddpssqYn5cd10e3TvBc=; b=TUukJpLM4okchiYhc+zikVlykZsTtXry/Ls9zGJ4lOofzZESmT35ASLTN7ghKV6t3pxDXQM3yqmWHCV90DZ5J8bLhft/3rrPqwsG3b9emt4kcK89yhYXdltrKGaNHZGE; Received: from [209.85.223.174] (port=64384 helo=mail-ie0-f174.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UEAYS-0007lu-5L for avt@ietf.org; Fri, 08 Mar 2013 20:34:40 -0700 Received: by mail-ie0-f174.google.com with SMTP id k10so2890547iea.33 for ; Fri, 08 Mar 2013 19:34:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.108.235 with SMTP id hn11mr1037630igb.107.1362800079344; Fri, 08 Mar 2013 19:34:39 -0800 (PST) Received: by 10.50.183.163 with HTTP; Fri, 8 Mar 2013 19:34:39 -0800 (PST) In-Reply-To: References:

Date: Fri, 8 Mar 2013 20:34:39 -0700 Message-ID: From: Kevin Gross To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=f46d0402aeefa1223804d7759ea8 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.174 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 03:35:12 -0000 --f46d0402aeefa1223804d7759ea8 Content-Type: text/plain; charset=ISO-8859-1 Stuff below Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Fri, Mar 8, 2013 at 3:17 PM, Ali C. Begen (abegen) wrote: > > On Mar 8, 2013, at 3:19 AM, Kevin Gross wrote: > > > That's technically sound. Editorially speaking, this new (b) method is > already described in the third bullet point in section 4.2. Hopefully the > authors can find a way to reference that instead of repeating it. > > > Editorially, I like the straightforward version, if you don't mind. > Author's choice as far as I'm concerned. > > > Separately, I note that section 5 allows you to create unique > identifiers with more than 96 bits. I now don't see anywhere where you're > allowed to use more than 96 bits so I question why we include that > flexibility. > > That part says "to compromise between packet size and uniqueness - refer > to Section 6.1". So, I think if one does not care about the packet size, he > can use longer bits. > > It also says "the least significant 96 bits are used to generate an identifier". To resolve this, we're first going to need to clarify the language here. "Are" needs to be changed to SHOULD or SHALL. This language problem exists in the other two bullet points in section 4.2. If we choose SHOULD, that gives implementations leeway to use longer (or shorter) per-session CNAMES and I will rethdraw my comment. I had been reading "are" and "is" in these paragraphs as SHALL. Do you think the draft intended SHOULD or SHALL for these requirements? --f46d0402aeefa1223804d7759ea8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Stuff below

Kevin Gross

+1-303-447= -0517

Media Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

On Fri, Mar 8, 2013 at 3:17 PM, Ali C. B= egen (abegen) <abegen@cisco.com> wrote:

On Mar 8, 2013, at 3:19 AM, Kevin Gross <kevin.gross@avanw.com> wrote:

> That's technically sound. Editorially speaking, this new (b) metho= d is already described in the third bullet point in section 4.2. Hopefully = the authors can find a way to reference that instead of repeating it.
>

Editorially, I like the straightforward version, if you don't min= d.

Author's choice as far as I'= m concerned.

=A0

> Separately, I note that section 5 allows you to create unique identifi= ers with more than 96 bits. I now don't see anywhere where you're a= llowed to use more than 96 bits so I question why we include that flexibili= ty.

That part says "to compromise between packet size and uniqueness= - refer to Section 6.1". So, I think if one does not care about the p= acket size, he can use longer bits.

I= t also says "the least significant 96 bi= ts are used to generate an=A0identifie= r". To resolve this, we're first going to need to clarify the lang= uage here. "Are" needs to be changed to SHOULD or SHALL.=A0This language problem exists in the other t= wo bullet points in section 4.2.=A0If we choose SHOULD, that gives implemen= tations leeway to use longer (or shorter) per-session CNAMES and I will ret= hdraw my comment. I had been reading "are" and "is" in = these paragraphs as SHALL. Do you think the draft intended SHOULD or SHALL = for these requirements?

--f46d0402aeefa1223804d7759ea8-- From abegen@cisco.com Sat Mar 9 01:52:03 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80621F859A for ; Sat, 9 Mar 2013 01:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhlhn4eONiPb for ; Sat, 9 Mar 2013 01:52:02 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3020321F857A for ; Sat, 9 Mar 2013 01:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1362822722; x=1364032322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wZ4ZTO30gJompDx16e+t9wb4iOsum1uf6wD+4bBgnnQ=; b=T2YDBHRr2uIgJpgONeuphWzlp/rNkpN8O0w8uw2m23TvSFjoG31bxtDH 7GFT7g+j9cWuJdJ8UYaIwUFkOCAC8McLW6OBEpfJwtqLwRVMpCa7uPwPd Kr+fYyIb9xeLX2F8fkB/HKP2hHpuyWFHru1m58x5xIk/qvW0ZbK/X1L/b w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIwFO1GtJV2b/2dsb2JhbAA/A4Q9wCWBXxZ0giwBAQEDAUkuAgULAgEIGAokMiUCBA4FCIgFBgG7M45ZAiEQBxGCTmEDiDufDIFUgTaCJw X-IronPort-AV: E=Sophos;i="4.84,813,1355097600"; d="scan'208";a="182623628" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 09 Mar 2013 09:52:01 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r299q1xS004619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Mar 2013 09:52:01 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Sat, 9 Mar 2013 03:52:01 -0600 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt Thread-Index: AQHOGujK1GhhnwNp7kueTxjcPqQXh5iazfuAgADtsYCAAWEmgIAAaXmA Date: Sat, 9 Mar 2013 09:52:00 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.145.96] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <87895D314E08604DA912CECC6C9FE4DE@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-rescorla-avtcore-6222bis-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 09:52:03 -0000 On Mar 8, 2013, at 7:34 PM, Kevin Gross wrote: > Stuff below >=20 > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com, www.X192.org >=20 >=20 > On Fri, Mar 8, 2013 at 3:17 PM, Ali C. Begen (abegen) = wrote: >=20 > On Mar 8, 2013, at 3:19 AM, Kevin Gross wrote: >=20 > > That's technically sound. Editorially speaking, this new (b) method is = already described in the third bullet point in section 4.2. Hopefully the a= uthors can find a way to reference that instead of repeating it. > > > Editorially, I like the straightforward version, if you don't mind. >=20 > Author's choice as far as I'm concerned. > =20 >=20 > > Separately, I note that section 5 allows you to create unique identifie= rs with more than 96 bits. I now don't see anywhere where you're allowed to= use more than 96 bits so I question why we include that flexibility. >=20 > That part says "to compromise between packet size and uniqueness - refer = to Section 6.1". So, I think if one does not care about the packet size, he= can use longer bits. >=20 > It also says "the least significant 96 bits are used to generate an ident= ifier". To resolve this, we're first going to need to clarify the language = here. "Are" needs to be changed to SHOULD or SHALL. This language problem e= xists in the other two bullet points in section 4.2. If we choose SHOULD, t= hat gives implementations leeway to use longer (or shorter) per-session CNA= MES and I will rethdraw my comment. I had been reading "are" and "is" in th= ese paragraphs as SHALL. Do you think the draft intended SHOULD or SHALL fo= r these requirements? OK, I see your point. SHOULD should address your concern and I am ok to cha= nge it that way. I will make these changes once the submission is open. Thanks. -acbegen From magnus.westerlund@ericsson.com Sun Mar 10 07:28:19 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0AA21F86B1 for ; Sun, 10 Mar 2013 07:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-zrUz18rMY7 for ; Sun, 10 Mar 2013 07:28:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B28921F86AF for ; Sun, 10 Mar 2013 07:28:18 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ec-513c98806d75 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 90.34.10459.0889C315; Sun, 10 Mar 2013 15:28:16 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sun, 10 Mar 2013 15:28:15 +0100 Message-ID: <513C987D.8010902@ericsson.com> Date: Sun, 10 Mar 2013 10:28:13 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Magnus Westerlund References: <50FD0BE9.90709@ericsson.com> In-Reply-To: <50FD0BE9.90709@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Rrdhhk2gQdNyfYuXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcejJcbaCP3wVR3etZWlgnM/TxcjJISFgIrF88WV2CFtM4sK9 9WwgtpDASUaJzkleXYxcQPZyRolPWzawgiR4BbQlbk47ygJiswioSly43gUWZxOwkLj5oxGo mYNDVCBY4uZiOYhyQYmTM5+AlYsImEk8nLAfbD6zgJLE3KWvmUFsYQEviXf717GCtAoJaEr8 +QFWwimgJXHiwzI2iNMkJba8aGeHaNWTmHK1hRHClpdo3jqbGeJkbYmGpg7WCYxCs5BsnoWk ZRaSlgWMzKsY2XMTM3PSyw03MQJD8uCW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QD47Tk4t4QXs2AzGPZLOF9pwoZo75LFk/5fnbyjFNz+I45/iy0ib85 M3nr675vz48dvOlm9612X75XiId2unxhM891t39S1n/FPS2yRG6urZSftoq7u2Hb3gzWh9e7 zsgdWCaiKRhdfcZc+jmnx/W2Dkcxv9Lm7/5VscuDGoXfZUlfPc8+qUNDiaU4I9FQi7moOBEA 3ksKGxcCAAA= Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG last call (Second) on draft-ietf-avtcore-idms-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:28:19 -0000 WG, There has been some time since this WG last call ended. I am bit worried about the lack of feedback on the call. Can at least the persons previously commenting on this say if they are happy with all the changes? We will progress this documents publication as soon as its normative dependencies (draft-ietf-avtcore-clksrc) are ready to go with it. Cheers Magnus On 2013-01-21 04:35, Magnus Westerlund wrote: > WG, > > This is a second WG last call on the "Inter-destination Media > Synchronization using the RTP Control Protocol (RTCP)" due to the > significant changes from the previously last called version. > > Please provide your feedback no later than the 4th of February. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms > > 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 Core Maintenance > 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 csp@csperkins.org Sun Mar 10 13:16:21 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A433D21F8873 for ; Sun, 10 Mar 2013 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0bFEJL-GiQ3 for ; Sun, 10 Mar 2013 13:16:20 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7F13E21F8869 for ; Sun, 10 Mar 2013 13:16:20 -0700 (PDT) Received: from [130.129.134.52] (port=50758) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UEmfC-0004Tm-4o for avt@ietf.org; Sun, 10 Mar 2013 20:16:10 +0000 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Mar 2013 16:16:07 -0400 Message-Id: To: "avt@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Subject: [AVTCORE] draft-ietf-avtcore-rtp-circuit-breakers-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 20:16:21 -0000 We submitted an update to the RTP circuit breakers draft just before the = cut-off, and I'll be presenting and discussing it in AVTCORE on Tuesday. = The significant changes in the -02 version are: - Disallow rate reduction by a factor of 10 as a response when the media = timeout circuit breaker is triggered. A media timeout (several reporting = intervals when media is being set but not received) signals a = significant path failure, rather than a transient problem, and so should = stop the RTP media flow, not just reduce it's rate. - Clarify RTCP Timeout circuit breaker, and note that the fixed minimum = RTCP reporting intervals SHOULD be used when calculating the RTCP = timeout based on the rationale in Section 6.2 of RFC 3550. - Clarify that the congestion circuit breaker uses the reduced minimum = interval, rather than the fixed minimum interval, if it's in use in the = RTP session. The reduced minimum interval scales with the data rate and = so matches the dynamics of the congestion circuit breaker. - Break the description of what it means to cease transmission into a separate section, and expand. Clarify that we look at the destination = 3-tuple (transport, port, IP addr) rather than the full 5-tuple when deciding when to restart (to prevent someone thinking it's okay to simply change the source port, and try again) - Clarify that reduced-size RTCP packets containing RTCP SR or RR = packets sent under the RTP/AVPF rules MUST be counted towards the = circuit breaker conditions. Reduced size RTCP packets that don't contain = SR or RR packets are not counted towards the circuit breaker. These = rules are intended to allow the use of low-overhead early RTP/AVPF = feedback for generic NACK messages without triggering the RTP circuit = breaker. This is expected to make such feedback suitable for RTP = congestion control algorithms that need to quickly report loss events in = between regular RTCP reports. The reaction to reduced-size RTCP SR/RR = packets is to allow such algorithms to send feedback that can trigger = the circuit breaker, when desired. - Expand discussion of how and when ECN-CE marks are counted towards the circuit breaker. RFC 6679 provides RTCP extensions to feed back ECN-CE = marks in RTCP XR, and these are counted towards the circuit breaker. = ECN-CE marks reported in a reduced size RTCP packet along with an SR or = RR block are processed; if the SR or RR block is not present, they're = ignored. In addition, there are a number of minor changes: - Update title and abstract - Explain why multicast circuit breakers are out of scope - Explain why the numbers of SSRCs might be greater than two in a = unicast RTP session - Note that RTCP is an essential part of the RTP protocol, and that the = circuit breaker cannot be used if RTCP is not implemented. Clarify that = implementations that don't have a circuit breaker (or equivalent) SHOULD = NOT be used on networks that might be subject to congestion. - Clarify that the RTCP RR jitter estimate is only valid where each RTP = packet comprises one complete frame of media (i.e., the estimate is not = valid if a frame gets split across multiple RTP packets with the same = timestamp). - Expand discussion of competition with TCP flows - Clarify operation of congestion circuit breaker if the fraction lost = is zero - Clarify that the circuit breaker at a sender only looks at RTCP SR/RR = packets that contain reports for the SSRC values it is using to send --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Sun Mar 10 20:16:03 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8221F8522; Sun, 10 Mar 2013 20:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJtfAOiz8-az; Sun, 10 Mar 2013 20:16:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC5F21F86DE; Sun, 10 Mar 2013 20:16:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130311031602.27199.40366.idtracker@ietfa.amsl.com> Date: Sun, 10 Mar 2013 20:16:02 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 03:16:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-01.txt Pages : 11 Date : 2013-03-10 Abstract: 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. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Mon Mar 11 11:48:56 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3121F8EB7 for ; Mon, 11 Mar 2013 11:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.532 X-Spam-Level: X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[AWL=2.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YS09NkKUZeHp for ; Mon, 11 Mar 2013 11:48:55 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 26C2821F8EAB for ; Mon, 11 Mar 2013 11:48:55 -0700 (PDT) Received: (qmail 23656 invoked by uid 0); 11 Mar 2013 18:48:28 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 11 Mar 2013 18:48:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=SY4bCXl1MRXcisS/zzND7PoRyeBM3YimV23h6cAyQvo=; b=MT9yc2cnmZeX6dU1sKGx6CtI8L3fwApzlQihpyYSgTIqmudgLjCMVnGbZW1Qpvn0SiSe82ZW8HEj2qbOatIGHQbJ6WeELkaNGn40AbpoWe6A6HkbQ3z5VPsAeRJJa9Tt; Received: from [209.85.223.181] (port=59995 helo=mail-ie0-f181.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UF7ls-0003fA-3l for avt@ietf.org; Mon, 11 Mar 2013 12:48:28 -0600 Received: by mail-ie0-f181.google.com with SMTP id 17so5125094iea.40 for ; Mon, 11 Mar 2013 11:48:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.122.66 with SMTP id m2mr9551801icr.15.1363027658675; Mon, 11 Mar 2013 11:47:38 -0700 (PDT) Received: by 10.50.183.163 with HTTP; Mon, 11 Mar 2013 11:47:38 -0700 (PDT) In-Reply-To: <3356A75F-D992-4BFE-9CFD-9C1B12AC7FA3@amsl.com> References: <3356A75F-D992-4BFE-9CFD-9C1B12AC7FA3@amsl.com> Date: Mon, 11 Mar 2013 12:47:38 -0600 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=20cf3003bbb66a224904d7aa9b23 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.181 authed with kevin.gross@avanw.com} Subject: [AVTCORE] Fwd: [86all] 86th IETF Agenda Changes X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:48:56 -0000 --20cf3003bbb66a224904d7aa9b23 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't know how ripe for misunderstanding this actually is, but one person I talked to interpreted this to mean that there would be no AVTCORE meeting at IETF86. We're still meeting at 13:00 tomorrow (Tuesday). Only the second AVTCORE session was cancelled. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org ---------- Forwarded message ---------- From: Wanda Lo Date: Sun, Mar 10, 2013 at 9:10 AM Subject: [86all] 86th IETF Agenda Changes To: 86all@ietf.org Please note the following changes on your printed pocket agenda: *MONDAY, March 11, 2013* 1300-1530 Afternoon Session I Boca 1 TSV ppsp Peer to Peer Streaming Protocol WG =96 = * CANCELED* ** ** *TUESDAY, March 12, 2013* 0900-1020 Morning Session I**** Caribbean 4 INT intarea Internet Area Working Group WG =96 *Now Starts at 1030* ** ** *THURSDAY, March 14, 2013* 1730-1830 Afternoon Session III**** Caribbean 5 RAI avtcore Audio/Video Transport Core Maintenance WG =96 *CANCELED***** ** ** Once again, the web agenda is always the most up to date,**** https://datatracker.ietf.org/meeting/86/agenda.txt**** ** ** ** ** Thanks,**** Wanda**** =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**** Wanda Lo / Project Manager**** Internet Engineering Task Force (IETF)**** ****48377 Fremont Blvd., Ste. 117** **Fremont**, **California** **94538**** / ****USA**** T: +1.510.492.4082 F: +1.510.492.4001 *www.ietf.org***** **** *--*** Managed by Association Management Solutions (AMS)**** Forum Management, Meeting and Event Planning**** www.amsl.com _______________________________________________ 86all mailing list 86all@ietf.org https://www.ietf.org/mailman/listinfo/86all --20cf3003bbb66a224904d7aa9b23 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't know how ripe for misunderstanding this=A0actually=A0is, but on= e person I talked to interpreted this to mean that there would be no AVTCOR= E meeting at IETF86. We're still meeting at 13:00 tomorrow (Tuesday). O= nly the second AVTCORE session was cancelled.

Kevin Gross

+1-303-447-0517

Media = Network Consultant

AVA Networks -=A0www.AVAnw.com,=A0www.X192.org

---------- Forwarded message ----------<= br>From: Wanda Lo <<= a href=3D"mailto:wlo@amsl.com">wlo@amsl.com>
Date: Sun, Ma= r 10, 2013 at 9:10 AM
Subject: [86all] 86th IETF Agenda Changes
To: 86all@ietf.org

Please note the following changes on your printed pocket agenda:

MONDAY, March 11, 2013=

1300-1530=A0 Afternoon Session I

Boca 1=A0=A0= =A0=A0=A0=A0=A0=A0=A0 TSV =A0=A0=A0 ppsp=A0=A0=A0=A0=A0=A0=A0 Peer to Peer = Streaming Protocol WG =96 CANCELED

= =A0

TUESDAY, March 12, 2013

0900-1020=A0= Morning Session I

Caribbean 4=A0=A0 INT = =A0=A0 intarea=A0=A0=A0=A0 Internet Area Working Group = WG =96 Now Starts at 1030

=A0<= /span>

THURS= DAY, March 14, 2013

1730-1830=A0 Afternoon Session I= II

Caribbean 5= =A0=A0 RAI =A0=A0 avtcore=A0=A0=A0=A0 Audi= o/Video Transport Core Maintenance WG =96 CANCELED

=A0

Once again, the web agenda is always the most up to date,

https://datatracker.ietf.org/meeting/86/agenda.txt

=A0

Thanks,

Wanda

=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

Wanda Lo / Proj= ect Manager

Internet Engine= ering Task Force (IETF)

<= /u>48= 377 Fremont Blvd., Ste. 117=A0
Fremont,=A0California=A094538=A0/=A0USA=A0
T: +1.510.492.4082=
F: +1.510.492.4001=A0
www.ietf.org

=A0

Managed by Association Management Solutions (AMS)

For= um Management, Meeting and Event Planning

www.amsl.com

_______________________________________________
86all mailing list
86all@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/86all

--20cf3003bbb66a224904d7aa9b23-- From ron.even.tlv@gmail.com Mon Mar 11 12:18:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1FD11E8121 for ; Mon, 11 Mar 2013 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhIbUJ2uq6YI for ; Mon, 11 Mar 2013 12:18:42 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 164A211E8120 for ; Mon, 11 Mar 2013 12:18:42 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4092227pbb.18 for ; Mon, 11 Mar 2013 12:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=ri2cjArCgP3eCEzR8jMXwv9u+VOj1cnOY8LKWe5P/8w=; b=gYSVda1jhnJzbprZbqrNiq/pv2f3WBKInh/P26YhATjZj4cF4xLc+FayG46RqMtlXc 2gwr+1t2XI+9W/uUlLadwj5qZ9L0fJ7Mz+jXNaLQrsA7kreQmpwBSOW9Oh3WV5WvPYIz QskEZMm/+8oO6iT6p5CIsVGol6Tgqtj9vuDaOqjgf/hzO/oRW7bSK8Zg9Ocki/8a/ZYp oaZyACynOpRQT4xdV9Rtv+xnrY9yDE/0IJ3wKiKya8FjSS5KyzvMf3qndVSpBiA9qL5n 1pS2cQe0DrbgeKqVCp53WJ5pOL90jacXq8SVsePeNoPUf1AHiB+ig3Yg4un25ly/E/lH o0zg== X-Received: by 10.68.232.162 with SMTP id tp2mr30442436pbc.192.1363029521673; Mon, 11 Mar 2013 12:18:41 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:cd47:2a8d:32c6:8262]) by mx.google.com with ESMTPS id iu10sm21587047pbc.13.2013.03.11.12.18.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Mar 2013 12:18:39 -0700 (PDT) From: "Roni Even" To: "'Kevin Gross'" , References: <3356A75F-D992-4BFE-9CFD-9C1B12AC7FA3@amsl.com> In-Reply-To: Date: Mon, 11 Mar 2013 21:18:15 +0200 Message-ID: <006501ce1e8d$30e5c670$92b15350$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01CE1E9D.F46FCEF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGgg21MTiiB9/2kXrSphfJQCGizogFZ5nuTmPFEGnA= Content-Language: en-us Subject: Re: [AVTCORE] Fwd: [86all] 86th IETF Agenda Changes X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 19:18:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0066_01CE1E9D.F46FCEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kevin, You are right, We only cancelled the Thursday session. The Tuesday session is on. Roni From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin Gross Sent: 11 March, 2013 8:48 PM To: avt@ietf.org Subject: [AVTCORE] Fwd: [86all] 86th IETF Agenda Changes I don't know how ripe for misunderstanding this actually is, but one person I talked to interpreted this to mean that there would be no AVTCORE meeting at IETF86. We're still meeting at 13:00 tomorrow (Tuesday). Only the second AVTCORE session was cancelled. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org ---------- Forwarded message ---------- From: Wanda Lo Date: Sun, Mar 10, 2013 at 9:10 AM Subject: [86all] 86th IETF Agenda Changes To: 86all@ietf.org Please note the following changes on your printed pocket agenda: MONDAY, March 11, 2013 1300-1530 Afternoon Session I Boca 1 TSV ppsp Peer to Peer Streaming Protocol WG - CANCELED TUESDAY, March 12, 2013 0900-1020 Morning Session I Caribbean 4 INT intarea Internet Area Working Group WG - Now Starts at 1030 THURSDAY, March 14, 2013 1730-1830 Afternoon Session III Caribbean 5 RAI avtcore Audio/Video Transport Core Maintenance WG - CANCELED Once again, the web agenda is always the most up to date, https://datatracker.ietf.org/meeting/86/agenda.txt Thanks, Wanda =========================== Wanda Lo / Project Manager Internet Engineering Task Force (IETF) 48377 Fremont Blvd., Ste. 117 Fremont, California 94538 / USA T: +1.510.492.4082 F: +1.510.492.4001 www.ietf.org -- Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ 86all mailing list 86all@ietf.org https://www.ietf.org/mailman/listinfo/86all ------=_NextPart_000_0066_01CE1E9D.F46FCEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Kevin,
You are right, We only cancelled the Thursday session. The Tuesday = session is on.

Roni

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross
Sent: 11 March, 2013 8:48 PM
To: = avt@ietf.org
Subject: [AVTCORE] Fwd: [86all] 86th IETF Agenda = Changes

I don't know = how ripe for misunderstanding this actually is, but one person = I talked to interpreted this to mean that there would be no AVTCORE = meeting at IETF86. We're still meeting at 13:00 tomorrow (Tuesday). Only = the second AVTCORE session was cancelled.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com, www.X192.org

---------- Forwarded = message ----------
From: Wanda Lo <wlo@amsl.com>
Date: Sun, Mar 10, = 2013 at 9:10 AM
Subject: [86all] 86th IETF Agenda Changes
To: 86all@ietf.org

<= div>
Please note the following = changes on your printed pocket agenda:
MONDAY, March 11, = 2013
1300-1530 Afternoon = Session I
Boca = 1          TSV =     ppsp        Peer = to Peer Streaming Protocol WG – = CANCELED

TUESDAY, March 12, = 2013
0900-1020 Morning = Session I
Caribbean 4   INT =    intarea     Internet Area Working Group = WG – Now Starts at 1030

THURSDAY, March 14, = 2013
1730-1830 Afternoon = Session III
Caribbean 5   RAI =    avtcore     Audio/Video Transport Core = Maintenance WG – CANCELED

Once again, the = web agenda is always the most up to date,
https://datatracker.ietf.org/m= eeting/86/agenda.txt

Thanks,
<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospac= e:none'>Wanda

=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=
Wanda Lo / = Project Manager
Internet = Engineering Task Force (IETF)
48377 = Fremont Blvd., Ste. = 117
Fremont, California 94538 / USA T: +1.510.492.4082
F: +1.510.492.4001
www.ietf.org
=

--
Managed by = Association Management Solutions = (AMS)
Forum = Management, Meeting and Event = Planning
www.amsl.com
&nbs= p;
&nbs= p;

______________________________________= _________
86all mailing list
86all@ietf.org
https://www.ietf.org/mailman/listinfo/86all

------=_NextPart_000_0066_01CE1E9D.F46FCEF0-- From abegen@cisco.com Mon Mar 11 15:32:09 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD25221F8D67 for ; Mon, 11 Mar 2013 15:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.969 X-Spam-Level: X-Spam-Status: No, score=-9.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTXmSY0n8DbM for ; Mon, 11 Mar 2013 15:32:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0A93121F8D5D for ; Mon, 11 Mar 2013 15:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3778; q=dns/txt; s=iport; t=1363041129; x=1364250729; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=vq1f0LeQImIxzyO8IK5CzTb0fTdo/EDHVNrS8Iih69E=; b=aQ52hPIb5XKAtrFKC3uvSQtGfGz9T1mxf8UcSMmtKNv2DMexNOpOvezl KkTwhpNwUIHq69lx21upf444jjd+j8vn94C4s2Loia1Z+vr2PtBjicnvy OXumCTaQiAUaChMlm+UlyHZof90eJzF2UtrbVkDMZuWDbLK/6TLHaCNgy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAGFaPlGtJXG8/2dsb2JhbABDhDyBE4JavDtpdBZtB4IpAQEBBAEBASARUQYBCBEDAQIDAgYgAgQlCxUGAQEFAwIEEwgBiAoBBgWeJ45VklyBI406FhASBl2BSjJhA5dzj1eCfQ2CKA X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186294451" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 11 Mar 2013 22:32:08 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2BMW8hl031986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Mar 2013 22:32:08 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 17:32:08 -0500 From: "Ali C. Begen (abegen)" To: "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-01.txt Thread-Index: AQHOHgbGfj4bECOS7Uyum6wf56PwBJihJTsA Date: Mon, 11 Mar 2013 22:32:07 +0000 Message-ID: In-Reply-To: <20130311031602.27199.40366.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.252.165] Content-Type: text/plain; charset="utf-8" Content-ID: <8EB1FF12CA91D446A1509309E57DFAF5@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [AVTCORE] FW: I-D Action: draft-ietf-avtcore-6222bis-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:32:09 -0000 VGhpcyB2ZXJzaW9uIGhhcyBhIGZldyBjaGFuZ2VzIHRoYXQgc2hvdWxkIGFkZHJlc3MgS2V2aW4g Ry4ncyBjb21tZW50cy4gQXMNCmZhciBhcyB0aGUgYXV0aG9ycyBhcmUgY29uY2VybmVkLCB0aGVy ZSBhcmUgbm8gb3BlbiBpc3N1ZXMgcmVtYWluaW5nLg0KUGxlYXNlIHJldmlldyBhbmQgcG9zdCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LCBpZiBhbnkuIFdlIHNob3VsZCBiZQ0KYWJsZSB0byBs YXN0IGNhbGwgdGhpcyBwcmV0dHkgc29vbiBJTU8uDQoNCi1hY2JlZ2VuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPg0KRGF0ZTogU3VuZGF5LCBNYXJjaCAxMCwgMjAxMyAxMToxNiBQ TQ0KVG86ICJpLWQtYW5ub3VuY2VAaWV0Zi5vcmciIDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQpD YzogImF2dEBpZXRmLm9yZyIgPGF2dEBpZXRmLm9yZz4NClN1YmplY3Q6IFtBVlRDT1JFXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMS50eHQNCg0KPg0KPkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cw0KPmRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdWRp by9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPldvcmtpbmcgR3JvdXAgb2YgdGhl IElFVEYuDQo+DQo+CVRpdGxlICAgICAgICAgICA6IEd1aWRlbGluZXMgZm9yIENob29zaW5nIFJU UCBDb250cm9sIFByb3RvY29sIChSVENQKQ0KPkNhbm9uaWNhbCBOYW1lcyAoQ05BTUVzKQ0KPglB dXRob3IocykgICAgICAgOiBBbGkgQmVnZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIENv bGluIFBlcmtpbnMNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIERhbiBXaW5nDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICBFcmljIFJlc2NvcmxhDQo+CUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzLTAxLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAxMQ0K PglEYXRlICAgICAgICAgICAgOiAyMDEzLTAzLTEwDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhlIFJU UCBDb250cm9sIFByb3RvY29sIChSVENQKSBDYW5vbmljYWwgTmFtZSAoQ05BTUUpIGlzIGENCj4g ICBwZXJzaXN0ZW50IHRyYW5zcG9ydC1sZXZlbCBpZGVudGlmaWVyIGZvciBhbiBSVFAgZW5kcG9p bnQuICBXaGlsZSB0aGUNCj4gICBTeW5jaHJvbml6YXRpb24gU291cmNlIChTU1JDKSBpZGVudGlm aWVyIG9mIGFuIFJUUCBlbmRwb2ludCBtYXkNCj4gICBjaGFuZ2UgaWYgYSBjb2xsaXNpb24gaXMg ZGV0ZWN0ZWQgb3Igd2hlbiB0aGUgUlRQIGFwcGxpY2F0aW9uIGlzDQo+ICAgcmVzdGFydGVkLCBp dHMgUlRDUCBDTkFNRSBpcyBtZWFudCB0byBzdGF5IHVuY2hhbmdlZCwgc28gdGhhdCBSVFANCj4g ICBlbmRwb2ludHMgY2FuIGJlIHVuaXF1ZWx5IGlkZW50aWZpZWQgYW5kIGFzc29jaWF0ZWQgd2l0 aCB0aGVpciBSVFANCj4gICBtZWRpYSBzdHJlYW1zLg0KPg0KPiAgIEZvciBwcm9wZXIgZnVuY3Rp b25hbGl0eSwgUlRDUCBDTkFNRXMgc2hvdWxkIGJlIHVuaXF1ZSB3aXRoaW4gdGhlDQo+ICAgcGFy dGljaXBhbnRzIG9mIGFuIFJUUCBzZXNzaW9uLiAgSG93ZXZlciwgdGhlIGV4aXN0aW5nIGd1aWRl bGluZXMgZm9yDQo+ICAgY2hvb3NpbmcgdGhlIFJUQ1AgQ05BTUUgcHJvdmlkZWQgaW4gdGhlIFJU UCBzdGFuZGFyZCBhcmUgaW5zdWZmaWNpZW50DQo+ICAgdG8gYWNoaWV2ZSB0aGlzIHVuaXF1ZW5l c3MuICBSRkMgNjIyMiB3YXMgcHVibGlzaGVkIHRvIHVwZGF0ZSB0aG9zZQ0KPiAgIGd1aWRlbGlu ZXMgdG8gYWxsb3cgZW5kcG9pbnRzIHRvIGNob29zZSB1bmlxdWUgUlRDUCBDTkFNRXMuDQo+ICAg VW5mb3J0dW5hdGVseSwgbGF0ZXIgaW52ZXN0aWdhdGlvbnMgc2hvd2VkIHRoYXQgc29tZSBwYXJ0 cyBvZiB0aGUgbmV3DQo+ICAgYWxnb3JpdGhtcyB3ZXJlIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0 ZWQgYW5kL29yIGluZWZmZWN0aXZlLiAgVGhpcw0KPiAgIGRvY3VtZW50IGFkZHJlc3NlcyB0aGVz ZSBjb25jZXJucyBhbmQgcmVwbGFjZXMgUkZDIDYyMjIuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMNCj4NCj5UaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KPg0KPkEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KPg0KPg0KPkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg TWFpbnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2F2dA0KPg0KDQoNCg== From internet-drafts@ietf.org Tue Mar 12 10:14:25 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F306C21F8A40; Tue, 12 Mar 2013 10:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1nm5SweU8r5; Tue, 12 Mar 2013 10:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1724721F8A74; Tue, 12 Mar 2013 10:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.42 Message-ID: <20130312171424.29659.43946.idtracker@ietfa.amsl.com> Date: Tue, 12 Mar 2013 10:14:24 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:14:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Update to Recommended Codecs for the RTP Profile for Aud= io and Video Conferences with Minimal Control (RTP/AVP) Author(s) : Timothy B. Terriberry Filename : draft-ietf-avtcore-avp-codecs-01.txt Pages : 3 Date : 2013-03-12 Abstract: [RFC3551] defines the AVP RTP profile, which is the basis for many other profiles, such as SAVP [RFC3711], AVPF [RFC4585], and SAVPF [RFC5124]. This document updates [RFC3551] (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-avp-codecs-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-avp-codecs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Tue Mar 12 10:18:51 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78211E80FB for ; Tue, 12 Mar 2013 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NikFfzmEtwth for ; Tue, 12 Mar 2013 10:18:49 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5731F11E80F7 for ; Tue, 12 Mar 2013 10:18:49 -0700 (PDT) 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 r2CHIRmP020171 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 18:18:48 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 18:18:41 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 18:18:40 +0100 From: "DRAGE, Keith (Keith)" To: "Brandenburg, R. (Ray) van" , "avt@ietf.org" Thread-Topic: New version of IDMS draft Thread-Index: Ac30y0R0A3EuA40XQ6uphQnYln+PPAqekXxg Date: Tue, 12 Mar 2013 17:18:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B012430@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B012430FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [AVTCORE] New version of IDMS draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:18:51 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B012430FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I checked the IANA considerations and they now look fine to me. Keith ________________________________ From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl] Sent: 17 January 2013 15:57 To: avt@ietf.org Cc: DRAGE, Keith (Keith); Roni Even (ron.even.tlv@gmail.com) Subject: New version of IDMS draft Dear WG, I've just uploaded a new version of the IDMS draft. The main changes in the= draft are related to the draft's relationship with the ETSI IPTV specifica= tion. In earlier versions of the draft, the draft included some normative r= eferences to an XR block specified by ETSI. In this new version, all such r= eferences have been removed and this IETF draft is now the normative specif= ication for all matters related to IDMS. We have coordinated with ETSI such that ETSI will update its specification = to point to this draft as the normative specification for IDMS once it beco= mes an RFC. Other changes in the draft relate to the sections on SDP and IANA considera= tions, after very careful review by some SDP experts. HTML: http://tools.ietf.org/html/draft-ietf-avtcore-idms-08 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-08 Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_949EF20990823C4C85C18D59AA11AD8B012430FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I checked the IANA considerations and = they now look fine to me.

Keith

From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]
Sent: 17 January 2013 15:57<= br> To: avt@ietf.org
Cc: DRAGE, Keith (Keith); Ro= ni Even (ron.even.tlv@gmail.com)
Subject: New version of IDMS= draft

Dear WG,

I’ve just uploaded a new version of the IDMS dra= ft. The main changes in the draft are related to the draft’s relation= ship with the ETSI IPTV specification. In earlier versions of the draft, the draft included some normative refere= nces to an XR block specified by ETSI. In this new version, all such refere= nces have been removed and this IETF draft is now the normative specificati= on for all matters related to IDMS.

We have coordinated with ETSI such that ETSI will upda= te its specification to point to this draft as the normative specification = for IDMS once it becomes an RFC.

Other changes in the draft relate to the sections on S= DP and IANA considerations, after very careful review by some SDP experts.

HTML: http://to= ols.ietf.org/html/draft-ietf-avtcore-idms-08

Diff: h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-08=

Best regards,

Ray

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_949EF20990823C4C85C18D59AA11AD8B012430FR712WXCHMBA11zeu_-- From magnus.westerlund@ericsson.com Tue Mar 12 12:02:59 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A011E81B5 for ; Tue, 12 Mar 2013 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.187 X-Spam-Level: X-Spam-Status: No, score=-106.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SagRVosMowv for ; Tue, 12 Mar 2013 12:02:58 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C411E819F for ; Tue, 12 Mar 2013 12:02:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ef-513f7be05e65 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F7.5E.10459.0EB7F315; Tue, 12 Mar 2013 20:02:56 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 20:02:56 +0100 Message-ID: <513F7BDD.8010700@ericsson.com> Date: Tue, 12 Mar 2013 15:02:53 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvje6DavtAg7NXbSxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpFHq1kKbrFVfFu2hrWB8RBrFyMnh4SAicT/dVOhbDGJC/fW s4HYQgInGSUWbYzqYuQCspczSvybuxcswSugLTHr6nZmEJtFQFVix4lb7CA2m4CFxM0fjUA1 HByiAsESNxfLQZQLSpyc+YQFxBYRUJLYMWkbWKuwgKXEpnV97BB7JSW2vGgHs5kF9CSmXG1h hLDlJZq3zmaGuEdboqGpg3UCI/8sJGNnIWmZhaRlASPzKkb23MTMnPRyw02MwGA6uOW37g7G U+dEDjFKc7AoifOGuV4IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBYOrlD9xuf1a+oheUG c/8+VVJe8raS92XMb1P5Q/sWywpOKoroMZdZK2Xyn0knL96o+vl3O98Zur77tPq2bgn656ng u2b6pLiJiVe+9j6bWGqx/7LK87TDLnutFRq9Hq+39tDfzrjrmMvSkAOzV6dHXP57688qj1nL pXYvOqmm4Gsn2SD78tcUJZbijERDLeai4kQAJI1duPQBAAA= Subject: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:02:59 -0000 WG, This is to announce the start of a WG last call on: Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) to be published as a proposed standard. Document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs Please provide any feedback by the 31st of March. Regards Magnus Westerlund WG chair ---------------------------------------------------------------------- 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 Tue Mar 12 12:05:14 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2596311E81B9 for ; Tue, 12 Mar 2013 12:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.191 X-Spam-Level: X-Spam-Status: No, score=-106.191 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQTS1OYC7AIN for ; Tue, 12 Mar 2013 12:05:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6669A11E8180 for ; Tue, 12 Mar 2013 12:05:12 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-02-513f7c67dbe9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 41.7E.32353.76C7F315; Tue, 12 Mar 2013 20:05:11 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 12 Mar 2013 20:05:01 +0100 Message-ID: <513F7C5B.5060101@ericsson.com> Date: Tue, 12 Mar 2013 15:04:59 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJMWRmVeSWpSXmKPExsUyM+JvjW56jX2gwaH7EhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49au7awFW9gq7h64z9bAuIS1i5GTQ0LARGJz11Y2CFtM4sK9 9WC2kMBJRol5D/W7GLmA7OWMEq/mrmDuYuTg4BXQltj5XxmkhkVAVWLTtQVgc9gELCRu/mhk AykRFQiWuLlYDiTMKyAocXLmExYQW0RASWLHpG3MILawgJnE5Fk3oU6QlNjyop0dxGYW0JOY crWFEcKWl2jeOpsZ4hxtiYamDtYJjPyzkIydhaRlFpKWBYzMqxjZcxMzc9LLzTcxAkPp4Jbf BjsYN90XO8QozcGiJM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj2qL2C5W7pYwv hn7a9I7xo95OpoxjB+4ufz2rovbrvw0dO+WCH8Xsev3g9jWlM8ezczIVbz6a3ii8I/Pli0nx rksn7jH7Gy3Vf3XDDJfzMqvE1l/8LnymuTheZPPrf2d7iw56z2/T0nvnHKe3Vcf3V4yz0VS1 3xuT5kQ/+HgiaMqi9jUVwWHthUosxRmJhlrMRcWJAEMtsKrzAQAA Subject: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:05:14 -0000 WG, This is to announce the start of a WG last call on: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) to be published as a proposed standard. Document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ Please provide any feedback by the 31st of March. Regards Magnus Westerlund WG chair ---------------------------------------------------------------------- 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 vsingh.ietf@gmail.com Tue Mar 12 12:18:14 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE011E8191 for ; Tue, 12 Mar 2013 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLRhDqscJNpo for ; Tue, 12 Mar 2013 12:18:14 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96E11E813F for ; Tue, 12 Mar 2013 12:18:14 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id k14so302845iea.13 for ; Tue, 12 Mar 2013 12:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=Ah36F5YsU4/sTetdWQN8h7K7kiVGyJmS0Zk7Z9ssGas=; b=v7p/iGbACQV/UNUSsF2RnrigzgpshW+/KUa/8u2oXHICcmS04bnFZrvZ6UygpDgND5 R3J7nvRG+Vrd0igy4APeB/22C88cpJD650994k2skoj0TWCwjX5kSuueEUaaXnZiGOS/ sFMucw4NwBl45Z7VgQfb1mSOQYx7LQBWpir006njpeYHOQ946wbana5PiFEwOFdeDryC 55iXmvDZV5xqCfbt8R58jJaluO8NZnhTghyLQi/0Zg6fICkSvsm0Q8s9nqNyf8RGnMiL jUsve9dsUxZO/+H4HHZeCku8jF6EqVrQsLb348ooTax6m2dGeqlXWROsyAJQ9678WFyr zKIQ== X-Received: by 10.42.150.131 with SMTP id a3mr13380540icw.8.1363115893807; Tue, 12 Mar 2013 12:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Tue, 12 Mar 2013 12:17:53 -0700 (PDT) From: Varun Singh Date: Tue, 12 Mar 2013 15:17:53 -0400 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [AVTCORE] Multipath RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:18:15 -0000 Hi all, Since our last presentation (in Paris/Vancouver), we've updated the draft. The SDP interface advertisement has been split into a corresponding MMUSIC draft. Reviews and Comments to the draft(s) are appreciated: http://tools.ietf.org/html/draft-singh-avtcore-mprtp if you have read an earlier version and would like to review just the changes, see http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-06.txt&url1=draft-singh-avtcore-mprtp-04.txt The MMUSIC draft is: http://tools.ietf.org/html/draft-singh-mmusic-mprtp-sdp-extension The scheduling algorithm which is not part of the IETF drafts, (because the end-points can implement their own) is discussed in a research paper: http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf Cheers, Varun -- http://www.netlab.tkk.fi/~varun/ From keith.drage@alcatel-lucent.com Tue Mar 12 13:40:16 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E13E11E80F0 for ; Tue, 12 Mar 2013 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.982 X-Spam-Level: X-Spam-Status: No, score=-109.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjCCL9+kI1ys for ; Tue, 12 Mar 2013 13:40:15 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB4711E80AE for ; Tue, 12 Mar 2013 13:40:15 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2CKeCXB023890 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 Mar 2013 21:40:12 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Mar 2013 21:40:11 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 21:40:11 +0100 From: "DRAGE, Keith (Keith)" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 Thread-Index: AQHOH1R1RMrWvv/s+EKJs+Bv7hGL2piig1og Date: Tue, 12 Mar 2013 20:40:11 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0128BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <513F7BDD.8010700@ericsson.com> In-Reply-To: <513F7BDD.8010700@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:40:16 -0000 I'm trying to parse the final sentence of the change made to RFC 3551. Essentially this i-d modifies: " Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol." To become: " Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload type 0 (PCMU). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. Some environments MAY make support for PCMU mandatory." What the final sentence currently says is that some environments provide an= option to make support for PCMU mandatory, which implies that other enviro= nments do not provide such an option. Neither of those make sense to me and= there I believe that cannot be the meaning. I suspect we are looking for sentence that looks more like "Some environmen= ts REQUIRE support for PCMU", but I am not sure if there is an "only" float= ing around in there somewhere. Regards Keith > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: 12 March 2013 19:03 > To: IETF AVTCore WG > Subject: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 >=20 > WG, >=20 > This is to announce the start of a WG last call on: >=20 > Update to Recommended Codecs for the RTP Profile for Audio and Video > Conferences with Minimal Control (RTP/AVP) to be published as a proposed > standard. >=20 > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs >=20 > Please provide any feedback by the 31st of March. >=20 > Regards >=20 > Magnus Westerlund > WG chair >=20 >=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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From mary.ietf.barnes@gmail.com Tue Mar 12 14:24:33 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379C421F85DB for ; Tue, 12 Mar 2013 14:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.751 X-Spam-Level: X-Spam-Status: No, score=-103.751 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKVkhfN0b+M7 for ; Tue, 12 Mar 2013 14:24:32 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id A1C4C11E80AE for ; Tue, 12 Mar 2013 14:24:31 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j8so1869091qah.20 for ; Tue, 12 Mar 2013 14:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=/Hjwt30H087nnAWUUqW/0zdPC9lODgiHlG8L4E+tEHc=; b=QJNzEJG1Om+3u3UgqqSWSv/hZao/3KsvzHzUZb7Nas42Wrm5Pvy57N+bWEK7xsnoWo zkr0K/3u5Awxyqd3tGX5f98T46oMTv2ItaOXoY4cw1W0OXcwmWbumRXMabF7TsiNsZYs tZzlwczY6Iy9uE3YRVZH7psy4V7CtVUP9P//29fuSEAwUrX9jaWDlx/bsm7lPu7W15E7 uDJhjbEavdqhnUkmj3BCV+hEUmiLxNA2eFvVx7SgUuZwEb4gLsQZVuY2njEYK4327LhI CX18ykc9Vx/uhZscYjx7EQDC38V3HCFI42frs9bKAGWw3W/Y/hNCB3DJqLU1BeGZCKpv +N5w== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr24067315qab.43.1363123471228; Tue, 12 Mar 2013 14:24:31 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Tue, 12 Mar 2013 14:24:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 16:24:31 -0500 Message-ID: From: Mary Barnes To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [AVTCORE] Fwd: WCIT Bof X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:24:33 -0000 FYI... this is the BoF I mentioned at the microphone in the AVTCORE session earlier today. Regards, Mary. ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, Mar 12, 2013 at 8:33 AM Subject: WCIT Bof To: "rai@ietf.org" Cc: DISPATCH Hi all, Since the AVTCORE WG session on Thursday afternoon was cancelled (17:30-18:30), folks might be interested in attending the WCIT Bof. Rather than summarize myself what it is, the agenda has some background: https://datatracker.ietf.org/meeting/86/agenda/iab-wcit/ Some of this may eventually (and likely will) impact SIP networks/service providers. Regards, Mary. From denglingli@gmail.com Thu Mar 14 21:49:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E103721F906A for ; Thu, 14 Mar 2013 21:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjx08eFk0WZ5 for ; Thu, 14 Mar 2013 21:49:47 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 92DAB21F906F for ; Thu, 14 Mar 2013 21:49:44 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so3267059pbc.29 for ; Thu, 14 Mar 2013 21:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:content-transfer-encoding:subject :mime-version:from:message-id:date:cc:to:x-mailer; bh=qAvtH7PCUV8zbCaI4HkbOEZjSLTlzw3mO1fxt8C2B+8=; b=X995JsFizppubd5hPU0RGI7DKgjdzn3MXc6CI1iinOMl+QW/Wu00mxtaCR2Ly7srj1 YpRy+dtdwKM21QC84S562BCvlc/2xi/O4nAv7gTIbZ1xNWQlcvcP5s2pk7NU4pzFyfY3 TmuLoiDrSGLmpU5aKds9WtOtOSKthW6OAZxMMJSwg7Mlys9Qot2F1gHGV0ov4QYEMR0O 2IUHSaUZTpP2TeBAR/1y+s0WP8V97fUkqiinMpbVCBYk2Pj7+hXAmrPhgMLlIddJQuOk htrqSs5Ot5iSMnEDB1OHhZnWJz/WIPUR1m1Hro4vh0PRlYnt/RYPrC+V8Lv/PRHjpUN9 uKnA== X-Received: by 10.68.197.193 with SMTP id iw1mr12712626pbc.86.1363322984527; Thu, 14 Mar 2013 21:49:44 -0700 (PDT) Received: from [130.129.128.229] ([130.129.128.229]) by mx.google.com with ESMTPS id hu2sm6680387pbc.38.2013.03.14.21.49.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 21:49:43 -0700 (PDT) Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: denglingli@gmail.com Message-Id: <0E0F8833-99F6-46C3-A44B-FAD5EFA6A75C@gmail.com> Date: Fri, 15 Mar 2013 00:49:42 -0400 To: "vsingh.ietf@DOMAIN.HIDDEN" X-Mailer: iPad Mail (10A550) Cc: "avt@ietf.org" Subject: Re: [AVTCORE] mufti path rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 04:49:48 -0000 Hi Varuna, Impressive work.=20 Do you have any implementation that provide support for real applications?=20= Have you ever considered to apply this solution for Traffic offloading from c= ellular to wifi networks or vise visa scenarios? BR Lingli China mobile =B7=A2=D7=D4=CE=D2=B5=C4 iPad= From denglingli@gmail.com Fri Mar 15 04:44:36 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A93421F8E62 for ; Fri, 15 Mar 2013 04:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.451 X-Spam-Level: ** X-Spam-Status: No, score=2.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDlOAbWfeAu for ; Fri, 15 Mar 2013 04:44:35 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 04F0221F8E5C for ; Fri, 15 Mar 2013 04:44:34 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id fq11so1793064vbb.38 for ; Fri, 15 Mar 2013 04:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=1c/lSry/mGJ2pCGdTfAfqaCJ60TGfwuFU4Bu9uxXp/k=; b=g9XLYajcyvWi8VFR6hPdhRSjwKNo/TFNhNx5fBdTQFcxxjC98x68f0/AfKRTGAGyAC 7fhbUPVuv+i9ZUXudvkqL5ClnNdAUySfNbB3aEuiFS1+VZ71/AiX64hYdqz4uqpUjojW bkla06UIuDCHWIxu2JcVz2KDFqv/deo54DVfWjO2vpqXr8oa5iDwow7nM2ZRM+VnSn57 qZ/RDfJRsmewXHae2W13fedwXb55AkJ3GGydOn2sCmID2QX+ZThTEGHBJoFKmfPHxt/t 1kmRMYfa9Zq0aj2R5wEzmaoyQPoAXsxngg1oiwKeoMdrK8p1zMICRMkt8bZWhPS33RMm 5Wcw== MIME-Version: 1.0 X-Received: by 10.52.90.140 with SMTP id bw12mr5581125vdb.50.1363347874281; Fri, 15 Mar 2013 04:44:34 -0700 (PDT) Received: by 10.58.169.45 with HTTP; Fri, 15 Mar 2013 04:44:34 -0700 (PDT) Date: Fri, 15 Mar 2013 19:44:34 +0800 Message-ID: From: lingli deng To: csp@csperkins.org Content-Type: multipart/alternative; boundary=20cf307f34d4c0ace804d7f52913 Cc: avt@ietf.org Subject: Re: [AVTCORE] draft-ietf-avtcore-rtp-circuit-breakers-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 11:44:36 -0000 --20cf307f34d4c0ace804d7f52913 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello Colin, To be honest, this is a really informative and well-written document. However, I do have a couple of concerns to post. A general one, the current algorithm is based on packet loss or equivalent events (as indicated by ECN-CE marks) only, which is aimed at setting a safe net for all RTP CC algorithms above. I am afraid this may result in severe unfairness against RTP over UDP streams in wireless accessing scenarios since: 1) There is likely to be consistent packet loss due to the unstable and sensitive nature of wirelss channels, average 2% for stable signal and can reach 5% on moving vehicle. Using the TCP bandwith calculation fomula in the draft, it is expected that when packet loss rate increase from 1% to 2%, the compliant RTP streams would lose 30% bandwidth. When the rate further increases from 2% to 5%, the limit further drops another 80%. I would not consider that to be fair. 2) On the other hand, there have been various TCP CC algorithms to improve TCP throughput for mobile devices. It is true that neither of them gained prevalence in end-systems. However, it may change the picture if the operator does something in between. Right now, China Mobile is experimenting deploying TCP proxies to enhance downlink throughput which basically ignores random losses. And it is common practice that DCs deploy such proxies to enhance user experience. In other words, computing TCP compliant bandwidth limit using Reno/NewReno may be too conservative. ECN is helpful, but to my knowledge they are mostly unsupported or turned off in cellular accessing networks. It may seem reasonable to add delay based detection for the triggering the algorithm, especially for the intial phase of the call. An other small issue: In section 4.4, it states "RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the sender has received information that the congestion has dissipated."] I wonder if the RTP flows are halted there is likely to be no further information about the congestion unless from the outside of RTP stack, meaning in most cases no automatical restart thereafter. Is this what you have in mind? Otherwise, some more clarification about how to acquire further information on congeston may help. BR --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --20cf307f34d4c0ace804d7f52913 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hello Colin,

To be honest,= this is a really informative and well-written document.
However,= I do have a couple of concerns to post.

A gener= al one, the current algorithm is based on packet loss or equivalent ev= ents (as indicated by ECN-CE marks) only, which is aimed at setting a safe = net for all RTP CC algorithms above. I am afraid this may result in se= vere unfairness against RTP over UDP streams in wireless accessing sce= narios since:

1) There is likely to be consistent packet loss due t= o the unstable and sensitive nature of wirelss channels, average 2% for sta= ble signal and can reach 5% on moving vehicle. Using the TCP bandwith calcu= lation fomula in the draft, it is expected that when packet loss rate incre= ase from 1% to 2%, the compliant RTP streams would lose 30% bandwidth. When= the rate further increases from 2% to 5%, the limit further drops another = 80%. I would not consider that to be fair.

2) On the other hand, there have been various TCP CC = algorithms to improve TCP throughput for mobile devices. It is true that ne= ither of them gained prevalence in end-systems. However, it may change the = picture if the operator does something in between. Right now, China Mobile = is experimenting deploying TCP proxies to enhance downlink throughput which= basically ignores random losses. And it is common practice that DCs d= eploy such proxies to enhance user experience. In other words, computing TC= P compliant bandwidth limit using Reno/NewReno may be too conservative.

ECN is helpful, but to my knowledge they are mostly unsuppo= rted or turned off in cellular accessing networks.

It= may seem reasonable to add delay based detection for the triggering t= he algorithm, especially for the intial phase of the call.

An other small issue:

In s= ection 4.4, it states "RTP flows halted by the circuit breaker SHOULD = NOT be restarted automatically unless the sender has received informat= ion that the congestion has dissipated."]

I wonder if the RTP flows are halted there is likely = to be no further information about the congestion unless from the outside o= f RTP stack, meaning in most cases no automatical restart thereafter. Is th= is what you have in mind? Otherwise, some more clarification about how to a= cquire further information on congeston may help.

BR

--
=B5=CB=C1=E9=C0= =F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/C= hina Mobile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--20cf307f34d4c0ace804d7f52913-- From vsingh.ietf@gmail.com Fri Mar 15 09:17:40 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F76C21F8746 for ; Fri, 15 Mar 2013 09:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+koCvtRfbyu for ; Fri, 15 Mar 2013 09:17:39 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8921F86D4 for ; Fri, 15 Mar 2013 09:17:38 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id c11so4613476ieb.1 for ; Fri, 15 Mar 2013 09:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:from:in-reply-to:mime-version:date:message-id :subject:to:cc:content-type; bh=2kiLpfU0pgxGudR08GHJYfJcnfZyju6vIzboulRBPc8=; b=aUw8UTEplmAnUPY3rbEsOiREyQav4F64jch0QiwCsXqjYzKkaD1QHsKkV8cFqSUzlO ZPBuRDDL2vnM/z1/AXBtb6SYOsfXPvHFIKPL4oKRJOt6Ql/N8i58PMNv9KSlKQYzw/Uo t4HiKL9BIQRRV9FwL1LTJy/RIZbZ1OHTRDqxOwICkm7IZ9MUElNyt0rA0mA7LgZzV2bB cqG4Hk5Rqi8uXzJW0fyYjvGQpHwEnKhnR6YLaTOiv+NnCn47g7JEowpXmugn8hfovEuv L7BZ/Qg3ysPGO7ou5sidH1esdM2pNG8wLqNjOn1U1g1jMr8RaYgoe/rJjTTtH+4qnsH5 u59w== X-Received: by 10.50.47.168 with SMTP id e8mr1812001ign.50.1363364258118; Fri, 15 Mar 2013 09:17:38 -0700 (PDT) References: <0E0F8833-99F6-46C3-A44B-FAD5EFA6A75C@gmail.com> From: Varun Singh In-Reply-To: <0E0F8833-99F6-46C3-A44B-FAD5EFA6A75C@gmail.com> Mime-Version: 1.0 (1.0) Date: Fri, 15 Mar 2013 12:17:34 -0400 Message-ID: <-8068907073408942395@unknownmsgid> To: "denglingli@gmail.com" Content-Type: multipart/alternative; boundary=14dae9340ab14e05bd04d7f8fa61 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] mufti path rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:17:40 -0000 --14dae9340ab14e05bd04d7f8fa61 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Lingli, We are working towards releasing an open-source version of our implementation. The details will emerge over the summer. The first thing we tested with our implementation was offloading. We have some scenarios in the paper [1] that shows how load balancing can be achieved, but these can be extended for offloading. Additionally, using mobility-ice extensions may help with some of the engineering issues. There are several ways in which MPRTP can be used, therefore we don't discuss the scheduling algorithm in the draft. I urge you to look at the research paper for those details. [1] http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf Regards, Varun ---- http://www.netlab.tkk.fi/~varun On 15.3.2013, at 0.50, "denglingli@gmail.com" wrote: Hi Varuna, Impressive work. Do you have any implementation that provide support for real applications? Have you ever considered to apply this solution for Traffic offloading from cellular to wifi networks or vise visa scenarios? BR Lingli China mobile =B7=A2=D7=D4=CE=D2=B5=C4 iPad _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --14dae9340ab14e05bd04d7f8fa61 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi L= ingli,

We are working towards releasing an= open-source version of our implementation. The details will emerge over th= e summer.

The first thing we tested with our implementation wa= s offloading. We have some scenarios in the paper [1] that shows how load b= alancing can be achieved, but these can be extended for offloading. Additio= nally, using mobility-ice extensions may help with some of the engineering = issues.

There are several ways in which MPRTP can be us= ed, therefore we don't discuss the scheduling algorithm in the draft. I= urge you to look at the research paper for those details.

[1] http://www.netlab.tkk.fi/~varun/2013_MMSYS_S= ingh_MPRTP.pdf

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

On 1= 5.3.2013, at 0.50, "denglingli= @gmail.com" <denglingli= @gmail.com> wrote:

Hi Varuna,

Impressive work.
Do you have any implementation that provide support for real applicat= ions?
Have you ever= considered to apply this solution for Traffic offloading from cellular to = wifi networks or vise visa scenarios?

BR

Lingli

China mobile

=B7=A2=D7=D4=CE=D2=B5=C4 iPad
______________________________________________= _

Audio/Video Transport Core Mai= ntenance
avt@ietf.org
https://www.iet= f.org/mailman/listinfo/avt
--14dae9340ab14e05bd04d7f8fa61-- From csp@csperkins.org Mon Mar 18 03:25:04 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B3B21F8C23 for ; Mon, 18 Mar 2013 03:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02ANgSNRNt2o for ; Mon, 18 Mar 2013 03:25:03 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A721F8BF4 for ; Mon, 18 Mar 2013 03:24:59 -0700 (PDT) Received: from [130.209.247.112] (port=53466 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHXFS-0005Fd-3d; Mon, 18 Mar 2013 10:24:58 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <513F7BDD.8010700@ericsson.com> Date: Fri, 15 Mar 2013 14:05:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D87EE07-5F27-488A-BEB2-8A4E900CA890@csperkins.org> References: <513F7BDD.8010700@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:25:04 -0000 On 12 Mar 2013, at 15:02, Magnus Westerlund wrote: > This is to announce the start of a WG last call on: >=20 > Update to Recommended Codecs for the RTP Profile for Audio and Video = Conferences with Minimal Control (RTP/AVP) to be published as a proposed = standard. >=20 > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs >=20 > Please provide any feedback by the 31st of March. I just have a minor nit: the profile names are "RTP/AVP", "RTP/SAVP", = "RTP/AVPF", and "RTP/SAVPF", not just "AVP", "SAVP", "AVPF", and = "SAVPF"; it would be good if the terminology in the draft was updated to = match this. Otherwise, looks good. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Mar 18 03:25:04 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9A21F8C3C for ; Mon, 18 Mar 2013 03:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byjEyCmqNVLm for ; Mon, 18 Mar 2013 03:25:03 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7F58721F8B98 for ; Mon, 18 Mar 2013 03:24:57 -0700 (PDT) Received: from [130.209.247.112] (port=53466 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UHXF4-0005Fd-8t; Mon, 18 Mar 2013 10:24:54 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0128BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Fri, 15 Mar 2013 13:59:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1515D7F3-AEC2-4612-829F-41EB3E7A9069@csperkins.org> References: <513F7BDD.8010700@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0128BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:25:04 -0000 On 12 Mar 2013, at 16:40, DRAGE, Keith (Keith) wrote: > I'm trying to parse the final sentence of the change made to RFC 3551. >=20 > Essentially this i-d modifies: >=20 > " Audio applications operating under this profile SHOULD, at a = minimum, > be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). > This allows interoperability without format negotiation and ensures > successful negotiation with a conference control protocol." >=20 > To become: >=20 > " Audio applications operating under this profile SHOULD, at a = minimum, > be able to send and/or receive payload type 0 (PCMU). > This allows interoperability without format negotiation and ensures > successful negotiation with a conference control protocol. Some > environments MAY make support for PCMU mandatory." >=20 > What the final sentence currently says is that some environments = provide an option to make support for PCMU mandatory, which implies that = other environments do not provide such an option. Neither of those make = sense to me and there I believe that cannot be the meaning. >=20 > I suspect we are looking for sentence that looks more like "Some = environments REQUIRE support for PCMU", but I am not sure if there is an = "only" floating around in there somewhere. I don't think the draft ought to say "only". This sentence looks to be = addressing the RTCWeb use case, which makes PCMU mandatory to implement = but also allows other codecs.=20 To my reading, "Some environments MAY make support for PCMU mandatory" = and "Some environments REQUIRE support for PCMU" are equivalent, but I = have no objection to the change if you think it clearer. --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Mon Mar 18 13:23:55 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216BE21F8FAF; Mon, 18 Mar 2013 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.266 X-Spam-Level: X-Spam-Status: No, score=-98.266 tagged_above=-999 required=5 tests=[AWL=-3.998, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr8KOkKSDqHR; Mon, 18 Mar 2013 13:23:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F7C21F8F41; Mon, 18 Mar 2013 13:23:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130318202354.23043.23039.idtracker@ietfa.amsl.com> Date: Mon, 18 Mar 2013 13:23:54 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:23:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-03.txt Pages : 23 Date : 2013-03-18 Abstract: NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-clksrc-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Mar 19 07:49:05 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88421F85FC for ; Tue, 19 Mar 2013 07:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.869 X-Spam-Level: X-Spam-Status: No, score=-105.869 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vVtn366a7bD for ; Tue, 19 Mar 2013 07:49:05 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E051721F8622 for ; Tue, 19 Mar 2013 07:49:04 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-32-51487adf0650 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B1.F2.19728.FDA78415; Tue, 19 Mar 2013 15:49:03 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 19 Mar 2013 15:49:03 +0100 Message-ID: <51487ADF.5010200@ericsson.com> Date: Tue, 19 Mar 2013 15:49:03 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Magnus Westerlund References: <50FD0BE9.90709@ericsson.com> In-Reply-To: <50FD0BE9.90709@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Rvd+lUegweHPZhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48Dx28wFB/gqJu2+xdLA+J+7i5GTQ0LAROLbpZmsELaYxIV7 69m6GLk4hAROMko0f5vODuEsZ5T4P28XC0gVr4C2xOtrX5i6GDk4WARUJXZs1QYJswlYSNz8 0cgGYosKBEv8fHUGqlxQ4uTMJ2C2iICZxMMJ+8FqmAWUJOYufc0MYgsLeEm827+OFWSkkICm xJ8fYCWcAloSJz4sY4O4TVJiy4t2dohWPYkpV1sYIWx5ieats8HGCAFd1tDUwTqBUWgWks2z kLTMQtKygJF5FSN7bmJmTnq50SZGYFAe3PJbdQfjnXMihxilOViUxHnDXS8ECAmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamBMcdAsUvn/zma7ZoRcVJVBfNVXweCyxeqsy1syImttNh+wbk5x MFpt8WX9Y5/74SqdH6wtKrJsH6+6z7u5PfNO8tlmE+uJmblRFy9oJi+Y0SzWq33KKLQzfAJ3 vJS/buzs+fKXnVcwVoQfmvpuhcVmBumtpxZtiOG+NOniTsvJn9e/PVzH16TEUpyRaKjFXFSc CABWahDPGAIAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG last call (Second) on draft-ietf-avtcore-idms-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 14:49:06 -0000 Hi, I just to want to state that my previous comments have been addressed. However, I think the authors needs to address the ID-nits that exist on this document before submitting the publication request. http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-avtcore-idms-08.txt Cheers Magnus On 2013-01-21 10:35, Magnus Westerlund wrote: > WG, > > This is a second WG last call on the "Inter-destination Media > Synchronization using the RTP Control Protocol (RTCP)" due to the > significant changes from the previously last called version. > > Please provide your feedback no later than the 4th of February. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms > > 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 Core Maintenance > 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 internet-drafts@ietf.org Tue Mar 19 08:46:55 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087B321F8E0C; Tue, 19 Mar 2013 08:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.39 X-Spam-Level: X-Spam-Status: No, score=-98.39 tagged_above=-999 required=5 tests=[AWL=-3.766, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHZsXUIopAx3; Tue, 19 Mar 2013 08:46:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE2C21F8DF2; Tue, 19 Mar 2013 08:46:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130319154654.12880.61606.idtracker@ietfa.amsl.com> Date: Tue, 19 Mar 2013 08:46:54 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:46:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Inter-destination Media Synchronization using the RTP Co= ntrol Protocol (RTCP) Author(s) : Ray van Brandenburg Hans Stokking Oskar van Deventer Fernando Boronat Mario Montagud Kevin Gross Filename : draft-ietf-avtcore-idms-09.txt Pages : 22 Date : 2013-03-19 Abstract: This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Reporting Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be send to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-idms-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-idms-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ray.vanbrandenburg@tno.nl Tue Mar 19 08:59:20 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0045B21F86EB for ; Tue, 19 Mar 2013 08:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxZTbKfiwYs9 for ; Tue, 19 Mar 2013 08:59:15 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF6B21F8D37 for ; Tue, 19 Mar 2013 08:59:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,872,1355094000"; d="scan'208";a="5706205" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 19 Mar 2013 16:59:11 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.241]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 16:59:11 +0100 From: "Brandenburg, R. (Ray) van" To: Magnus Westerlund Thread-Topic: [AVTCORE] WG last call (Second) on draft-ietf-avtcore-idms-08 Thread-Index: AQHN97rExfTtzuaMI0+9qH87DFIeBZitYZKAgAAjbZA= Date: Tue, 19 Mar 2013 15:59:11 +0000 Message-ID: References: <50FD0BE9.90709@ericsson.com> <51487ADF.5010200@ericsson.com> In-Reply-To: <51487ADF.5010200@ericsson.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.153] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG last call (Second) on draft-ietf-avtcore-idms-08 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:59:20 -0000 Hi Magnus, WG, Thanks for the confirmation. I've uploaded a new draft that fixed the nits. http://tools.ietf.org/html/draft-ietf-avtcore-idms-09 Cheers, Ray -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: dinsdag 19 maart 2013 15:49 To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] WG last call (Second) on draft-ietf-avtcore-idms-08 Hi, I just to want to state that my previous comments have been addressed. However, I think the authors needs to address the ID-nits that exist on thi= s document before submitting the publication request. http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-avtc= ore-idms-08.txt Cheers Magnus On 2013-01-21 10:35, Magnus Westerlund wrote: > WG, > = > This is a second WG last call on the "Inter-destination Media = > Synchronization using the RTP Control Protocol (RTCP)" due to the = > significant changes from the previously last called version. > = > Please provide your feedback no later than the 4th of February. > = > https://datatracker.ietf.org/doc/draft-ietf-avtcore-idms > = > 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 Core Maintenance 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=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance 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/emaildisclaimer From keith.drage@alcatel-lucent.com Tue Mar 19 10:15:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77B21F8F00 for ; Tue, 19 Mar 2013 10:15:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gelovBNPD8U for ; Tue, 19 Mar 2013 10:15:37 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4421F8DD9 for ; Tue, 19 Mar 2013 10:15:37 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r2JHFSlE023012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2013 12:15:28 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r2JHFSZE017059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 13:15:28 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 19 Mar 2013 13:15:28 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 19 Mar 2013 18:15:23 +0100 From: "DRAGE, Keith (Keith)" To: Colin Perkins Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 Thread-Index: AQHOI8LhCA0R1lcTUk2XY0zvQt8uJZitLXpw Date: Tue, 19 Mar 2013 17:15:22 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0181CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <513F7BDD.8010700@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0128BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1515D7F3-AEC2-4612-829F-41EB3E7A9069@csperkins.org> In-Reply-To: <1515D7F3-AEC2-4612-829F-41EB3E7A9069@csperkins.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:15:38 -0000 I'm still confused. Surely PCMU0 was recommended before this update and is recommended now. DVI4 was recommended before this update and is now optional. I guess the result of that is that I can be conformant but implement neithe= r, although it will not be a terribly useful implementation. Regards Keith > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 15 March 2013 18:00 > To: DRAGE, Keith (Keith) > Cc: Magnus Westerlund; IETF AVTCore WG > Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 >=20 > On 12 Mar 2013, at 16:40, DRAGE, Keith (Keith) wrote: > > I'm trying to parse the final sentence of the change made to RFC 3551. > > > > Essentially this i-d modifies: > > > > " Audio applications operating under this profile SHOULD, at a minimu= m, > > be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). > > This allows interoperability without format negotiation and ensures > > successful negotiation with a conference control protocol." > > > > To become: > > > > " Audio applications operating under this profile SHOULD, at a minimu= m, > > be able to send and/or receive payload type 0 (PCMU). > > This allows interoperability without format negotiation and ensures > > successful negotiation with a conference control protocol. Some > > environments MAY make support for PCMU mandatory." > > > > What the final sentence currently says is that some environments provid= e > an option to make support for PCMU mandatory, which implies that other > environments do not provide such an option. Neither of those make sense t= o > me and there I believe that cannot be the meaning. > > > > I suspect we are looking for sentence that looks more like "Some > environments REQUIRE support for PCMU", but I am not sure if there is an > "only" floating around in there somewhere. >=20 >=20 > I don't think the draft ought to say "only". This sentence looks to be > addressing the RTCWeb use case, which makes PCMU mandatory to implement > but also allows other codecs. >=20 > To my reading, "Some environments MAY make support for PCMU mandatory" an= d > "Some environments REQUIRE support for PCMU" are equivalent, but I have n= o > objection to the change if you think it clearer. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From denglingli@gmail.com Tue Mar 19 21:07:00 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDECE21F8F1C for ; Tue, 19 Mar 2013 21:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.451 X-Spam-Level: ** X-Spam-Status: No, score=2.451 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+AGwT-BH50u for ; Tue, 19 Mar 2013 21:06:52 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 18CFB21F874A for ; Tue, 19 Mar 2013 21:06:51 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id fq11so849332vbb.10 for ; Tue, 19 Mar 2013 21:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pidC7r/UJYtmURiVQ8UapMtXr8FmUEWwZFsY0gv+DY4=; b=fZD8mbkpwKyzpRwAz/6K5DKVMehSKMGUvHtHwrTjK3LlfS7L4oAXDZBb95EYziadQT t9QdeXAGxRY76+jYjm+NGnKN9YgZ3vTp0tzny7p/7cVyXBfgym6XZqEUlojey+S3YWFt LGQX0QKhjP6Cl7ict8sB0Xt4GKJY0t42GD6+zDzwO57saIO/mWfxVdop8FIx24iGnUei yyZr1h+13+OFfZWxaL22PNVy8zDnNM9mzkIlBqfW8rC2EJHosdN3HNxg2/AuDX0PPchS 54b8EGSUSB2nh0j116NOt/VGGp9Dg22zOy0Y45QRGmzS9CbeLxq0n9pqhBBnbzMOJywf 1Yqg== MIME-Version: 1.0 X-Received: by 10.52.230.10 with SMTP id su10mr5072551vdc.50.1363752411369; Tue, 19 Mar 2013 21:06:51 -0700 (PDT) Received: by 10.58.169.45 with HTTP; Tue, 19 Mar 2013 21:06:51 -0700 (PDT) In-Reply-To: <-8068907073408942395@unknownmsgid> References: <0E0F8833-99F6-46C3-A44B-FAD5EFA6A75C@gmail.com> <-8068907073408942395@unknownmsgid> Date: Wed, 20 Mar 2013 12:06:51 +0800 Message-ID: From: lingli deng To: Varun Singh Content-Type: multipart/alternative; boundary=089e0111ae300ac5ad04d8535afb Cc: "avt@ietf.org" Subject: Re: [AVTCORE] mufti path rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 04:07:01 -0000 --089e0111ae300ac5ad04d8535afb Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Varun,**** ** ** Thank you for your sharing~**** The paper is well-written and easy to follow, to which I have the following comments:**** ** ** **1) **Firstly, although it may be out of scope for the current multi-rtp draft, but I kind of believe that the performance evaluation (between multipath and singlepath) on packet loss rate and PSNR is not sufficient for interactive real-time communication apps. Since the user perceived RTT delay ( or equivalently the MPRTP stack=A1=AFs application=A1=AFs perceived= RTT delay) is not included as a metric. What concerns me is that, delay screwing may eat up all the potential benefit of multiple paths, if the increased RTT is above the tolerable threshold set by application. Therefore, I would suggest to add a suite of tests between the QoE gained from single-path transferring on the most promising candidate channel (e.g. the one with the biggest bandwidth and tolerable RTT) to multi-path transferring solution.**** ** ** As matter of fact, the current scheduling algorithm is not delay centric and provides no hard protection for tolerable RTT requirements as it bases its decision for the most important I-frame streams according to the channel with the highest bandwidth/delay ratio. This could lead to suboptimal scheduling results if some of channels looks better in ratio but actually is unacceptable in terms of RTT constraint.**** ** ** **2) **Secondly, even though the paper stresses the work is orthogonal to congestion control, I can=A1=AFt help but thinking that the interaction bet= ween individual CC mechanism for sub-flows channels and the application (or codec) rate control mechanism seems to be at the heart of maximizing QoE boost gained from heterogeneous channels instead of doing simple traffic partition for CBR media flows. **** ** ** It may be straightforward to borrow the current work in RTP CC algorithms in RMCAT WG here. But I still believe there may be case for two-level rate control in MPRTP stack, which means interfaces for cross-layer status-sharing and coordinated rate control needs to be considered.**** ** ** **3) **Moreover, in this paper, to yield non-linear monitory overhead for sub-flow RTCP traffic, each sub-RTCP traffic is limited according to the sub-flow rate of media traffic. It is a clever choice, but one may wonder given the fact that the unfairness among the sampling and reporting activity may transfer to the unfairness in cross-channel traffic offloading and finally hold the ultimate application=A1=AFs loss in QoE. If the source code is available, we would like to participate and do some more exploration. BR Lingli**** 2013/3/16 Varun Singh > Hi Lingli, > > We are working towards releasing an open-source version of our > implementation. The details will emerge over the summer. > > The first thing we tested with our implementation was offloading. We have > some scenarios in the paper [1] that shows how load balancing can be > achieved, but these can be extended for offloading. Additionally, using > mobility-ice extensions may help with some of the engineering issues. > > There are several ways in which MPRTP can be used, therefore we don't > discuss the scheduling algorithm in the draft. I urge you to look at the > research paper for those details. > > [1] http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf > > Regards, > Varun > > ---- > http://www.netlab.tkk.fi/~varun > > > On 15.3.2013, at 0.50, "denglingli@gmail.com" > wrote: > > Hi Varuna, > > > Impressive work. > > Do you have any implementation that provide support for real applications= ? > > Have you ever considered to apply this solution for Traffic offloading > from cellular to wifi networks or vise visa scenarios? > > > BR > > > Lingli > > China mobile > > > =B7=A2=D7=D4=CE=D2=B5=C4 iPad > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --089e0111ae300ac5ad04d8535afb Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi Varun,
=

T= hank you for your sharing~
= The paper is well-written and easy to follow, to which I have the following= comments:

1) = Firstly, although it may b= e out of scope for the current multi-rtp draft, but I kind of believe that = the performance evaluation (between multipath and singlepath) on packet los= s rate and PSNR is not sufficient for interactive real-time communication a= pps. Since the user perceived RTT delay ( or equivalently the MPRTP stack&r= squo;s application’s perceived RTT delay) is not included as a metric= . What concerns me is that, delay screwing may eat up all the potential ben= efit of multiple paths, if the increased RTT is above the tolerable thresho= ld set by application. Therefore, I would suggest to add a suite of tests b= etween the QoE gained from single-path transferring on the most promising c= andidate channel (e.g. the one with the biggest bandwidth and tolerable RTT= ) to multi-path transferring solution.

As matter of fact, the current scheduling algorit= hm is not delay centric and provides no hard protection for tolerable RTT r= equirements as it bases its decision for the most important I-frame streams= according to the channel with the highest bandwidth/delay ratio. This coul= d lead to suboptimal scheduling results if some of channels looks better in= ratio but actually is unacceptable in terms of RTT constraint.

2) = Secondly, even though the = paper stresses the work is orthogonal to congestion control, I can’t = help but thinking that the interaction between individual CC mechanism for = sub-flows channels and the application (or codec) rate control mechanism se= ems to be at the heart of maximizing QoE boost gained from heterogeneous ch= annels instead of doing simple traffic partition for CBR media flows.

It may be straightforward to borrow the current w= ork in RTP CC algorithms in RMCAT WG here. But I still believe there may be= case for two-level rate control in MPRTP stack, which means interfaces for= cross-layer status-sharing and coordinated rate control needs to be consid= ered.

3) = Moreover, in this paper,= to yield non-linear monitory overhead for sub-flow RTCP traffic, each sub-= RTCP traffic is limited according to the sub-flow rate of media traffic. It= is a clever choice, but one may wonder given the fact that the unfairness = among the sampling and reporting activity may transfer to the unfairness in= cross-channel traffic offloading and finally hold the ultimate application= ’s loss in QoE.

If the source code is ava= ilable, we would like to participate and do some more exploration.

BR
Lingli

2013/3/= 16 Varun Singh <vsingh.ietf@gmail.com>

Hi Lingli,
<= span>
We are working towards releasing an open-source versi= on of our implementation. The details will emerge over the summer. <= br>
The first thing we tested with our implementation wa= s offloading. We have some scenarios in the paper [1] that shows how load b= alancing can be achieved, but these can be extended for offloading. Additio= nally, using mobility-ice extensions may help with some of the engineering = issues.

There are several ways in which MPRTP can be us= ed, therefore we don't discuss the scheduling algorithm in the draft. I= urge you to look at the research paper for those details.

[1] http://www.netlab.tkk.fi= /~varun/2013_MMSYS_Singh_MPRTP.pdf

Regards,
Varun

----
http://www.netlab.tkk.fi/~varun

On 15.3.2013, at 0.50, "denglingli@gmail.com" <<= a href=3D"mailto:denglingli@gmail.com" target=3D"_blank">denglingli@gmail.c= om> wrote:

Hi Varuna,

Impressive work.
Do you have any implementation that provide support for real applicat= ions?
Have you ever= considered to apply this solution for Traffic offloading from cellular to = wifi networks or vise visa scenarios?

BR

Lingli

China mobile

=B7=A2=D7=D4=CE=D2=B5=C4 iPad
_______________________________________________

Audio/Video Transport Core Mai= ntenance
avt@ietf.org

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

--
=B5=CB=C1=E9=C0=F2/Ling= li Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mob= ile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
--089e0111ae300ac5ad04d8535afb-- From vsingh.ietf@gmail.com Wed Mar 20 06:55:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91D521F8D46 for ; Wed, 20 Mar 2013 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPE0DpwiPcIo for ; Wed, 20 Mar 2013 06:55:36 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B5BAE21F8D3C for ; Wed, 20 Mar 2013 06:55:36 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id k10so2004224iea.19 for ; Wed, 20 Mar 2013 06:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Zizsp8lzAKCltolhJ08YufrXwny1Jy+rkPixKgSeb1w=; b=I+Mx25AQjku91q0fCjC0pod4rAkWS6xkmd4O9+ClDCWsoCOCKoj/w6zpBB0iFMyu8X eW/Uj4FiPQUivah/iWx4ZQF3McUId9Vs/V/CiIZfT/jcbAsVMojFYz1QNWvBRUHVg934 L6aPEb4NU+jIvDJKzrCc7Je6py/sW5tLNwQwYNsYQQVKzbXG7fPtfN0uU6m+gFtWnVLT cF1+zJS65ZwUpIuftzDm29uXbxZ+/98N8bP0sLRWiVmz1cWFuz53u1+9AO5MN7q5lmrS obtoy2ObYZhiPzgORdlXNbVB5vk3H5J+g8MCtDiaxa3V3MnG55D1pUj4eJBo5/3RSA8l H2qw== X-Received: by 10.50.6.202 with SMTP id d10mr4167868iga.28.1363787736282; Wed, 20 Mar 2013 06:55:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.152.7 with HTTP; Wed, 20 Mar 2013 06:55:16 -0700 (PDT) In-Reply-To: References: <0E0F8833-99F6-46C3-A44B-FAD5EFA6A75C@gmail.com> <-8068907073408942395@unknownmsgid> From: Varun Singh Date: Wed, 20 Mar 2013 15:55:16 +0200 Message-ID: To: lingli deng Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "avt@ietf.org" Subject: Re: [AVTCORE] mufti path rtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:55:39 -0000 Hi Lingli, comments inline. On Wed, Mar 20, 2013 at 6:06 AM, lingli deng wrote: > Hi Varun, > > Thank you for your sharing~ > > The paper is well-written and easy to follow, to which I have the followi= ng > comments: > > 1) Firstly, although it may be out of scope for the current multi-rtp dra= ft, > but I kind of believe that the performance evaluation (between multipath = and > singlepath) on packet loss rate and PSNR is not sufficient for interactiv= e > real-time communication apps. Since the user perceived RTT delay ( or We can compare the PSNR because we use the same media in all our experiments. Moreover, packets that arrive late are discarded. However, I agree we have not done a QoE evaluation, so cannot really comment on user perceived annoyances. > equivalently the MPRTP stack=A1=AFs application=A1=AFs perceived RTT dela= y) is not > included as a metric. What concerns me is that, delay screwing may eat up > all the potential benefit of multiple paths, if the increased RTT is abov= e > the tolerable threshold set by application. Therefore, I would suggest to In our experiments, we let the application choose the tolerable skew betwee= n path delays. For example, the skew tolerance for media streaming will be hi= gher than that for live streaming and much lower for interactive multimedia. Also in our experiments, if the RTT of a path was above the acceptable dela= y chosen by the application, it would try and ignore the path. > add a suite of tests between the QoE gained from single-path transferring= on > the most promising candidate channel (e.g. the one with the biggest > bandwidth and tolerable RTT) to multi-path transferring solution. > I agree and the endpoint only chooses paths which meets the RTT requirement= s. > As matter of fact, the current scheduling algorithm is not delay centric = and > provides no hard protection for tolerable RTT requirements as it bases it= s > decision for the most important I-frame streams according to the channel > with the highest bandwidth/delay ratio. This could lead to suboptimal maybe it is not explicitly mentioned in the algorithm section, but all path delays should be within the application's maximum delay budget. Another way to look at it is the max allowed skew between the path RTTs, i.e., the schedul= ing algorithm can ignore the paths that increase the skew from the optimum. > scheduling results if some of channels looks better in ratio but actually= is > unacceptable in terms of RTT constraint. > As mentioned earlier, this max-RTT value is application dependent, and the scheduling algorithm can ignore all paths that don't meet this requirement. > 2) Secondly, even though the paper stresses the work is orthogonal to > congestion control, I can=A1=AFt help but thinking that the interaction b= etween > individual CC mechanism for sub-flows channels and the application (or > codec) rate control mechanism seems to be at the heart of maximizing QoE > boost gained from heterogeneous channels instead of doing simple traffic > partition for CBR media flows. > In my opinion, for congestion control we would do something like coupled congestion control. i.e., measure across all subflows and based on the aggregate increase/decrease the media rate. > It may be straightforward to borrow the current work in RTP CC algorithms= in > RMCAT WG here. But I still believe there may be case for two-level rate > control in MPRTP stack, which means interfaces for cross-layer > status-sharing and coordinated rate control needs to be considered. > > 3) Moreover, in this paper, to yield non-linear monitory overhead for > sub-flow RTCP traffic, each sub-RTCP traffic is limited according to the > sub-flow rate of media traffic. It is a clever choice, but one may wonder > given the fact that the unfairness among the sampling and reporting activ= ity > may transfer to the unfairness in cross-channel traffic offloading and > finally hold the ultimate application=A1=AFs loss in QoE. Receiving subflows can use early feedback (AVPF) if they observe losses. Moreover, each subflow irrespective of its rate has a maximum RTCP interval based on RFC3550 reporting interval. For example, passive subflows also send subflow SRs and/or subflow RRs. In our experimentation, we started by reporting on each subflow simultaneou= sly and slowly relaxed that requirement to the one in the paper. IMO, the MPRTP protocol extension does not limit the timing requirements set in RFC3550/RFC4585. It should be noted that in our paper the scheduling decisions are not made every time an endpoint receives an subflow report but when sufficient subflow reports have been received. In some cases, the endpoint may have received multiple reports for a single subflow while only a single one for another subflow. It is up to the scheduling algorithm to synthesize the information in these reports to make scheduling decisions= . > > If the source code is available, we would like to participate and do some > more exploration. > We will try to get this out as soon as possible, however, we do not have a delivery date set for this. > > BR > Lingli > > > 2013/3/16 Varun Singh >> >> Hi Lingli, >> >> We are working towards releasing an open-source version of our >> implementation. The details will emerge over the summer. >> >> The first thing we tested with our implementation was offloading. We hav= e >> some scenarios in the paper [1] that shows how load balancing can be >> achieved, but these can be extended for offloading. Additionally, using >> mobility-ice extensions may help with some of the engineering issues. >> >> There are several ways in which MPRTP can be used, therefore we don't >> discuss the scheduling algorithm in the draft. I urge you to look at the >> research paper for those details. >> >> [1] http://www.netlab.tkk.fi/~varun/2013_MMSYS_Singh_MPRTP.pdf >> >> Regards, >> Varun >> >> ---- >> http://www.netlab.tkk.fi/~varun >> >> >> On 15.3.2013, at 0.50, "denglingli@gmail.com" >> wrote: >> >> Hi Varuna, >> >> >> Impressive work. >> >> Do you have any implementation that provide support for real application= s? >> >> Have you ever considered to apply this solution for Traffic offloading >> from cellular to wifi networks or vise visa scenarios? >> >> >> BR >> >> >> Lingli >> >> China mobile >> >> >> =B7=A2=D7=D4=CE=D2=B5=C4 iPad >> >> _______________________________________________ >> >> Audio/Video Transport Core Maintenance >> >> avt@ietf.org >> >> https://www.ietf.org/mailman/listinfo/avt > > > > > -- > =B5=CB=C1=E9=C0=F2/Lingli Deng > =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Resea= rch Institute > e-mail: denglingli@chinamobile.com > tel: 15801696688-3367 > mobile: 13810597148 --=20 http://www.netlab.tkk.fi/~varun/ From gabor.somogyi@nsn.com Wed Mar 20 07:07:21 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE17221F8F9F for ; Wed, 20 Mar 2013 07:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjcdfxDC1LD8 for ; Wed, 20 Mar 2013 07:07:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEE021F8F92 for ; Wed, 20 Mar 2013 07:07:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2KE6Qd0000566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Mar 2013 15:06:26 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2KE6QP7012001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 15:06:26 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.02.0328.009; Wed, 20 Mar 2013 15:06:25 +0100 From: "Somogyi, Gabor (NSN - HU/Budapest)" To: "DRAGE, Keith (Keith)" , Colin Perkins , IETF AVTCore WG Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 Thread-Index: AQHOI8LhCA0R1lcTUk2XY0zvQt8uJZitLXpwgAE+a0A= Date: Wed, 20 Mar 2013 14:06:25 +0000 Message-ID: References: <513F7BDD.8010700@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0128BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> <1515D7F3-AEC2-4612-829F-41EB3E7A9069@csperkins.org> <949EF20990823C4C85C18D59AA11AD8B0181CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0181CF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4412 X-purgate-ID: 151667::1363788386-00007FD3-657D4D1F/0-0/0-0 Cc: Magnus Westerlund Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:07:21 -0000 RFC 1890 (obsoleted by 3551): Audio applications operating under this profile should, at minimum, be able to send and receive payload types 0 (PCMU) and 5 (DVI4). Maybe I am a little bit late, as RFC 1890 was finalized in 1996. Still, my = question is why PCMU should be supported, while PCMA is absolutely optional= ? As far as I know in traditional telecom networks G.711 u-Law (PCMU) is used= in North America and Japan only, while A-law is used by the vast majority.= And when interconnecting A-law and u-Law regions, then A-Law is used. That= suggests that supporting PCMA is at least as important as PCMU. Maybe I answered my own question referring to "traditional telecom networks= ". I have no access to VoIP / IMS statistics. What is the usage ratio betwe= en PCMU and PCMA nowadays? And do you see any firm trend in royalty and pat= ent free codec usage, such as Opus? I am just asking, because if you plan d= ecades ahead, then writing that a high bandwidth but low quality G.711 SHOU= LD be supported sounds a bit like living in the 20th century. Well, actuall= y in the pre-1980 era, as on radio networks, such as GSM, at least the band= width was optimized. And "modern" wireless devices, such as 3GPP LTE client= s may not support PCMA/PCMU at all, even though this RFC draft applies to t= hem. (See 3GPP TS 26.114 section 5.2 "Codecs for MTSI clients in terminals"= .) All in all, I may say that supporting PCMU or PCMA is RECOMMENDED, but defi= nitely remove SHOULD.=20 BR, Gabor Somogyi -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of ext D= RAGE, Keith (Keith) Sent: Tuesday, March 19, 2013 6:15 PM To: Colin Perkins Cc: Magnus Westerlund; IETF AVTCore WG Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 I'm still confused. Surely PCMU0 was recommended before this update and is recommended now. DVI4 was recommended before this update and is now optional. I guess the result of that is that I can be conformant but implement neithe= r, although it will not be a terribly useful implementation. Regards Keith > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 15 March 2013 18:00 > To: DRAGE, Keith (Keith) > Cc: Magnus Westerlund; IETF AVTCore WG > Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 >=20 > On 12 Mar 2013, at 16:40, DRAGE, Keith (Keith) wrote: > > I'm trying to parse the final sentence of the change made to RFC 3551. > > > > Essentially this i-d modifies: > > > > " Audio applications operating under this profile SHOULD, at a minimu= m, > > be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). > > This allows interoperability without format negotiation and ensures > > successful negotiation with a conference control protocol." > > > > To become: > > > > " Audio applications operating under this profile SHOULD, at a minimu= m, > > be able to send and/or receive payload type 0 (PCMU). > > This allows interoperability without format negotiation and ensures > > successful negotiation with a conference control protocol. Some > > environments MAY make support for PCMU mandatory." > > > > What the final sentence currently says is that some environments provid= e > an option to make support for PCMU mandatory, which implies that other > environments do not provide such an option. Neither of those make sense t= o > me and there I believe that cannot be the meaning. > > > > I suspect we are looking for sentence that looks more like "Some > environments REQUIRE support for PCMU", but I am not sure if there is an > "only" floating around in there somewhere. >=20 >=20 > I don't think the draft ought to say "only". This sentence looks to be > addressing the RTCWeb use case, which makes PCMU mandatory to implement > but also allows other codecs. >=20 > To my reading, "Some environments MAY make support for PCMU mandatory" an= d > "Some environments REQUIRE support for PCMU" are equivalent, but I have n= o > objection to the change if you think it clearer. >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Wed Mar 20 07:11:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A4211E80BA for ; Wed, 20 Mar 2013 07:11:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iaz2iLI56b1 for ; Wed, 20 Mar 2013 07:11:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B914C11E80C5 for ; Wed, 20 Mar 2013 07:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6952; q=dns/txt; s=iport; t=1363788691; x=1364998291; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vGSU/FgmOXsS/uc1acnuEAFxmWZTWjOo/2oijYVzJcY=; b=OZAeT2qhlNJ6tPAWcfv8yJacnF40JsyTTovA6xT+Ztthjako7AHE+AFB Z4mf7IoENzzj+4k7o+7breuE+qzLMrl2mQ/Vh5AlzWbUAE9t1vUEc/Olt E5GMXtA8tm9Lk7zj+RuigSSJBHn+CbPfAT6Cjc1WPzqDTAVlLM7TKxIvP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAODCSVGtJV2Z/2dsb2JhbABDhCeDbb0FZWkWdIIkAQEBBAEBASARNBEMBgEIEQMBAQEBAgIGHQMCBCULFAEICAIEAQ0FCIgMAQuva5JggSONOwYgCwcEAoInMmEDl3+PY4MKgig X-IronPort-AV: E=Sophos;i="4.84,877,1355097600"; d="scan'208";a="189551280" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 20 Mar 2013 14:11:30 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2KEBT9m023458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 14:11:30 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 09:11:29 -0500 From: "Ali C. Begen (abegen)" To: "Somogyi, Gabor (NSN - HU/Budapest)" , "DRAGE, Keith (Keith)" , Colin Perkins , IETF AVTCore WG Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 Thread-Index: AQHOH1RqdnFDc19/Jk++bxrvlWzTQpii2L2AgASKIQCABjz3AIABXYuAgAAi8AA= Date: Wed, 20 Mar 2013 14:11:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.96.48] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Magnus Westerlund Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 14:11:46 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDxTb21vZ3lpPiwgIkdhYm9yICAgKE5T TiAtIEhVL0J1ZGFwZXN0KSIgPGdhYm9yLnNvbW9neWlAbnNuLmNvbT4NCkRhdGU6IFdlZG5lc2Rh eSwgTWFyY2ggMjAsIDIwMTMgNDowNiBQTQ0KVG86IEtlaXRoICdEUkFHRSA8a2VpdGguZHJhZ2VA YWxjYXRlbC1sdWNlbnQuY29tPiwgQ29saW4gUGVya2lucw0KPGNzcEBjc3BlcmtpbnMub3JnPiwg ImF2dEBpZXRmLm9yZyIgPGF2dEBpZXRmLm9yZz4NCkNjOiBNYWdudXMgV2VzdGVybHVuZCA8bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBXRyBs YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLWF2cC1jb2RlY3MtMDENCg0KPlJGQyAxODkw IChvYnNvbGV0ZWQgYnkgMzU1MSk6DQo+ICAgQXVkaW8gYXBwbGljYXRpb25zIG9wZXJhdGluZyB1 bmRlciB0aGlzIHByb2ZpbGUgc2hvdWxkLCBhdCBtaW5pbXVtLA0KPiAgIGJlIGFibGUgdG8gc2Vu ZCBhbmQgcmVjZWl2ZSBwYXlsb2FkIHR5cGVzIDAgIChQQ01VKSAgYW5kIDUgKERWSTQpLg0KPg0K Pk1heWJlIEkgYW0gYSBsaXR0bGUgYml0IGxhdGUsIGFzIFJGQyAxODkwIHdhcyBmaW5hbGl6ZWQg aW4gMTk5Ni4gU3RpbGwsDQo+bXkgcXVlc3Rpb24gaXMgd2h5IFBDTVUgc2hvdWxkIGJlIHN1cHBv cnRlZCwgd2hpbGUgUENNQSBpcyBhYnNvbHV0ZWx5DQo+b3B0aW9uYWw/DQo+DQo+QXMgZmFyIGFz IEkga25vdyBpbiB0cmFkaXRpb25hbCB0ZWxlY29tIG5ldHdvcmtzIEcuNzExIHUtTGF3IChQQ01V KSBpcw0KPnVzZWQgaW4gTm9ydGggQW1lcmljYSBhbmQgSmFwYW4gb25seSwgd2hpbGUgQS1sYXcg aXMgdXNlZCBieSB0aGUgdmFzdA0KPm1ham9yaXR5LiBBbmQgd2hlbiBpbnRlcmNvbm5lY3Rpbmcg QS1sYXcgYW5kIHUtTGF3IHJlZ2lvbnMsIHRoZW4gQS1MYXcgaXMNCj51c2VkLiBUaGF0IHN1Z2dl c3RzIHRoYXQgc3VwcG9ydGluZyBQQ01BIGlzIGF0IGxlYXN0IGFzIGltcG9ydGFudCBhcyBQQ01V Lg0KPg0KPk1heWJlIEkgYW5zd2VyZWQgbXkgb3duIHF1ZXN0aW9uIHJlZmVycmluZyB0byAidHJh ZGl0aW9uYWwgdGVsZWNvbQ0KPm5ldHdvcmtzIi4gSSBoYXZlIG5vIGFjY2VzcyB0byBWb0lQIC8g SU1TIHN0YXRpc3RpY3MuIFdoYXQgaXMgdGhlIHVzYWdlDQo+cmF0aW8gYmV0d2VlbiBQQ01VIGFu ZCBQQ01BIG5vd2FkYXlzPyBBbmQgZG8geW91IHNlZSBhbnkgZmlybSB0cmVuZCBpbg0KPnJveWFs dHkgYW5kIHBhdGVudCBmcmVlIGNvZGVjIHVzYWdlLCBzdWNoIGFzIE9wdXM/IEkgYW0ganVzdCBh c2tpbmcsDQo+YmVjYXVzZSBpZiB5b3UgcGxhbiBkZWNhZGVzIGFoZWFkLCB0aGVuIHdyaXRpbmcg dGhhdCBhIGhpZ2ggYmFuZHdpZHRoIGJ1dA0KPmxvdyBxdWFsaXR5IEcuNzExIFNIT1VMRCBiZSBz dXBwb3J0ZWQgc291bmRzIGEgYml0IGxpa2UgbGl2aW5nIGluIHRoZQ0KPjIwdGggY2VudHVyeS4g V2VsbCwgYWN0dWFsbHkgaW4gdGhlIHByZS0xOTgwIGVyYSwgYXMgb24gcmFkaW8gbmV0d29ya3Ms DQo+c3VjaCBhcyBHU00sIGF0IGxlYXN0IHRoZSBiYW5kd2lkdGggd2FzIG9wdGltaXplZC4gQW5k ICJtb2Rlcm4iIHdpcmVsZXNzDQo+ZGV2aWNlcywgc3VjaCBhcyAzR1BQIExURSBjbGllbnRzIG1h eSBub3Qgc3VwcG9ydCBQQ01BL1BDTVUgYXQgYWxsLCBldmVuDQo+dGhvdWdoIHRoaXMgUkZDIGRy YWZ0IGFwcGxpZXMgdG8gdGhlbS4gKFNlZSAzR1BQIFRTIDI2LjExNCBzZWN0aW9uIDUuMg0KPiJD b2RlY3MgZm9yIE1UU0kgY2xpZW50cyBpbiB0ZXJtaW5hbHMiLikNCj4NCj5BbGwgaW4gYWxsLCBJ IG1heSBzYXkgdGhhdCBzdXBwb3J0aW5nIFBDTVUgb3IgUENNQSBpcyBSRUNPTU1FTkRFRCwgYnV0 DQo+ZGVmaW5pdGVseSByZW1vdmUgU0hPVUxELg0KDQpGcm9tIDIxMTkgcGVyc3BlY3RpdmUsIFJF Q09NTUVOREVEIGFuZCBTSE9VTEQgYXJlIGlkZW50aWNhbC4NCg0KPg0KPkJSLA0KPkdhYm9yIFNv bW9neWkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGF2dC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQN Cj5EUkFHRSwgS2VpdGggKEtlaXRoKQ0KPlNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDEzIDY6 MTUgUE0NCj5UbzogQ29saW4gUGVya2lucw0KPkNjOiBNYWdudXMgV2VzdGVybHVuZDsgSUVURiBB VlRDb3JlIFdHDQo+U3ViamVjdDogUmU6IFtBVlRDT1JFXSBXRyBsYXN0IGNhbGwgb24gZHJhZnQt aWV0Zi1hdnRjb3JlLWF2cC1jb2RlY3MtMDENCj4NCj5JJ20gc3RpbGwgY29uZnVzZWQuDQo+DQo+ U3VyZWx5IFBDTVUwIHdhcyByZWNvbW1lbmRlZCBiZWZvcmUgdGhpcyB1cGRhdGUgYW5kIGlzIHJl Y29tbWVuZGVkIG5vdy4NCj4NCj5EVkk0IHdhcyByZWNvbW1lbmRlZCBiZWZvcmUgdGhpcyB1cGRh dGUgYW5kIGlzIG5vdyBvcHRpb25hbC4NCj4NCj5JIGd1ZXNzIHRoZSByZXN1bHQgb2YgdGhhdCBp cyB0aGF0IEkgY2FuIGJlIGNvbmZvcm1hbnQgYnV0IGltcGxlbWVudA0KPm5laXRoZXIsIGFsdGhv dWdoIGl0IHdpbGwgbm90IGJlIGEgdGVycmlibHkgdXNlZnVsIGltcGxlbWVudGF0aW9uLg0KPg0K PlJlZ2FyZHMNCj4NCj5LZWl0aA0KPg0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCj4+ IFNlbnQ6IDE1IE1hcmNoIDIwMTMgMTg6MDANCj4+IFRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKQ0K Pj4gQ2M6IE1hZ251cyBXZXN0ZXJsdW5kOyBJRVRGIEFWVENvcmUgV0cNCj4+IFN1YmplY3Q6IFJl OiBbQVZUQ09SRV0gV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1hdnAtY29kZWNz LTAxDQo+PiANCj4+IE9uIDEyIE1hciAyMDEzLCBhdCAxNjo0MCwgRFJBR0UsIEtlaXRoIChLZWl0 aCkgd3JvdGU6DQo+PiA+IEknbSB0cnlpbmcgdG8gcGFyc2UgdGhlIGZpbmFsIHNlbnRlbmNlIG9m IHRoZSBjaGFuZ2UgbWFkZSB0byBSRkMgMzU1MS4NCj4+ID4NCj4+ID4gRXNzZW50aWFsbHkgdGhp cyBpLWQgbW9kaWZpZXM6DQo+PiA+DQo+PiA+ICIgICBBdWRpbyBhcHBsaWNhdGlvbnMgb3BlcmF0 aW5nIHVuZGVyIHRoaXMgcHJvZmlsZSBTSE9VTEQsIGF0IGENCj4+bWluaW11bSwNCj4+ID4gICBi ZSBhYmxlIHRvIHNlbmQgYW5kL29yIHJlY2VpdmUgcGF5bG9hZCB0eXBlcyAwIChQQ01VKSBhbmQg NSAoRFZJNCkuDQo+PiA+ICAgVGhpcyBhbGxvd3MgaW50ZXJvcGVyYWJpbGl0eSB3aXRob3V0IGZv cm1hdCBuZWdvdGlhdGlvbiBhbmQgZW5zdXJlcw0KPj4gPiAgIHN1Y2Nlc3NmdWwgbmVnb3RpYXRp b24gd2l0aCBhIGNvbmZlcmVuY2UgY29udHJvbCBwcm90b2NvbC4iDQo+PiA+DQo+PiA+IFRvIGJl Y29tZToNCj4+ID4NCj4+ID4gIiAgIEF1ZGlvIGFwcGxpY2F0aW9ucyBvcGVyYXRpbmcgdW5kZXIg dGhpcyBwcm9maWxlIFNIT1VMRCwgYXQgYQ0KPj5taW5pbXVtLA0KPj4gPiAgIGJlIGFibGUgdG8g c2VuZCBhbmQvb3IgcmVjZWl2ZSBwYXlsb2FkIHR5cGUgMCAoUENNVSkuDQo+PiA+ICAgVGhpcyBh bGxvd3MgaW50ZXJvcGVyYWJpbGl0eSB3aXRob3V0IGZvcm1hdCBuZWdvdGlhdGlvbiBhbmQgZW5z dXJlcw0KPj4gPiAgIHN1Y2Nlc3NmdWwgbmVnb3RpYXRpb24gd2l0aCBhIGNvbmZlcmVuY2UgY29u dHJvbCBwcm90b2NvbC4gU29tZQ0KPj4gPiAgIGVudmlyb25tZW50cyBNQVkgbWFrZSBzdXBwb3J0 IGZvciBQQ01VIG1hbmRhdG9yeS4iDQo+PiA+DQo+PiA+IFdoYXQgdGhlIGZpbmFsIHNlbnRlbmNl IGN1cnJlbnRseSBzYXlzIGlzIHRoYXQgc29tZSBlbnZpcm9ubWVudHMNCj4+cHJvdmlkZQ0KPj4g YW4gb3B0aW9uIHRvIG1ha2Ugc3VwcG9ydCBmb3IgUENNVSBtYW5kYXRvcnksIHdoaWNoIGltcGxp ZXMgdGhhdCBvdGhlcg0KPj4gZW52aXJvbm1lbnRzIGRvIG5vdCBwcm92aWRlIHN1Y2ggYW4gb3B0 aW9uLiBOZWl0aGVyIG9mIHRob3NlIG1ha2Ugc2Vuc2UNCj4+dG8NCj4+IG1lIGFuZCB0aGVyZSBJ IGJlbGlldmUgdGhhdCBjYW5ub3QgYmUgdGhlIG1lYW5pbmcuDQo+PiA+DQo+PiA+IEkgc3VzcGVj dCB3ZSBhcmUgbG9va2luZyBmb3Igc2VudGVuY2UgdGhhdCBsb29rcyBtb3JlIGxpa2UgIlNvbWUN Cj4+IGVudmlyb25tZW50cyBSRVFVSVJFIHN1cHBvcnQgZm9yIFBDTVUiLCBidXQgSSBhbSBub3Qg c3VyZSBpZiB0aGVyZSBpcyBhbg0KPj4gIm9ubHkiIGZsb2F0aW5nIGFyb3VuZCBpbiB0aGVyZSBz b21ld2hlcmUuDQo+PiANCj4+IA0KPj4gSSBkb24ndCB0aGluayB0aGUgZHJhZnQgb3VnaHQgdG8g c2F5ICJvbmx5Ii4gVGhpcyBzZW50ZW5jZSBsb29rcyB0byBiZQ0KPj4gYWRkcmVzc2luZyB0aGUg UlRDV2ViIHVzZSBjYXNlLCB3aGljaCBtYWtlcyBQQ01VIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQN Cj4+IGJ1dCBhbHNvIGFsbG93cyBvdGhlciBjb2RlY3MuDQo+PiANCj4+IFRvIG15IHJlYWRpbmcs ICJTb21lIGVudmlyb25tZW50cyBNQVkgbWFrZSBzdXBwb3J0IGZvciBQQ01VIG1hbmRhdG9yeSIN Cj4+YW5kDQo+PiAiU29tZSBlbnZpcm9ubWVudHMgUkVRVUlSRSBzdXBwb3J0IGZvciBQQ01VIiBh cmUgZXF1aXZhbGVudCwgYnV0IEkgaGF2ZQ0KPj5ubw0KPj4gb2JqZWN0aW9uIHRvIHRoZSBjaGFu Z2UgaWYgeW91IHRoaW5rIGl0IGNsZWFyZXIuDQo+PiANCj4+IC0tDQo+PiBDb2xpbiBQZXJraW5z DQo+PiBodHRwOi8vY3NwZXJraW5zLm9yZy8NCj4+IA0KPj4gDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQg Q29yZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXZ0DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPmF2 dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+ DQoNCg0K From gabor.somogyi@nsn.com Thu Mar 21 06:42:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC3121F8804 for ; Thu, 21 Mar 2013 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V30XtmkXZvHw for ; Thu, 21 Mar 2013 06:42:34 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2890921F874B for ; Thu, 21 Mar 2013 06:42:33 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r2LDgLY5032401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Mar 2013 14:42:21 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r2LDgKNB011640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Mar 2013 14:42:20 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.02.0328.009; Thu, 21 Mar 2013 14:42:20 +0100 From: "Somogyi, Gabor (NSN - HU/Budapest)" To: "ext Ali C. Begen (abegen)" , "DRAGE, Keith (Keith)" , Colin Perkins , "IETF AVTCore WG" Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 Thread-Index: AQHOI8LhCA0R1lcTUk2XY0zvQt8uJZitLXpwgAE+a0CAACVVAIABkwww Date: Thu, 21 Mar 2013 13:42:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8142 X-purgate-ID: 151667::1363873341-000053F1-9DC4494A/0-0/0-0 Cc: Magnus Westerlund Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 13:42:35 -0000 PiBGcm9tIDIxMTkgcGVyc3BlY3RpdmUsIFJFQ09NTUVOREVEIGFuZCBTSE9VTEQgYXJlIGlkZW50 aWNhbC4NCg0KT2gsIHllcywgeW91IGFyZSByaWdodC4gVGhlbiBJIHdvdWxkIHNpbXBseSByZW1v dmUgdGhhdCByZWNvbW1lbmRhdGlvbiBlbnRpcmVseS4NCg0KUENNVSB3YXMgbm90IGFuZCB3aWxs IG5vdCBiZSBzdXBwb3J0ZWQgYnkgcXVpdGUgd2lkZSByYW5nZSBvZiBSVFAvQVZQIGRldmljZXMg Zm9yIHRoZSByZWFzb25zIEkgbWVudGlvbmVkLiBUaGF0IHJlY29tbWVuZGF0aW9uIG1heSBmaXQg UFNUTiBhbmQgZW50ZXJwcmlzZSBWb0lQIG5ldHdvcmtzIGluIHRoZSBVUywgYnV0IGdlbmVyYWxs eSBpdCBkb2VzIG5vdCBzZWVtIHRvIGJlIHJpZ2h0LiBJbiBvdGhlciB3b3JkcyBQQ01VIGlzIGVp dGhlciBzdXBwb3J0ZWQgYnkgZGV2aWNlcyBldmVuIHdpdGhvdXQgaGF2aW5nIHRoYXQgcmVjb21t ZW5kYXRpb24gb3IgaXQgaXMgbm90IHN1cHBvcnRlZCByZWdhcmRsZXNzIG9mIHRoYXQgcmVjb21t ZW5kYXRpb24uIFRoZW4gd2h5IHRvIGhhdmUgaXQ/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBleHQgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIFttYWlsdG86YWJlZ2VuQGNpc2Nv LmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDIwLCAyMDEzIDM6MTEgUE0NClRvOiBTb21v Z3lpLCBHYWJvciAoTlNOIC0gSFUvQnVkYXBlc3QpOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgQ29s aW4gUGVya2luczsgSUVURiBBVlRDb3JlIFdHDQpDYzogTWFnbnVzIFdlc3Rlcmx1bmQNClN1Ympl Y3Q6IFJlOiBbQVZUQ09SRV0gV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1hdnAt Y29kZWNzLTAxDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA8U29tb2d5aT4s ICJHYWJvciAgIChOU04gLSBIVS9CdWRhcGVzdCkiIDxnYWJvci5zb21vZ3lpQG5zbi5jb20+DQpE YXRlOiBXZWRuZXNkYXksIE1hcmNoIDIwLCAyMDEzIDQ6MDYgUE0NClRvOiBLZWl0aCAnRFJBR0Ug PGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4sIENvbGluIFBlcmtpbnMNCjxjc3BAY3Nw ZXJraW5zLm9yZz4sICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+DQpDYzogTWFnbnVzIFdl c3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NClN1YmplY3Q6IFJlOiBb QVZUQ09SRV0gV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1hdnAtY29kZWNzLTAx DQoNCj5SRkMgMTg5MCAob2Jzb2xldGVkIGJ5IDM1NTEpOg0KPiAgIEF1ZGlvIGFwcGxpY2F0aW9u cyBvcGVyYXRpbmcgdW5kZXIgdGhpcyBwcm9maWxlIHNob3VsZCwgYXQgbWluaW11bSwNCj4gICBi ZSBhYmxlIHRvIHNlbmQgYW5kIHJlY2VpdmUgcGF5bG9hZCB0eXBlcyAwICAoUENNVSkgIGFuZCA1 IChEVkk0KS4NCj4NCj5NYXliZSBJIGFtIGEgbGl0dGxlIGJpdCBsYXRlLCBhcyBSRkMgMTg5MCB3 YXMgZmluYWxpemVkIGluIDE5OTYuIFN0aWxsLA0KPm15IHF1ZXN0aW9uIGlzIHdoeSBQQ01VIHNo b3VsZCBiZSBzdXBwb3J0ZWQsIHdoaWxlIFBDTUEgaXMgYWJzb2x1dGVseQ0KPm9wdGlvbmFsPw0K Pg0KPkFzIGZhciBhcyBJIGtub3cgaW4gdHJhZGl0aW9uYWwgdGVsZWNvbSBuZXR3b3JrcyBHLjcx MSB1LUxhdyAoUENNVSkgaXMNCj51c2VkIGluIE5vcnRoIEFtZXJpY2EgYW5kIEphcGFuIG9ubHks IHdoaWxlIEEtbGF3IGlzIHVzZWQgYnkgdGhlIHZhc3QNCj5tYWpvcml0eS4gQW5kIHdoZW4gaW50 ZXJjb25uZWN0aW5nIEEtbGF3IGFuZCB1LUxhdyByZWdpb25zLCB0aGVuIEEtTGF3IGlzDQo+dXNl ZC4gVGhhdCBzdWdnZXN0cyB0aGF0IHN1cHBvcnRpbmcgUENNQSBpcyBhdCBsZWFzdCBhcyBpbXBv cnRhbnQgYXMgUENNVS4NCj4NCj5NYXliZSBJIGFuc3dlcmVkIG15IG93biBxdWVzdGlvbiByZWZl cnJpbmcgdG8gInRyYWRpdGlvbmFsIHRlbGVjb20NCj5uZXR3b3JrcyIuIEkgaGF2ZSBubyBhY2Nl c3MgdG8gVm9JUCAvIElNUyBzdGF0aXN0aWNzLiBXaGF0IGlzIHRoZSB1c2FnZQ0KPnJhdGlvIGJl dHdlZW4gUENNVSBhbmQgUENNQSBub3dhZGF5cz8gQW5kIGRvIHlvdSBzZWUgYW55IGZpcm0gdHJl bmQgaW4NCj5yb3lhbHR5IGFuZCBwYXRlbnQgZnJlZSBjb2RlYyB1c2FnZSwgc3VjaCBhcyBPcHVz PyBJIGFtIGp1c3QgYXNraW5nLA0KPmJlY2F1c2UgaWYgeW91IHBsYW4gZGVjYWRlcyBhaGVhZCwg dGhlbiB3cml0aW5nIHRoYXQgYSBoaWdoIGJhbmR3aWR0aCBidXQNCj5sb3cgcXVhbGl0eSBHLjcx MSBTSE9VTEQgYmUgc3VwcG9ydGVkIHNvdW5kcyBhIGJpdCBsaWtlIGxpdmluZyBpbiB0aGUNCj4y MHRoIGNlbnR1cnkuIFdlbGwsIGFjdHVhbGx5IGluIHRoZSBwcmUtMTk4MCBlcmEsIGFzIG9uIHJh ZGlvIG5ldHdvcmtzLA0KPnN1Y2ggYXMgR1NNLCBhdCBsZWFzdCB0aGUgYmFuZHdpZHRoIHdhcyBv cHRpbWl6ZWQuIEFuZCAibW9kZXJuIiB3aXJlbGVzcw0KPmRldmljZXMsIHN1Y2ggYXMgM0dQUCBM VEUgY2xpZW50cyBtYXkgbm90IHN1cHBvcnQgUENNQS9QQ01VIGF0IGFsbCwgZXZlbg0KPnRob3Vn aCB0aGlzIFJGQyBkcmFmdCBhcHBsaWVzIHRvIHRoZW0uIChTZWUgM0dQUCBUUyAyNi4xMTQgc2Vj dGlvbiA1LjINCj4iQ29kZWNzIGZvciBNVFNJIGNsaWVudHMgaW4gdGVybWluYWxzIi4pDQo+DQo+ QWxsIGluIGFsbCwgSSBtYXkgc2F5IHRoYXQgc3VwcG9ydGluZyBQQ01VIG9yIFBDTUEgaXMgUkVD T01NRU5ERUQsIGJ1dA0KPmRlZmluaXRlbHkgcmVtb3ZlIFNIT1VMRC4NCg0KRnJvbSAyMTE5IHBl cnNwZWN0aXZlLCBSRUNPTU1FTkRFRCBhbmQgU0hPVUxEIGFyZSBpZGVudGljYWwuDQoNCj4NCj5C UiwNCj5HYWJvciBTb21vZ3lpDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBhdnQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgZXh0DQo+RFJBR0UsIEtlaXRoIChLZWl0aCkNCj5TZW50OiBUdWVzZGF5LCBNYXJj aCAxOSwgMjAxMyA2OjE1IFBNDQo+VG86IENvbGluIFBlcmtpbnMNCj5DYzogTWFnbnVzIFdlc3Rl cmx1bmQ7IElFVEYgQVZUQ29yZSBXRw0KPlN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gV0cgbGFzdCBj YWxsIG9uIGRyYWZ0LWlldGYtYXZ0Y29yZS1hdnAtY29kZWNzLTAxDQo+DQo+SSdtIHN0aWxsIGNv bmZ1c2VkLg0KPg0KPlN1cmVseSBQQ01VMCB3YXMgcmVjb21tZW5kZWQgYmVmb3JlIHRoaXMgdXBk YXRlIGFuZCBpcyByZWNvbW1lbmRlZCBub3cuDQo+DQo+RFZJNCB3YXMgcmVjb21tZW5kZWQgYmVm b3JlIHRoaXMgdXBkYXRlIGFuZCBpcyBub3cgb3B0aW9uYWwuDQo+DQo+SSBndWVzcyB0aGUgcmVz dWx0IG9mIHRoYXQgaXMgdGhhdCBJIGNhbiBiZSBjb25mb3JtYW50IGJ1dCBpbXBsZW1lbnQNCj5u ZWl0aGVyLCBhbHRob3VnaCBpdCB3aWxsIG5vdCBiZSBhIHRlcnJpYmx5IHVzZWZ1bCBpbXBsZW1l bnRhdGlvbi4NCj4NCj5SZWdhcmRzDQo+DQo+S2VpdGgNCj4NCj4NCj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBDb2xpbiBQZXJraW5zIFttYWlsdG86Y3NwQGNzcGVy a2lucy5vcmddDQo+PiBTZW50OiAxNSBNYXJjaCAyMDEzIDE4OjAwDQo+PiBUbzogRFJBR0UsIEtl aXRoIChLZWl0aCkNCj4+IENjOiBNYWdudXMgV2VzdGVybHVuZDsgSUVURiBBVlRDb3JlIFdHDQo+ PiBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLWF2dGNv cmUtYXZwLWNvZGVjcy0wMQ0KPj4gDQo+PiBPbiAxMiBNYXIgMjAxMywgYXQgMTY6NDAsIERSQUdF LCBLZWl0aCAoS2VpdGgpIHdyb3RlOg0KPj4gPiBJJ20gdHJ5aW5nIHRvIHBhcnNlIHRoZSBmaW5h bCBzZW50ZW5jZSBvZiB0aGUgY2hhbmdlIG1hZGUgdG8gUkZDIDM1NTEuDQo+PiA+DQo+PiA+IEVz c2VudGlhbGx5IHRoaXMgaS1kIG1vZGlmaWVzOg0KPj4gPg0KPj4gPiAiICAgQXVkaW8gYXBwbGlj YXRpb25zIG9wZXJhdGluZyB1bmRlciB0aGlzIHByb2ZpbGUgU0hPVUxELCBhdCBhDQo+Pm1pbmlt dW0sDQo+PiA+ICAgYmUgYWJsZSB0byBzZW5kIGFuZC9vciByZWNlaXZlIHBheWxvYWQgdHlwZXMg MCAoUENNVSkgYW5kIDUgKERWSTQpLg0KPj4gPiAgIFRoaXMgYWxsb3dzIGludGVyb3BlcmFiaWxp dHkgd2l0aG91dCBmb3JtYXQgbmVnb3RpYXRpb24gYW5kIGVuc3VyZXMNCj4+ID4gICBzdWNjZXNz ZnVsIG5lZ290aWF0aW9uIHdpdGggYSBjb25mZXJlbmNlIGNvbnRyb2wgcHJvdG9jb2wuIg0KPj4g Pg0KPj4gPiBUbyBiZWNvbWU6DQo+PiA+DQo+PiA+ICIgICBBdWRpbyBhcHBsaWNhdGlvbnMgb3Bl cmF0aW5nIHVuZGVyIHRoaXMgcHJvZmlsZSBTSE9VTEQsIGF0IGENCj4+bWluaW11bSwNCj4+ID4g ICBiZSBhYmxlIHRvIHNlbmQgYW5kL29yIHJlY2VpdmUgcGF5bG9hZCB0eXBlIDAgKFBDTVUpLg0K Pj4gPiAgIFRoaXMgYWxsb3dzIGludGVyb3BlcmFiaWxpdHkgd2l0aG91dCBmb3JtYXQgbmVnb3Rp YXRpb24gYW5kIGVuc3VyZXMNCj4+ID4gICBzdWNjZXNzZnVsIG5lZ290aWF0aW9uIHdpdGggYSBj b25mZXJlbmNlIGNvbnRyb2wgcHJvdG9jb2wuIFNvbWUNCj4+ID4gICBlbnZpcm9ubWVudHMgTUFZ IG1ha2Ugc3VwcG9ydCBmb3IgUENNVSBtYW5kYXRvcnkuIg0KPj4gPg0KPj4gPiBXaGF0IHRoZSBm aW5hbCBzZW50ZW5jZSBjdXJyZW50bHkgc2F5cyBpcyB0aGF0IHNvbWUgZW52aXJvbm1lbnRzDQo+ PnByb3ZpZGUNCj4+IGFuIG9wdGlvbiB0byBtYWtlIHN1cHBvcnQgZm9yIFBDTVUgbWFuZGF0b3J5 LCB3aGljaCBpbXBsaWVzIHRoYXQgb3RoZXINCj4+IGVudmlyb25tZW50cyBkbyBub3QgcHJvdmlk ZSBzdWNoIGFuIG9wdGlvbi4gTmVpdGhlciBvZiB0aG9zZSBtYWtlIHNlbnNlDQo+PnRvDQo+PiBt ZSBhbmQgdGhlcmUgSSBiZWxpZXZlIHRoYXQgY2Fubm90IGJlIHRoZSBtZWFuaW5nLg0KPj4gPg0K Pj4gPiBJIHN1c3BlY3Qgd2UgYXJlIGxvb2tpbmcgZm9yIHNlbnRlbmNlIHRoYXQgbG9va3MgbW9y ZSBsaWtlICJTb21lDQo+PiBlbnZpcm9ubWVudHMgUkVRVUlSRSBzdXBwb3J0IGZvciBQQ01VIiwg YnV0IEkgYW0gbm90IHN1cmUgaWYgdGhlcmUgaXMgYW4NCj4+ICJvbmx5IiBmbG9hdGluZyBhcm91 bmQgaW4gdGhlcmUgc29tZXdoZXJlLg0KPj4gDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsgdGhlIGRy YWZ0IG91Z2h0IHRvIHNheSAib25seSIuIFRoaXMgc2VudGVuY2UgbG9va3MgdG8gYmUNCj4+IGFk ZHJlc3NpbmcgdGhlIFJUQ1dlYiB1c2UgY2FzZSwgd2hpY2ggbWFrZXMgUENNVSBtYW5kYXRvcnkg dG8gaW1wbGVtZW50DQo+PiBidXQgYWxzbyBhbGxvd3Mgb3RoZXIgY29kZWNzLg0KPj4gDQo+PiBU byBteSByZWFkaW5nLCAiU29tZSBlbnZpcm9ubWVudHMgTUFZIG1ha2Ugc3VwcG9ydCBmb3IgUENN VSBtYW5kYXRvcnkiDQo+PmFuZA0KPj4gIlNvbWUgZW52aXJvbm1lbnRzIFJFUVVJUkUgc3VwcG9y dCBmb3IgUENNVSIgYXJlIGVxdWl2YWxlbnQsIGJ1dCBJIGhhdmUNCj4+bm8NCj4+IG9iamVjdGlv biB0byB0aGUgY2hhbmdlIGlmIHlvdSB0aGluayBpdCBjbGVhcmVyLg0KPj4gDQo+PiAtLQ0KPj4g Q29saW4gUGVya2lucw0KPj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+PiANCj4+IA0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlk ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFp bnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2F2dA0KPg0KDQoNCg== From rjsparks@nostrum.com Fri Mar 22 08:27:03 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB99521F8E10 for ; Fri, 22 Mar 2013 08:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzk4lTfwXW7u for ; Fri, 22 Mar 2013 08:27:03 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4F21F8E65 for ; Fri, 22 Mar 2013 08:27:02 -0700 (PDT) Received: from unnumerable.tekelec.com ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r2MFQVA7024150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 10:26:31 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <514C7827.3030503@nostrum.com> Date: Fri, 22 Mar 2013 10:26:31 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Karl Norrman References: <20121128143149.E05F3B1E004@rfc-editor.org> <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se> In-Reply-To: <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Sun, 24 Mar 2013 08:09:10 -0700 Cc: "even.roni@huawei.com" , "avt@ietf.org" , "elisabetta.carrara@ericsson.com" , "mbaugher@cisco.com" , =?ISO-8859-1?Q?Mats_N=E4slund?= , "matthias.schertler@gmx.net" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3420) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:27:04 -0000 Using the criteria at I recommend putting this into Hold For Document Update. ( I could make an argument for Reject, given the text in 3550 is very clear, but a working group can make that decision if 3771 is ever revised). On 11/28/12 9:13 AM, Karl Norrman wrote: > Hello! > > I always considered the padding count to be part of the padding itself and hence it would be included in the encrypted portion. However, the proposed errata below makes the text more explicit on this point. So, if it can avoid some interoperability problems I'm all for accepting it. > > BR > Karl > > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: den 28 november 2012 15:32 >> To: mbaugher@cisco.com; elisabetta.carrara@ericsson.com; >> mcgrew@cisco.com; Mats N�slund; Karl Norrman; Gonzalo >> Camarillo; rjsparks@nostrum.com; >> keith.drage@alcatel-lucent.com; even.roni@huawei.com >> Cc: matthias.schertler@gmx.net; avt@ietf.org; >> rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC3711 (3420) >> >> >> The following errata report has been submitted for RFC3711, >> "The Secure Real-time Transport Protocol (SRTP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=3420 >> >> -------------------------------------- >> Type: Technical >> Reported by: Matthias Schertler >> >> Section: 3.1. >> >> Original Text >> ------------- >> The "Encrypted Portion" of an SRTP packet consists of the >> encryption of the RTP payload (including RTP padding when >> present) of the equivalent RTP packet. >> >> Corrected Text >> -------------- >> The "Encrypted Portion" of an SRTP packet consists of the >> encryption of the RTP payload (including RTP padding and >> RTP pad count when present) of the equivalent RTP packet. >> >> Notes >> ----- >> In Figure 1 "RTP padding" and "RTP pad count" are different >> things. The text should use the same terminology in order to >> make clear that the padding count is encrypted. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, >> please use "Reply All" to discuss whether it should be >> verified or rejected. When a decision is reached, the >> verifying party (IESG) can log in to change the status and >> edit the report, if necessary. >> >> -------------------------------------- >> RFC3711 (draft-ietf-avt-srtp-09) >> -------------------------------------- >> Title : The Secure Real-time Transport Protocol (SRTP) >> Publication Date : March 2004 >> Author(s) : M. Baugher, D. McGrew, M. Naslund, E. >> Carrara, K. Norrman >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG From karl.norrman@ericsson.com Fri Mar 22 10:45:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3097321F8F4A for ; Fri, 22 Mar 2013 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOECnG5aVCwx for ; Fri, 22 Mar 2013 10:45:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE29921F8F43 for ; Fri, 22 Mar 2013 10:45:25 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-5e-514c98b37b72 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 46.90.19728.3B89C415; Fri, 22 Mar 2013 18:45:24 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.183]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 18:45:23 +0100 From: Karl Norrman To: Robert Sparks Thread-Topic: [Technical Errata Reported] RFC3711 (3420) Thread-Index: AQHOJxGrsLg0sGohOEGnXhFDB+UzwJix+4Rw Date: Fri, 22 Mar 2013 17:45:22 +0000 Message-ID: <33E51946CDE71249AF9D86CE4D8966B4121F17BE@ESESSMB203.ericsson.se> References: <20121128143149.E05F3B1E004@rfc-editor.org> <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se> <514C7827.3030503@nostrum.com> In-Reply-To: <514C7827.3030503@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RnfLDJ9AgxcvuSxe9qxkt3j1+gqr xdPGs4wW1w7sZ7H4MmU5i8XVVX/YLa7NaWSzmNpn68Dh0fpsL6vHlN8bWT0Wb9rP5tFy5C2r x5IlP5k8Jm+cxeIxa+cTlgD2KC6blNSczLLUIn27BK6MS8v2Mha8l61Y9DSlgfGmeBcjJ4eE gInEy6+HWCFsMYkL99azdTFycQgJHGKU+Pr0ADuEs4RRouvWYnaQKjYBPYlrN5+D2SICGhLX liwBK2IW2Mki8XrSbSaQhLCAucTc04tZIIosJA62PYayjSSmr+tkBrFZBFQlZrWvARvEK+Ar 8Wf5B0aIbbMYJdZPWM8IkuAU0JY4PfEWWBEj0H3fT60BW8AsIC5x68l8Joi7BSSW7DnPDGGL Srx8/A/oHw4gW1Fieb8cRLmexI2pU9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIps5C0jILScss JC0LGFlWMbLnJmbmpJcbbWIERuTBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsbtlxz3fcwyv73fYfGO2zemXfuyrJ1h1ewDLyr5RK1epTVsfWEls8fy eMq+3ZPPBszQLNxiNSVi0qsIzw2++gW7GguZNadf6Klflru12fho+RcXz7QZkonLn1+6rNft Nnn+d+eFz0y9vkzYc/HqnRUZVxaGZiVuezLl/a4in/2aQuwLNjfZVb1brMRSnJFoqMVcVJwI AMVD18OWAgAA X-Mailman-Approved-At: Sun, 24 Mar 2013 08:09:10 -0700 Cc: "even.roni@huawei.com" , "avt@ietf.org" , "elisabetta.carrara@ericsson.com" , "mbaugher@cisco.com" , =?iso-8859-1?Q?Mats_N=E4slund?= , "matthias.schertler@gmx.net" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3420) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:47:52 -0000 Hello! OK, putting it on hold for document update is fine with me. BR Karl > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: den 22 mars 2013 16:27 > To: Karl Norrman > Cc: mbaugher@cisco.com; elisabetta.carrara@ericsson.com; > mcgrew@cisco.com; Mats N=E4slund; Gonzalo Camarillo; keith.drage@alcatel- > lucent.com; even.roni@huawei.com; matthias.schertler@gmx.net; > avt@ietf.org; Gonzalo Camarillo; Richard Barnes > Subject: Re: [Technical Errata Reported] RFC3711 (3420) >=20 > Using the criteria at > I recommend > putting this into Hold For Document Update. >=20 > ( I could make an argument for Reject, given the text in 3550 is very cle= ar, but > a working group can make that decision if 3771 is ever revised). >=20 > On 11/28/12 9:13 AM, Karl Norrman wrote: > > Hello! > > > > I always considered the padding count to be part of the padding itself = and > hence it would be included in the encrypted portion. However, the > proposed errata below makes the text more explicit on this point. So, if= it > can avoid some interoperability problems I'm all for accepting it. > > > > BR > > Karl > > > > > >> -----Original Message----- > >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >> Sent: den 28 november 2012 15:32 > >> To: mbaugher@cisco.com; elisabetta.carrara@ericsson.com; > >> mcgrew@cisco.com; Mats N=E4slund; Karl Norrman; Gonzalo Camarillo; > >> rjsparks@nostrum.com; keith.drage@alcatel-lucent.com; > >> even.roni@huawei.com > >> Cc: matthias.schertler@gmx.net; avt@ietf.org; > >> rfc-editor@rfc-editor.org > >> Subject: [Technical Errata Reported] RFC3711 (3420) > >> > >> > >> The following errata report has been submitted for RFC3711, "The > >> Secure Real-time Transport Protocol (SRTP)". > >> > >> -------------------------------------- > >> You may review the report below and at: > >> http://www.rfc-editor.org/errata_search.php?rfc=3D3711&eid=3D3420 > >> > >> -------------------------------------- > >> Type: Technical > >> Reported by: Matthias Schertler > >> > >> Section: 3.1. > >> > >> Original Text > >> ------------- > >> The "Encrypted Portion" of an SRTP packet consists of the > >> encryption of the RTP payload (including RTP padding when > >> present) of the equivalent RTP packet. > >> > >> Corrected Text > >> -------------- > >> The "Encrypted Portion" of an SRTP packet consists of the > >> encryption of the RTP payload (including RTP padding and > >> RTP pad count when present) of the equivalent RTP packet. > >> > >> Notes > >> ----- > >> In Figure 1 "RTP padding" and "RTP pad count" are different things. > >> The text should use the same terminology in order to make clear that > >> the padding count is encrypted. > >> > >> Instructions: > >> ------------- > >> This errata is currently posted as "Reported". If necessary, please > >> use "Reply All" to discuss whether it should be verified or rejected. > >> When a decision is reached, the verifying party (IESG) can log in to > >> change the status and edit the report, if necessary. > >> > >> -------------------------------------- > >> RFC3711 (draft-ietf-avt-srtp-09) > >> -------------------------------------- > >> Title : The Secure Real-time Transport Protocol (SRTP) > >> Publication Date : March 2004 > >> Author(s) : M. Baugher, D. McGrew, M. Naslund, E. > >> Carrara, K. Norrman > >> Category : PROPOSED STANDARD > >> Source : Audio/Video Transport > >> Area : Real-time Applications and Infrastructure > >> Stream : IETF > >> Verifying Party : IESG From magnus.westerlund@ericsson.com Mon Mar 25 01:49:11 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1223121F8EB9 for ; Mon, 25 Mar 2013 01:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vk4ahGQAsQG for ; Mon, 25 Mar 2013 01:49:10 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 494D121F8EAE for ; Mon, 25 Mar 2013 01:49:08 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-ec-51500f82ebb0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 02.36.32353.28F00515; Mon, 25 Mar 2013 09:49:07 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Mar 2013 09:49:06 +0100 Message-ID: <51500F82.50803@ericsson.com> Date: Mon, 25 Mar 2013 09:49:06 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-avp-codecs@tools.ietf.org References: <513F7BDD.8010700@ericsson.com> In-Reply-To: <513F7BDD.8010700@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RreZPyDQ4PJUdouXPSvZLfbumcLi wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGXMmnGaveCCRMWhnY9ZGhhvCHcxcnBICJhI fJxk1cXICWSKSVy4t56ti5GLQ0jgJKPEzS33GCGc5YwS3f/nsoBU8QpoSkyeu4QRxGYRUJV4 tO8gM4jNJmAhcfNHIxuILSoQLPHz1RmoekGJkzOfgNkiQPGOZ5PB6oUF3CWuPHgJNkdIQFvi yMUmVhCbU0BH4u2JNYwQF0lKbHnRzg5iMwvoSUy52sIIYctLNG+dzQzT29DUwTqBUXAWknWz kLTMQtKygJF5FSN7bmJmTnq5+SZGYEge3PLbYAfjpvtihxilOViUxHnDXS8ECAmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamDMPt3+TEvn4qtU59WN/AdnJBp+bLwx84utwfzkTZnxk+vlvXde cE9/dpT/fInUgoUz9sQuaVjyYwJv3Eq2Hf8+O7pVtN57HFu96OrjJerf7Xb5B2sd1dmyjtn6 TtGecyv1XPlfF0maJyx7pvLkmktDSr/ypCdHO3W4dmwvmyu46saCh9vtOn4JKbEUZyQaajEX FScCADOqd9QXAgAA Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 08:49:11 -0000 WG, Here is my individual review of the draft. 1. The Abstract must not contain citations, see 3.1.B of the ID-checklist: https://www.ietf.org/id-info/checklist.html Instead use title or abbreveitaded title to make clear what is referred to. 2. Section 3 and 3.1: I believe that this section would be clearer if it was presented as: 3. Updates to RFC 3551 The following text of [RFC3551] is hereby updated as set forth below in Section 3.1: Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. 3.1. Updates to Section 6 In the final paragraph of Section 6, replace, "payload types 0 (PCMU) and 5 (DVI4)," with "payload type 0 (PCMU)." Also, add a final sentence to this paragraph that states, "Some environments MAY make support for PCMU mandatory." Resulting in the following paragraph: Audio applications operating under this profile SHOULD, at a minimum, be able to send and/or receive payload type 0 (PCMU). This allows interoperability without format negotiation and ensures successful negotiation with a conference control protocol. Some environments MAY make support for PCMU mandatory. ---- end of suggested text ---- Note, this does not take the other comments or mailing list discussion into account. Cheers Magnus On 2013-03-12 20:02, Magnus Westerlund wrote: > WG, > > This is to announce the start of a WG last call on: > > Update to Recommended Codecs for the RTP Profile for Audio and Video > Conferences with Minimal Control (RTP/AVP) to be published as a proposed > standard. > > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs > > Please provide any feedback by the 31st of March. > > Regards > > Magnus Westerlund > WG chair > > > ---------------------------------------------------------------------- > 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 Core Maintenance > 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 magnus.westerlund@ericsson.com Mon Mar 25 09:07:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE84021E8087 for ; Mon, 25 Mar 2013 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PxGlPn4UDq0 for ; Mon, 25 Mar 2013 09:07:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 912CC21F901F for ; Mon, 25 Mar 2013 09:07:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-4c-51507648cb68 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 75.45.10459.84670515; Mon, 25 Mar 2013 17:07:36 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Mar 2013 17:07:36 +0100 Message-ID: <51507647.1050802@ericsson.com> Date: Mon, 25 Mar 2013 17:07:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org, draft-ietf-avtcore-6222bis@tools.ietf.org References: <513F7C5B.5060101@ericsson.com> In-Reply-To: <513F7C5B.5060101@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3RtejLCDQYPNXOYuXPSvZLU5PuMfo wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGWcfraeqeCuWMWSty8ZGxhnCXUxcnJICJhI 3Oh9wwRhi0lcuLeerYuRi0NI4CSjRPvsKSwQznJGiQ2/prGCVPEKaEt0z5zPCGKzCKhKnH4/ gRnEZhOwkLj5o5ENxBYVCJb4+eoMC0S9oMTJmU+AbA4OEQFrial//UHCwgIuEv8mPQAbIwQ0 cvXdr2A2p4COxPpby1kgDpKU2PKinR3EZhbQk5hytYURwpaXaN46mxmmt6Gpg3UCo+AsJNtm IWmZhaRlASPzKkb23MTMnPRyw02MwJA8uOW37g7GU+dEDjFKc7AoifOGuV4IEBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cBo/Hp2ZNe+4+c33WV4yJ34Om2ORciSZXEmnQ3vFs5066wVjN8r VWui8nTGBsPpqnMZOiaoaO9I9Jpyr039ytxy+3MKLsIaU4yXKcZE/2P/9CF5v8yX0JNC/03U uosfrOkxaLaet+GrxGklnna5joxvl7eefN3px1PNb+cSJZpirSF6ZOH790eUWIozEg21mIuK EwELZaafFwIAAA== Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:07:38 -0000 WG & Authors, I have reviewed this document as an individual and have the following comments: 1. Section 4.2, second bullet: To produce a short-term persistent RTCP CNAME, an RTP endpoint MUST either (a) use the numeric representation of the layer-2 (Media Access Control (MAC)) address of the interface that is used to initiate the RTP session as the "host" part of its RTCP CNAME or Is using the MAC really that unique? In these days of MAC cloning is this good enough to use as long term persistent CNAME identifier? I also wonder of its persistence behavior as it says to use the MAC of the Interface that ones initiate the communication over. With multiple interfaces, I can in the context of an application use all of these interfaces over a set of calls. Thus it doesn't have particular good long term stability either. Should this option simply be removed? Or at least some discussion of these deficiencies? 2. Section 6.1: Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP session, but it does not aim to prevent impersonation attacks from unauthorized entities. Shouldn't the last "unauthorized" be "authorized". Unauthorized packets will never be processed where the impersonation matters. Otherwise this looks good. Cheers Magnus On 2013-03-12 20:04, Magnus Westerlund wrote: > WG, > > This is to announce the start of a WG last call on: > > Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > (CNAMEs) to be published as a proposed standard. > > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ > > Please provide any feedback by the 31st of March. > > Regards > > Magnus Westerlund > WG chair > > > ---------------------------------------------------------------------- > 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 Core Maintenance > 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 Mar 25 13:01:41 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D021F9588 for ; Mon, 25 Mar 2013 13:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRIKDZyU-2Gu for ; Mon, 25 Mar 2013 13:01:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBD1221F9581 for ; Mon, 25 Mar 2013 13:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3505; q=dns/txt; s=iport; t=1364241700; x=1365451300; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t173Rzj2ZRT8n9z7Iz0m6Ruxr09gNPR1AfNNvz99KQ8=; b=mM3QY22EktMjpeJ4qyaVfatq8m7G1jEJImrQSeWNtBOTac0jJ5sRZthu RpxS55VYWTsr2w3IxKdZBv6Uy2FrRgOuFU397KT7XiqxEO5CBHvFl+Imz 6LZ6crVwYUnu+3O4BKFZ/TUxU5V5B3UNPNfZzzujG9cY5hy0lgW/mNXnP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKCrUFGtJXG9/2dsb2JhbABDgmfBDoEKFnSCHwEBAQMBAQEBCW0FCQICAQgYJwcbDAsUEQIEDgWIDgYBC8NNBASOYTMHgl9hA4hBjiaRBIMK X-IronPort-AV: E=Sophos;i="4.84,907,1355097600"; d="scan'208";a="191246433" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 25 Mar 2013 20:01:39 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2PK1dE0030383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 20:01:39 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 15:01:39 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHOH1SRBgQ8NzU4bUC2VIRlvWTydpi2+uKA///tk60= Date: Mon, 25 Mar 2013 20:00:58 +0000 Message-ID: <35F99675-E69A-48E6-BB17-CDF2A59B2FA3@cisco.com> References: <513F7C5B.5060101@ericsson.com>,<51507647.1050802@ericsson.com> In-Reply-To: <51507647.1050802@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:01:41 -0000 Thanks for the review.=20 On Mar 25, 2013, at 5:07 PM, "Magnus Westerlund" wrote: > WG & Authors, >=20 > I have reviewed this document as an individual and have the following > comments: >=20 > 1. Section 4.2, second bullet: >=20 > To produce a short-term persistent RTCP CNAME, an RTP endpoint > MUST either (a) use the numeric representation of the layer-2 > (Media Access Control (MAC)) address of the interface that is used > to initiate the RTP session as the "host" part of its RTCP CNAME > or >=20 > Is using the MAC really that unique? In these days of MAC cloning is > this good enough to use as long term persistent CNAME identifier? I also The probability of clash is pretty small but we can make a note of this.=20 > wonder of its persistence behavior as it says to use the MAC of the > Interface that ones initiate the communication over. With multiple > interfaces, I can in the context of an application use all of these > interfaces over a set of calls. Thus it doesn't have particular good > long term stability either. I think it is meant to say the interface over which the initial connection = was made not all other possible interfaces that could be used during the rt= p session.=20 >=20 > Should this option simply be removed? Or at least some discussion of > these deficiencies? >=20 > 2. Section 6.1: >=20 > Secure RTP (SRTP) [RFC3711] keeps unauthorized entities out of an RTP > session, but it does not aim to prevent impersonation attacks from > unauthorized entities. >=20 > Shouldn't the last "unauthorized" be "authorized". Unauthorized packets > will never be processed where the impersonation matters. Yup.=20 >=20 >=20 > Otherwise this looks good. Thanks.=20 >=20 > Cheers >=20 > Magnus >=20 >=20 > On 2013-03-12 20:04, Magnus Westerlund wrote: >> WG, >>=20 >> This is to announce the start of a WG last call on: >>=20 >> Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names >> (CNAMEs) to be published as a proposed standard. >>=20 >> Document can be retrieved here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ >>=20 >> Please provide any feedback by the 31st of March. >>=20 >> Regards >>=20 >> Magnus Westerlund >> WG chair >>=20 >>=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 >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 > --=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 > ---------------------------------------------------------------------- >=20 From steveu@coppice.org Mon Mar 25 16:39:36 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949F321F86C5 for ; Mon, 25 Mar 2013 16:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwCzD0AHbu+O for ; Mon, 25 Mar 2013 16:39:36 -0700 (PDT) Received: from thorns-k143.hkbn.net (thorns-k143.hkbn.net [61.92.211.143]) by ietfa.amsl.com (Postfix) with ESMTP id D4CAB21F86C2 for ; Mon, 25 Mar 2013 16:39:35 -0700 (PDT) Received: from outguard01.hkbn.net ([203.186.94.187]) by iguard15.hkbn.net with ESMTP; 26 Mar 2013 07:37:28 +0800 Received: from outguard01.hkbn.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 831EB3D006A for ; Tue, 26 Mar 2013 07:39:33 +0800 (HKT) Received: from smtp1o.ctimail.com (unknown [203.186.94.57]) by outguard01.hkbn.net (Postfix) with ESMTP id 6DEF03D006C for ; Tue, 26 Mar 2013 07:39:33 +0800 (HKT) Received: from i7.coppice.org (123203240234.ctinets.com [123.203.240.234]) by smtp1o.ctimail.com (8.14.5/8.14.5) with ESMTP id r2PNdU2G005829 for ; Tue, 26 Mar 2013 07:39:33 +0800 Message-ID: <5150E032.4060307@coppice.org> Date: Tue, 26 Mar 2013 07:39:30 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org References: <513F7C5B.5060101@ericsson.com>, <51507647.1050802@ericsson.com> <35F99675-E69A-48E6-BB17-CDF2A59B2FA3@cisco.com> In-Reply-To: <35F99675-E69A-48E6-BB17-CDF2A59B2FA3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSVA-8.2.0.1391-7.0.0.1014-19748.003 X-TM-AS-Result: No--10.344-9.9-31-10 X-imss-scan-details: No--10.344-9.9-31-10;No--10.344-5.0-31-10 X-TMASE-Version: IMSVA-8.2.0.1391-7.0.1014-19748.003 X-TMASE-Result: 10--10.344200-5.000000 X-TMASE-MatchedRID: pBwXUM+nCwszx9GDMr0HvzYTypjB3iDVjLOy13Cgb4+qvcIF1TcLYLwo sMBsCF61zOBjyl8LhNNDnqZ83klHV/mWoNcaH82usyNb+yeIRAqzSPa58jvhVvFJXtgF4GFLPXb E9n1s2cupgH6TIJi3FFwtzewu2M63dzO/yc8X33HdB/CxWTRRu25FeHtsUoHuA0Eye7xDGa7/dy +i6LxdyKpE3GAI6h0LlkBx5KmG6Q3FhXMjdQIJpg== Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:39:36 -0000 On 03/26/2013 04:00 AM, Ali C. Begen (abegen) wrote: > Thanks for the review. > > On Mar 25, 2013, at 5:07 PM, "Magnus Westerlund" wrote: > >> WG & Authors, >> >> I have reviewed this document as an individual and have the following >> comments: >> >> 1. Section 4.2, second bullet: >> >> To produce a short-term persistent RTCP CNAME, an RTP endpoint >> MUST either (a) use the numeric representation of the layer-2 >> (Media Access Control (MAC)) address of the interface that is used >> to initiate the RTP session as the "host" part of its RTCP CNAME >> or >> >> Is using the MAC really that unique? In these days of MAC cloning is >> this good enough to use as long term persistent CNAME identifier? I also > The probability of clash is pretty small but we can make a note of this. > That depends on the platform. If you use the MAC address on a virtual machine it always clashes, as it always appears to be zero. Steve From magnus.westerlund@ericsson.com Tue Mar 26 02:49:26 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409DE21F88D6 for ; Tue, 26 Mar 2013 02:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkbPXHUxU4Ur for ; Tue, 26 Mar 2013 02:49:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4209A21F88D8 for ; Tue, 26 Mar 2013 02:49:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-a0-51516f2387ab Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 97.A0.32353.32F61515; Tue, 26 Mar 2013 10:49:23 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 26 Mar 2013 10:49:23 +0100 Message-ID: <51516F22.3050501@ericsson.com> Date: Tue, 26 Mar 2013 10:49:22 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <513F7C5B.5060101@ericsson.com>, <51507647.1050802@ericsson.com> <35F99675-E69A-48E6-BB17-CDF2A59B2FA3@cisco.com> In-Reply-To: <35F99675-E69A-48E6-BB17-CDF2A59B2FA3@cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvja5yfmCgwfS1YhYPts9ltHjZs5Ld 4vSEe4wOzB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mua+nsZUsI6nYsOHfqYG xmauLkZODgkBE4ntxx+yQdhiEhfurQeyuTiEBE4yShxouwXlLGeUuHutl6mLkYODV0BbYsJ0 N5AGFgFViT9T5rGD2GwCFhI3fzSCDRIVCJb4+eoMC4jNKyAocXLmEzBbREBPYn/HNEYQm1mg VuLui/WsILawgIvEv0kPwOJCAjUSlyacBrM5BWwlLi2aywpxnKTElhft7BC9ehJTrrZAzZGX aN46mxmiV1uioamDdQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLzTYzA8D245bfBDsZN98UO MUpzsCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLgloJBdxPJyuJas3dZVG/8F F/KvelPqutpa+lWuu/39/1vzfDVZD7jE7biw94T5yvWVy/Uzl2Ts1z40Zeb7zD2r3U0mHNzK L+qouvTQl71zp9kWezBq/LuyYNXV9MlV92yV90+wE6pOmPtsT9XPx4IMqV2X3qYoJx2sTp2f nzU5q1hEUcTAu0CJpTgj0VCLuag4EQDk9utwLQIAAA== Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 09:49:26 -0000 On 2013-03-25 21:00, Ali C. Begen (abegen) wrote: > Thanks for the review. > > On Mar 25, 2013, at 5:07 PM, "Magnus Westerlund" > wrote: > >> wonder of its persistence behavior as it says to use the MAC of >> the Interface that ones initiate the communication over. With >> multiple interfaces, I can in the context of an application use all >> of these interfaces over a set of calls. Thus it doesn't have >> particular good long term stability either. > > I think it is meant to say the interface over which the initial > connection was made not all other possible interfaces that could be > used during the rtp session. >> The main point I try to get across is that which interface you use for the initial connection varies between different communication establishments. If your goal is to have a long term persistent identifier then you need to store the first one used in the context of an application and use that, rather than take the interface you used for the SIP dialog, or similar, used to establish this particular RTP session(s). 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 Tue Mar 26 02:57:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4BA21F851E for ; Tue, 26 Mar 2013 02:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8MAiKL2mJpx for ; Tue, 26 Mar 2013 02:57:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 797BA21F8511 for ; Tue, 26 Mar 2013 02:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2964; q=dns/txt; s=iport; t=1364291865; x=1365501465; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BunB9o4Z1Z6GcUDx0WwjSuDdtriH8DXTKxIx31CEAtc=; b=OLWsC+eccC9wMoZIn6U2Fr9BeMy4N1vfeiMTFar5C0Qn6ZZ1YzO58DAz WdHZquE75ejlwJkg3jk09K9pjRPMk4r6fKJH/qYi+K4WecTRwxsmXmSqd Edn/SrWhDW0xOYApNnT1Sy7+X9WCCsUgsNBiF1Sma5h2siOKHDMZUARsc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAHZwUVGtJV2a/2dsb2JhbABDgmeDFlq9Kw16FoEqgh8BAQEEDBcRRQwCBAEGAhEDAQIBAgIGHQMCBBkXFAEICAIEDgUIiAwBlA+bBIJAkBEEgR+NPAIWGwcGgicyYQOnboMKgig X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="191534012" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2013 09:57:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2Q9viww003050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 09:57:44 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 04:57:44 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHOH1SRBgQ8NzU4bUC2VIRlvWTydpi2+uKA///tk62AATsWAIAAExuA Date: Tue, 26 Mar 2013 09:57:02 +0000 Message-ID: In-Reply-To: <51516F22.3050501@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.206] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 09:57:46 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAx MyAxMTo0OSBBTQ0KVG86ICJBbGkgQy4gQmVnZW4iIDxhYmVnZW5AY2lzY28uY29tPg0KQ2M6ICJh dnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+LA0KImRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlz QHRvb2xzLmlldGYub3JnIg0KPGRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzQHRvb2xzLmlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1h dnRjb3JlLTYyMjJiaXMtMDENCg0KPk9uIDIwMTMtMDMtMjUgMjE6MDAsIEFsaSBDLiBCZWdlbiAo YWJlZ2VuKSB3cm90ZToNCj4+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4NCj4+IA0KPj4gT24gTWFy IDI1LCAyMDEzLCBhdCA1OjA3IFBNLCAiTWFnbnVzIFdlc3Rlcmx1bmQiDQo+PiA8bWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IA0KPj4+IHdvbmRlciBvZiBpdHMgcGVy c2lzdGVuY2UgYmVoYXZpb3IgYXMgaXQgc2F5cyB0byB1c2UgdGhlIE1BQyBvZg0KPj4+IHRoZSBJ bnRlcmZhY2UgdGhhdCBvbmVzIGluaXRpYXRlIHRoZSBjb21tdW5pY2F0aW9uIG92ZXIuIFdpdGgN Cj4+PiBtdWx0aXBsZSBpbnRlcmZhY2VzLCBJIGNhbiBpbiB0aGUgY29udGV4dCBvZiBhbiBhcHBs aWNhdGlvbiB1c2UgYWxsDQo+Pj4gb2YgdGhlc2UgaW50ZXJmYWNlcyBvdmVyIGEgc2V0IG9mIGNh bGxzLiBUaHVzIGl0IGRvZXNuJ3QgaGF2ZQ0KPj4+IHBhcnRpY3VsYXIgZ29vZCBsb25nIHRlcm0g c3RhYmlsaXR5IGVpdGhlci4NCj4+IA0KPj4gSSB0aGluayBpdCBpcyBtZWFudCB0byBzYXkgdGhl IGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBpbml0aWFsDQo+PiBjb25uZWN0aW9uIHdhcyBtYWRl IG5vdCBhbGwgb3RoZXIgcG9zc2libGUgaW50ZXJmYWNlcyB0aGF0IGNvdWxkIGJlDQo+PiB1c2Vk IGR1cmluZyB0aGUgcnRwIHNlc3Npb24uDQo+Pj4gDQo+DQo+VGhlIG1haW4gcG9pbnQgSSB0cnkg dG8gZ2V0IGFjcm9zcyBpcyB0aGF0IHdoaWNoIGludGVyZmFjZSB5b3UgdXNlIGZvcg0KPnRoZSBp bml0aWFsIGNvbm5lY3Rpb24gdmFyaWVzIGJldHdlZW4gZGlmZmVyZW50IGNvbW11bmljYXRpb24N Cj5lc3RhYmxpc2htZW50cy4gSWYgeW91ciBnb2FsIGlzIHRvIGhhdmUgYSBsb25nIHRlcm0gcGVy c2lzdGVudA0KPmlkZW50aWZpZXIgdGhlbiB5b3UgbmVlZCB0byBzdG9yZSB0aGUgZmlyc3Qgb25l IHVzZWQgaW4gdGhlIGNvbnRleHQgb2YNCj5hbiBhcHBsaWNhdGlvbiBhbmQgdXNlIHRoYXQsIHJh dGhlciB0aGFuIHRha2UgdGhlIGludGVyZmFjZSB5b3UgdXNlZCBmb3INCj50aGUgU0lQIGRpYWxv Zywgb3Igc2ltaWxhciwgdXNlZCB0byBlc3RhYmxpc2ggdGhpcyBwYXJ0aWN1bGFyIFJUUA0KPnNl c3Npb24ocykuDQoNClRoZSB0ZXh0IGlzIG5vdCBzYXlpbmcgdG8gdXNlIE1BQyBmb3IgbG9uZy10 ZXJtIHBlcnNpc3RlbnQgQ05BTUUuIEl0IHNheXMNCnRvIHVzZSBpdCBmb3IgKnNob3J0LXRlcm0q IHBlcnNpc3RlbmN5LiBTb3JyeSwgSSBhbSBub3QgZ2V0dGluZyB3aGVyZQ0KdGhlcmUgaXMgdW5j bGFyaXR5Lg0KDQoNCj4NCj5DaGVlcnMNCj4NCj5NYWdudXMgV2VzdGVybHVuZA0KPg0KPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj5NdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFC L1RWTQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Fcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25l ICArNDYgMTAgNzE0ODI4Nw0KPkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUg KzQ2IDczIDA5NDkwNzkNCj5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KDQoNCg== From abegen@cisco.com Tue Mar 26 02:58:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1008221F88CC for ; Tue, 26 Mar 2013 02:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-T57umTEqVs for ; Tue, 26 Mar 2013 02:58:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEDA21F88C7 for ; Tue, 26 Mar 2013 02:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2190; q=dns/txt; s=iport; t=1364291927; x=1365501527; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Zzp51FnjogZNr7VvEh7DazVsL7ZC4b9n9YbQLPjRmNI=; b=Ot9oGdyUU7Hr1fQSXo5mEQn+bqOjcyXG5UnNsBW8zLsn68cH7gjjWlzw NhbyEZM3SybV9oCseBAcu5eXfFpC59dQoNqnNrr+xR58v/IdVqaDHqrO2 Zt+G9gQ9IigskpoirxulJGWb28emQfuDFto+B6v16JpPbfsZqp2hITw+X U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAHZwUVGtJV2Y/2dsb2JhbABDgmeDcL0rDXoWgSqCHwEBAQQBAQEgEVEGAQgRAwECAQICBiACBCULFQgIAgQBEgiIDAELrwiCQJANBIEjjTwCFhASBoInMmEDp26DCoIo X-IronPort-AV: E=Sophos;i="4.84,911,1355097600"; d="scan'208";a="191534234" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2013 09:58:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2Q9wkrR010037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 09:58:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 04:58:46 -0500 From: "Ali C. Begen (abegen)" To: Steve Underwood , "avt@ietf.org" Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHOH1SRBgQ8NzU4bUC2VIRlvWTydpi2+uKA///tk62AAJCxAIAAvcqA Date: Tue, 26 Mar 2013 09:58:05 +0000 Message-ID: In-Reply-To: <5150E032.4060307@coppice.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.206] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 09:58:48 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXZlIFVuZGVyd29vZCA8c3RldmV1 QGNvcHBpY2Uub3JnPg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMjYsIDIwMTMgMTozOSBBTQ0KVG86 ICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFdH IGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KDQo+T24gMDMvMjYv MjAxMyAwNDowMCBBTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOg0KPj4gVGhhbmtzIGZv ciB0aGUgcmV2aWV3Lg0KPj4NCj4+IE9uIE1hciAyNSwgMjAxMywgYXQgNTowNyBQTSwgIk1hZ251 cyBXZXN0ZXJsdW5kIg0KPj48bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4+DQo+Pj4gV0cgJiBBdXRob3JzLA0KPj4+DQo+Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgYXMgYW4gaW5kaXZpZHVhbCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nDQo+Pj4gY29tbWVu dHM6DQo+Pj4NCj4+PiAxLiBTZWN0aW9uIDQuMiwgc2Vjb25kIGJ1bGxldDoNCj4+Pg0KPj4+ICAg ICAgIFRvIHByb2R1Y2UgYSBzaG9ydC10ZXJtIHBlcnNpc3RlbnQgUlRDUCBDTkFNRSwgYW4gUlRQ IGVuZHBvaW50DQo+Pj4gICAgICAgTVVTVCBlaXRoZXIgKGEpIHVzZSB0aGUgbnVtZXJpYyByZXBy ZXNlbnRhdGlvbiBvZiB0aGUgbGF5ZXItMg0KPj4+ICAgICAgIChNZWRpYSBBY2Nlc3MgQ29udHJv bCAoTUFDKSkgYWRkcmVzcyBvZiB0aGUgaW50ZXJmYWNlIHRoYXQgaXMNCj4+PnVzZWQNCj4+PiAg ICAgICB0byBpbml0aWF0ZSB0aGUgUlRQIHNlc3Npb24gYXMgdGhlICJob3N0IiBwYXJ0IG9mIGl0 cyBSVENQIENOQU1FDQo+Pj4gICAgICAgb3INCj4+Pg0KPj4+IElzIHVzaW5nIHRoZSBNQUMgcmVh bGx5IHRoYXQgdW5pcXVlPyBJbiB0aGVzZSBkYXlzIG9mIE1BQyBjbG9uaW5nIGlzDQo+Pj4gdGhp cyBnb29kIGVub3VnaCB0byB1c2UgYXMgbG9uZyB0ZXJtIHBlcnNpc3RlbnQgQ05BTUUgaWRlbnRp Zmllcj8gSQ0KPj4+YWxzbw0KPj4gVGhlIHByb2JhYmlsaXR5IG9mIGNsYXNoIGlzIHByZXR0eSBz bWFsbCBidXQgd2UgY2FuIG1ha2UgYSBub3RlIG9mIHRoaXMuDQo+Pg0KPlRoYXQgZGVwZW5kcyBv biB0aGUgcGxhdGZvcm0uIElmIHlvdSB1c2UgdGhlIE1BQyBhZGRyZXNzIG9uIGEgdmlydHVhbA0K Pm1hY2hpbmUgaXQgYWx3YXlzIGNsYXNoZXMsIGFzIGl0IGFsd2F5cyBhcHBlYXJzIHRvIGJlIHpl cm8uDQoNCkkgY2hlY2tlZCBtaW5lIGFuZCB0aGF0IGlzIG5vdCB0aGUgY2FzZSBmb3IgbWluZS4g SWYgYW4gT1MgdXNlcyBhIE1BQyBvZg0KYWxsIHplcm9zLCBJIHRoaW5rIGl0IHdvdWxkIGhhdmUg bW9yZSBzZXJpb3VzIGlzc3VlcyB0aGFuIHRoZSB1bmlxdWVuZXNzDQpvZiBpdHMgQ05BTUUuDQoN Cg0KDQo+DQo+U3RldmUNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+YXZ0QGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCj4NCg0K DQo= From dwing@cisco.com Tue Mar 26 08:45:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E2821F8A5E for ; Tue, 26 Mar 2013 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.359 X-Spam-Level: X-Spam-Status: No, score=-109.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2IKbE3jFq2p for ; Tue, 26 Mar 2013 08:45:54 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EEC5321F871C for ; Tue, 26 Mar 2013 08:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3038; q=dns/txt; s=iport; t=1364312754; x=1365522354; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=i86HMeyGyL953TYgAirWu6wnV0qEDzNSjQ0wVRh3kKE=; b=lyzh+BiPTuLm+cDRtNneiGc7tOs2EIScRDIlGzK5mKt1TnDDGB3jREEN hwcq/7IEkYqWAll9qBrLzCppnLtvdwFYcTFeBoJdG9rWo8VH/1IvJeYsm EWGkD79qTZVLx+gn5Plidc9l391DYw9IM0b2Dj59HBBufeLA1UOS1rpkM A=; X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208";a="74198404" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Mar 2013 15:45:53 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2QFjp7d021270; Tue, 26 Mar 2013 15:45:51 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Dan Wing In-Reply-To: Date: Tue, 26 Mar 2013 08:45:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1503) Cc: Magnus Westerlund , "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:45:54 -0000 On Mar 26, 2013, at 2:57 AM, Ali C. Begen (abegen) = wrote: > -----Original Message----- > From: Magnus Westerlund > Date: Tuesday, March 26, 2013 11:49 AM > To: "Ali C. Begen" > Cc: "avt@ietf.org" , > "draft-ietf-avtcore-6222bis@tools.ietf.org" > > Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 >=20 >> On 2013-03-25 21:00, Ali C. Begen (abegen) wrote: >>> Thanks for the review. >>>=20 >>> On Mar 25, 2013, at 5:07 PM, "Magnus Westerlund" >>> wrote: >>>=20 >>>> wonder of its persistence behavior as it says to use the MAC of >>>> the Interface that ones initiate the communication over. With >>>> multiple interfaces, I can in the context of an application use all >>>> of these interfaces over a set of calls. Thus it doesn't have >>>> particular good long term stability either. >>>=20 >>> I think it is meant to say the interface over which the initial >>> connection was made not all other possible interfaces that could be >>> used during the rtp session. >>>>=20 >>=20 >> The main point I try to get across is that which interface you use = for >> the initial connection varies between different communication >> establishments. If your goal is to have a long term persistent >> identifier then you need to store the first one used in the context = of >> an application and use that, rather than take the interface you used = for >> the SIP dialog, or similar, used to establish this particular RTP >> session(s). >=20 > The text is not saying to use MAC for long-term persistent CNAME. It = says > to use it for *short-term* persistency. Sorry, I am not getting where > there is unclarity. I think what Magnus is saying is that one person's long term is another = person's short term, and the text needs to explain this situation. How = about this: For the duration of an RTP session, different interfaces might be used. For example, a single RTP session might be established on a WiFi interface and a mobility event moves that session to a 3G interface. When such an interface change occurs, the same CNAME MUST be retained. -d >=20 >=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 >> = ---------------------------------------------------------------------- >>=20 >>=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Tue Mar 26 08:52:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6221F8BA6 for ; Tue, 26 Mar 2013 08:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-eXgCvy8S7O for ; Tue, 26 Mar 2013 08:52:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BD3D521F8B0C for ; Tue, 26 Mar 2013 08:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5236; q=dns/txt; s=iport; t=1364313146; x=1365522746; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G3vnVcH5GFCv77b/k1Fpahv45FlAuEvt3KohhQSvUc8=; b=WzIIxbD9fUqUFeWWEIAz5325ej1liOPsEIKChuvKQkW7BVB4/RWruHK4 TDg213ZaR/sTrk/237YHCQDxterB5SS6RuKV6NxPk046RaVa4jlnLFb3H Cp8Ova+GM3nED0RuIqawluCflGbTZZStChww0HgxzIhWt/DZ6293Xveb1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAIDDUVGtJXHA/2dsb2JhbABDgmeDFlq9Kw15FoEqgh8BAQEEAQEBCRcRRQwCBAEGAhEDAQIBAgIGHQMCBBkMCxQBCAgCBA4FCIgMAQuTSJsEgkCPfgQEgR+NPAIWEAsHBoInMmEDp26DCoIo X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="scan'208";a="191622987" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 26 Mar 2013 15:52:26 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2QFqQ5Y003337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 15:52:26 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 10:52:25 -0500 From: "Ali C. Begen (abegen)" To: "Dan Wing (dwing)" Thread-Topic: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHOH1SRBgQ8NzU4bUC2VIRlvWTydpi2+uKA///tk62AATsWAIAAExuAgABQfoCAABKYAA== Date: Tue, 26 Mar 2013 15:51:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.55] Content-Type: text/plain; charset="utf-8" Content-ID: <8BD27E1D0DD59F4FBAB00E1FDF01A3DD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Magnus Westerlund , "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 15:52:27 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhbiBXaW5nIDxkd2luZ0BjaXNjby5j b20+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyA1OjQ1IFBNDQpUbzogIkFsaSBDLiBC ZWdlbiIgPGFiZWdlbkBjaXNjby5jb20+DQpDYzogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4sDQoiZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXNAdG9v bHMuaWV0Zi5vcmciDQo8ZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXNAdG9vbHMuaWV0Zi5vcmc+ LCAiYXZ0QGlldGYub3JnIiA8YXZ0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBX RyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDENCg0KPg0KPk9uIE1h ciAyNiwgMjAxMywgYXQgMjo1NyBBTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIDxhYmVnZW5AY2lz Y28uY29tPg0KPndyb3RlOg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZy b206IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQo+ PiBEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNiwgMjAxMyAxMTo0OSBBTQ0KPj4gVG86ICJBbGkgQy4g QmVnZW4iIDxhYmVnZW5AY2lzY28uY29tPg0KPj4gQ2M6ICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0 Zi5vcmc+LA0KPj4gImRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzQHRvb2xzLmlldGYub3JnIg0K Pj4gPGRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzQHRvb2xzLmlldGYub3JnPg0KPj4gU3ViamVj dDogUmU6IFtBVlRDT1JFXSBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJi aXMtMDENCj4+IA0KPj4+IE9uIDIwMTMtMDMtMjUgMjE6MDAsIEFsaSBDLiBCZWdlbiAoYWJlZ2Vu KSB3cm90ZToNCj4+Pj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KPj4+PiANCj4+Pj4gT24gTWFy IDI1LCAyMDEzLCBhdCA1OjA3IFBNLCAiTWFnbnVzIFdlc3Rlcmx1bmQiDQo+Pj4+IDxtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IHdvbmRlciBvZiBp dHMgcGVyc2lzdGVuY2UgYmVoYXZpb3IgYXMgaXQgc2F5cyB0byB1c2UgdGhlIE1BQyBvZg0KPj4+ Pj4gdGhlIEludGVyZmFjZSB0aGF0IG9uZXMgaW5pdGlhdGUgdGhlIGNvbW11bmljYXRpb24gb3Zl ci4gV2l0aA0KPj4+Pj4gbXVsdGlwbGUgaW50ZXJmYWNlcywgSSBjYW4gaW4gdGhlIGNvbnRleHQg b2YgYW4gYXBwbGljYXRpb24gdXNlIGFsbA0KPj4+Pj4gb2YgdGhlc2UgaW50ZXJmYWNlcyBvdmVy IGEgc2V0IG9mIGNhbGxzLiBUaHVzIGl0IGRvZXNuJ3QgaGF2ZQ0KPj4+Pj4gcGFydGljdWxhciBn b29kIGxvbmcgdGVybSBzdGFiaWxpdHkgZWl0aGVyLg0KPj4+PiANCj4+Pj4gSSB0aGluayBpdCBp cyBtZWFudCB0byBzYXkgdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBpbml0aWFsDQo+Pj4+ IGNvbm5lY3Rpb24gd2FzIG1hZGUgbm90IGFsbCBvdGhlciBwb3NzaWJsZSBpbnRlcmZhY2VzIHRo YXQgY291bGQgYmUNCj4+Pj4gdXNlZCBkdXJpbmcgdGhlIHJ0cCBzZXNzaW9uLg0KPj4+Pj4gDQo+ Pj4gDQo+Pj4gVGhlIG1haW4gcG9pbnQgSSB0cnkgdG8gZ2V0IGFjcm9zcyBpcyB0aGF0IHdoaWNo IGludGVyZmFjZSB5b3UgdXNlIGZvcg0KPj4+IHRoZSBpbml0aWFsIGNvbm5lY3Rpb24gdmFyaWVz IGJldHdlZW4gZGlmZmVyZW50IGNvbW11bmljYXRpb24NCj4+PiBlc3RhYmxpc2htZW50cy4gSWYg eW91ciBnb2FsIGlzIHRvIGhhdmUgYSBsb25nIHRlcm0gcGVyc2lzdGVudA0KPj4+IGlkZW50aWZp ZXIgdGhlbiB5b3UgbmVlZCB0byBzdG9yZSB0aGUgZmlyc3Qgb25lIHVzZWQgaW4gdGhlIGNvbnRl eHQgb2YNCj4+PiBhbiBhcHBsaWNhdGlvbiBhbmQgdXNlIHRoYXQsIHJhdGhlciB0aGFuIHRha2Ug dGhlIGludGVyZmFjZSB5b3UgdXNlZA0KPj4+Zm9yDQo+Pj4gdGhlIFNJUCBkaWFsb2csIG9yIHNp bWlsYXIsIHVzZWQgdG8gZXN0YWJsaXNoIHRoaXMgcGFydGljdWxhciBSVFANCj4+PiBzZXNzaW9u KHMpLg0KPj4gDQo+PiBUaGUgdGV4dCBpcyBub3Qgc2F5aW5nIHRvIHVzZSBNQUMgZm9yIGxvbmct dGVybSBwZXJzaXN0ZW50IENOQU1FLiBJdA0KPj5zYXlzDQo+PiB0byB1c2UgaXQgZm9yICpzaG9y dC10ZXJtKiBwZXJzaXN0ZW5jeS4gU29ycnksIEkgYW0gbm90IGdldHRpbmcgd2hlcmUNCj4+IHRo ZXJlIGlzIHVuY2xhcml0eS4NCj4NCj5JIHRoaW5rIHdoYXQgTWFnbnVzIGlzIHNheWluZyBpcyB0 aGF0IG9uZSBwZXJzb24ncyBsb25nIHRlcm0gaXMgYW5vdGhlcg0KPnBlcnNvbidzIHNob3J0IHRl cm0sIGFuZCB0aGUgdGV4dCBuZWVkcyB0byBleHBsYWluIHRoaXMgc2l0dWF0aW9uLiAgSG93DQo+ YWJvdXQgdGhpczoNCj4NCj4gICAgRm9yIHRoZSBkdXJhdGlvbiBvZiBhbiBSVFAgc2Vzc2lvbiwg ZGlmZmVyZW50IGludGVyZmFjZXMNCj4gICAgbWlnaHQgYmUgdXNlZC4gIEZvciBleGFtcGxlLCBh IHNpbmdsZSBSVFAgc2Vzc2lvbiBtaWdodCBiZQ0KPiAgICBlc3RhYmxpc2hlZCBvbiBhIFdpRmkg aW50ZXJmYWNlIGFuZCBhIG1vYmlsaXR5IGV2ZW50IG1vdmVzDQo+ICAgIHRoYXQgc2Vzc2lvbiB0 byBhIDNHIGludGVyZmFjZS4gIFdoZW4gc3VjaCBhbiBpbnRlcmZhY2UgY2hhbmdlDQo+ICAgIG9j Y3VycywgdGhlIHNhbWUgQ05BTUUgTVVTVCBiZSByZXRhaW5lZC4NCg0KUmVnYXJkbGVzcyBvZiB3 aGF0IG1ldGhvZCB5b3UgdXNlIHRvIHByb2R1Y2UgYSBDTkFNRSBvciBob3cgbWFueQ0KaW50ZXJm YWNlcyB5b3UgaGF2ZSBvciB3aGV0aGVyIHlvdSByb2FtIGZyb20gb25lIHRvIGFub3RoZXIgZHVy aW5nIGFuIFJUUA0Kc2Vzc2lvbiwgeW91IG11c3Qga2VlcCB0aGUgc2FtZSBDTkFNRSBhbnl3YXku IEkgdGhpbmsgd2Ugd2FudGVkIHRvIHNheQ0KdGhpcyB0aHJ1ICJJbiBlaXRoZXIgY2FzZSwgdGhl IHByb2NlZHVyZSBpcyBwZXJmb3JtZWQgb25jZSBwZXINCmluaXRpYWxpemF0aW9uIG9mIHRoZSBz b2Z0d2FyZS4iIEJ1dCB5b3VyIGNsYXJpZmljYXRpb24gaXMgaGVscGZ1bCwgSQ0KYWdyZWUuDQoN Cj4NCj4tZA0KPg0KPg0KPg0KPg0KPj4gDQo+PiANCj4+PiANCj4+PiBDaGVlcnMNCj4+PiANCj4+ PiBNYWdudXMgV2VzdGVybHVuZA0KPj4+IA0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBNdWx0aW1l ZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0 ODI4Nw0KPj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5 NDkwNzkNCj4+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IA0KPj4+IA0KPj4g DQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0QGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPg0KPg0K DQoNCg== From magnus.westerlund@ericsson.com Tue Mar 26 09:40:49 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3617621F8C8F for ; Tue, 26 Mar 2013 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.629 X-Spam-Level: X-Spam-Status: No, score=-105.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny2U4DuDL396 for ; Tue, 26 Mar 2013 09:40:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE321F8C71 for ; Tue, 26 Mar 2013 09:40:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-75-5151cf8e9682 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 25.0A.32353.E8FC1515; Tue, 26 Mar 2013 17:40:46 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 26 Mar 2013 17:40:45 +0100 Message-ID: <5151CF8C.5080304@ericsson.com> Date: Tue, 26 Mar 2013 17:40:44 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW7f+cBAgx+dEhYPts9ltHjZs5Ld 4vSEe4wOzB5Tfm9k9Viy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4Mh6cuMxcsFu4YmvLP8YG xi38XYycHBICJhInr09jhLDFJC7cW88GYgsJnGSUmN+S08XIBWQvZ5TY9WsBE0iCV0BbovFS I5jNIqAqsfjMdbAGNgELiZs/GsFsUYFgiZ+vzrBA1AtKnJz5BMwWEdCT2N8BsYxZoFbi7ov1 rCC2sICLxL9JDxghFvtI9E/5zAxicwr4Smxu3ckEcZykxJYX7ewQvZoSrdt/Q9nyEs1bZzND 9GpLNDR1sE5gFJqFZPUsJC2zkLQsYGRexciem5iZk15uvokRGL4Ht/w22MG46b7YIUZpDhYl cd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgrPyl6v9aZ23Zx4TsGlx53c4P27ScT DZfusVvMPFmXzbFuYUp54JSbE/SeH5HxZi85HnL+7LPYv6tj4+OWuZV8nrUw+Jth5wGONy7T 2o1aQmIylW9/DD41Maf1+MmbeyLvKb/7UzFboEH1SJve5KTChb0832dmpW0QT7v63PBR3ruC KQFSCsZKLMUZiYZazEXFiQBfmp6JLQIAAA== Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:40:49 -0000 On 2013-03-26 10:57, Ali C. Begen (abegen) wrote: > -----Original Message----- > From: Magnus Westerlund >>> >>>> wonder of its persistence behavior as it says to use the MAC of >>>> the Interface that ones initiate the communication over. With >>>> multiple interfaces, I can in the context of an application use all >>>> of these interfaces over a set of calls. Thus it doesn't have >>>> particular good long term stability either. >>> >>> I think it is meant to say the interface over which the initial >>> connection was made not all other possible interfaces that could be >>> used during the rtp session. >>>> >> >> The main point I try to get across is that which interface you use for >> the initial connection varies between different communication >> establishments. If your goal is to have a long term persistent >> identifier then you need to store the first one used in the context of >> an application and use that, rather than take the interface you used for >> the SIP dialog, or similar, used to establish this particular RTP >> session(s). > > The text is not saying to use MAC for long-term persistent CNAME. It says > to use it for *short-term* persistency. Sorry, I am not getting where > there is unclarity. > Sorry, about the short term vs. long term persistence. My mixup. I think the text that exist is likely to produce the desired result, but not really clear. As the aspect that the same short term persistent CNAME needs to be used over all the RTP sessions part of the same communication session is not that explicit. One improvement could be to say: o To produce a short-term persistent RTCP CNAME, an RTP endpoint MUST either (a) use the numeric representation of the layer-2 (Media Access Control (MAC)) address of the interface that is used to initiate the initial set of RTP sessions as the "host" part of ^^^^^^^^^^^^^^ ^ its RTCP CNAME or 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 Tue Mar 26 09:45:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683BC21F8A3E for ; Tue, 26 Mar 2013 09:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.474 X-Spam-Level: X-Spam-Status: No, score=-105.474 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf0KUw-TFm7C for ; Tue, 26 Mar 2013 09:45:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 786A821F8A41 for ; Tue, 26 Mar 2013 09:45:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-f5-5151d0aba3bf Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 17.0F.10459.BA0D1515; Tue, 26 Mar 2013 17:45:32 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 26 Mar 2013 17:45:32 +0100 Message-ID: <5151D0AB.6010804@ericsson.com> Date: Tue, 26 Mar 2013 17:45:31 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvje6aC4GBBl3ruS0ebJ/LaPGyZyW7 xekJ9xgtLl57yOTA4jHl90ZWjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr40PvWtaCxUIV 95pPsTYwnuTrYuTkkBAwkVgz5zQ7hC0mceHeerYuRi4OIYGTjBIn7k1mhnCWM0pMfvCbGaSK V0Bb4uKdXWwgNouAqsSFXesZQWw2AQuJmz8aweKiAsESP1+dYYGoF5Q4OfMJmC0ioCexv2Ma WD2zwFJGiWnLI0FsYQEXiX+THgDFOYCW+Ugc7zMECXMK+Eq83DKZEeI4SYktL9rZIVo1JVq3 /4ay5SWat84GO00I6LSGpg7WCYxCs5BsnoWkZRaSlgWMzKsY2XMTM3PSyw03MQID+eCW37o7 GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo7/C78hcwdB34fuX S92PSX+fwxkSx/3hNfsOu81rw37XH30trG1wx8JL6p3W/ZDdZww4Vm0S3+IZ7e+sn/a0r4Lz 6conTNf9XRZr2j0xYVGNffpm4oSSRTqT7Ot+/o74sJpxgYs5fyHrg7O3WXj5PF9t3T55cpao opTq5dfOcidWmf9r/RTho8RSnJFoqMVcVJwIAFNiUkAyAgAA Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" , "avt@ietf.org" , "Dan Wing $dwing$" Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:45:38 -0000 On 2013-03-26 16:51, Ali C. Begen (abegen) wrote: >>>> >>>> The main point I try to get across is that which interface you use for >>>> the initial connection varies between different communication >>>> establishments. If your goal is to have a long term persistent >>>> identifier then you need to store the first one used in the context of >>>> an application and use that, rather than take the interface you used >>>> for >>>> the SIP dialog, or similar, used to establish this particular RTP >>>> session(s). >>> >>> The text is not saying to use MAC for long-term persistent CNAME. It >>> says >>> to use it for *short-term* persistency. Sorry, I am not getting where >>> there is unclarity. >> >> I think what Magnus is saying is that one person's long term is another >> person's short term, and the text needs to explain this situation. How >> about this: >> >> For the duration of an RTP session, different interfaces >> might be used. For example, a single RTP session might be >> established on a WiFi interface and a mobility event moves >> that session to a 3G interface. When such an interface change >> occurs, the same CNAME MUST be retained. > > Regardless of what method you use to produce a CNAME or how many > interfaces you have or whether you roam from one to another during an RTP > session, you must keep the same CNAME anyway. I think we wanted to say > this thru "In either case, the procedure is performed once per > initialization of the software." But your clarification is helpful, I > agree. > Exactly, this what was I was after. The main point is the need to continue using the same CNAME during the whole communication session that include any set of RTP sessions. I will leave it the authors hands to do what you think are the best word smithing to improve this. 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 Thu Mar 28 03:01:56 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9B21F8E7D for ; Thu, 28 Mar 2013 03:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.001 X-Spam-Level: X-Spam-Status: No, score=-106.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtWA-g5jqLib for ; Thu, 28 Mar 2013 03:01:56 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE521F8E6B for ; Thu, 28 Mar 2013 03:01:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-d6-5154150b3a21 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.01.19728.B0514515; Thu, 28 Mar 2013 11:01:47 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 28 Mar 2013 11:01:47 +0100 Message-ID: <51541502.90406@ericsson.com> Date: Thu, 28 Mar 2013 11:01:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org References: <513F7C5B.5060101@ericsson.com> In-Reply-To: <513F7C5B.5060101@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+JvjS63aEigwamdOhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49O0JawFr3krLjw/z9TAOIe7i5GTQ0LAROLo9JNMELaYxIV7 69m6GLk4hAROMkr8fXYVylnOKPHs721WkCpeAU2Jpi3LwGwWAVWJJd+2sYPYbAIWEjd/NLKB 2KICwRI/X51hgagXlDg58wmYLSIgILFi+18gm4NDWMBP4u95sHIhAW2J1Xe/MoLYnAI6Eutv LWeBOEhSYsuLdrDxzAJ6ElOutjBC2PISzVtnM8P0NjR1sE5gFJyFZNssJC2zkLQsYGRexcie m5iZk15utIkRGH4Ht/xW3cF455zIIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhi7/utpKx3kz+vdJJPQt0Dt1ZFvkne0I4v33jiZzZ6tnZG93o7jkfQFp8JQtRNhs8Kn bHH3Uii5HzbZeztP4o6GCe/Nj049GTq9inXzxKCDT4NWWXybuC5gsZRxttBF2VutJlw3K+ps mw33B5xPkSq/v+xE14U/gVsPrktRfZvouEspmi/ztIQSS3FGoqEWc1FxIgBCHOEmDQIAAA== Subject: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:01:57 -0000 WG, So far there has be no other reviews of this document than mine. Can someone please review this document? I hereby extended the WG last call with one week until the 7th of April. Cheers Magnus On 2013-03-12 20:04, Magnus Westerlund wrote: > WG, > > This is to announce the start of a WG last call on: > > Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > (CNAMEs) to be published as a proposed standard. > > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ > > Please provide any feedback by the 31st of March. > > Regards > > Magnus Westerlund > WG chair > > > ---------------------------------------------------------------------- > 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 Core Maintenance > 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 ron.even.tlv@gmail.com Sun Mar 31 00:33:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5E21F85B8; Sun, 31 Mar 2013 00:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxoCaeUrOgKc; Sun, 31 Mar 2013 00:33:34 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 517EB21F8523; Sun, 31 Mar 2013 00:33:33 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id n15so701121ead.0 for ; Sun, 31 Mar 2013 00:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=GxQCFJj4UzaoImNt80xHVMxqOHfpeQidzMEAKci5YnU=; b=ahKjpVGguwMMy/U/riZFqfTV5v9IIT5ihdCN7P0XxFIXuJJHU04NoWAPAwK6J2SVYS rltGtiYQqQ6OILm3dRIRPVLbhx6K67akP2r0UWXV9g4KsrhXdCl+ieEhVpLsAhuAjSmu /FRuqHq/cqEPqKKBHYmBS+Hapi5SndvvwRYgeyBpOiCf0ypeCEdbRM6P88dpKvPjtldS bx0EIqyUOy/TB+pIdMESa+JpOCMrnCC+RDUW+J9TxL+oaroiWZBgLQWs3N/+/dC9U9LZ XDkeZS/16FLNx6xMvqZV0r2WwktBdv8Hrh0BJ1vMImCz1cq4xPwKpeMVAmUhgK9B5T9E L/3Q== X-Received: by 10.14.111.72 with SMTP id v48mr25206351eeg.11.1364715212384; Sun, 31 Mar 2013 00:33:32 -0700 (PDT) Received: from RoniE (bzq-109-65-179-201.red.bezeqint.net. [109.65.179.201]) by mx.google.com with ESMTPS id t4sm14119806eel.0.2013.03.31.00.33.29 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 31 Mar 2013 00:33:31 -0700 (PDT) From: "Roni Even" To: "'Richard Barnes'" Date: Sun, 31 Mar 2013 10:33:07 +0300 Message-ID: <05c501ce2de1$fedab280$fc901780$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C6_01CE2DFB.24297120" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4t4fyMMwectRaoRnCdDhcYbVjHMg== Content-Language: en-us Cc: iesg-secretary@ietf.org, rai-ads@tools.ietf.org, avt@ietf.org, Magnus Westerlund Subject: [AVTCORE] Request for publication of draft-ietf-avtcore-idms-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 07:33:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05C6_01CE2DFB.24297120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Richard, I'd like to request that draft-ietf-avtcore-idms-09, Inter-destination Media Synchronization using the RTP Control Protocol (RTCP), be published as Standard Track RFC. I've reviewed the draft in detail, and the AVTCore working group was given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVTCore. Accordingly, please consider it for publication. Thanks, Roni Even (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a standard track RFC defining new RTCP packets and procedures for synchronizing media between multiple sites. The title page header indicates it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Typical use cases in which IDMS is usefull are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. Working Group Summary: This document went through a working group last call. There were comments and the document was updated to resolve all comments. The work started in ETSI and since it have to do with RTCP it was brought to the IETF AVTCore WG. The last issue that took some time was to update the ETSI document clarifying that the change control will be at the IETF. Document Quality: The document got good reviews from AVTcore members. Personnel: Roni Even is the Document Shepherd and the Responsible Area Director is Richard Barnes. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document very carefully in all the versions including the last one 09. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document got good review by mutiple people from AVTcore and all comments were addressed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No need for any such review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, the shepherd has confirmed with all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a strong consensus to start this work at the IETF when it was brought. Multiple people contributed to the work and as a result the WG identified two new work items that are addressed in other new documents which are currently in progress. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits in this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There is a normative reference to draft-ietf-avtcore-clksrc-03 that will start WGLC very soon. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. no (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document defines a new extension URI to the RTP Compact Header Extensions sub-registry of the Real-Time Transport Protocol (RTP) Parameters registry. The registration was reviewed by the document shepherd and it follows the registration requirements. No new IANA registries are defined. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is an ABNF definition for using the new RTCP packet using RFC3264 offer answer. This is common for any new RTCP packe ------=_NextPart_000_05C6_01CE2DFB.24297120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = Richard,
I'd like to request that = draft-ietf-avtcore-idms-09, Inter-destination Media Synchronization = using the RTP Control Protocol (RTCP), be published as Standard Track = RFC.
=
I've reviewed the draft in detail, = and the AVTCore working group was given the opportunity to comment. The = draft is documented in sufficient detail to meet the registration = requirements, and doesn't conflict with other work in AVTCore. = Accordingly, please consider it for publication.

Thanks,
Roni = Even

(1) What type of RFC is = being requested (BCP, Proposed Standard, Internet Standard, = Informational, Experimental, or Historic)? Why is this the proper type = of RFC? Is this type of RFC indicated in the title page header? =
This is a standard track RFC defining new RTCP = packets and procedures for synchronizing media between multiple = sites.
The title page header indicates = it.
(2) The IESG approval = announcement includes a Document Announcement Write-Up. Please provide = such a Document Announcement Write-Up. Recent examples can be found in = the "Action" announcements for approved documents. The = approval announcement contains the following sections:
Technical = Summary:
This document defines = a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report = (XR) Block Type to be used for achieving Inter-Destination Media = Synchronization (IDMS). IDMS is the process of synchronizing = playout across multiple geographically distributed media receivers. = Typical use cases in which IDMS is usefull are social TV, shared = service control (i.e. applications where two or more = geographically separated users are watching a media stream = together), distance learning, networked video walls, networked = loudspeakers, etc.

Working Group Summary:
This document went through = a working group last call. There were comments and the document was = updated to resolve all comments. The work started in ETSI and since it = have to do with RTCP it was brought to the IETF AVTCore WG. The last = issue that took some time was to update the ETSI document clarifying = that the change control will be at the IETF.
Document = Quality:
The document got good reviews from AVTcore = members.
Personnel:
Roni Even is the Document Shepherd and the Responsible Area Director = is Richard Barnes.
(3) Briefly describe the review of this document = that was performed by the Document Shepherd. If this version of the = document is not ready for publication, please explain why the document = is being forwarded to the IESG.
The shepherd reviewed the document very carefully in all the = versions including the last one 09.
(4) Does the document Shepherd have any concerns = about the depth or breadth of the reviews that have been performed? =
This document got good review by mutiple people = from AVTcore and all comments were addressed.
(5) Do portions of the = document need review from a particular or from broader perspective, = e.g., security, operational complexity, AAA, DNS, DHCP, XML, or = internationalization? If so, describe the review that took place. =
No need for any such = review.
(6) Describe any specific concerns or issues that = the Document Shepherd has with this document that the Responsible Area = Director and/or the IESG should be aware of? For example, perhaps he or = she is uncomfortable with certain parts of the document, or has concerns = whether there really is a need for it. In any event, if the WG has = discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.
No = concerns
(7) Has each author confirmed that any and all = appropriate IPR disclosures required for full conformance with the = provisions of BCP 78 and BCP 79 have already been filed. If not, explain = why?
Yes, the shepherd has confirmed with all authors.
(8) Has an IPR disclosure been filed that = references this document? If so, summarize any WG discussion and = conclusion regarding the IPR disclosures.
No IPR = disclosure
(9) How solid is the WG consensus behind this = document? Does it represent the strong concurrence of a few individuals, = with others being silent, or does the WG as a whole understand and agree = with it?
There was a strong consensus to start this work at = the IETF when it was brought. Multiple people contributed to the work = and as a result the WG identified two new work items that are addressed = in other new documents which are currently in = progress.
(10) Has anyone threatened an appeal or otherwise = indicated extreme discontent? If so, please summarise the areas of = conflict in separate email messages to the Responsible Area Director. = (It should be in a separate email because this questionnaire is publicly = available.)
No
(11) Identify any ID nits the Document Shepherd = has found in this document. (See http://www.ietf.org/tools/idnits/ and = the Internet-Drafts Checklist). Boilerplate checks are not enough; this = check needs to be thorough.
No ID nits in this = document.
(12) Describe how the document meets any required = formal review criteria, such as the MIB Doctor, media type, and URI type = reviews.
Not applicable
(13) Have all references = within this document been identified as either normative or informative? =
yes
(14) Are there normative = references to documents that are not ready for advancement or are = otherwise in an unclear state? If such normative references exist, what = is the plan for their completion?
There is a normative = reference to draft-ietf-avtcore-clksrc-03 that will start WGLC = very soon.
(15) Are there downward normative references (see = RFC 3967)? If so, list these downward references to support the Area = Director in the Last Call procedure.
no
(16) Will publication of = this document change the status of any existing RFCs? Are those RFCs = listed on the title page header, listed in the abstract, and discussed = in the introduction? If the RFCs are not listed in the Abstract and = Introduction, explain why, and point to the part of the document where = the relationship of this document to the other RFCs is discussed. If = this information is not in the document, explain why the WG considers it = unnecessary.
No
(17) Describe the Document = Shepherd's review of the IANA considerations section, especially with = regard to its consistency with the body of the document. Confirm that = all protocol extensions that the document makes are associated with the = appropriate reservations in IANA registries. Confirm that any referenced = IANA registries have been clearly identified. Confirm that newly created = IANA registries include a detailed specification of the initial contents = for the registry, that allocations procedures for future registrations = are defined, and a reasonable name for the new registry has been = suggested (see RFC 5226).
This = document defines a new extension URI to the RTP Compact Header = Extensions sub-registry of the Real-Time Transport Protocol = (RTP)   Parameters registry. The registration was reviewed by = the document shepherd and it follows the registration requirements. =

No new IANA registries are = defined.

(18) List any new IANA = registries that require Expert Review for future allocations. Provide = any public guidance that the IESG would find useful in selecting the = IANA Experts for these new registries.
No new IANA = registries.
(19) Describe reviews and automated checks = performed by the Document Shepherd to validate sections of the document = written in a formal language, such as XML code, BNF rules, MIB = definitions, etc.
There is an = ABNF definition for using the new RTCP packet using RFC3264 offer = answer. This is common for any new RTCP = packe
------=_NextPart_000_05C6_01CE2DFB.24297120--

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Tuesday, 12 March 2013 at 13:00-15:00 (Caribbean 4)