From roni.even@mail01.huawei.com Thu Nov 1 07:48:46 2012 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 D9A2721F8D36; Thu, 1 Nov 2012 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KAmhUOhbAzh; Thu, 1 Nov 2012 07:48:46 -0700 (PDT) Received: from hwsga01-in.huaweimarine.com (unknown [119.145.15.223]) by ietfa.amsl.com (Postfix) with ESMTP id BC04B21F8D2E; Thu, 1 Nov 2012 07:48:43 -0700 (PDT) Received: from szxpml204-edg.exmail.huawei.com ([172.17.1.119]) by hwsga01-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id AED23081; Thu, 1 Nov 2012 22:48:33 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml204-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml204-edg.exmail.huawei.com 5 none Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 1 Nov 2012 22:48:19 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.23]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Thu, 1 Nov 2012 22:48:32 +0800 From: Roni Even To: "avt@ietf.org" , "payload@ietf.org" Thread-Topic: CORRECTION: Help the NomCom Thread-Index: AQHNuDCgu11Va/GwQkSHgjeke/CnipfVDwn3 Date: Thu, 1 Nov 2012 14:48:31 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B622A9@szxpml504-mbs.exmail.huawei.com> References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] FW: CORRECTION: Help the NomCom 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, 01 Nov 2012 14:48:47 -0000 Hi, Note that NomCopm will receive input till 11/11 and not till the 4th as was= stated in previous email Roni Even ________________________________________ From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of No= mCom Chair [nomcom-chair@ietf.org] Sent: Thursday, November 01, 2012 2:17 PM To: Working Group Chairs Subject: CORRECTION: Help the NomCom I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11= . The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org= From kevin.gross@avanw.com Thu Nov 1 10:22:01 2012 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 1608721F9121 for ; Thu, 1 Nov 2012 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.357 X-Spam-Level: ** X-Spam-Status: No, score=2.357 tagged_above=-999 required=5 tests=[AWL=-3.999, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOlInVf7VsoH for ; Thu, 1 Nov 2012 10:22:00 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 246D921F8FA7 for ; Thu, 1 Nov 2012 10:22:00 -0700 (PDT) Received: (qmail 31223 invoked by uid 0); 1 Nov 2012 17:21:32 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 1 Nov 2012 17:21:32 -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=csW8ZWeaVa1q2RkdbWi+3HSXLkpHuABFy/0huQTWXIs=; b=dZWNKxlTHddmwF3V750d9d2T5xF9k8dyq+ElzEma1yIUwCobC54YU4DQUUzOWLhNXsfsZhoq1lAsN+ttpTIy3Wq7RKDlg7JepS//Jq9viS7Ro7kLeA3cTF3tw+iJSQc1; Received: from [74.125.83.44] (port=57548 helo=mail-ee0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TTySR-00014w-Ni for avt@ietf.org; Thu, 01 Nov 2012 11:21:32 -0600 Received: by mail-ee0-f44.google.com with SMTP id d4so1632331eek.31 for ; Thu, 01 Nov 2012 10:21:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.173.137 with SMTP id v9mr86472645eel.41.1351790490401; Thu, 01 Nov 2012 10:21:30 -0700 (PDT) Received: by 10.223.152.201 with HTTP; Thu, 1 Nov 2012 10:21:30 -0700 (PDT) In-Reply-To: <20121022212911.14822.99642.idtracker@ietfa.amsl.com> References: <20121022212911.14822.99642.idtracker@ietfa.amsl.com> Date: Thu, 1 Nov 2012 10:21:30 -0700 Message-ID: From: Kevin Gross To: "avt@ietf.org" Content-Type: multipart/alternative; boundary=047d7b621ea0fdba8304cd723f0c X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.83.44 authed with kevin.gross@avanw.com} Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-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: Thu, 01 Nov 2012 17:22:01 -0000 --047d7b621ea0fdba8304cd723f0c Content-Type: text/plain; charset=ISO-8859-1 We have revised draft-ietf-avtcore-clksrc based on discussion at IETF 84 1. We've made minor improvements to language, terminology and formatting. 2. Fixed a bug in ABNF specifying a traceable PTP clock - no grandmaster ID or domain indication is required in this case. 3. Improved readability for specifying direct-referenced media clock - now indicated with "direct" instead of "offset". Made offset specification optional and described how to determine it if not supplied. 4. We have removed use of the term "confidence" in clock discussion and replaced it with "quality" to avoid giving the impression that a confidence interval is under discussion here. We've also clarified the purpose and caveats in communicating clock quality. This should address Johnathan's comment that RTCP may be a better means than SDP to convey synchronization status. 5. Jonathan also made a suggestion that instead of allowing indication of traceability of various clock sources that we define a generic traceable clock and identify it by its stratum value. We researched doing this and discovered that stratum designations are used in NTP clock distribution and in legacy telecommunications systems. In the NTP context, stratum describes how time servers are interconnected but does not describe the quality of the clock produced. The usefulness stratum system in the telecommunications began eroding with the breakup of the bell system. Telecomm synchronization can now be characterized as plesiochronous meaning there is is more of a peering than hierarchical relationship between clocks. We believe knowing the source of a traceable clock is the most reliable and available information for assessing a clock. 6. Added some background material on Stream-Referenced media clock (section 5.3). Added separate signaling of master and slave stream-referenced media clocks. Removed address and port specifications from clock descriptions. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Oct 22, 2012 at 2:29 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > Title : RTP Clock Source Signalling > Author(s) : Aidan Williams > Kevin Gross > Ray van Brandenburg > Hans Stokking > Filename : draft-ietf-avtcore-clksrc-01.txt > Pages : 21 > Date : 2012-10-22 > > Abstract: > NTP timestamps are used by several RTP protocols for synchronisation > and statistical measurement. This memo specifies SDP signalling > identifying NTP timestamp 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-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --047d7b621ea0fdba8304cd723f0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We have revised draft-ietf-avtcore-clksrc based on discussion at IETF 84
  1. We've made minor improvements to lan= guage, terminology and formatting.
  2. Fixed= a bug in ABNF specifying a traceable PTP clock - no grandmaster ID or doma= in indication is required in this case.
  3. Improved readability for specifying direct-r= eferenced media clock - now=A0indicated=A0with "direct" instead o= f "offset". Made offset specification optional and described how = to determine it if not supplied.
  4. We have removed use of the term "confid= ence" in clock discussion and replaced it with "quality" to = avoid giving the impression that a confidence interval is under discussion = here. We've also clarified the purpose and caveats in communicating clo= ck quality. This should address Johnathan's comment that RTCP may be a = better means than SDP to convey synchronization status.
  5. Jonathan also made a suggestion that instead= of allowing indication of traceability of various clock sources that we de= fine a generic traceable clock and identify it by its stratum value. We res= earched doing this and discovered that stratum designations are used in NTP= clock distribution and in legacy telecommunications systems. In the NTP co= ntext, stratum describes how time servers are interconnected but does not d= escribe the quality of the clock produced. The=A0usefulness=A0stratum syste= m in the telecommunications began eroding with the breakup of the bell syst= em. Telecomm synchronization can now be characterized as plesiochronous mea= ning there is is more of a peering than=A0hierarchical=A0relationship betwe= en clocks. We believe knowing the source of a traceable clock is the most r= eliable and available information for assessing a clock.
  6. Added some background material on Stream-Ref= erenced media clock (section 5.3). Added separate signaling of master and s= lave stream-referenced media clocks. Removed address and port specification= s from clock descriptions.

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



On Mon, Oct 22, 2012 at 2:29 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Audio/Video Transport Core Maintenance = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Clock Source Signalling
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Aidan Williams
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin Gross
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ray van Brandenburg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hans Stokking
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-clksrc-01.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22

Abstract:
=A0 =A0NTP timestamps are used by several RTP protocols for synchronisation=
=A0 =A0and statistical measurement. =A0This memo specifies SDP signalling =A0 =A0identifying NTP timestamp clock sources and SDP signalling
=A0 =A0identifying 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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-cl= ksrc-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b621ea0fdba8304cd723f0c-- From magnus.westerlund@ericsson.com Sat Nov 3 10:02:21 2012 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 A3CD721F9C35 for ; Sat, 3 Nov 2012 10:02:21 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKCN456TfgwP for ; Sat, 3 Nov 2012 10:02:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A281A21F9ADF for ; Sat, 3 Nov 2012 10:02:20 -0700 (PDT) X-AuditID: c1b4fb30-b7f936d0000018b3-04-50954e1bc36a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 56.D3.06323.B1E45905; Sat, 3 Nov 2012 18:02:19 +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; Sat, 3 Nov 2012 18:02:18 +0100 Message-ID: <50954E14.9040102@ericsson.com> Date: Sat, 3 Nov 2012 13:02:12 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: rjsparks@nostrum.com References: <20121016225107.EC75072F402@rfc-editor.org> In-Reply-To: <20121016225107.EC75072F402@rfc-editor.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvja6039QAg4dXxCxe9qxkt1j+8gSj xavXV1gtnjaeZbS4/tfI4tqcRjYHNo/WZ3tZPabdv8/m0XLkLavHkiU/mTzOrL7G6DFr5xOW ALYoLpuU1JzMstQifbsEroz5R76xFVwVqeh8NZO5gXGCQBcjJ4eEgIlEZ9tPdghbTOLCvfVs XYxcHEICJxkl7kx7C+UsY5T4+2YjG0gVr4C2xOHfX1hAbBYBFYmjjasZQWw2AQuJmz8awWpE BYIl9hxbywhRLyhxcuYTsHoRAQmJqSf+s4MMZRaYyCix42g3WEJYwFzi/9p5YM1CQPbei5eY QWxOoKHfF/5mhThPUuLt+1dgcWYBPYkpV1sYIWx5ieats5kherUlGpo6WCcwCs1CsnsWkpZZ SFoWMDKvYmTPTczMSS8338QIDP6DW34b7GDcdF/sEKM0B4uSOK+e6n5/IYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYz560oe+ga8cZnxXTyyz6xxj0Siz6FXc2Lr314S2Kgar2ZiOdv6f6by N8MZqsvvpt56J3Tqe3f+/3lnz4R0btvg8nOCcNEc30vbz6ve3KLCufuRweHN4rFta/b95Xyd JKAi+rZjxvOfegk583SN9Xb9e8XLsuxT4+aCp1lMfuaThSWOc1g+n2KoxFKckWioxVxUnAgA QRIirUwCAAA= Cc: avt@ietf.org, even.roni@huawei.com, martin@martin.st, csp@csperkins.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC5761 (3380) 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, 03 Nov 2012 17:02:21 -0000 Hi, The errata is correct. I would approve it. This is an important correction that should be available until the day, if ever this document is updated. Cheers Magnus On 2012-10-16 18:51, RFC Errata System wrote: > > The following errata report has been submitted for RFC5761, > "Multiplexing RTP Data and Control Packets on a Single Port". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5761&eid=3380 > > -------------------------------------- > Type: Technical > Reported by: Martin Storsjö > > Section: 4 > > Original Text > ------------- > o RTP payload type 80 conflicts with Receiver Summary Information > (RSI) packets defined in "RTCP Extensions for Single-Source > Multicast Sessions with Unicast Feedback" [6]. > > Corrected Text > -------------- > o RTP payload type 81 conflicts with Receiver Summary Information > (RSI) packets defined in "RTCP Extensions for Single-Source > Multicast Sessions with Unicast Feedback" [6]. > > Notes > ----- > Reference [6], RFC 5760 (IANA likewise), specifies that RTCP RSI has the RTCP packet type number 209, which means that it would conflict with RTP payload type 81, not 80 as stated. > > 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. > > -------------------------------------- > RFC5761 (draft-ietf-avt-rtp-and-rtcp-mux-07) > -------------------------------------- > Title : Multiplexing RTP Data and Control Packets on a Single Port > Publication Date : April 2010 > Author(s) : C. Perkins, M. Westerlund > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- 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 eckelcu@cisco.com Sat Nov 3 10:41:56 2012 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 3E6E821F9991 for ; Sat, 3 Nov 2012 10:41:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmltDeyG1HCx for ; Sat, 3 Nov 2012 10:41:55 -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 3A60C21F9977 for ; Sat, 3 Nov 2012 10:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5222; q=dns/txt; s=iport; t=1351964515; x=1353174115; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WDWq87uj1seSghwWm6Hm5mMfngDKWaSD8qQouyadweQ=; b=aSL01yb6xNV3vf0nNrqXU4zy/G/udj5sYS6yMNOpeY2TemRDc43S0rLo QF8Bt4KeTxNc2/tBoj5t1OOCOEIulZf+fTsgIkgUi/sQ1h9iubipxhuBM H3FQsD/QIBYBvUPnUyAZjz9X0hXnfK+Igc5D2+9AKuEEWWdA6Prm/NxPf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGxWlVCtJV2a/2dsb2JhbABEhhe8I3uBCIIeAQEBBBIBEBE+BQ4EAgEIEQQBAQMCBgsOBAMCAgIwFAEICAIEARIIEweHaJljjSiSIYEgimGDC4IeMmEDkkmSC4Frgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138511715" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 03 Nov 2012 17:41:54 +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 qA3HfsQO030523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 17:41:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 12:41:54 -0500 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , IETF AVTCore WG Thread-Topic: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.txt Thread-Index: AQHNsGpY3aKNUyAhXkWGyRcy0JiGXpfYaxPg Date: Sat, 3 Nov 2012 17:41:53 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828104224@xmb-aln-x08.cisco.com> References: <20121022152200.10065.7482.idtracker@ietfa.amsl.com> <508566CF.3010503@ericsson.com> In-Reply-To: <508566CF.3010503@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--52.156800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.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, 03 Nov 2012 17:41:56 -0000 SSB0aGluayB0aGlzIGlzIGEgdXNlZnVsIGRvY3VtZW50OyBIb3dldmVyLCBJIGRvIGhhdmUgYSBm ZXcgY29tbWVudHMgYW5kIGNvbmNlcm5zIHJlZ2FyZGluZyBpdHMgZm9jdXMgYW5kIHJlbGF0aW9u c2hpcCB3aXRoIG90aGVyIGRyYWZ0cy4NCg0KMSkgU2VjdGlvbiAzLCBNb3RpdmF0aW9ucy4gSXQg Y3VycmVudGx5IHJlYWRzIGFzIGZvbGxvd3M6DQoNCiAgIFRoaXMgc2VjdGlvbiBsb29rcyBhdCB0 aGUgbW90aXZhdGlvbnMgd2h5IGFuIGFkZGl0aW9uYWwgc29sdXRpb24gaXMNCiAgIG5lZWRlZCBh c3N1bWluZyB0aGF0IHlvdSBjYW4gZG8gYm90aCB0aGUgY2xhc3NpY2FsIG1ldGhvZCBvZiBoYXZp bmcNCiAgIG9uZSBSVFAgc2Vzc2lvbiBwZXIgdHJhbnNwb3J0IGZsb3cgYXMgZGVmaW5lZCBieSB0 aGUgUlRQDQogICBzcGVjaWZpY2F0aW9uIFtSRkMzNTUwXSBhbmQgd2hlbiB5b3UgaGF2ZSBtdWx0 aXBsZSBtZWRpYSB0eXBlcyB3aXRoaW4NCiAgIG9uZSBSVFAgc2Vzc2lvbiBbSS1ELmlldGYtYXZ0 Y29yZS1tdWx0aS1tZWRpYS1ydHAtc2Vzc2lvbl0uDQoNCkhvdyBhYm91dCB0aGUgZm9sbG93aW5n IGluc3RlYWQ6DQoNCiAgIFRoaXMgc2VjdGlvbiBsb29rcyBhdCB0aGUgbW90aXZhdGlvbnMgZm9y IHN0YW5kYXJkaXppbmcgdHdvIG1lY2hhbmlzbXMgDQogICBmb3IgbXVsdGlwbGV4aW5nIG11bHRp cGxlIG1lZGlhIHR5cGVzIHdpdGhpbiBhIHNpbmdsZSB0cmFuc3BvcnQgZmxvdzoNCiAgMSkgaGF2 aW5nIG9uZSBSVFAgc2Vzc2lvbiBwZXIgdHJhbnNwb3J0IGZsb3csIGFzIGRlZmluZWQgYnkgdGhl IFJUUA0KICAgc3BlY2lmaWNhdGlvbiBbUkZDMzU1MF0sIGFuZCBtdWx0aXBsZXhpbmcgbXVsdGlw bGUgUlRQIHNlc3Npb24gcGVyIHRyYW5zcG9ydA0KICAgZmxvdywgYXMgZGVmaW5lZCBpbiB0aGlz IGRvY3VtZW50ICggb3IgZWxzZXdoZXJlIGlmIHByZWZlcnJlZCB0byBzcGxpdCBpdCBvdXQpLg0K ICAyKSBoYXZpbmcgIG11bHRpcGxlIG1lZGlhIHR5cGVzIHdpdGhpbiBvbmUgUlRQIHNlc3Npb24s IGFzIGRlZmluZWQgaW4NCiAgW0ktRC5pZXRmLWF2dGNvcmUtbXVsdGktbWVkaWEtcnRwLXNlc3Np b25dLg0KDQoyKSBTZWN0aW9ucyAzLjEgYW5kIDMuMiBhcmUgbW90aXZhdGlvbnMgZm9yICgyKSBh bmQgYXJlIGR1cGxpY2F0ZWQgaW4gIFtJLUQuaWV0Zi1hdnRjb3JlLW11bHRpLW1lZGlhLXJ0cC1z ZXNzaW9uXSAsIHdoZXJlYXMgc2VjdGlvbnMgMy4zIGFuZCAzLjQgYXJlIG1vdGl2YXRpb25zIGZv ciAoMSkuIFBlcmhhcHMgaXQgaXMgYmVzdCB0byByZW1vdmUgc2VjdGlvbnMgMy4xIGFuZCAzLjIg YW5kIGxldCB0aGlzIGRyYWZ0IGZvY3VzIG9uIHRoZSByZWFzb25zIHdoeSAoMSkgaXMgbmVlZGVk LCBhcyB0aGF0IGlzIHJlYWwgZm9jdXMgb2YgdGhpcyBkcmFmdC4NCg0KMykgU2VjdGlvbiAzLjUg aXMgbW9yZSBhIHN0YXRlbWVudCBvZiB0aGUgcmVxdWlyZW1lbnQgZm9yIGEgd2F5IHRvIG5lZ290 aWF0ZSAoMSkgdnMgKDIpLCByYXRoZXIgdGhhbiBhIG1vdGl2YXRpb24gZm9yIGVpdGhlci4NCg0K NCkgU2VjdGlvbiA2LjIsIFNpZ25hbGluZywgY29udGFpbnMgdGhlIGZvbGxvd2luZzoNCg0KICAg VGhlICdzZXNzaW9uLW11eC1pZCcgYXR0cmlidXRlIGlzIGluY2x1ZGVkIGZvciBhIG1lZGlhIGRl c2NyaXB0aW9uLA0KICAgaW4gb3JkZXIgdG8gaW5kaWNhdGUgdGhlIFNlc3Npb24gSUQgZm9yIHRo YXQgcGFydGljdWxhciBtZWRpYQ0KICAgZGVzY3JpcHRpb24uICBFdmVyeSBtZWRpYSBkZXNjcmlw dGlvbiB0aGF0IHNoYXJlcyBhIGNvbW1vbiBhdHRyaWJ1dGUNCiAgIHZhbHVlIGlzIGFzc3VtZWQg dG8gYmUgcGFydCBvZiBhIHNpbmdsZSBSVFAgc2Vzc2lvbi4gIA0KDQpJcyB0aGF0IHRydWU/IEkg dGhpbmsgeW91IG1lYW50IHRvIHNheSB0aGVzZSBtYXkgZXhpc3QgaW4gb25lIG9yIG1vcmUgUlRQ IHNlc3Npb25zLCB3aXRoIHRoZSBSVFAgc2Vzc2lvbnMgYmVpbmcgbXVsdGlwbGV4ZWQgb24gYSBz aW5nbGUgdHJhbnNwb3J0IGZsb3cuDQpBbmQgdGhlIGxhdGVyIGl0IHJlYWRzIGFzIGZvbGxvd3M6 DQoNCiAgIEFuIFNEUCBPZmZlcmVyDQogICBNVVNUIGluY2x1ZGUgdGhlICdzZXNzaW9uLW11eC1p ZCcgYXR0cmlidXRlIGZvciBldmVyeSBtZWRpYQ0KICAgZGVzY3JpcHRpb24gYXNzb2NpYXRlZCB3 aXRoIGEgJ1NISU0nIGdyb3VwLiAgSWYgdGhlIFNEUCBBbnN3ZXIgZG9lcw0KICAgbm90IGNvbnRh aW4gdGhlIFNISU0gZ3JvdXAsIHRoZSBTRFAgT2ZmZXJlciBNVVNUIE5PVCB1c2UgU0hJTSBiYXNl ZA0KICAgbGF5ZXJpbmcuICBIb3dldmVyLCBpZiB0aGF0IGlzIHNlcGFyYXRlIFJUUCBzZXNzaW9u cyBvciBCVU5ETEUgaXMNCiAgIGRldGVybWluZWQgb24gd2hhdCB3YXMgcHJlc2VudCBpbiB0aGUg b2ZmZXIgYW5kIGFuc3dlci4gIFRoaXMgd2lsbA0KICAgZGVwZW5kIG9uIHdoYXQgdGhlIG9mZmVy aW5nIHBhcnR5IGxpa2VzIHRvIGhhcHBlbi4gDQoNCllvdSBsb3N0IG1lIGhlcmUuIEhvcGVmdWxs eSBzb21lICByZXdvcmRpbmcgd291bGQgaGVscC4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBNYWdudXMgV2VzdGVy bHVuZA0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMjIsIDIwMTIgMTE6MzEgQU0NCj4gVG86IElF VEYgQVZUQ29yZSBXRw0KPiBTdWJqZWN0OiBbQVZUQ09SRV0gRndkOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXdlc3Rlcmx1bmQtDQo+IGF2dGNvcmUtdHJhbnNwb3J0LW11bHRp cGxleGluZy0wNC50eHQNCj4gDQo+IFdHLA0KPiAoQXMgaW5kaXZpZHVhbCkNCj4gDQo+IFdlIGhh dmUgbm93IHN1Ym1pdHRlZCBhbiB1cGRhdGUgdG8gdGhlIG11bHRpcGxleGluZyBvZiBtdWx0aXBs ZSBSVFANCj4gc2Vzc2lvbnMgb3ZlciBhIHNpbmdsZSB0cmFuc3BvcnQgKFNISU0pLiBUaGUgY2hh bmdlcyBpbiB0aGlzIHZlcnNpb24gYXJlOg0KPiANCj4gLSBNYWtpbmcgdGhlIFNISU0gMiBieXRl cywgcHJlLWZpeGVkIGFuZCBpdCBpbmNsdWRlIGEgZml4ZWQgcGF0dGVybiBmb3INCj4gU1RVTiBh bmQgRFRMUyBzZXBhcmF0aW9uLg0KPiAtIFByb3Bvc2UgdGhhdCB3ZSBkbyBzb21lIGtleS1kZXJp dmF0aW9uIGZvciBkaWZmZXJlbnQgUlRQIHNlc3Npb25zIHNvDQo+IHRoYXQgYSBzaW5nbGUga2V5 LW1hbmFnZW1lbnQgc2VxdWVuY2UgY2FuIGtleSBhbGwgdGhlIHNlc3Npb24gd2hlbiBkb2luZw0K PiBEVExTLVNSVFAuDQo+IA0KPiBUaGUgc2lnbmFsaW5nIHNvbHV0aW9uIGluIHRoaXMgZHJhZnQg aGFzIG5vdCBiZWVuIGltcHJvdmVkIHlldCwgd2UgYXJlDQo+IGF3YWl0aW5nIHJlc29sdXRpb24g b2YgdGhlIEJVTkRMRSBkaXNjdXNzaW9uIGluIE1NVVNJQyB0byBiZXR0ZXINCj4gdW5kZXJzdGFu ZCB3aGF0IHBhdGggaXMgc2VsZWN0ZWQgYW5kIGhvdyB0byBpbnRlcmFjdCB3aXRoIHRoYXQgc29s dXRpb24NCj4gYW5kIHRha2UgdGhlIHJhaXNlZCBjb25jZXJucyBpbnRvIGFjY291bnQuDQo+IA0K PiBXZSBoYXZlIG5vdyBkaXNjdXNzZWQgdGhpcyBwcm9wb3NhbCBmb3Igc29tZSB0aW1lIGFuZCBp dCBhcHBlYXJzIGNsZWFyDQo+IHRoYXQgaXQgdGFyZ2V0cyBhIHVzZWZ1bCBjb21iaW5hdGlvbiBv ZiB0cmFkZS1vZmZzLiBXZSBhdXRob3JzIHdvdWxkDQo+IGxpa2UgdG8gcmVxdWVzdCBXRyBhZG9w dGlvbiBvZiB0aGlzIHByb3Bvc2FsLg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMNCg== From eckelcu@cisco.com Sat Nov 3 12:03:08 2012 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 0DDFB21F9CE1 for ; Sat, 3 Nov 2012 12:03:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cziyFD8y-RB5 for ; Sat, 3 Nov 2012 12:03:07 -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 277B921F9CE0 for ; Sat, 3 Nov 2012 12:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5177; q=dns/txt; s=iport; t=1351969387; x=1353178987; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jSAU6C3ar4NFRGvXt5dgdClJufBkcV3ZqgLxf9o3wzQ=; b=goA+NrRkV9BPQDadpi/lVsfdG95avW3ucDtiJcLsoQjzAtrHyIr2CrUi /DPOYo1eZgJZ2wRtHOQ+IVn1y7+hB2A9NhXFrFiz/Q8gPvtEYm2JnfY97 QcHvb/PA6pYtZFDqCfUPaQsvTHxAJhiFjKx7t8CXD2GRSQhlR+BndthcK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD1plVCtJXHA/2dsb2JhbABEAcM0gQiCHgEBAQQBAQEJBgFyAgICAQgRBAEBAQodBxsMCxQJCAIEARIIARIHh2gLmVSfQgSLfYVbYQOIJY5yjT2Ba4Jvghk X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138462725" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2012 19:03:06 +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 qA3J36VA022345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 19:03:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 14:03:06 -0500 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-01.txt Thread-Index: AQHNsGcaldrZDR6Gpkyp34mowd2rfZfFws4AgBK99oA= Date: Sat, 3 Nov 2012 19:03:05 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088281042AA@xmb-aln-x08.cisco.com> References: <20121022150825.29482.25024.idtracker@ietfa.amsl.com> <508562C6.4040902@ericsson.com> In-Reply-To: <508562C6.4040902@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--54.191500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-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: Sat, 03 Nov 2012 19:03:08 -0000 I have some comment on this draft. 1) Section 3.3, Architectural Equality, reads as follows, " Provided the me= dia flows have similar bandwidth requirements, so that the RTCP timing rule= s work, using the same RTP session for several types of media at once appea= rs a reasonable choice." This is confusing because the condition stated abo= ut similar bandwidth is not met by the use case or which this functionality= is being proposed (e.g. sessions with audio and video and perhaps data). 2) Section 4, reads, "The goal of the solution is to enable having one or m= ore RTP sessions, where each RTP session may contain two or more media type= s." I think the goal is for each RTP session to be able to contain one or m= ore media types, right? 3) Section 5.1, reads, " The main rule is that if one expects to have equal= treatment of all media packets, then this specification might be suitable.= The equal treatment [may] include anything from network level up to RTCP = reporting and feedback." However, some other mechanism not based on the 5-t= uple for the flow may be used to provide differential treatment, in which c= ase this multiplexing mechanism may still be suitable despite dissimilar ba= ndwidths. Then later in the same section it reads, "The second important consideratio= n is that all media flows to be sent within a single RTP session need to ha= ve similar bandwidth ... If an RTP session contains flows with very differe= nt bandwidths, for example low-rate audio coupled with high-quality video .= ..". Here is well, as this is one of the intended use cases, I think it is worth= while to clearly state that this draft provides a [proposed] solution; othe= rwise, it seems the mechanism defined in this draft is not suitable for the= very use case that prompted its creation. 4) Section 5.5, same issue as with section 5.1.=20 5) Section 6.1 s/motivating the previously/motivated previously And where is reads, "each SSRC will commonly a native media type", did you = mean to say, "each SSRC will be associated with a specific media type"? Cheers, Charles > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Monday, October 22, 2012 11:14 AM > To: avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp- > session-01.txt >=20 > WG, >=20 > (As author) >=20 > This updates makes three significant changes: >=20 > - Updates also RFC 3551 > - Expandes on the RTCP bandwidth issues > * Note solution is still an open issue > - Add a proposal for XOR based FEC handling in this context. >=20 > Cheers >=20 > Magnus >=20 >=20 > On 2012-10-22 17:08, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Audio/Video Transport Core Maintenanc= e > Working Group of the IETF. > > > > Title : Multiple Media Types in an RTP Session > > Author(s) : Magnus Westerlund > > Colin Perkins > > Jonathan Lennox > > Filename : draft-ietf-avtcore-multi-media-rtp-session-01.txt > > Pages : 19 > > Date : 2012-10-22 > > > > Abstract: > > This document specifies how an RTP session can contain media streams > > with media from multiple media types such as audio, video, and text. > > This has been restricted by the RTP Specification, and thus this > > document updates RFC 3550 and RFC 3551 to enable this behavior for > > applications that satisfy the applicability for using multiple media > > types in a single RTP session. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp- > session > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-0= 1 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multi-media-rtp- > session-01 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > >=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 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Sun Nov 4 10:36:13 2012 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 EB2EA21F874A for ; Sun, 4 Nov 2012 10:36:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C30bZiZZVw8p for ; Sun, 4 Nov 2012 10:36:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7321F8741 for ; Sun, 4 Nov 2012 10:36:13 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-28-5096b59c1de3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 71.0D.26143.C95B6905; Sun, 4 Nov 2012 19:36:12 +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, 4 Nov 2012 19:36:11 +0100 Message-ID: <5096B598.3050900@ericsson.com> Date: Sun, 4 Nov 2012 13:36:08 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "jo@acm.org" References: <20120811205708.F2134B1E002@rfc-editor.org> In-Reply-To: <20120811205708.F2134B1E002@rfc-editor.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvje6crdMCDJZcl7d42bOS3aKpaTqb xe37O5gt5jRfYLE4cX0bu8X1xk3sDmwel694e5y90cDqsWTJTyaPeWc3snksXv+eMYA1issm JTUnsyy1SN8ugSvj5IV2xoLZ0hXrFy9ja2B8INLFyMkhIWAiseDQelYIW0ziwr31bCC2kMBJ RomnU/m7GLmA7GWMEt/eXGQCSfAKaEu0n3/GDmKzCKhI/LyzDsxmE7CQuPmjEaxZVCBYYs+x tYwQ9YISJ2c+YQGxRQRkJZb/Xs0GMpRZ4DejxJFT94GKODiEBRwltr02hVhsLvH4/gywmZxA M+83XmKEOE5S4u37V8wgNrOAnsSUqy2MELa8RPPW2cwQvdoSDU0drBMYhWYhWT0LScssJC0L GJlXMbLnJmbmpJcbbWIEhvvBLb9VdzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYzNTbaHp/3YbjSrcnfzpYj3U2IColhmrJ9q4KQiysHKfuG8r1nkleKJUz1n z31dePRZVJrgy6T9PJ6ZK52VbRXOezXs6izh4Nt7smvWCqXpk0q0WWM1fk2UnHpu8n2bvlj9 x3V/2otulxyVtt7kddGLU4ftTer3zDSDqXdNzbZ9Yts5WzLnS70SS3FGoqEWc1FxIgB/EMbf RQIAAA== Cc: "carsten.burmeister@eu.panasonic.com" , "stewe@stewe.org" , "jose.rey@eu.panasonic.com" , "avt@ietf.org" , "sato652@oki.com" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4585 (3313) 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, 04 Nov 2012 18:36:14 -0000 WG, I have reviewed this errata and it appears correct. I would recommend that it is approved. Additional views on this? Please provide any feedback within a week, after that I will instruct the ADs to approve this errata. Cheers Magnus On 2012-08-11 16:57, RFC Errata System wrote: > > The following errata report has been submitted for RFC4585, > "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=3313 > > -------------------------------------- > Type: Technical > Reported by: Mo Zanaty > > Section: 4.2 > > Original Text > ------------- > rtcp-fb-ack-param = SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > > > Corrected Text > -------------- > rtcp-fb-ack-param = SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > > > Notes > ----- > RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says: > ... > Parameters MUST be provided to further distinguish different types > of positive acknowledgement feedback. > ... > The feedback type "nack", without parameters, indicates use of the > Generic NACK feedback format as defined in Section 6.2.1. > ... > The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK. > > 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. > > -------------------------------------- > RFC4585 (draft-ietf-avt-rtcp-feedback-11) > -------------------------------------- > Title : Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) > Publication Date : July 2006 > Author(s) : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > 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 alan.d.clark@telchemy.com Sun Nov 4 10:39:42 2012 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 BD4AC21F84C8 for ; Sun, 4 Nov 2012 10:39:42 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTTXZOkpYAoQ for ; Sun, 4 Nov 2012 10:39:42 -0800 (PST) Received: from smtp01.myhostedservice.com (smtp01.myhostedservice.com [216.134.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id 727D821F8475 for ; Sun, 4 Nov 2012 10:39:41 -0800 (PST) Received: from mail01.netplexity.net (172.29.251.14) by SMTP01.netplexity.local (172.29.211.9) with Microsoft SMTP Server id 14.0.722.0; Sun, 4 Nov 2012 13:39:18 -0500 Received: from [192.168.1.117] (UnknownHost [97.67.102.65]) by mail01.netplexity.net with SMTP; Sun, 4 Nov 2012 13:39:30 -0500 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 4 Nov 2012 13:39:19 -0500 From: Alan Clark To: Magnus Westerlund , "jo@acm.org" Message-ID: Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC4585 (3313) Thread-Index: Ac26u7MYNJgu1VnSo0Clz6Y0dFGUtg== In-Reply-To: <5096B598.3050900@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: "carsten.burmeister@eu.panasonic.com" , "stewe@stewe.org" , "jose.rey@eu.panasonic.com" , Org , "sato652@oki.com" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4585 (3313) 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, 04 Nov 2012 18:39:42 -0000 Magnus I also recommend that the proposed change is approved Regards Alan On 11/4/12 1:36 PM, "Magnus Westerlund" wrote: > WG, > > I have reviewed this errata and it appears correct. I would recommend > that it is approved. Additional views on this? Please provide any > feedback within a week, after that I will instruct the ADs to approve > this errata. > > Cheers > > Magnus > > On 2012-08-11 16:57, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC4585, >> "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based >> Feedback (RTP/AVPF)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=3313 >> >> -------------------------------------- >> Type: Technical >> Reported by: Mo Zanaty >> >> Section: 4.2 >> >> Original Text >> ------------- >> rtcp-fb-ack-param = SP "rpsi" >> / SP "app" [SP byte-string] >> / SP token [SP byte-string] >> / ; empty >> >> >> Corrected Text >> -------------- >> rtcp-fb-ack-param = SP "rpsi" >> / SP "app" [SP byte-string] >> / SP token [SP byte-string] >> >> >> Notes >> ----- >> RFC 4585 defines and allows generic NACK (with no further parameters) but not >> generic ACK (which always requires further parameters). Section 4.2 says: >> ... >> Parameters MUST be provided to further distinguish different types >> of positive acknowledgement feedback. >> ... >> The feedback type "nack", without parameters, indicates use of the >> Generic NACK feedback format as defined in Section 6.2.1. >> ... >> The ABNF incorrectly allows nothing after "ack", implying that generic ACK is >> valid. Even the approved errata, which replaces the invalid empty alternate >> with optional [], still allows nothing after "ack". Note that recent interest >> in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard >> ACK. >> >> 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. >> >> -------------------------------------- >> RFC4585 (draft-ietf-avt-rtcp-feedback-11) >> -------------------------------------- >> Title : Extended RTP Profile for Real-time Transport Control >> Protocol (RTCP)-Based Feedback (RTP/AVPF) >> Publication Date : July 2006 >> Author(s) : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > From Hua.Chao@alcatel-sbell.com.cn Sun Nov 4 18:49:48 2012 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 BD33721F8916 for ; Sun, 4 Nov 2012 18:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkGMeHPmaGG0 for ; Sun, 4 Nov 2012 18:49:48 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD921F8914 for ; Sun, 4 Nov 2012 18:49:47 -0800 (PST) X-AuditID: ac189297-b7fc36d0000051ff-75-5097276603fe Received: from CNSHJCASHUB04.ad4.ad.alcatel.com (Unknown_Domain [135.251.50.74]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Messaging Gateway) with SMTP id E0.79.20991.66727905; Mon, 5 Nov 2012 10:41:42 +0800 (HKT) Received: from CNSHJMBX01.ad4.ad.alcatel.com ([135.251.50.101]) by CNSHJCASHUB04.ad4.ad.alcatel.com ([135.251.50.74]) with mapi id 14.02.0283.003; Mon, 5 Nov 2012 10:49:45 +0800 From: CHAO Hua To: "avt@ietf.org" Thread-Topic: New Version Notification for draft-hua-avt-rtp-svcmvc-00.txt Thread-Index: AQHNuv0H8gMaxXZ6hEi82FeuaBXKxJfahDww Date: Mon, 5 Nov 2012 02:49:44 +0000 Message-ID: <07D9E2574A252B44ACD1718FC7E9BC9B01223EA0@cnshjmbx01> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.149.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsXS/ltRSjdNfXqAwbl2c4uXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWD2FLaCS8IV1298YW5gnCDcxcjJISFgInHh+xM2CFtM4sK9 9UA2F4eQwB1GiY3fN7FCOFsZJXatf8YOUsUmoCfx+sEiZhBbREBRovXaZ0YQm1nAQOJaSzfY JGEBT4n7v1cD2RxANV4Sq99UQJQbSTy+vxCshEVAReLxruMsIDavgKPEiWO3wOKMArIS0x7d Z4IYKS5x68l8JojjBCSW7DnPDGGLSrx8/I8VwlaU+HhxCSvIKmYBTYn1u/QhWhUlpnQ/ZIcY LyhxcuYTFohySYmDK26wTGAUnYVkwyyE7llIumch6V7AyLKKUSE5rzgjqzg3M8/AUC8xJzmx JDVHtzgpNSdHLzk/Vy85bxMjMErWSEyavoNx137LQ4wCHIxKPLwLlk0NEGJNLCuuzD3EKMHB rCTCy8EwPUCINyWxsiq1KD++qDQntfgQozQHi5I4b+bm4gAhgXSg2dmpqQWpRTBZJg5OqQbG mKJ79hftlqUuTjSNO3Pa4YEhG3fqJuHpQiJTc3/qfXqUwBe60NGg55eNfeSsxTv3ha2acH3K lWOzIjJduBZ+Mj63bNsq51farruY/9x4yPHH+lqkmxsP/3XHF4ucH0yKMtN+MdcoW9RWLOnL rh96ShzlC/8kbE3QNJj9erHK0vv/Ioq+qJqxKbEUZyQaajEXFScCADWp6qeOAgAA Cc: HU Zhongji Subject: [AVTCORE] FW: New Version Notification for draft-hua-avt-rtp-svcmvc-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: Mon, 05 Nov 2012 02:49:48 -0000 RGVhciBhbGwsIA0KDQpJIGhhdmUgc3VibWl0dGVkIG9uZSBuZXcgSS1EIHRvIGRpc2N1c3MgdGhl IHJlbGlhYmxlIEVDTiBwcm9ibGVtIGZvciBTVkMgYW5kIE1WQyB3aXRoIFJUUCBvdmVyIFVEUC4g DQpVUkw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1YS1hdnQt cnRwLXN2Y212Yy0wMC50eHQgDQoNCllvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3Qg UmVnYXJkcw0KSHVhIENIQU8NCkFsY2F0ZWwtTHVjZW50IFNoYW5naGFpIEJlbGwgQ28uIEx0ZA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDIwMTLlubQxMeac iDXml6UgMTA6MjcNClRvOiBDSEFPIEh1YQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWh1YS1hdnQtcnRwLXN2Y212Yy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgSHVhIENoYW8gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMNClJldmlzaW9u OgkgMDANClRpdGxlOgkJIEV4dGVuc2lvbiBvZiBSVFAgZm9yIFNWQyBhbmQgTVZDIHdpdGggdXNh Z2Ugb2YgRUNODQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMS0wNQ0KV0cgSUQ6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNClVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhLWF2dC1ydHAtc3ZjbXZjLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWh1YS1hdnQtcnRwLXN2Y212Yw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMtMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgbWVtbyBzcGVjaWZpZXMgaG93IHRvIHN1cHBvcnQgUlRQIHBhY2tldCBzdHJlYW0gdGhp bm5pbmcgKG9yDQogICByYXRlIGFkYXB0YXRpb24pIGFuZCBFeHBsaWNpdCBDb25nZXN0aW9uIE5v dGlmaWNhdGlvbiAoRUNOKSB3aXRoIHRoZQ0KICAgUmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2Nv bCAoUlRQKSBydW5uaW5nIG92ZXIgVURQIHRvIG1ha2UgZWZmZWN0IGluDQogICBwYXJhbGxlbCB3 aXRoIHJlbGlhYmxlIFJUQ1AgcmVwb3J0IHRvIHRoZSBSVFAgc2VuZGVyLiAgSXQgaW50cm9kdWNl cw0KICAgImR1bW15IFJUUCBwYWNrZXRzIiBpbnRvIHRoZSBzaW5nbGUtc2Vzc2lvbiB0cmFuc21p c3Npb24gKFNTVCkgbW9kZQ0KICAgZm9yIFNjYWxhYmxlIFZpZGVvIENvZGluZyAoU1ZDKSBhbmQg TXVsdGl2aWV3IFZpZGVvIENvZGluZyAoTVZDKS4NCiAgIFRoZSByZWFjdGlvbnMgb2YgUlRQIHJl Y2VpdmVycyB1cG9uIHJlY2VpdmluZyB0aGUgImR1bW15IFJUUCBwYWNrZXRzIg0KICAgYXJlIGRl ZmluZWQuICBUaGUgZG9jdW1lbnQgYWxzbyByZWNvbW1lbmQgdG8gZXh0ZW5kIHRoZSBFQ04NCiAg IGZ1bmN0aW9uYWxpdGllcyBiYXNlZCBvbiB0aGUgc2NhbGFiaWxpdHkgZmVhdHVyZSBvZiBTVkMg YW5kIE1WQy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From ekr@rtfm.com Mon Nov 5 10:17:43 2012 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 6D51821F8945 for ; Mon, 5 Nov 2012 10:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a6d2tMJ7h1k for ; Mon, 5 Nov 2012 10:17:43 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E144721F8912 for ; Mon, 5 Nov 2012 10:17:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id v19so6469054obq.31 for ; Mon, 05 Nov 2012 10:17:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=wHXouvNT2qv5Lnum0vs1Eianf2jGMhdfxlV9OOD5eNM=; b=liEjTDq/idgXEhfJINrFsLQlUtcn0x4a0a7q4iln4TYA2tWwu+0P7ryF6Hgh2OdYUC Rc/teXLo7TFbuYZIPCVVRcui9tAeseQqGC835NXZK5skvSDL7+QoIcSSGuKgmrjQ5agh 14Uyd/T0/XACBNgK4uyBxKMolQDwIoKZ43fekEoljQxxqH9l5jlb+7Q46U2wzpGh8LfN TPHzhBSumkLp63K0QTwUhzM65z4viRwoBrYD8gdKVqVv/Q25vh7xjHmBfLKtOo+pFMcj GINPGvpkD4FLlPkprL7EGnACnMoXJqyVKiuoLvn3ZaKiU2oC/c/tuBwp63FvIa4pnLYF wRaA== Received: by 10.60.7.41 with SMTP id g9mr8383391oea.18.1352139462441; Mon, 05 Nov 2012 10:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.69.104 with HTTP; Mon, 5 Nov 2012 10:17:02 -0800 (PST) X-Originating-IP: [2001:df8:0:16:5a55:caff:fef1:5a11] From: Eric Rescorla Date: Mon, 5 Nov 2012 13:17:02 -0500 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkGekc4wmdao+F8I3D9kIVRk02TB8ARY547TDW9aEFie6s3m5cdY5WjxMsjNvTcoNdwKncm Subject: [AVTCORE] Review of draft-ietf-avtcore-aria-srtp-00 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, 05 Nov 2012 18:17:43 -0000 I have reviewed draft-ietf-avtcore-aria-srtp-00. I'm leaving aside the question of whether it's useful to define another symmetric encryption algorithm for SRTP (my view is generally no, especially since we have already specified SEED) but the WG seems to have decided that. With that said I don't really understand why you are defining three key sizes and three counter modes. I would recommend defining only 128 and 256-bit GCM unless there is some actual reason not to. Other than that, this seems like a reasonably plausible draft. From mamontor@posgrado.upv.es Mon Nov 5 04:20:06 2012 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 3075821F84EC for ; Mon, 5 Nov 2012 04:20:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCOX3dA0dZIv for ; Mon, 5 Nov 2012 04:20:05 -0800 (PST) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 463D021F84EB for ; Mon, 5 Nov 2012 04:20:04 -0800 (PST) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id qA5CK31P021581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Nov 2012 13:20:04 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id qA5CK3Rc020214 for ; Mon, 5 Nov 2012 13:20:03 +0100 Received: from localhost (wm2.cc.upv.es [158.42.249.57]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id qA5CK2Bm023043 for ; Mon, 5 Nov 2012 13:20:02 +0100 Received: from gnd2g71-118.wi-fi.upv.es (gnd2g71-118.wi-fi.upv.es [158.42.71.118]) by webmail.upv.es (Horde Framework) with HTTP; Mon, 05 Nov 2012 13:20:02 +0100 Message-ID: <20121105132002.50214lz37taa88he@webmail.upv.es> Date: Mon, 05 Nov 2012 13:20:02 +0100 From: Mario Montagud Climent To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-Mailman-Approved-At: Mon, 05 Nov 2012 10:46:09 -0800 Subject: [AVTCORE] Question about the minimum RTCP report interval 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, 05 Nov 2012 12:20:06 -0000 Hi all, I would appreciate it very much if you could clarify me a doubt about the minimum RTCP reporting interval. According to RFC 3550, the RTCP report interval is dynamically computed based on the allocated session bandwidth, the average size of all (received and sent) RTCP packets, the number of participants in the session and their role (senders or receivers), or their proportion, and the unicast or multicast nature of the session (Section 6.2 of RFC 3550). Nevertheless, it is also specified that this deterministically computed RTCP report interval should have a lower bound to avoid having bursts (cumpling) of RTCP packets when the number of participants is small and the law of large numbers is not helping to smooth out the traffic overhead. This would also help to avoid excessive frequent reports during transient outages like a network partition. The recommended value in RFC 3550 for that fixed RTCP minimum interval is 5 seconds. The RFC 3550 also specifies that in some cases (e.g., if the data rate is high and the application demands more timely feedback reports) an implementation may scale the minimum RTCP interval to a smaller value given by 360 divided by the session bandwidth (in kbps). Consequently, this yields to an interval smaller than 5 seconds for bandwidths greater than 72 kbps. In multicast sessions, only active senders may use that reduced minimum interval, whilst in unicast sessions it also may be used by receivers. In the above cases, however, the RTCP minimum interval must be still taken into account during the membership accounting procedure in order to not prematurely time out participants (who can indeed be using it) because of inactivity. However, RFC 4585 defines an extension to the RTP Audio-Visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback messages to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented, while maintaining the bandwidth constraints for RTCP and preserving scalability to large groups. In RFC 4585, the RTCP transmission interval specified in RFC 3550 is denoted as Regular RTCP interval. In addition, RFC 4585 specifies that feedback messages can be reported earlier than the next scheduled Regular RTCP transmission time if a receiver detects the need to inform about events of interest in the media stream (e.g., picture or slice loss) close to their occurrence. Otherwise, the Regular RTCP transmission mode is employed, but the minimum RTCP report interval of 5 seconds recommended in RFC 3550 is dropped. So, my questions about this are: - When using the Regular RTCP reporting rules (RFC 3550) in multicast scenarios, which option should we select for the minimum RTCP reporting interval (for a media sender)? Can we use any of the two options for selection the minimum thresholds (i.e., 5 sec or 360/bw_session_kbps)? - Likewise, should the sentence "the minimum RTCP report interval of 5 seconds recommended in RFC 3550 is dropped" from RFC 4585 be applied in all cases (i.e. not only when using the early RTCP reporting rules)? Thank you very much in advance. Best Regards, Mario Montagud From hoene@uni-tuebingen.de Mon Nov 5 11:49:40 2012 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 EF94121F8643 for ; Mon, 5 Nov 2012 11:49:40 -0800 (PST) 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_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42ISK1u5fybo for ; Mon, 5 Nov 2012 11:49:40 -0800 (PST) Received: from mx08.uni-tuebingen.de (mx08.uni-tuebingen.de [134.2.3.6]) by ietfa.amsl.com (Postfix) with ESMTP id DB98C21F8620 for ; Mon, 5 Nov 2012 11:49:39 -0800 (PST) Received: from wm03.uni-tuebingen.de (wm03.uni-tuebingen.de [134.2.3.21]) by mx08.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id qA5JnPhf029298 for ; Mon, 5 Nov 2012 20:49:30 +0100 Received: by wm03.uni-tuebingen.de (Postfix, from userid 30) id BA164D2C015; Mon, 5 Nov 2012 20:49:25 +0100 (CET) Received: from dhcp-54d6.meeting.ietf.org (dhcp-54d6.meeting.ietf.org [130.129.84.214]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Mon, 05 Nov 2012 20:49:25 +0100 Message-ID: <20121105204925.55565gdupykox9vp@webmail.uni-tuebingen.de> Date: Mon, 05 Nov 2012 20:49:25 +0100 From: "Dr. Christian Hoene" To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.10) X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.2.1.23; spam filter version: 3.2.0/2.3; host: mx08) X-AntiVirus: checked by Avira MailGate (version: 3.2.1.23; AVE: 8.2.5.34; VDF: 7.11.10.215; host: mx08); id=3612-LpJFQM Subject: [AVTCORE] RTCP Circuit breaker 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, 05 Nov 2012 19:49:41 -0000 Hi Colin, the following paper might be interesting to your work. http://dl.acm.org/citation.cfm?id=507673 Best regards, Christian From jonathan@vidyo.com Mon Nov 5 13:13:48 2012 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 C288821F85FC for ; Mon, 5 Nov 2012 13:13:48 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psq+TCjggHm6 for ; Mon, 5 Nov 2012 13:13:48 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E321F8510 for ; Mon, 5 Nov 2012 13:13:48 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AB43B7DF1EB for ; Mon, 5 Nov 2012 15:48:30 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 438D87DF1D5 for ; Mon, 5 Nov 2012 15:48:30 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Mon, 5 Nov 2012 16:13:37 -0500 From: Jonathan Lennox To: IETF AVTCore WG Date: Mon, 5 Nov 2012 16:13:44 -0500 Thread-Topic: RTP Circuit breakers and report blocks Thread-Index: Ac27mmvTK6HuDbVPSVO3S/PIZUGQvA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] RTP Circuit breakers and report blocks 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, 05 Nov 2012 21:13:48 -0000 Hi -- Colin asked me to repeat on the list a comment I made at the Mic in t= he session today, so the idea doesn't get lost. There was the discussion about when the circuit breakers should trigger for= AVPF early feedback, and the comment was it should be done for compound pa= ckets containing SR or RR packets, but not for those that don't. If something like the RGRP proposal is adopted, and in the presence of RFC = 3550 report block round-robining, this will need to be more complex. I thi= nk the correct formulation might be that you should respond to SR or RR pac= kets that contain a report block for one of your sources, but not those tha= t don't. -- Jonathan Lennox jonathan@vidyo.com From kevin.gross@avanw.com Mon Nov 5 13:57:03 2012 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 D348711E8099 for ; Mon, 5 Nov 2012 13:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPunTYTfEThP for ; Mon, 5 Nov 2012 13:57:02 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 4378321F8665 for ; Mon, 5 Nov 2012 13:57:02 -0800 (PST) Received: (qmail 19134 invoked by uid 0); 5 Nov 2012 21:56:35 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 5 Nov 2012 21:56:35 -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=IbOmBpleNUtjIHo/qOrSTIoWED4ZATpFdruYVS5KOgs=; b=SVlhJhZm7Pfp5zxdKfD/fF0dIF6uH1wQtOc9RJ2pX6ncunJWLxfJbyzKkTXm7LX7IYWE8omR11VIxxTPDGabRh1cuRch0/jjDQ/4UCaJhPKMSIGO63RCJco3Ga3hQpM0; Received: from [209.85.215.172] (port=35524 helo=mail-ea0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TVUep-0007WB-BL for avt@ietf.org; Mon, 05 Nov 2012 14:56:35 -0700 Received: by mail-ea0-f172.google.com with SMTP id k13so2794338eaa.31 for ; Mon, 05 Nov 2012 13:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.174.194 with SMTP id x42mr41405559eel.22.1352152594057; Mon, 05 Nov 2012 13:56:34 -0800 (PST) Received: by 10.223.152.201 with HTTP; Mon, 5 Nov 2012 13:56:34 -0800 (PST) In-Reply-To: References: <20121022221624.7138.24306.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 16:56:34 -0500 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=047d7b621ede0d0ad204cdc68f40 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.215.172 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org WG" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-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, 05 Nov 2012 21:57:04 -0000 --047d7b621ede0d0ad204cdc68f40 Content-Type: text/plain; charset=ISO-8859-1 Comments on this draft. Some I mentioned in the session today. Smaller ones I did not. Abrstract: Contains the phrase "is expected to stop transmitting." We probably want to make a stronger statement here. Normative text in the draft uses "MUST". Suggest untangling and clarifying this sentence: Old: "It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation." New: "It is expected that, in the absence of severe congestion, all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers." Section 3: Explain why multicast sessions are out of scope. Last bullet point on page 4 mentions that RTCP report interval is dependent on number of participants in the session. Number of participants in a unicast session is always 2 so this is not a contribution if multicast is our of scope. Add editorial clarification to rapid feedback bullet on page 5: Old: "The use of the RTP/AVPF profile is dependent on signalling, but is otherwise generally backwards compatible, as it keeps the same average RTCP reporting interval as the base RTP specification." New: "The use of the RTP/AVPF profile is dependent on signalling, but is otherwise generally backwards compatible with RTP/AVP, as it keeps the same average RTCP reporting interval as the base RTP specification." Section 4 point 2: Multiple packets per frame is a problem. Multiple frames per packet is not a problem: Old: "...the jitter is only meaningful for RTP flows that send a single data packet for each RTP timestamp value (i.e., audio flows, or video flows where each frame comprises one RTP packet)." New: "...the jitter is only meaningful for RTP flows that send a single data packet for each RTP timestamp value (i.e., audio flows, or video flows where each packet comprises one or more video frames)." p.7 The following text may need work: "The remaining congestion signals are the packet loss fraction and the cumulative number of packets lost. These are robust indicators of congestion in a network where packet loss is primarily due to queue overflows, although less accurate in networks where losses can be caused by non-congestive packet corruption. TCP uses packet loss as a congestion signal." TCP intentionally causes congestion to determine available link bandwidth. It is using packet loss to measure capacity. In the presence of TCP characterizing loss fraction as a roust indicator is probably an overstatement. The interaction probably deserves some some further investigation. Section 4.1: Delete second paragraph. As disused in the session today, if things are messed up enough to trigger circuit breaker #1, reducing offered load is not likely a useful response. Section 4.3 contains a copy of this recommendation and is probably an appropriate recommendation for circuit breaker #3 described there. "What it means to cease transmission..." text appears three times (4.1, 4.2 and 4.3). It probably should just appear once and be reference three times. Section 4.1: Specify what a "long time" is: Old: "...but would lead to problematic flows running for a long time before being cut off." New: "...but would lead to problematic flows running for at least 15 seconds before being cut off." Section 4.2: As discussed in the session today, this section needs to be improved to discuss devices that don't implement RTCP. One obvious improvement is to condition the receiver behavior described at the bottom of page 9. A receiver should not trip this circuit breaker if it is receiving RTP packets from the sender. p.10: The equation has a divide-by-zero hazard. You may want to explicitly state that the circuit breaker does not trip if the denominator is 0. Section 4.3: Simulation is required to gain confidence that there are no false-trigger conditions for this circuit breaker. Test in the presence of competing TCP flows. Test different RTCP RR reporting delay and packet loss scenarios. Solicit more ideas from others. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Oct 30, 2012 at 11:05 AM, Colin Perkins wrote: > A summary of the changes in this version is as follows: > > - Clarify that multicast congestion control is outside the scope of this > memo. > > - Clarify what it means for an implementation to cease transmission when > the circuit breaker fires. Specifically, the intention is that the > application will stop sending RTP data packets until the user makes an > explicit attempt to restart the call. The draft notes that RTP flows halted > by the circuit breaker should not be restarted automatically unless the > sender has received information that the congestion has dissipated. > > - Add an explicit RTCP Timeout circuit breaker in Section 4.2 (this is a > revised and extended version of Section 8 of the -00 draft). Unlike the > media timeout in Section 4.1, which fires when returning RTCP RR packets > show that media isn't reaching the receiver, this circuit breaker is > triggered if RTCP packets are no longer returning to the sender. > > - In section 4.3, clarify when high-rate senders can back-off to a lower > rate when the circuit breaker is triggered, and when they need to cease > transmission. > > - Expand and clarify Section 5 about RTP circuit breakers for systems > using the RTP/AVPF profile. A sender needs to process early RTCP reports > that contain an SR/RR packet as-if they were regular RTCP reports, but > ignore early non-compound RTCP packets without an SR/RR. This allows the > use of low-overhead early RTP/AVPF feedback without triggering the RTP > circuit breaker, and so is suitable for RTP congestion control algorithms > that need to quickly report loss events in between regular RTCP reports. > > - Expand and clarify Section 6 about the impact of RTCP XR, to note that > RTCP XR packets are ignored by the circuit breaker algorithm. > > - Expand and clarify Section 7 about the impact of ECN, to note that > reports of ECN-CE marks are treated as packet loss for the congestion based > circuit breaker, but ignored for the media timeout and RTCP timeout circuit > breakers. > > - Expand and clarify Section 8 on the security considerations to discuss > authentication requirements. > > I believe this draft is on the agenda for the AVTCORE meeting in Atlanta, > but feedback via the list is also welcome. > > Colin > > > > > On 22 Oct 2012, at 23:16, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > > > Title : RTP Congestion Control: Circuit Breakers for > Unicast Sessions > > Author(s) : Colin Perkins > > Varun Singh > > Filename : draft-ietf-avtcore-rtp-circuit-breakers-01.txt > > Pages : 16 > > Date : 2012-10-22 > > > > Abstract: > > The Real-time Transport Protocol (RTP) is widely used in telephony, > > video conferencing, and telepresence applications. Such applications > > are often run on best-effort UDP/IP networks. If congestion control > > is not implemented in the applications, then network congestion will > > deteriorate the user's multimedia experience. This document does not > > propose a congestion control algorithm; rather, it defines a minimal > > set of "circuit-breakers". Circuit-breakers are conditions under > > which an RTP flow is expected to stop transmitting media to protect > > the network from excessive congestion. It is expected that all RTP > > applications running on best-effort networks will be able to run > > without triggering these circuit breakers in normal operation. Any > > future RTP congestion control specification is expected to operate > > within the envelope defined by these circuit breakers. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-01 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-circuit-breakers-01 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --047d7b621ede0d0ad204cdc68f40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments on this draft. Some I mentioned in the session today.=A0Smaller=A0= ones I did not.

Abrstract:

Contains = the phrase "is expected to stop transmitting." We probably want t= o make a stronger statement here. Normative text in the draft uses "MU= ST".

Suggest untangling and clarifying this sentence:=A0

Old: "It is expected that all RTP
   applications running on best-effort networks will be able to run
without triggering these circuit breakers in normal operation." 

New: "It is expected t=
hat, in the absence of severe congestion, all RTP
   applications running on best-effort networks will be able to run
   without triggering these circuit breakers."
=

Section 3:

Explain why multicast session=
s are out of scope.



Last=A0bullet=A0point on page 4 mentions t=
hat RTCP report interval is dependent on number of participants in the sess=
ion. Number of participants in a unicast session is always 2 so this is not=
 a=A0contribution if multicast is our of scope.



Add editorial=A0clarification=A0to rapid feedback bulle=
t on page 5:

Old: "The use of the RTP/AVPF profile is depende=
nt

=A0 =A0 =A0 on signalling, but is otherwise generally backwards compatible,=
 as
=A0 =A0 =A0 it keeps the same average RTCP reporting interval as the=
 base RTP
=A0 =A0 =A0 specification."

New: "The use of =
the RTP/AVPF profile is dependent

=A0 =A0 =A0 on signalling, but is otherwise generally backwards compatible =
with RTP/AVP, as
=A0 =A0 =A0 it keeps the same average RTCP reporting in=
terval as the base RTP
=A0 =A0 =A0 specification."

Section 4 point 2: Multiple packets per frame is a problem. Multiple frames= per packet is not a problem:

Old: "...the jitter is only meaningful for RTP<= /div> 
       flows that send a single data packet for each RTP tim=
estamp value
       (i.e., audio flows, or video flows where each frame comprises one
       RTP packet)."

New: "...the ji=
tter is only meaningful for RTP
       flows that send a single data packet for each RTP timestamp value
       (i.e., audio flows, or video flows where each pack=
et comprises one or more video frames)."



p.7 The following text=
 may need work:

"The remaining congestion signals are the packet loss fraction and the=

   cumulative number of packets lost.  These are robus=
t indicators of
   congestion in a network where packet loss is primarily du=
e to queue
   overflows, although less accurate in networks where losses can be
<= pre class=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;colo= r:rgb(0,0,0)"> caused by non-congestive packet corruption. TCP uses pack= et loss as 
   a congestion signal."<=
/span>

TCP intentionally causes con= gestion to determine available link bandwidth. It is using packet loss to m= easure capacity. In the presence of TCP=A0characterizing=A0loss fraction as= a roust indicator is probably an overstatement. The interaction probably= =A0deserves=A0some some=A0further=A0investigation.

Section 4.1: Delete=A0second paragraph. As=A0disused in= the session=A0today, if things are messed up enough to trigger circuit bre= aker #1, reducing offered load is not likely a useful response. Section 4.3= contains a copy of this recommendation and is probably an appropriate reco= mmendation for circuit breaker #3 described there.

"What it means to cease transmission..." text= appears three times (4.1, 4.2 and 4.3). It probably should just appear onc= e and be reference three times.

Section 4.1: Speci= fy what a "long time" is:

Old: "...but w= ould lead to problematic flows running for a
   long time before being cut off."

New: "...but would lead to problematic f= lows running for at least 15 seconds b= efore being cut off."

Section 4.2: As discussed in= the session today, this section needs to be improved to discuss devices th= at don't implement RTCP. One obvious improvement is to condition the re= ceiver behavior described at the bottom of page 9. A receiver should not tr= ip this circuit breaker if it is receiving RTP packets from the sender.
p.10: The equation has a divide-by-zero hazard. You may want= to explicitly state that the=A0circuit=A0breaker does not trip if the deno= minator is 0.

Section 4.3: Simulation is required = to gain=A0confidence=A0that there are no false-trigger conditions for this = circuit breaker. Test in the presence of competing TCP flows. Test differen= t RTCP RR reporting delay and packet loss scenarios. Solicit more ideas fro= m others.

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



On Tue, Oct 30, 2012 at 11:05 AM, Colin = Perkins <csp@csperkins.org> wrote:
A summary of the changes in this version is as follows:

- Clarify that multicast congestion control is outside the scope of this me= mo.

- Clarify what it means for an implementation to cease transmission when th= e circuit breaker fires. Specifically, the intention is that the applicatio= n will stop sending RTP data packets until the user makes an explicit attem= pt to restart the call. The draft notes that RTP flows halted by the circui= t breaker should not be restarted automatically unless the sender has recei= ved information that the congestion has dissipated.

- Add an explicit RTCP Timeout circuit breaker in Section 4.2 (this is a re= vised and extended version of Section 8 of the -00 draft). Unlike the media= timeout in Section 4.1, which fires when returning RTCP RR packets show th= at media isn't reaching the receiver, this circuit breaker is triggered= if RTCP packets are no longer returning to the sender.

- In section 4.3, clarify when high-rate senders can back-off to a lower ra= te when the circuit breaker is triggered, and when they need to cease trans= mission.

- Expand and clarify Section 5 about RTP circuit breakers for systems using= the RTP/AVPF profile. A sender needs to process early RTCP reports that co= ntain an SR/RR packet as-if they were regular RTCP reports, but ignore earl= y non-compound RTCP packets without an SR/RR. This allows the use of low-ov= erhead early RTP/AVPF feedback without triggering the RTP circuit breaker, = and so is suitable for RTP congestion control algorithms that need to quick= ly report loss events in between regular RTCP reports.

- Expand and clarify Section 6 about the impact of RTCP XR, to note that RT= CP XR packets are ignored by the circuit breaker algorithm.

- Expand and clarify Section 7 about the impact of ECN, to note that report= s of ECN-CE marks are treated as packet loss for the congestion based circu= it breaker, but ignored for the media timeout and RTCP timeout circuit brea= kers.

- Expand and clarify Section 8 on the security considerations to discuss au= thentication requirements.

I believe this draft is on the agenda for the AVTCORE meeting in Atlanta, b= ut feedback via the list is also welcome.

Colin




On 22 Oct 2012, at 23:16, Inter= net-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Congestion Control: Circui= t Breakers for Unicast Sessions
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Colin Perkins
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Varun Singh
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-rtp-circuit-b= reakers-01.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 16
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22
>
> Abstract:
> =A0 The Real-time Transport Protocol (RTP) is widely used in telephony= ,
> =A0 video conferencing, and telepresence applications. =A0Such applica= tions
> =A0 are often run on best-effort UDP/IP networks. =A0If congestion con= trol
> =A0 is not implemented in the applications, then network congestion wi= ll
> =A0 deteriorate the user's multimedia experience. =A0This document= does not
> =A0 propose a congestion control algorithm; rather, it defines a minim= al
> =A0 set of "circuit-breakers". =A0Circuit-breakers are condi= tions under
> =A0 which an RTP flow is expected to stop transmitting media to protec= t
> =A0 the network from excessive congestion. =A0It is expected that all = RTP
> =A0 applications running on best-effort networks will be able to run > =A0 without triggering these circuit breakers in normal operation. =A0= Any
> =A0 future RTP congestion control specification is expected to operate=
> =A0 within the envelope defined by these circuit breakers.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-iet= f-avtcore-rtp-circuit-breakers
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtcore= -rtp-circuit-breakers-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-avtcore-rtp-circuit-breakers-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt



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



_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b621ede0d0ad204cdc68f40-- From kevin.gross@avanw.com Mon Nov 5 14:19:00 2012 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 B9CC721F86A1 for ; Mon, 5 Nov 2012 14:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1yTv5CW7SVf for ; Mon, 5 Nov 2012 14:18:59 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id C4A8D21F86D3 for ; Mon, 5 Nov 2012 14:18:59 -0800 (PST) Received: (qmail 23477 invoked by uid 0); 5 Nov 2012 22:18:23 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 5 Nov 2012 22:18:23 -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=yYj2ypwVYe8Prm4iY6CbyaMfnZR48k+Yx0vWNhFvPWU=; b=Vom+BhpbTCeoHuIxdGpjXtEa+JQRPIy0uMaLFAIcMD4h1geaN+WXrSylTQy+neWoXs6QHrb/N7/fAAY6msVamhUj9srgR4Frsvf4CLGAdfu4ZN0p0MlyRYQtKWJM7rTV; Received: from [74.125.83.44] (port=49690 helo=mail-ee0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TVUzv-0007FP-4N for avt@ietf.org; Mon, 05 Nov 2012 15:18:23 -0700 Received: by mail-ee0-f44.google.com with SMTP id d4so3737644eek.31 for ; Mon, 05 Nov 2012 14:18:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.179.69 with SMTP id g45mr41323320eem.42.1352153901779; Mon, 05 Nov 2012 14:18:21 -0800 (PST) Received: by 10.223.152.201 with HTTP; Mon, 5 Nov 2012 14:18:21 -0800 (PST) In-Reply-To: References: <20121014023052.25416.50131.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 17:18:21 -0500 Message-ID: From: Kevin Gross To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=047d7b62243cff4a5f04cdc6dc43 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.83.44 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org" Subject: Re: [AVTCORE] FW: 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: Mon, 05 Nov 2012 22:19:00 -0000 --047d7b62243cff4a5f04cdc6dc43 Content-Type: text/plain; charset=ISO-8859-1 Since it looks like this will be accepted as a workgroup item, here are a few comments: I'm not clear on how a bis works but I assume this draft needs to be able to stand on it's own as it proposes to obsolete RFC 6222. Some or all references to RFC 6222 probably need to be removed. Particularly confusing are statements in the abstract that seem to indicate that only parts of RFC 6222 are being replaced. Second bullet point in section 4.2 Item (a): I don't understand how a CNAME based on MAC address would be considered short-term. Seems like this would have same or better persistence properties as the UUID in the first bullet point. 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 necessary for the different types of CNAMEs to have different appearance? p.6: Phrase, "(to compromise between packet size and uniqueness)" is scary. Exude more confidence here and/or insert a forward reference to section 6.1. Section 6.1: Please provide a collision probability for a worst-case population. 2^48 is an unreasonable population for this application (and 50% is a scary probability). Is 2^40 a worst-case population. Seems large. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Sat, Oct 13, 2012 at 10:32 PM, Ali C. Begen (abegen) wrote: > We have submitted a draft to replace 6222. This document is a new version > of 6222 and has the fixes proposed by Eric in the last meeting. > > Comments are welcome. > -acbegen > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Saturday, October 13, 2012 10:30 PM > To: "Ali C. Begen" > Cc: "Eric com>" > Subject: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt > > > > >A new version of I-D, draft-rescorla-avtcore-6222bis-00.txt > >has been successfully submitted by Ali Begen and posted to the > >IETF repository. > > > >Filename: draft-rescorla-avtcore-6222bis > >Revision: 00 > >Title: Guidelines for Choosing RTP Control Protocol (RTCP) > Canonical > >Names (CNAMEs) > >Creation date: 2012-10-14 > >WG ID: Individual Submission > >Number of pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-rescorla-avtcore-6222bis-00.txt > >Status: > >http://datatracker.ietf.org/doc/draft-rescorla-avtcore-6222bis > >Htmlized: > >http://tools.ietf.org/html/draft-rescorla-avtcore-6222bis-00 > > > > > >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 specifies a replacement for those parts. > > > > > > > > > > > >The IETF Secretariat > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --047d7b62243cff4a5f04cdc6dc43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since it looks like this will be accepted as a workgroup item, here are a f= ew comments:

I'm not clear on how a bis works but I = assume this draft needs to be able to stand on it's own as it proposes = to obsolete RFC 6222. Some or all references to RFC 6222 probably need to b= e removed. Particularly confusing are statements in the abstract that seem = to indicate that only parts of RFC 6222 are being replaced.

Second bullet point in section 4.2=A0Item (a): I don= 9;t understand how a CNAME based on MAC address would be considered short-t= erm. Seems like this would have same or better persistence properties as th= e UUID in the first bullet point.

Second bullet point in section 4.2=A0Item (b): Proposes= truncating our nice 96-bit random CNAME to 48 bits. I think we have an una= cceptable 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 softwar= e=A0initialization. Is it necessary for the different types of CNAMEs to ha= ve different appearance?

p.6: Phrase, "(to compromise between packet size and uniqueness)&= quot; is scary. Exude more=A0confidence=A0here and/or insert a forward reference to section 6.1.

Section = 6.1: Please provide a=A0collision=A0probability=A0for a worst-case populatio= n. 2^48 is an unreasonable population for this application (and 50% is a sc= ary=A0probability). Is 2^40 a worst-ca= se population. Seems large.

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



On Sat, Oct 13, 2012 at 10:32 PM, Ali C.= Begen (abegen) <abegen@cisco.com> wrote:
We have submitted a draft to replace 6222. This document is a new version of 6222 and has the fixes proposed by Eric in the last meeting.

Comments are welcome.
-acbegen

-----Original Message-----
From: "internet-drafts@iet= f.org" <internet-dr= afts@ietf.org>
Date: Saturday, October 13, 2012 10:30 PM
To: "Ali C. Begen" <abegen= @cisco.com>
Cc: "Eric com>" <ekr@rtfm.c= om>
Subject: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt=

>
>A new version of I-D, draft-rescorla-avtcore-6222bis-00.txt
>has been successfully submitted by Ali Begen and posted to the
>IETF repository.
>
>Filename: =A0 =A0 =A0 draft-rescorla-avtcore-6222bis
>Revision: =A0 =A0 =A0 00
>Title: =A0 =A0 =A0 =A0 =A0Guidelines for Choosing RTP Control Protocol = (RTCP) Canonical
>Names (CNAMEs)
>Creation date: =A02012-10-14
>WG ID: =A0 =A0 =A0 =A0 =A0Individual Submission
>Number of pages: 10
>URL:
>http://www.ietf.org/internet-drafts/draft-= rescorla-avtcore-6222bis-00.txt
>Status:
>http://datatracker.ietf.org/doc/draft-rescorla-avtcor= e-6222bis
>Htmlized:
>http://tools.ietf.org/html/draft-rescorla-avtcore-6222b= is-00
>
>
>Abstract:
> =A0 The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
> =A0 persistent transport-level identifier for an RTP endpoint. =A0Whil= e the
> =A0 Synchronization Source (SSRC) identifier of an RTP endpoint may > =A0 change if a collision is detected or when the RTP application is > =A0 restarted, its RTCP CNAME is meant to stay unchanged, so that RTP<= br> > =A0 endpoints can be uniquely identified and associated with their RTP=
> =A0 media streams.
>
> =A0 For proper functionality, RTCP CNAMEs should be unique within the<= br> > =A0 participants of an RTP session. =A0However, the existing guideline= s for
> =A0 choosing the RTCP CNAME provided in the RTP standard are insuffici= ent
> =A0 to achieve this uniqueness. =A0RFC 6222 was published to update th= ose
> =A0 guidelines to allow endpoints to choose unique RTCP CNAMEs.
> =A0 Unfortunately, later investigations showed that some parts of the = new
> =A0 algorithms were unnecessarily complicated and/or ineffective. =A0T= his
> =A0 document specifies a replacement for those parts.
>
>
>
>
>
>The IETF Secretariat
>

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b62243cff4a5f04cdc6dc43-- From abegen@cisco.com Mon Nov 5 16:02:26 2012 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 A54B411E80A5 for ; Mon, 5 Nov 2012 16:02:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd8ySY5xhJTQ for ; Mon, 5 Nov 2012 16:02:25 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6A21D21F850E for ; Mon, 5 Nov 2012 16:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5194; q=dns/txt; s=iport; t=1352160145; x=1353369745; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mfPjAtTD9Lzlp0winyiW4X80og/ul4VybdFTHFCY6fI=; b=mcTIxfMy6wj0WzlRU5ZfcoFYh5ECOn5qOvZ7cjOpDzyS1WgbzqXt119m aaqm2X6FaeZcmk98lIIBCae48m0YkZY+r7gV+bJ6RbhHhurBsD8mTlnQv Fvb0inHc6Z//46rvtGMZ6Lvh/AKmc31mJ4z6BZj8QEqsrlScK5bp627DX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANtSmFCtJXHB/2dsb2JhbABBA4JswEeBCIIeAQEBAwEBAQEPATYuAgwGAQgHCgMBAgEKSwscAQgCBA4FCAEZh2IGAQqafI9kkDWLfIMrgklhA4gljnKNPYFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139070950" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2012 00:02:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA602H0Z021133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 00:02:17 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.001; Mon, 5 Nov 2012 18:02:17 -0600 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt Thread-Index: AQHNqbPzDESOY6uX60uCchMrTLBMoZe47vUAgCNpJYCAAB0HAA== Date: Tue, 6 Nov 2012 00:02:16 +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.2.4.120824 x-originating-ip: [10.86.253.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--53.793100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] FW: 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: Tue, 06 Nov 2012 00:02:26 -0000 From: Kevin Gross Date: Monday, November 5, 2012 6:18 PM To: "Ali C. Begen" Cc: "avt@ietf.org" Subject: Re: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt > >Since it looks like this will be accepted as a workgroup item, here are a >few comments: > >I'm not clear on how a bis works but I assume this draft needs to be able >to stand on it's own as it proposes to obsolete RFC 6222. Some or all >references to RFC 6222 probably need to be removed. Particularly >confusing are statements in the abstract that > seem to indicate that only parts of RFC 6222 are being replaced. > I think it is ok to refer to 6222 to explain what things caused a concern and are being fixed in this document.Now reading the last sentence in the abstract, yeah, it sounds a bit funny. It should rather say "This document addresses these concerns and replaces RFC 6222." > >Second bullet point in section 4.2 Item (a): I don't understand how a >CNAME based on MAC address would be considered short-term. Seems like >this would have same or better persistence properties as the UUID in the >first bullet point. Well, there could be multiple MACs associated with an endpoint and they could be changed via software, etc. So, I don't think it is as persistent as UUID. > >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 necessary >for the different types of CNAMEs to have different appearance? I don=B9t think there is such a requirement and your suggestion makes sense= . BTW, there is a sentence that needs to be deleted here (artifact from 6222): "hence, only the initial SSRC value chosen by the endpoint is used" > >p.6: Phrase, "(to compromise between packet size and uniqueness)" is >scary. Exude more confidence here and/or insert a forward reference to >section 6.1. OK. > >Section 6.1: Please provide a collision probability for a worst-case >population. 2^48 is an unreasonable population for this application > (and 50% is a scary probability). Is 2^40 a worst-case population. Seems >large. Eric, do you have any numbers here? -acbegen > >Kevin Gross >+1-303-447-0517 >Media Network Consultant >AVA Networks - www.AVAnw.com , www.X192.org > > > > > >On Sat, Oct 13, 2012 at 10:32 PM, Ali C. Begen (abegen) > wrote: > >We have submitted a draft to replace 6222. This document is a new version >of 6222 and has the fixes proposed by Eric in the last meeting. > >Comments are welcome. >-acbegen > >-----Original Message----- >From: "internet-drafts@ietf.org" >Date: Saturday, October 13, 2012 10:30 PM >To: "Ali C. Begen" >Cc: "Eric com>" >Subject: New Version Notification for >draft-rescorla-avtcore-6222bis-00.txt > >> >>A new version of I-D, draft-rescorla-avtcore-6222bis-00.txt >>has been successfully submitted by Ali Begen and posted to the >>IETF repository. >> >>Filename: draft-rescorla-avtcore-6222bis >>Revision: 00 >>Title: Guidelines for Choosing RTP Control Protocol (RTCP) >>Canonical >>Names (CNAMEs) >>Creation date: 2012-10-14 >>WG ID: Individual Submission >>Number of pages: 10 >>URL: >>http://www.ietf.org/internet-drafts/draft-rescorla-avtcore-6222bis-00.txt >>Status: >>http://datatracker.ietf.org/doc/draft-rescorla-avtcore-6222bis >>Htmlized: >>http://tools.ietf.org/html/draft-rescorla-avtcore-6222bis-00 >> >> >>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 specifies a replacement for those parts. >> >> >> >> >> >>The IETF Secretariat >> > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt > > > > > > > From Hua.Chao@alcatel-sbell.com.cn Wed Nov 7 01:08:53 2012 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 CDF3C21F855E for ; Wed, 7 Nov 2012 01:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqKZNxyA6naV for ; Wed, 7 Nov 2012 01:08:53 -0800 (PST) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id ACF1D21F858E for ; Wed, 7 Nov 2012 01:08:52 -0800 (PST) X-AuditID: ac189297-b7fc36d0000051ff-7f-509a23289099 Received: from CNSHJCASHUB04.ad4.ad.alcatel.com (Unknown_Domain [135.251.50.74]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Messaging Gateway) with SMTP id D4.D4.20991.8232A905; Wed, 7 Nov 2012 17:00:24 +0800 (HKT) Received: from CNSHJMBX01.ad4.ad.alcatel.com ([135.251.50.101]) by CNSHJCASHUB04.ad4.ad.alcatel.com ([135.251.50.74]) with mapi id 14.02.0283.003; Wed, 7 Nov 2012 17:08:43 +0800 From: CHAO Hua To: "avt@ietf.org" Thread-Topic: [AVTCORE] FW: New Version Notification for draft-hua-avt-rtp-svcmvc-00.txt Thread-Index: AQHNuv0H8gMaxXZ6hEi82FeuaBXKxJfahDwwgAM02IA= Date: Wed, 7 Nov 2012 09:08:42 +0000 Message-ID: <07D9E2574A252B44ACD1718FC7E9BC9B01224447@cnshjmbx01> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.149.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsXS/ltRSldDeVaAwZz3phYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/2SdtaCJ2IVu1fMYWtgnCHWxcjJISFgIrHs13p2CFtM4sK9 9WwgtpDAHUaJZ7vsuhi5gOytjBJd8z8wgSTYBPQkXj9YxAxiiwgoSrRe+8wIYgsLhEoce/AT qIYDKB4l8XQLP0SJlcTrNffBylkEVCQ2TF3KCmLzCjhKdG+7DNbKKCArMe3RfbDxzALiEree zGeCuEdAYsme88wQtqjEy8f/WCFsRYmPF5ewgqxiFtCUWL9LH6JVUWJK90N2iPGCEidnPmGB KJeUOLjiBssERpFZSDbMQuiehaR7FpLuBYwsqxgVkvOKM7KKczPzDAz1EnOSE0tSc3SLk1Jz cvSS83P1kvM2MQJjYY3EpOk7GHfttzzEKMDBqMTDqxk+M0CINbGsuDL3EKMEB7OSCC8D76wA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryZm4sDhATSgWZnp6YWpBbBZJk4OKUaGEXtrudLaDSH vujJXrU0iO3mg/vRrWJ9V2bICbM8W/G0UkPinKxGqu1K353GkzaXiNYGPG94ZmCsEZHz6WLT 5cvMzg1lmy8LtLj39zC48Nw78iPQ3OAC1x6TDI2dW98x27IkbrHu7Qz/ty+0R+2xZFOu1eTF Z46/X7g/lqP22sNblyf5/O3+p8RSnJFoqMVcVJwIAJW4sMWBAgAA Subject: [AVTCORE] FW: New Version Notification for draft-hua-avt-rtp-svcmvc-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: Wed, 07 Nov 2012 09:08:53 -0000 SGkgYWxsLA0KDQpJdCBzZWVtcyB0aGF0IG15IGVtYWlsIGRvZXMgbm90IHBvc3QgdG8gdGhlIG1h aWxpbmcgbGlzdC4gSSByZS1zZW5kIGl0Lg0KDQpCZXN0IFJlZ2FyZHMNCkh1YQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ0hBTyBIdWEgDQpTZW50OiAyMDEy5bm0MTHmnIg1 5pelIDEwOjUwDQpUbzogYXZ0QGlldGYub3JnDQpDYzogSFUgWmhvbmdqaQ0KU3ViamVjdDogRlc6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHVhLWF2dC1ydHAtc3ZjbXZjLTAw LnR4dA0KDQpEZWFyIGFsbCwgDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgb25lIG5ldyBJLUQgdG8gZGlz Y3VzcyB0aGUgcmVsaWFibGUgRUNOIHByb2JsZW0gZm9yIFNWQyBhbmQgTVZDIHdpdGggUlRQIG92 ZXIgVURQLiANClVSTDogaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aHVhLWF2dC1ydHAtc3ZjbXZjLTAwLnR4dCAgDQoNCllvdXIgY29tbWVudHMgYXJlIHdlbGNvbWUu DQoNCkJlc3QgUmVnYXJkcw0KSHVhIENIQU8NCkFsY2F0ZWwtTHVjZW50IFNoYW5naGFpIEJlbGwg Q28uIEx0ZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IDIw MTLlubQxMeaciDXml6UgMTA6MjcNClRvOiBDSEFPIEh1YQ0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMtMDAudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1YS1hdnQtcnRwLXN2Y212Yy0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSHVhIENoYW8gYW5kIHBvc3RlZCB0byB0aGUN CklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMN ClJldmlzaW9uOgkgMDANClRpdGxlOgkJIEV4dGVuc2lvbiBvZiBSVFAgZm9yIFNWQyBhbmQgTVZD IHdpdGggdXNhZ2Ugb2YgRUNODQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMS0wNQ0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVhLWF2dC1ydHAt c3ZjbXZjLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWh1YS1hdnQtcnRwLXN2Y212Yw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWEtYXZ0LXJ0cC1zdmNtdmMtMDANCg0KDQpBYnN0 cmFjdDoNCiAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgaG93IHRvIHN1cHBvcnQgUlRQIHBhY2tldCBz dHJlYW0gdGhpbm5pbmcgKG9yDQogICByYXRlIGFkYXB0YXRpb24pIGFuZCBFeHBsaWNpdCBDb25n ZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB3aXRoIHRoZQ0KICAgUmVhbC10aW1lIFRyYW5zcG9y dCBQcm90b2NvbCAoUlRQKSBydW5uaW5nIG92ZXIgVURQIHRvIG1ha2UgZWZmZWN0IGluDQogICBw YXJhbGxlbCB3aXRoIHJlbGlhYmxlIFJUQ1AgcmVwb3J0IHRvIHRoZSBSVFAgc2VuZGVyLiAgSXQg aW50cm9kdWNlcw0KICAgImR1bW15IFJUUCBwYWNrZXRzIiBpbnRvIHRoZSBzaW5nbGUtc2Vzc2lv biB0cmFuc21pc3Npb24gKFNTVCkgbW9kZQ0KICAgZm9yIFNjYWxhYmxlIFZpZGVvIENvZGluZyAo U1ZDKSBhbmQgTXVsdGl2aWV3IFZpZGVvIENvZGluZyAoTVZDKS4NCiAgIFRoZSByZWFjdGlvbnMg b2YgUlRQIHJlY2VpdmVycyB1cG9uIHJlY2VpdmluZyB0aGUgImR1bW15IFJUUCBwYWNrZXRzIg0K ICAgYXJlIGRlZmluZWQuICBUaGUgZG9jdW1lbnQgYWxzbyByZWNvbW1lbmQgdG8gZXh0ZW5kIHRo ZSBFQ04NCiAgIGZ1bmN0aW9uYWxpdGllcyBiYXNlZCBvbiB0aGUgc2NhbGFiaWxpdHkgZmVhdHVy ZSBvZiBTVkMgYW5kIE1WQy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From thomas.belling@nsn.com Thu Nov 8 09:26:44 2012 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 BDC0121F8438 for ; Thu, 8 Nov 2012 09:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4xqwLgvkpge for ; Thu, 8 Nov 2012 09:26:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED121F8436 for ; Thu, 8 Nov 2012 09:26:40 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qA8HQaXN022880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Nov 2012 18:26:36 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qA8HQXgw000344; Thu, 8 Nov 2012 18:26:35 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 18:26:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDBDD6.20AF7C01" Date: Thu, 8 Nov 2012 18:26:02 +0100 Message-ID: <1A8A7D59006A8240B27FF63C794CA57F01F76068@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Do RFC 4585 and RFC 5104 mandate the usage of the a=rtcp-fb SDP attribute? Thread-Index: Ac291gX62RmVSga9TAK73+IBAJ/pLg== From: "Belling, Thomas (NSN - DE/Munich)" To: X-OriginalArrivalTime: 08 Nov 2012 17:26:03.0744 (UTC) FILETIME=[20F8CE00:01CDBDD6] 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: 25595 X-purgate-ID: 151667::1352395597-00003C61-6639495D/0-0/0-0 Cc: "Nikolai Leung \(@qti.qualcomm.com\)" , "Jari Mutikainen \(@nokia.com\)" , "Kyunghun Jung \(@samsung.com\)" , =?iso-8859-1?Q?Kari_J=E4rvinen_=28=40nokia=2Ecom=29?= Subject: [AVTCORE] Do RFC 4585 and RFC 5104 mandate the usage of the a=rtcp-fb SDP attribute? 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, 08 Nov 2012 17:26:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDBDD6.20AF7C01 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear RTP/AVPF experts, Triggered by some recent discussion in 3GPP SA4, I would welcome your = opinion on the following question: Do RFC 4585 and RFC 5104 allow sending the RTCP feedback messages = defined in those RFCs, if AVPF has been negotiated using SDP = offer-answer, but no a=3Drtcp-fb SDP attribute was included in the SDP = negotiation? A more detailed discussion is below: >From RFC 4585: 4.2. RTCP Feedback Capability Attribute ... The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB messages MAY be used in this media session for the indicated payload = type. ... If no "rtcp-fb" attribute is specified, the RTP receivers MAY send feedback using other suitable RTCP feedback packets as defined for the respective media type. The RTP receivers MUST NOT rely on the RTP senders reacting to any of the FB messages. The RTP sender MAY choose to ignore some feedback messages. If one or more "rtcp-fb" attributes are present in a media session description, the RTCP receivers for the media session(s) containing the "rtcp-fb" o MUST ignore all "rtcp-fb" attributes of which they do not fully understand the semantics (i.e., where they do not understand the meaning of all values in the "a=3Drtcp-fb" line); o SHOULD provide feedback information as specified in this document using any of the RTCP feedback packets as specified in one of the "rtcp-fb" attributes for this media session; and o MUST NOT use other FB messages than those listed in one of the "rtcp-fb" attribute lines. When used in conjunction with the offer/answer model [8], the offerer MAY present a set of these AVPF attributes to its peer. The answerer MUST remove all attributes it does not understand as well as those it does not support in general or does not wish to use in this particular media session. The answerer MUST NOT add feedback parameters to the media description and MUST NOT alter values of such parameters. The answer is binding for the media session, and both offerer and answerer MUST only use feedback mechanisms negotiated in this way. Both offerer and answerer MAY independently decide to send RTCP FB messages of only a subset of the negotiated feedback mechanisms, but they SHOULD react properly to all types of the negotiated FB messages when received. >From RFC 5104 7.2. Offer-Answer The Offer/Answer [RFC3264] implications for codec control protocol feedback messages are similar to those described in [RFC4585]. The offerer MAY indicate the capability to support selected codec commands and indications. The answerer MUST remove all CCM parameters corresponding to the CCMs that it does not wish to support in this particular media session (for example, because it does not implement the message in question, or because its application logic suggests that support of the message adds no value). The answerer MUST NOT add new ccm parameters in addition to what has been offered. The answer is binding for the media session and both offerer and answerer MUST NOT use any feedback messages other than what both sides have explicitly indicated as being supported. In other words, only the joint subset of CCM parameters from the offer and answer may be used. Note that including a CCM parameter in an offer or answer indicates that the party (offerer or answerer) is at least capable of receiving the corresponding CCM(s) and act upon them. In cases when the reception of a negotiated CCM mandates the party to respond with another CCM, it must also have that capability. Although it is not mandated to initiate CCMs of any negotiated type, it is generally expected that a party will initiate CCMs when appropriate. The session maximum packet rate parameter part of the TMMBR indication is declarative, and the highest value from offer and answer SHALL be used. If the session maximum packet rate parameter is not present in an offer, it SHALL NOT be included by the answerer. A suggested Interpretation for RFC 4585 in 3GPP SA4 was : The SDP offer may or may not include one or more a=3Drtcp-fb attributes = for negotiating various AVPF feedback messages. (this is of course = assuming that AVPF is negotiated on the m=3D line). IF attribute lines with a=3Drtcp-fb are NOT included THEN Both end-points may send any AVPF FB messages (if AVPF is agreed) It is not guaranteed that any AVPF FB messages will work (in = either direction) IF attribute lines with a=3Drtcp-fb are included for some or all of the = AVPF FB messages THEN The answerer must remove the attribute lines for the AVPF FB = messages it does not want to use Only those AVPF FB messages that are in the SDP answer are allowed = to be used, i.e. it is forbidden to send the AVPF FB messages that are = not in the SDP answer Is that correct? Does the same interpretation apply for RFC 5104? Based on: "The answer is binding for the media session and both offerer = and answerer MUST NOT use any feedback messages other than what both = sides have explicitly indicated as being supported. " , the following = alternative interpretation has been suggested: * Every CCM FB message that one intend to use must be negotiated in = SDP offer-answer. * Any CCM FB message that has not been negotiated (and therefore is = not agreed) in SDP offer-answer cannot be used in the session. Many thanks for your help, Thomas ----------------------------------=20 Dr. Thomas Belling=20 3GPP Standardisation Nokia Siemens Networks=20 ------_=_NextPart_001_01CDBDD6.20AF7C01 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do RFC 4585 and RFC 5104 mandate the usage of the a=3Drtcp-fb SDP = attribute?

Dear RTP/AVPF = experts,

Triggered by some recent = discussion in 3GPP SA4, I would welcome your opinion on the following = question:


Do RFC 4585 and = RFC 5104 allow sending the RTCP feedback messages defined in those RFCs, if = AVPF has been negotiated using SDP offer-answer, but no  a=3Drtcp-fb SDP = attribute = was included in the SDP = negotiation?



A more detailed = discussion is below:

From RFC = 4585:

4.2.  RTCP Feedback Capability = Attribute

…

   The "rtcp-fb" = attribute SHOULD be used to indicate which RTCP FB

   messages MAY be used in this media session for the = indicated payload  type.

…

   If no = "rtcp-fb" attribute is specified, the RTP receivers MAY = send

   feedback using other suitable RTCP feedback packets as = defined for

   the respective media type.  The RTP receivers = MUST NOT rely on the

   RTP senders reacting to any of the FB messages.  = The RTP sender MAY

   choose to ignore some feedback = messages.

   If one or more = "rtcp-fb" attributes are present in a media = session

   description, the RTCP receivers for the media = session(s) containing

   the "rtcp-fb"

   o  MUST ignore all "rtcp-fb" attributes = of which they do not fully

      understand the semantics (i.e., = where they do not understand the

      meaning of all values in the = "a=3Drtcp-fb" line);

   o  SHOULD provide feedback information as = specified in this document

      using any of the RTCP feedback = packets as specified in one of the

      "rtcp-fb" attributes for = this media session; and

   o  MUST NOT use other FB messages than those = listed in one of the

      "rtcp-fb" attribute = lines.

   When used in conjunction with the offer/answer model = [8], the offerer

   MAY present a set of these AVPF attributes to its = peer.  The answerer

   MUST remove all attributes it does not understand as = well as those it

   does not support in general or does not wish to use in = this

   particular media session.  The answerer MUST NOT = add feedback

   parameters to the media description and MUST NOT alter = values of such

   parameters.  The answer is binding for the media = session, and both

   offerer and answerer MUST only use feedback mechanisms = negotiated in

   this way.  Both offerer and answerer MAY = independently decide to send

   RTCP FB messages of only a subset of the negotiated = feedback

   mechanisms, but they SHOULD react properly to all = types of the

   negotiated FB messages when = received.

From RFC 5104

7.2.  = Offer-Answer

   The Offer/Answer [RFC3264] implications for codec = control protocol

   feedback messages are similar to those described in = [RFC4585].  The

   offerer MAY indicate the capability to support = selected codec

   commands and indications.  The answerer MUST = remove all CCM

   parameters corresponding to the CCMs that it does not = wish to support

   in this particular media session (for example, because = it does not

   implement the message in question, or because its = application logic

   suggests that support of the message adds no = value).  The answerer

   MUST NOT add new ccm parameters in addition to what = has been offered.

   The answer is binding for the media session and both = offerer and

   answerer MUST NOT use any feedback messages other than = what both

   sides have explicitly indicated as being = supported.  In other words,

   only the joint subset of CCM parameters from the offer = and answer may

   be used.

   Note that including a CCM = parameter in an offer or answer indicates

   that the party (offerer or answerer) is at least = capable of receiving

   the corresponding CCM(s) and act upon them.  In = cases when the

   reception of a negotiated CCM mandates the party to = respond with

   another CCM, it must also have that capability.  = Although it is not

   mandated to initiate CCMs of any negotiated type, it = is generally

   expected that a party will initiate CCMs when = appropriate.

   The session maximum packet rate parameter part of the = TMMBR

   indication is declarative, and the highest value from = offer and

   answer SHALL be used.  If the session maximum = packet rate parameter

   is not present in an offer, it SHALL NOT be included = by the answerer.

A = suggested = Interpretation = for RFC = 4585 = in 3GPP SA4 was :

The SDP offer = may or may not include one or more a=3Drtcp-fb attributes for = negotiating various AVPF feedback messages. (this is of course assuming = that AVPF is negotiated on the m=3D line).

IF attribute = lines with a=3Drtcp-fb are NOT included THEN

  =     Both end-points may send any = AVPF FB messages (if AVPF is agreed)

      It is not guaranteed = that any AVPF FB messages will work (in either = direction)

IF attribute = lines with a=3Drtcp-fb are included for some or all of the AVPF FB = messages THEN

      The answerer must remove = the attribute lines for the AVPF FB messages it does not want to = use

      Only those AVPF FB = messages that are in the SDP answer are allowed to be used, i.e. it is = forbidden to send the AVPF FB messages that are not in the SDP answer

Is that = correct?


Does the same = interpretation apply for RFC 5104?

Based = on:  “The answer is = binding for the media session and both offerer and answerer MUST NOT use any = feedback messages other than what both  sides have explicitly indicated as being = supported. “ , the following alternative interpretation has been = suggested:

*     Every CCM FB message that one intend to use must be = negotiated in SDP = offer-answer.

*     Any CCM FB message that has not been negotiated (and = therefore is not agreed) in SDP offer-answer cannot be used in the = session.


Many thanks for = your help,

Thomas

----------------------------------
Dr. Thomas = Belling

3GPP Standardisation
Nokia Siemens Networks=A0

------_=_NextPart_001_01CDBDD6.20AF7C01-- From magnus.westerlund@ericsson.com Thu Nov 8 11:12:04 2012 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 9022F21F8479 for ; Thu, 8 Nov 2012 11:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gywG+YkeXejA for ; Thu, 8 Nov 2012 11:12:03 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DAD6121F847C for ; Thu, 8 Nov 2012 11:12:02 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-6e-509c04016a04 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.30.11564.1040C905; Thu, 8 Nov 2012 20:12:01 +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; Thu, 8 Nov 2012 20:12:00 +0100 Message-ID: <509C03FD.4030709@ericsson.com> Date: Thu, 8 Nov 2012 14:11:57 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <1A8A7D59006A8240B27FF63C794CA57F01F76068@DEMUEXC014.nsn-intra.net> In-Reply-To: <1A8A7D59006A8240B27FF63C794CA57F01F76068@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvjS4jy5wAg82TDCxe9qxkt3i17Tuz xcGmG0wWK9qms1mcPWBk0bZrH6MDm8eSJT+ZPO7eusTk8XP9VXaPRVOfMXr0bVnFGMAaxWWT kpqTWZZapG+XwJXR9fINa8FUu4rZk1YyNzBO0+9i5OSQEDCR2N97jg3CFpO4cG89mC0kcJJR orMtBMJexiixuNUSxOYV0JZ4+XsFWA2LgIrE+59PwGw2AQuJmz8awWxRgWCJPcfWMkLUC0qc nPmEBcQWEXCQ2L74E1Cci4NZYD2TxK/JLWBFwgLJEo1bWpgglvlLnHnRChbnFAiQmPNuLzvE cZISb9+/YgaxmQUMJI4smsMKYctLNG+dzQzRqy3R0NTBOoFRaBaS3bOQtMxC0rKAkXkVI3tu YmZOernhJkZguB/c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi 4JRqYLQtDUir/t4p6znluba5wMxMFskuh4tq/or2sa9LGva9kYl8dPfcxOWslTt/sj/JmC98 8X7fFz6GU5uOs9jc00nk1E7jCDuWxLq4JJDjc4TaASdjP5ut206teveh5s3R20+/Z/sJLY99 KLhIw5dp3uIDig5T/LM+W5/K9b36LvWA/7VtBWf/8CmxFGckGmoxFxUnAgDNjEWzRQIAAA== Cc: =?windows-1252?Q?=22Kari_J=E4rvinen_=28=40nokia=2Ecom=29=22?= , "Jari Mutikainen \(@nokia.com\)" , "Kyunghun Jung \(@samsung.com\)" , avt@ietf.org, "Nikolai Leung \(@qti.qualcomm.com\)" Subject: Re: [AVTCORE] Do RFC 4585 and RFC 5104 mandate the usage of the a=rtcp-fb SDP attribute? 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, 08 Nov 2012 19:12:04 -0000 Hi Thomas, > > > Do RFC 4585 and RFC 5104allowsendingtheRTCP feedback messages defined in > those RFCs, if AVPF has beennegotiatedusing SDP offer-answer, but > no a=rtcp-fb SDP attributewas includedin the SDP negotiation? > Yes, I think it is allowed based on Section 4.2 of RFC 4585: The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB messages MAY be used in this media session for the indicated payload type. The above SHOULD allows for exception to explicitly indicate the FB messages that is to be used. However, I would remember that this SHOULD is an IETF SHOULD. See RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. So, if one is not going to do this one better have a good reason for not using a=rtcp-fb attribute to indicate which feedback messages that are supported. I would guess that the intention for the SHOULD is to allow cases where SDP is used, but it is not really possible for the entity providing the SDP to indicate the actual set of feedback messages that are supported on the end-point(s). >From my perspective, I would use the signaling if it is available. It makes it explicit which of the messages types that are supported by the end-points. Cheers Magnus > > > A more detailed discussion is below: > > From RFC 4585: > > 4.2. RTCP Feedback Capability Attribute > > … > > The "rtcp-fb" attribute SHOULD be used to indicate which RTCP FB > > messages MAY be used in this media session for the indicated > payload type. > > … > > If no "rtcp-fb" attribute is specified, the RTP receivers MAY send > > feedback using other suitable RTCP feedback packets as defined for > > the respective media type. The RTP receivers MUST NOT rely on the > > RTP senders reacting to any of the FB messages. The RTP sender MAY > > choose to ignore some feedback messages. > > If one or more "rtcp-fb" attributes are present in a media session > > description, the RTCP receivers for the media session(s) containing > > the "rtcp-fb" > > o MUST ignore all "rtcp-fb" attributes of which they do not fully > > understand the semantics (i.e., where they do not understand the > > meaning of all values in the "a=rtcp-fb" line); > > o SHOULD provide feedback information as specified in this document > > using any of the RTCP feedback packets as specified in one of the > > "rtcp-fb" attributes for this media session; and > > o MUST NOT use other FB messages than those listed in one of the > > "rtcp-fb" attribute lines. > > When used in conjunction with the offer/answer model [8], the offerer > > MAY present a set of these AVPF attributes to its peer. The answerer > > MUST remove all attributes it does not understand as well as those it > > does not support in general or does not wish to use in this > > particular media session. The answerer MUST NOT add feedback > > parameters to the media description and MUST NOT alter values of such > > parameters. The answer is binding for the media session, and both > > offerer and answerer MUST only use feedback mechanisms negotiated in > > this way. Both offerer and answerer MAY independently decide to send > > RTCP FB messages of only a subset of the negotiated feedback > > mechanisms, but they SHOULD react properly to all types of the > > negotiated FB messages when received. > > FromRFC 5104 > > 7.2. Offer-Answer > > The Offer/Answer [RFC3264] implications for codec control protocol > > feedback messages are similar to those described in [RFC4585]. The > > offerer MAY indicate the capability to support selected codec > > commands and indications. The answerer MUST remove all CCM > > parameters corresponding to the CCMs that it does not wish to support > > in this particular media session (for example, because it does not > > implement the message in question, or because its application logic > > suggests that support of the message adds no value). The answerer > > MUST NOT add new ccm parameters in addition to what has been offered. > > The answer is binding for the media session and both offerer and > > answerer MUST NOT use any feedback messages other than what both > > sides have explicitly indicated as being supported. In other words, > > only the joint subset of CCM parameters from the offer and answer may > > be used. > > Note that including a CCM parameter in an offer or answer indicates > > that the party (offerer or answerer) is at least capable of receiving > > the corresponding CCM(s) and act upon them. In cases when the > > reception of a negotiated CCM mandates the party to respond with > > another CCM, it must also have that capability. Although it is not > > mandated to initiate CCMs of any negotiated type, it is generally > > expected that a party will initiate CCMs when appropriate. > > The session maximum packet rate parameter part of the TMMBR > > indication is declarative, and the highest value from offer and > > answer SHALL be used. If the session maximum packet rate parameter > > is not present in an offer, it SHALL NOT be included by the answerer. > > A suggestedInterpretationforRFC 4585in3GPPSA4was : > > The SDP offer may or may not include one or more a=rtcp-fb attributes > for negotiating various AVPF feedback messages. (this is of course > assuming that AVPF is negotiated on the m= line). > > IF attribute lines with a=rtcp-fb are NOT included THEN > > Both end-points may send any AVPF FB messages (if AVPF is agreed) > > It is not guaranteed that any AVPF FB messages will work (in > either direction) > > IF attribute lines with a=rtcp-fb are included for some or all of the > AVPF FB messages THEN > > The answerer must remove the attribute lines for the AVPF FB > messages it does not want to use > > Only those AVPF FB messages that are in the SDP answer are allowed > to be used, i.e. it is forbidden to send the AVPF FB messages that are > not in the SDP answer > > Is that correct? > > > Does the same interpretation apply for RFC 5104? > > Based on: “The answer is binding for the media session and both offerer > andanswerer MUST NOT use any feedback messages other than what both > sides have explicitly indicated as being supported. “, the following > alternative interpretation has been suggested: > > * Every CCM FB message that one intend to use must be negotiated in > SDP offer-answer. > > * Any CCM FB message that has not been negotiated (and therefore is > not agreed) in SDP offer-answer cannot be used in the session. > > > Many thanks for your help, > > Thomas > > ---------------------------------- > Dr. Thomas Belling > > 3GPP Standardisation > Nokia Siemens Networks > > > > _______________________________________________ > 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 Thu Nov 8 13:40:24 2012 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 CA21D21F86D4 for ; Thu, 8 Nov 2012 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.184 X-Spam-Level: X-Spam-Status: No, score=-106.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bAWmGzsVqPN for ; Thu, 8 Nov 2012 13:40:24 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4E21F86AD for ; Thu, 8 Nov 2012 13:40:23 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-35-509c26c6a810 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3D.E3.26143.6C62C905; Thu, 8 Nov 2012 22:40:22 +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; Thu, 8 Nov 2012 22:40:21 +0100 Message-ID: <509C26C2.30505@ericsson.com> Date: Thu, 8 Nov 2012 16:40:18 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-leap-second@tools.ietf.org X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+Jvje4xtTkBBreXiFm87FnJbrHz/342 ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStjyRmLgtlSFTdmPmdqYHwj0sXIySEhYCJx +/JBNghbTOLCvfVgtpDASUaJ7/sKuhi5gOxljBL3L65iAUnwCmhKTFi6mBnEZhFQkVi8eA5Y nE3AQuLmj0awZlGBYIk9x9YyQtQLSpyc+QSsRkQgRGJTwyx2EFtYwExiXd9KJojFkhJv378C m8ksoCcx5WoLI4QtL9G8dTYzxEHaEg1NHawTGPlnIRk7C0nLLCQtCxiZVzGy5yZm5qSXG21i BAbYwS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Mu/6J au5sPPBSVaz381LZTYsffmme67VGuJElVuD+4b8Wq77MijLrenObre3uX464MNcun8+ZyuyN 85xqZRS5VWaJXzxu2Km0Q/7tu2nFYhrsspUcoVEaXEJf5Gd+ELjyMFsw8I/bgf8J8zIqGZoC lXuf7EqzWPMgbVHUvmUi4kc/eHF2mOQrsRRnJBpqMRcVJwIAnbBE0f4BAAA= Subject: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-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, 08 Nov 2012 21:40:24 -0000 Hi, I have reviewed the leap second document and have the following comments. 1. Section 1. It needs to say also in the introduction that it updates RFC 3550, not only in the abstract. 2. Section 3.4: +-------+--------------+--------------+--------------+--------------+ | RTP | TAI | UTC | POSIX | NTP | +-------+--------------+--------------+--------------+--------------+ | 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 | | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 | | 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 | | 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 | | 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 | | 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 | | 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 | +-------+--------------+--------------+--------------+--------------+ Table 1 I am wondering if the RTP 20000 and 24000 is really correctly representing what you write in section 3.2 for the NTP column. Should't the 00:00:00.000 actually 00:00:00.000-, i.e. something that is prior to 00:00:00.000 but just? 3. Section 4.1: RTP Senders working to a leap-second-bearing reference SHOULD NOT generate sender reports containing an originating NTP timestamp in the vicinity of a leap second. Receivers SHOULD ignore timestamps in any such reports inadvertently generated. I wonder how you in practice are going to fulfill the sender recommendation. That only works if your regular reporting interval is on the order of a second or longer. Otherwise not sending a SR packet for a RTP packet sender within 1.5*Td (where Td is your deterministic reporting interval) will be counted towards source time-out or other methods detecting missing packets. So for a reporting interval of 100 or 200 ms you can't actually follow the SHOULD. 4. Section 5. Security Consideration. I wonder if this section really are covering some potential issues. First are there security replay mechanisms that uses the clock? SRTP is not effected as it uses packet index, i.e. roll over counter + seq_nr. But there might be other things that could be confused for example by the posix clock. Are there attack vectors that are created when by possibly fool an end-host to believe a leap-second event is happening and thus thinks the clock are freezing or repeating that otherwise would be possible? 5. Reference section: I don't believe that all references are normative. I think for example the note in section 3.0 uses [3] in an informative one. Additional ones may be similar. Please check the usage of all the references if they really are normative. 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 kevin.gross@avanw.com Thu Nov 8 14:06:18 2012 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 EC19F21F8836 for ; Thu, 8 Nov 2012 14:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5tabqrxZC1w for ; Thu, 8 Nov 2012 14:06:17 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 90E9B21F87F2 for ; Thu, 8 Nov 2012 14:06:16 -0800 (PST) Received: (qmail 31521 invoked by uid 0); 8 Nov 2012 22:05:54 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 8 Nov 2012 22:05:53 -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=mM4C9e8v858zmRTaLZTQDtXn/waKuReZnhkVInv/dt0=; b=TRxNHvwKBKSK1DujaFWlol0NIXqMINe/HmAO9KMoiNSK2J4u9Z2Vme+xAIa8Rz6Jl9rUxS09uW8vhkePh113rEnV1GSXogG45uTRYXeEu9E4pjvkgpzHqFzAIjfZmKeG; Received: from [74.125.83.44] (port=57589 helo=mail-ee0-f44.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TWaET-0005eR-Fn for avt@ietf.org; Thu, 08 Nov 2012 15:05:53 -0700 Received: by mail-ee0-f44.google.com with SMTP id d4so2088092eek.31 for ; Thu, 08 Nov 2012 14:05:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.209.136 with SMTP id s8mr30951773eeo.33.1352412352021; Thu, 08 Nov 2012 14:05:52 -0800 (PST) Received: by 10.223.152.201 with HTTP; Thu, 8 Nov 2012 14:05:51 -0800 (PST) In-Reply-To: <509C26C2.30505@ericsson.com> References: <509C26C2.30505@ericsson.com> Date: Thu, 8 Nov 2012 17:05:51 -0500 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=047d7b603a8ad5063b04ce030992 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.83.44 authed with kevin.gross@avanw.com} Cc: IETF AVTCore WG , draft-ietf-avtcore-leap-second@tools.ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-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, 08 Nov 2012 22:06:18 -0000 --047d7b603a8ad5063b04ce030992 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the review. Responses below. On Thu, Nov 8, 2012 at 4:40 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have reviewed the leap second document and have the following comments. > > 1. Section 1. It needs to say also in the introduction that it updates > RFC 3550, not only in the abstract. > Ok. > > 2. Section 3.4: > +-------+--------------+--------------+--------------+--------------+ > | RTP | TAI | UTC | POSIX | NTP | > +-------+--------------+--------------+--------------+--------------+ > | 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 | > | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 | > | 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 | > | 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 | > | 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 | > | 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 | > | 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 | > +-------+--------------+--------------+--------------+--------------+ > > Table 1 > > I am wondering if the RTP 20000 and 24000 is really correctly > representing what you write in section 3.2 for the NTP column. Should't > the 00:00:00.000 actually 00:00:00.000-, i.e. something that is prior > to 00:00:00.000 but just? > A common system behavior is that when the NTP clock is frozen, successive calls to retrieve system return incrementally larger time values. This keeps applications from faulting from assumptions about time being continuous and monotonic. This behavior occurs in the LS bits of the time value and so is not generally visible in the human-readable format shown in the table. I can add a discussion of this if you think it is useful. > > 3. Section 4.1: > > RTP Senders working to a leap-second-bearing reference SHOULD NOT > generate sender reports containing an originating NTP timestamp in > the vicinity of a leap second. Receivers SHOULD ignore timestamps in > any such reports inadvertently generated. > > I wonder how you in practice are going to fulfill the sender > recommendation. That only works if your regular reporting interval is on > the order of a second or longer. Otherwise not sending a SR packet for a > RTP packet sender within 1.5*Td (where Td is your deterministic > reporting interval) will be counted towards source time-out or other > methods detecting missing packets. So for a reporting interval of 100 or > 200 ms you can't actually follow the SHOULD. > That's a good point. If we need to keep sending SRs during the 2second leap second interval to avoid timeouts, they can be sent with a 0 NTP timestamp. This might be a better approach for all RTCP rates. I have to research what special receiver behavior may be required to accommodate this. > > 4. Section 5. Security Consideration. > > I wonder if this section really are covering some potential issues. > First are there security replay mechanisms that uses the clock? SRTP is > not effected as it uses packet index, i.e. roll over counter + seq_nr. > But there might be other things that could be confused for example by > the posix clock. > > Are there attack vectors that are created when by possibly fool an > end-host to believe a leap-second event is happening and thus thinks the > clock are freezing or repeating that otherwise would be possible? > Today I volunteered to review draft-ietf-tictoc-security-requirements. I will take this and your comments into consideration and try to improve the security considerations section. > > > 5. Reference section: > > I don't believe that all references are normative. I think for example > the note in section 3.0 uses [3] in an informative one. Additional ones > may be similar. Please check the usage of all the references if they > really are normative. > Sounds like I need to look at dividing informative vs. normative references. > > 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 > --047d7b603a8ad5063b04ce030992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the review. Responses below.

On Thu, Nov 8, 2012 at 4:40 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

I have reviewed the leap second document and have the following comments.
1. Section 1. It needs to say also in the introduction that it updates
RFC 3550, not only in the abstract.

Ok.= =A0

2. Section 3.4:
=A0 =A0+-------+--------------+--------------+--------------+--------------= +
=A0 =A0| =A0RTP =A0| =A0 =A0 =A0TAI =A0 =A0 | =A0 =A0 =A0UTC =A0 =A0 | =A0 = =A0 POSIX =A0 =A0| =A0 =A0 =A0NTP =A0 =A0 |
=A0 =A0+-------+--------------+--------------+--------------+--------------= +
=A0 =A0| =A08000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.50= 0 |
=A0 =A0| 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 = |
=A0 =A0| 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 = |
=A0 =A0| 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 = |
=A0 =A0| 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 = |
=A0 =A0| 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 = |
=A0 =A0| 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 = |
=A0 =A0+-------+--------------+--------------+--------------+--------------= +

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Table 1=

I am wondering if the RTP 20000 and 24000 is really correctly
representing what you write in section 3.2 for the NTP column. Should't=
the 00:00:00.000 actually =A000:00:00.000-, i.e. something that is prior to 00:00:00.000 but just?

A common syst= em behavior is that when the NTP clock is frozen,=A0successive=A0calls to= =A0retrieve=A0system return incrementally larger time values. This keeps ap= plications from faulting from assumptions about time being continuous and= =A0monotonic. This behavior=A0occurs=A0in the LS bits of the time value and= so is not generally visible in the human-readable format shown in the tabl= e. I can add a discussion of this if you think it is useful.

3. Section 4.1:

=A0 =A0RTP Senders working to a leap-second-bearing reference SHOULD NOT =A0 =A0generate sender reports containing an originating NTP timestamp in =A0 =A0the vicinity of a leap second. =A0Receivers SHOULD ignore timestamps= in
=A0 =A0any such reports inadvertently generated.

I wonder how you in practice are going to fulfill the sender
recommendation. That only works if your regular reporting interval is on the order of a second or longer. Otherwise not sending a SR packet for a RTP packet sender within 1.5*Td (where Td is your deterministic
reporting interval) will be counted towards source time-out or other
methods detecting missing packets. So for a reporting interval of 100 or 200 ms you can't actually follow the SHOULD.

<= /div>
That's a good point. If we need to keep sending SRs during th= e 2second leap second interval to avoid timeouts, they can be sent with a 0= NTP timestamp. This=A0might=A0be a better approach for all RTCP rates. I h= ave to research what special receiver behavior may be required to=A0accommo= date=A0this.

4. Section 5. Security Consideration.

I wonder if this section really are covering some potential issues.
First are there security replay mechanisms that uses the clock? SRTP is
not effected as it uses packet index, i.e. roll over counter + seq_nr.
But there might be other things that could be confused for example by
the posix clock.

Are there attack vectors that are created when by possibly fool an
end-host to believe a leap-second event is happening and thus thinks the clock are freezing or repeating that otherwise would be possible?

Today I volunteered to review draft-ietf-tictoc-secur= ity-requirements. I will take this and your comments into consideration and= try to improve the security considerations section.

5. Reference section:

I don't believe that all references are normative. I think for example<= br> the note in section 3.0 uses [3] in an informative one. Additional ones
may be similar. Please check the usage of all the references if they
really are normative.

Sounds like I nee= d to look at dividing informative vs. normative references.=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--047d7b603a8ad5063b04ce030992-- From ekr@rtfm.com Thu Nov 8 15:09:27 2012 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 28E5321F8932 for ; Thu, 8 Nov 2012 15:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+IsDD2LpuaL for ; Thu, 8 Nov 2012 15:09:26 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6045321F89E5 for ; Thu, 8 Nov 2012 15:09:26 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so2771591lam.31 for ; Thu, 08 Nov 2012 15:09:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=cmUaU5mFUSOBFBtdY/lSwPvBpQ5GrKZ8P3TVnHtEs7U=; b=h+iOayOxESyavvG/QtiJzbwq+gm5013XZ3WdmpxLmVIjBp0bDfXJFatgH8SG/6ioJW Tk5cuYZnfTPPddxNBA61nCjs36EtvxjNYdU3CvPmCFX9hRsMCy0dbcmBEx9X9F4f0Y9d azZWxoIsqygZ+RTch6ugXA4AP55xqhOF1JoVKOTfeYCwOT6qK+ZYxE8AvAV8YvN9vl7O /4ovkqRQn0UGZO4sdjTCzs0wdGiCwUZKdqUucnTIY0zCidagjvudQLp5uxcHRBgwFfyA 56r75OwOLXRHnaPhZRtDlExpl157lN4/IpAnxv6Pac7JmwtTyS8q5yIPI0bTEw9nMbLr OBig== Received: by 10.112.47.228 with SMTP id g4mr3682759lbn.21.1352416165023; Thu, 08 Nov 2012 15:09:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.25.39 with HTTP; Thu, 8 Nov 2012 15:08:41 -0800 (PST) X-Originating-IP: [130.129.16.175] From: Eric Rescorla Date: Thu, 8 Nov 2012 18:08:41 -0500 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnjuJs6K/+szx+8egrbwHTpzew4EeJ5ybsM+rz3lauwUuLzkCmHIXULTRlFcByk7bLo9IF/ Subject: [AVTCORE] Key diversification with DTLS-SRTP with Shim 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, 08 Nov 2012 23:09:27 -0000 Section 6.3.2 of http://tools.ietf.org/id/draft-westerlund-avtcore-transport-multiplexing-04.txt states: Instead we propose that an DTLS-SRTP key-derivation change is introduced. By including the Session ID value in the derivation of the keying material a single DTLS-SRTP key-management operation could apply keys and parameters for all the RTP sessions in the same transport flow. Thus the keying cost is significantly reduced, especially in regards to network communication and delay impact and vunerability to packet loss. This seems totally reasonable. DTLS-SRTP uses RFC 5705 TLS Exporters. These take an optional "context" value which is currently not used. I propose we set the "context" to be the shim ID (represented as a 16-bit big-endian unsigned integer). -Ekr From magnus.westerlund@ericsson.com Fri Nov 9 03:40:43 2012 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 B535321F85EA for ; Fri, 9 Nov 2012 03:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.09 X-Spam-Level: X-Spam-Status: No, score=-105.09 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WeMDIuWxe9K for ; Fri, 9 Nov 2012 03:40:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8021F85DD for ; Fri, 9 Nov 2012 03:40:42 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-7b-509cebb92c05 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7C.64.26143.9BBEC905; Fri, 9 Nov 2012 12:40:41 +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; Fri, 9 Nov 2012 12:40:39 +0100 Message-ID: <509CEBAF.1030305@ericsson.com> Date: Fri, 9 Nov 2012 06:40:31 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IETF AVTCore WG , draft-ietf-avtcore-clksrc@tools.ietf.org X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvje7O13MCDNbcErR42bOS3WLS1+2s DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG5O7TLAVfZCv2ndZsYNwt3sXIySEhYCLR e/8hO4QtJnHh3nq2LkYuDiGBk4wSR/dtYodwljFKHDx/hQ2kildAW+LexhMsIDaLgIrEwbZP zCA2m4CFxM0fjWA1ogLBEnuOrWWEqBeUODnzCVi9iIC/RM+TR2D1wgKGEq/a2xghNktKvH3/ CizOLKAnMeVqCyOELS/RvHU2WFwIaG9DUwfrBEb+WUjGzkLSMgtJywJG5lWM7LmJmTnp5Uab GIEhdnDLb9UdjHfOiRxilOZgURLntd66x19IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4/rT SoF671/O2cRymEX1ZeHkeZ/vGv5eurJe5N+9uKS92yeu/RpmvCDp5ZUza9PyDzOFOpRNPTrh /trZBT/PnjFbuWFbwOo+7hPJ/BUnKxhOObUVm82a4pA74djOmTt9sqZbfLrzMe1Couqr/Tuk PrLtCG2pUH1zhffw7pdKS/+6zls7bf2qIzOMlFiKMxINtZiLihMBAp6/uf8BAAA= Subject: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-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: Fri, 09 Nov 2012 11:40:43 -0000 Hi, I have review the Clock Source document draft-ietf-avtcore-clksrc-01 and have the following comments: 1. General comment on all the use of hanging lists. Please put in some separator characters like ":" between the label and the bullet text. 2. Section 3. media stream Yes, it is made clear above that this is SDP terminology. But as "media stream" is also used for the sequnce of packets comming from an SSRC in RTP I think it is prudent to call this type of media stream "SDP media stream" to avoid confusion in the reader. 3. Section 4.6 This is really a question of how traceable clocks works. I know in Sweden we have "Swedish Time" which is produced by a governmental body using a number of time production centers and time sources. Several of the time sources are also used to help produce UTC. Commonly the difference between Swedish time and UTC will be minimal, i.e on the nano second level. However, in the case Sweden would be isolated from UTC users of Swedish time will be able to use a common time-base. This is clearly tracable, but how do you deal with the fact that there are different sources of traceable time. For example, my home computer's clocks runs of the Swedish strata one NTP servers, but I think it is traceable also. 4. Section 4.8: clksrc = ntp / ptp / gps / gal / local / private I think this should ad a syntax element that make clear the syntax of a future extension shall have. An example: clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext clksrc-ext = token ; token as in SDP The similar extensibility I think should exist in the following rules: ptp-version ptp-server 5. Section 4.8: hostname = *( domainlabel "." ) toplabel [ "." ] Where is this rule taken from. I try to remember why you need a hostname to end on a ".". 6. Section 4.8 port = 1*DIGIT I would recommend that we restrict the port number to 5 digits maximum length, i.e. port = 1*5DIGIT Or do you see any need for totally unlimited number of digits? 7. I wonder if it should be more explicit that the a=clksrc attribute actually are defined to usage at the source (a=SSRC) level in the definition text by including a mention of source-specific and a ref to RFC 5576? 8. Section 5.3: In a given system, master clock identifiers must be unique. Such identifiers MAY be manually configured, however 17 octet string identifiers SHOULD be generated according to the "short-term persistent RTCP CNAME" algorithm as described in RFC6222 [7]. I can see that a short term persistent is sufficient, but aren't it desired to actually use a long term persistent identifier for clock sources so that one can track their usage over different RTP sessions? 9. Section 5.4: mediaclock = refclk / streamid / sender I think the above ABNF syntax rules shall include a syntax definition for future extensions of the attribute. 10. Section 4 and 5: The SDP attributes are lacking clear rules for interpretation in a SDP Offer/Answer context and thus also the declarative usage should be contrasted and clear. But, I think this document is shaping up nicely and the authors are doing an excellent work with it. So lets get these last things settled so that we can last call it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 9 03:53:53 2012 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 70E7721F854C for ; Fri, 9 Nov 2012 03:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.127 X-Spam-Level: X-Spam-Status: No, score=-106.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTpzUmj8XOJ6 for ; Fri, 9 Nov 2012 03:53:52 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 483C121F84B1 for ; Fri, 9 Nov 2012 03:53:52 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-a9-509ceecfd1a6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 60.4A.11564.FCEEC905; Fri, 9 Nov 2012 12:53:51 +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; Fri, 9 Nov 2012 12:53:51 +0100 Message-ID: <509CEECB.4000908@ericsson.com> Date: Fri, 9 Nov 2012 06:53:47 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Kevin Gross References: <509C26C2.30505@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvje75d3MCDK4tF7B42bOS3WLn//1s Fi8OtbM5MHv8u7qd2WPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgynjTNZO14J1mxdwPLxkb GKcrdDFyckgImEgcn3KfBcIWk7hwbz1bFyMXh5DASUaJOyuWMEI4yxglVm6/wgpSxSugLXFj 8XegDg4OFgEViXn3q0DCbAIWEjd/NLKB2KICwRJ7jq1lhCgXlDg58wnYAhEBdYlHux4ygdjM AiESfeub2EFsYQEXiaf3esDiQgJ5EusnfwCbwykQKNF5cgs7xHGSEm/fv2KG6NWTmHK1hRHC lpdo3jqbGaJXW6KhqYN1AqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0csNNjMDwPbjlt+4OxlPn RA4xSnOwKInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Ondn18518L05bSvZZMj dlgrXJFbdVfiXH6uYeW2FC/WpSH6uTKPQ1X+yR/IeqFZk8tgcdb28uKPEVoXry/Vdpp0ZWr5 6jfRXytnJJS5iXxZddFjSv2zBuErLc27L0qfXxKhNMH9m8XeuueH5QSsma727rjoqJ1u0FO1 db14dkZjFJe1eKmnEktxRqKhFnNRcSIA9udErC0CAAA= Cc: IETF AVTCore WG , draft-ietf-avtcore-leap-second@tools.ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-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: Fri, 09 Nov 2012 11:53:53 -0000 Hi, Responding to the ones with question or feedback desired. On 2012-11-08 17:05, Kevin Gross wrote: > Thanks for the review. Responses below. > > On Thu, Nov 8, 2012 at 4:40 PM, Magnus Westerlund > > > wrote: > > > 2. Section 3.4: > +-------+--------------+--------------+--------------+--------------+ > | RTP | TAI | UTC | POSIX | NTP | > +-------+--------------+--------------+--------------+--------------+ > | 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 | > | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 | > | 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 | > | 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 | > | 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 | > | 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 | > | 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 | > +-------+--------------+--------------+--------------+--------------+ > > Table 1 > > I am wondering if the RTP 20000 and 24000 is really correctly > representing what you write in section 3.2 for the NTP column. Should't > the 00:00:00.000 actually 00:00:00.000-, i.e. something that is prior > to 00:00:00.000 but just? > > > A common system behavior is that when the NTP clock is > frozen, successive calls to retrieve system return incrementally larger > time values. This keeps applications from faulting from assumptions > about time being continuous and monotonic. This behavior occurs in the > LS bits of the time value and so is not generally visible in the > human-readable format shown in the table. I can add a discussion of this > if you think it is useful. I think a short comment / note why this doesn't show up in the table might be beneficial to avoid confusion in the reader. > > > 3. Section 4.1: > > RTP Senders working to a leap-second-bearing reference SHOULD NOT > generate sender reports containing an originating NTP timestamp in > the vicinity of a leap second. Receivers SHOULD ignore timestamps in > any such reports inadvertently generated. > > I wonder how you in practice are going to fulfill the sender > recommendation. That only works if your regular reporting interval is on > the order of a second or longer. Otherwise not sending a SR packet for a > RTP packet sender within 1.5*Td (where Td is your deterministic > reporting interval) will be counted towards source time-out or other > methods detecting missing packets. So for a reporting interval of 100 or > 200 ms you can't actually follow the SHOULD. > > > That's a good point. If we need to keep sending SRs during the 2second > leap second interval to avoid timeouts, they can be sent with a 0 NTP > timestamp. This might be a better approach for all RTCP rates. I have to > research what special receiver behavior may be required to accommodate this. > I think using 0 makes it very clear that the NTP field is not to be trusted for these packets. That is very clear for the updated and aware implementation. It is quite bad for an old implementation. Using the system clock across a leap second event can clearly result in a desynchronization of audio and video with a second. If you use the 0 value a naive implementation can suddenly believe that the media is desynchronized with 112+ years. I have seen this occur in at least one implementation when feeding it bad time-synch data. The implementation started buffering until it run out of memory. > > 4. Section 5. Security Consideration. > > I wonder if this section really are covering some potential issues. > First are there security replay mechanisms that uses the clock? SRTP is > not effected as it uses packet index, i.e. roll over counter + seq_nr. > But there might be other things that could be confused for example by > the posix clock. > > Are there attack vectors that are created when by possibly fool an > end-host to believe a leap-second event is happening and thus thinks the > clock are freezing or repeating that otherwise would be possible? > > > Today I volunteered to review draft-ietf-tictoc-security-requirements. I > will take this and your comments into consideration and try to improve > the security considerations section. > Good, I encourage people to think creatively if there are ways of using the rules provided for attacks. For example I think the insertion of 0 in the NTP field might have some implications. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 9 03:55:48 2012 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 B6C7721F854E for ; Fri, 9 Nov 2012 03:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI7p4DTc3vS3 for ; Fri, 9 Nov 2012 03:55:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEB21F854C for ; Fri, 9 Nov 2012 03:55:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-1f-509cef422dec Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.8A.11564.24FEC905; Fri, 9 Nov 2012 12:55:46 +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; Fri, 9 Nov 2012 12:55:46 +0100 Message-ID: <509CEF40.9020400@ericsson.com> Date: Fri, 9 Nov 2012 06:55:44 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvja7T+zkBBk/3aFm87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMuTZ7MXdPNUNHe9Y29gfMHZxcjJISFgInF7xWVWCFtM4sK9 9WxdjFwcQgInGSXW/p/DCuEsY5RYPHc5I0gVr4C2xP5d15hBbBYBFYl3m2aDxdkELCRu/mhk A7FFBYIl9hxbC1UvKHFy5hMWEFtEQEBixfa/YLawgLPE60mvwWqEBAIknr9ewARicwoESizq P8YOcZGkxNv3r8B2MQvoSUy52sIIYctLNG+dzQzRqy3R0NTBOoFRcBaSdbOQtMxC0rKAkXkV I3tuYmZOernhJkZgAB7c8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYGT16958yL7zWs7M6udhifMus14v7DuZztIksXsV31uzU3q3ZLhfqAeLs7/+b9Ji sH/CU4UX2vMUe6u3BCaemlSsc/Ddi3nb+fKL9s+/dbjWU4aZV/05xxmfH2vSlp802XXIY8V5 9//xJkeeGj+1Djn3USTZa+GZg41BJ2dtqa9O8IpmWtPg90CJpTgj0VCLuag4EQAZE2LMDgIA AA== Subject: Re: [AVTCORE] Key diversification with DTLS-SRTP with Shim 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, 09 Nov 2012 11:55:48 -0000 Thanks, On 2012-11-08 18:08, Eric Rescorla wrote: > Section 6.3.2 of > http://tools.ietf.org/id/draft-westerlund-avtcore-transport-multiplexing-04.txt > states: > > Instead we propose that an DTLS-SRTP key-derivation change is > introduced. By including the Session ID value in the derivation of > the keying material a single DTLS-SRTP key-management operation could > apply keys and parameters for all the RTP sessions in the same > transport flow. Thus the keying cost is significantly reduced, > especially in regards to network communication and delay impact and > vunerability to packet loss. > > This seems totally reasonable. > > DTLS-SRTP uses RFC 5705 TLS Exporters. These take an optional "context" value > which is currently not used. I propose we set the "context" to be the shim ID > (represented as a 16-bit big-endian unsigned integer). Do one want this value to be prefixed with something like "SHIM" or other so that others can feed in their values without causing risk of extracting the same material? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Nov 14 06:57:09 2012 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 84CCD21F85ED for ; Wed, 14 Nov 2012 06:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuV3CRB8TVbq for ; Wed, 14 Nov 2012 06:57:09 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4621F85EB for ; Wed, 14 Nov 2012 06:57:08 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-95-50a3b142a9c0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 11.2F.06323.241B3A05; Wed, 14 Nov 2012 15:57:07 +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; Wed, 14 Nov 2012 15:57:06 +0100 Message-ID: <50A3B141.5000900@ericsson.com> Date: Wed, 14 Nov 2012 15:57:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Roni Even References: <20121015142026.6075.9386.idtracker@ietfa.amsl.com> <507C1C7C.8080007@ericsson.com> <060c01cdb2b0$aa047720$fe0d6560$@gmail.com> In-Reply-To: <060c01cdb2b0$aa047720$fe0d6560$@gmail.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Rtd54+IAg1Pb2Sxe9qxkt/jbzuzA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZVxYzFvwiadizaNNLA2M67i6GDk5JARMJE48 m8kEYYtJXLi3nq2LkYtDSOAko8ShczsZIZzljBJbl25n7WLk4OAV0JZYP9MVpIFFQFXiweLj jCA2m4CFxM0fjWwgtqhAsMSeY2vB4rwCghInZz5hAbFFBNQkXq/9zAYyhllAReLt4UKQsLBA rMTGfzdYIVZ1M0qsPtfNDlLDCTRz0pdEiNskJd6+f8UMYjML6ElMudrCCGHLSzRvnQ0WFwK6 rKGpg3UCo9AsJJtnIWmZhaRlASPzKkb23MTMnPRy802MwCA9uOW3wQ7GTffFDjFKc7AoifPq qe73FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoulsjNe3Z/iQxgZks0c8U9OZd/RIeuvTb tdrL9+5v4cpzmZguN3dPZHDYyQKxf83XNoe/bk7UnGAmeLYydUbSvGeWPJbi6aVViS+sDWre /NZU9Y+SlFkl+Z4jbJcd/5ID/9+7u+rZqn60TZx8Rl66VmrlX4269RzvE9teztMTU1QI9Tfc P1mJpTgj0VCLuag4EQDCZXubIAIAAA== Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-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: Wed, 14 Nov 2012 14:57:09 -0000 Hi, Sorry for the delay in responding. On 2012-10-25 15:00, Roni Even wrote: > Hi Magnus, > I read the draft so to answer the questions > > 1. I think the document need also to discuss the SDES behavior (CNAME must > be forwarded to support the CSRC) specified in 7.2 and 7.3 of RFC 3550 for > the different topologies (we had recently a discussion about using SDES > messages). Yes, that is a good idea. > 2. I did not fully understand the SSRC behavior for source projecting > middlebox and how it is different from the topologies in 3.5. The difference between a RTP mixer and a source projecting mixer and its usage of SSRCs are as follow. Source projection: SSRC has a one to one relation to a CSRC RTP Mixer: Has one SSRC that carries content from potentially multiple CSRCs. The big difference is that an RTP mixer's SSRC contains either a selection or a media level mix/composition of the contributed media streams. A source projection mixer really is a way of projecting the other media sources in the conference into the RTP session between the Mixer and this particular conference participant. Does this make it clearer? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Nov 14 07:27:09 2012 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 61A1E21F858E for ; Wed, 14 Nov 2012 07:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.145 X-Spam-Level: X-Spam-Status: No, score=-106.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v24YFEKICSqJ for ; Wed, 14 Nov 2012 07:27:08 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37EB321F8589 for ; Wed, 14 Nov 2012 07:27:08 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-9b-50a3b84ab73b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 71.AC.11564.A48B3A05; Wed, 14 Nov 2012 16:27:06 +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; Wed, 14 Nov 2012 16:27:06 +0100 Message-ID: <50A3B849.5090200@ericsson.com> Date: Wed, 14 Nov 2012 16:27:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <20121022152200.10065.7482.idtracker@ietfa.amsl.com> <508566CF.3010503@ericsson.com> <92B7E61ADAC1BB4F941F943788C08828104224@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828104224@xmb-aln-x08.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rtdrx+IAg03LDC1e9qxkt9g06wub A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJWxuWsLY8FSxYqLi3YwNTCul+pi5OCQEDCR mLS1pouRE8gUk7hwbz1bFyMXh5DASUaJ6ZNeMEE4yxklmhYfZwZp4BXQlpjSUQ3SwCKgKjFj Xh8LiM0mYCFx80cjG4gtKhAssefYWkYQm1dAUOLkzCdgNSIChhKLJq0Ds5kFlCTmLn0NNlJY IF9i8kpniFXzGSU+3/8BVsMp4C3x+uVfRojjJCXevn/FDNGrKdG6/Tc7hC0v0bx1NlhcCOi0 hqYO1gmMQrOQrJ6FpGUWkpYFjMyrGNlzEzNz0ssNNzECA/Xglt+6OxhPnRM5xCjNwaIkzsuV tN9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyPf+alfp5QdsXv15uqXYA7WozJ7vp9/tqfm zb5P2yrv71790uV257vI1+kPTt6LXf8gNCd+dkB+wgNOZu33OzLZ3+q5MSvNE5ifbLj2vBuv IONhs4Yql2lhD+3CSxItq9081taLeIccnLV0xc3FG5N+s0pEvRf5t2Ku6uroo2+PCBzoFHq3 NHCpEktxRqKhFnNRcSIAx/JqHyICAAA= Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.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: Wed, 14 Nov 2012 15:27:09 -0000 Hi, Thanks for the comments. On 2012-11-03 18:41, Charles Eckel (eckelcu) wrote: > I think this is a useful document; However, I do have a few comments > and concerns regarding its focus and relationship with other drafts. > > 1) Section 3, Motivations. It currently reads as follows: > > This section looks at the motivations why an additional solution is > needed assuming that you can do both the classical method of having > one RTP session per transport flow as defined by the RTP > specification [RFC3550] and when you have multiple media types within > one RTP session [I-D.ietf-avtcore-multi-media-rtp-session]. > > How about the following instead: > > This section looks at the motivations for standardizing two mechanisms > for multiplexing multiple media types within a single transport flow: > 1) having one RTP session per transport flow, as defined by the RTP > specification [RFC3550], and multiplexing multiple RTP session per transport > flow, as defined in this document ( or elsewhere if preferred to split it out). > 2) having multiple media types within one RTP session, as defined in > [I-D.ietf-avtcore-multi-media-rtp-session]. Yes, that is clearer. > > 2) Sections 3.1 and 3.2 are motivations for (2) and are duplicated > in [I-D.ietf-avtcore-multi-media-rtp-session] , whereas sections 3.3 and 3.4 are motivations for (1). Perhaps it is best to remove sections 3.1 and 3.2 and let this draft focus on the reasons why (1) is needed, as that is real focus of this draft. > I will need to think about this. It might be that some restructuring are needed in general to consider both when a single transport is motivated and what the motivation is for having multiple RTP sessions over one transport flow. Thus maybe further tweaking of the introduction section and the structure. > 3) Section 3.5 is more a statement of the requirement for a way to negotiate (1) vs (2), rather than a motivation for either. Then I don't think the message comes across that this session tries to describe. To deploy a mix of legacy multiple RTP sessions clients and single RTP session with multiple media types clients are not possible in a joint multi-party conference unless one have a full RTP level translation capable middlebox. > > 4) Section 6.2, Signaling, contains the following:> > The 'session-mux-id' attribute is included for a media description, > in order to indicate the Session ID for that particular media > description. Every media description that shares a common attribute > value is assumed to be part of a single RTP session. > > Is that true? I think you meant to say these may exist in one or > more RTP sessions, with the RTP sessions being multiplexed on a single > transport flow. > > And the later it reads as follows: > > An SDP Offerer > MUST include the 'session-mux-id' attribute for every media > description associated with a 'SHIM' group. If the SDP Answer does > not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based > layering. However, if that is separate RTP sessions or BUNDLE is > determined on what was present in the offer and answer. This will > depend on what the offering party likes to happen. > > You lost me here. Hopefully some rewording would help. I wonder if what you are getting confused over is the statement that multiple m= lines where each m= lines contains the same SID would form a joint RTP session. That was a notion that is included, but based on the BUNDLE discussions I think should be avoided as the majority of the difficult issues with BUNDLE is due to having multiple m= lines be part of describing one RTP session. 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 eckelcu@cisco.com Thu Nov 15 14:19:44 2012 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 5ED6521F8A0D for ; Thu, 15 Nov 2012 14:19:44 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHZzssQ8lZUE for ; Thu, 15 Nov 2012 14:19:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 463DB21F8A0B for ; Thu, 15 Nov 2012 14:19:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7650; q=dns/txt; s=iport; t=1353017984; x=1354227584; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YmlnZXcZnY5zCRDwf+dTGqWMTvkcMiQ1F1DphsKpd5A=; b=DM88I1z8F3g8Hk0+WIWsHo1gAgABVDNtyuzMjd6J7gfBdNDT4sa1z2T+ TOhNZQOyesmAvU896CCr2FB/0c7LSDzBWxt5yrHPizZz3nsh3E0/Bquxj YnLKaxVo7PybGrTviE+ULaY7AxFGhAz3TtesagBy1xFekfjMbQjGnEALH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAAFqpVCtJV2d/2dsb2JhbABEhUNauy14gQiCHgEBAQMBDAYBEBE0CgUCDAICAgEGAhEEAQEBAgIGGQQDAgICGRcUAQgIAgQOBQgTB4dlBQGdBI0oklwEgR6LD4UZMmEDkkqSCoFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="142990576" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2012 22:19:43 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAFMJgos026486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 22:19:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 16:19:42 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund Thread-Topic: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.txt Thread-Index: AQHNwnyEwyhgEH/lSEeCap8gb7qnQZfrbzfg Date: Thu, 15 Nov 2012 22:19:41 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882812C8EC@xmb-aln-x08.cisco.com> References: <20121022152200.10065.7482.idtracker@ietfa.amsl.com> <508566CF.3010503@ericsson.com> <92B7E61ADAC1BB4F941F943788C08828104224@xmb-aln-x08.cisco.com> <50A3B849.5090200@ericsson.com> In-Reply-To: <50A3B849.5090200@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19368.001 x-tm-as-result: No--66.392300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.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, 15 Nov 2012 22:19:44 -0000 SGkgTWFnbnVzLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMiA3 OjI3IEFNDQo+IFRvOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPiBDYzogSUVURiBBVlRDb3Jl IFdHDQo+IFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LQ0KPiB3ZXN0ZXJsdW5kLWF2dGNvcmUtdHJhbnNwb3J0LW11bHRpcGxleGlu Zy0wNC50eHQNCj4gDQo+IEhpLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMuDQo+IA0K PiBPbiAyMDEyLTExLTAzIDE4OjQxLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSB3cm90ZToNCj4g PiBJIHRoaW5rIHRoaXMgaXMgYSB1c2VmdWwgZG9jdW1lbnQ7IEhvd2V2ZXIsIEkgZG8gaGF2ZSBh IGZldyBjb21tZW50cw0KPiA+IGFuZCBjb25jZXJucyByZWdhcmRpbmcgaXRzIGZvY3VzIGFuZCBy ZWxhdGlvbnNoaXAgd2l0aCBvdGhlciBkcmFmdHMuDQo+ID4NCj4gPiAxKSBTZWN0aW9uIDMsIE1v dGl2YXRpb25zLiBJdCBjdXJyZW50bHkgcmVhZHMgYXMgZm9sbG93czoNCj4gPg0KPiA+ICAgIFRo aXMgc2VjdGlvbiBsb29rcyBhdCB0aGUgbW90aXZhdGlvbnMgd2h5IGFuIGFkZGl0aW9uYWwgc29s dXRpb24gaXMNCj4gPiAgICBuZWVkZWQgYXNzdW1pbmcgdGhhdCB5b3UgY2FuIGRvIGJvdGggdGhl IGNsYXNzaWNhbCBtZXRob2Qgb2YgaGF2aW5nDQo+ID4gICAgb25lIFJUUCBzZXNzaW9uIHBlciB0 cmFuc3BvcnQgZmxvdyBhcyBkZWZpbmVkIGJ5IHRoZSBSVFANCj4gPiAgICBzcGVjaWZpY2F0aW9u IFtSRkMzNTUwXSBhbmQgd2hlbiB5b3UgaGF2ZSBtdWx0aXBsZSBtZWRpYSB0eXBlcyB3aXRoaW4N Cj4gPiAgICBvbmUgUlRQIHNlc3Npb24gW0ktRC5pZXRmLWF2dGNvcmUtbXVsdGktbWVkaWEtcnRw LXNlc3Npb25dLg0KPiA+DQo+ID4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgaW5zdGVhZDoNCj4g Pg0KPiA+ICAgIFRoaXMgc2VjdGlvbiBsb29rcyBhdCB0aGUgbW90aXZhdGlvbnMgZm9yIHN0YW5k YXJkaXppbmcgdHdvIG1lY2hhbmlzbXMNCj4gPiAgICBmb3IgbXVsdGlwbGV4aW5nIG11bHRpcGxl IG1lZGlhIHR5cGVzIHdpdGhpbiBhIHNpbmdsZSB0cmFuc3BvcnQgZmxvdzoNCj4gPiAgIDEpIGhh dmluZyBvbmUgUlRQIHNlc3Npb24gcGVyIHRyYW5zcG9ydCBmbG93LCBhcyBkZWZpbmVkIGJ5IHRo ZSBSVFANCj4gPiAgICBzcGVjaWZpY2F0aW9uIFtSRkMzNTUwXSwgYW5kIG11bHRpcGxleGluZyBt dWx0aXBsZSBSVFAgc2Vzc2lvbiBwZXINCj4gdHJhbnNwb3J0DQo+ID4gICAgZmxvdywgYXMgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50ICggb3IgZWxzZXdoZXJlIGlmIHByZWZlcnJlZCB0byBzcGxp dCBpdA0KPiBvdXQpLg0KPiA+ICAgMikgaGF2aW5nICBtdWx0aXBsZSBtZWRpYSB0eXBlcyB3aXRo aW4gb25lIFJUUCBzZXNzaW9uLCBhcyBkZWZpbmVkIGluDQo+ID4gICBbSS1ELmlldGYtYXZ0Y29y ZS1tdWx0aS1tZWRpYS1ydHAtc2Vzc2lvbl0uDQo+IA0KPiBZZXMsIHRoYXQgaXMgY2xlYXJlci4N Cj4gDQo+ID4NCj4gDQo+ID4gMikgU2VjdGlvbnMgMy4xIGFuZCAzLjIgYXJlIG1vdGl2YXRpb25z IGZvciAoMikgYW5kIGFyZSBkdXBsaWNhdGVkDQo+ID4gaW4NCj4gW0ktRC5pZXRmLWF2dGNvcmUt bXVsdGktbWVkaWEtcnRwLXNlc3Npb25dICwgd2hlcmVhcyBzZWN0aW9ucyAzLjMgYW5kDQo+IDMu NCBhcmUgbW90aXZhdGlvbnMgZm9yICgxKS4gUGVyaGFwcyBpdCBpcyBiZXN0IHRvIHJlbW92ZSBz ZWN0aW9ucyAzLjENCj4gYW5kIDMuMiBhbmQgbGV0IHRoaXMgZHJhZnQgZm9jdXMgb24gdGhlIHJl YXNvbnMgd2h5ICgxKSBpcyBuZWVkZWQsIGFzDQo+IHRoYXQgaXMgcmVhbCBmb2N1cyBvZiB0aGlz IGRyYWZ0Lg0KPiA+DQo+IA0KPiBJIHdpbGwgbmVlZCB0byB0aGluayBhYm91dCB0aGlzLiBJdCBt aWdodCBiZSB0aGF0IHNvbWUgcmVzdHJ1Y3R1cmluZyBhcmUNCj4gbmVlZGVkIGluIGdlbmVyYWwg dG8gY29uc2lkZXIgYm90aCB3aGVuIGEgc2luZ2xlIHRyYW5zcG9ydCBpcyBtb3RpdmF0ZWQNCj4g YW5kIHdoYXQgdGhlIG1vdGl2YXRpb24gaXMgZm9yIGhhdmluZyBtdWx0aXBsZSBSVFAgc2Vzc2lv bnMgb3ZlciBvbmUNCj4gdHJhbnNwb3J0IGZsb3cuIFRodXMgbWF5YmUgZnVydGhlciB0d2Vha2lu ZyBvZiB0aGUgaW50cm9kdWN0aW9uIHNlY3Rpb24NCj4gYW5kIHRoZSBzdHJ1Y3R1cmUuDQo+IA0K PiA+IDMpIFNlY3Rpb24gMy41IGlzIG1vcmUgYSBzdGF0ZW1lbnQgb2YgdGhlIHJlcXVpcmVtZW50 IGZvciBhIHdheSB0bw0KPiBuZWdvdGlhdGUgKDEpIHZzICgyKSwgcmF0aGVyIHRoYW4gYSBtb3Rp dmF0aW9uIGZvciBlaXRoZXIuDQo+IA0KPiBUaGVuIEkgZG9uJ3QgdGhpbmsgdGhlIG1lc3NhZ2Ug Y29tZXMgYWNyb3NzIHRoYXQgdGhpcyBzZXNzaW9uIHRyaWVzIHRvDQo+IGRlc2NyaWJlLiBUbyBk ZXBsb3kgYSBtaXggb2YgbGVnYWN5IG11bHRpcGxlIFJUUCBzZXNzaW9ucyBjbGllbnRzIGFuZA0K PiBzaW5nbGUgUlRQIHNlc3Npb24gd2l0aCBtdWx0aXBsZSBtZWRpYSB0eXBlcyBjbGllbnRzIGFy ZSBub3QgcG9zc2libGUgaW4NCj4gYSBqb2ludCBtdWx0aS1wYXJ0eSBjb25mZXJlbmNlIHVubGVz cyBvbmUgaGF2ZSBhIGZ1bGwgUlRQIGxldmVsDQo+IHRyYW5zbGF0aW9uIGNhcGFibGUgbWlkZGxl Ym94Lg0KDQpJIHNlZSBub3cuIEkgd2FzIG5vdCBjb21pbmcgdG8gdGhhdCB1bmRlcnN0YW5kaW5n IHdpdGggdGhlIGV4aXN0aW5nIHdvcmRpbmcgaW4gdGhlIGRyYWZ0LiBJbmNvcnBvcmF0aW5nIHRo ZSB0ZXh0IHlvdSBwcm92aWRlZCBhYm92ZSB3b3VsZCBoZWxwLiANCiANCj4gPg0KPiA+IDQpIFNl Y3Rpb24gNi4yLCBTaWduYWxpbmcsIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmc6Pg0KPiA+ICAgIFRo ZSAnc2Vzc2lvbi1tdXgtaWQnIGF0dHJpYnV0ZSBpcyBpbmNsdWRlZCBmb3IgYSBtZWRpYSBkZXNj cmlwdGlvbiwNCj4gPiAgICBpbiBvcmRlciB0byBpbmRpY2F0ZSB0aGUgU2Vzc2lvbiBJRCBmb3Ig dGhhdCBwYXJ0aWN1bGFyIG1lZGlhDQo+ID4gICAgZGVzY3JpcHRpb24uICBFdmVyeSBtZWRpYSBk ZXNjcmlwdGlvbiB0aGF0IHNoYXJlcyBhIGNvbW1vbiBhdHRyaWJ1dGUNCj4gPiAgICB2YWx1ZSBp cyBhc3N1bWVkIHRvIGJlIHBhcnQgb2YgYSBzaW5nbGUgUlRQIHNlc3Npb24uDQo+ID4NCj4gPiBJ cyB0aGF0IHRydWU/IEkgdGhpbmsgeW91IG1lYW50IHRvIHNheSB0aGVzZSBtYXkgZXhpc3QgaW4g b25lIG9yDQo+ID4gbW9yZSBSVFAgc2Vzc2lvbnMsIHdpdGggdGhlIFJUUCBzZXNzaW9ucyBiZWlu ZyBtdWx0aXBsZXhlZCBvbiBhIHNpbmdsZQ0KPiA+IHRyYW5zcG9ydCBmbG93Lg0KPiA+DQo+ID4g QW5kIHRoZSBsYXRlciBpdCByZWFkcyBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gICAgQW4gU0RQIE9m ZmVyZXINCj4gPiAgICBNVVNUIGluY2x1ZGUgdGhlICdzZXNzaW9uLW11eC1pZCcgYXR0cmlidXRl IGZvciBldmVyeSBtZWRpYQ0KPiA+ICAgIGRlc2NyaXB0aW9uIGFzc29jaWF0ZWQgd2l0aCBhICdT SElNJyBncm91cC4gIElmIHRoZSBTRFAgQW5zd2VyIGRvZXMNCj4gPiAgICBub3QgY29udGFpbiB0 aGUgU0hJTSBncm91cCwgdGhlIFNEUCBPZmZlcmVyIE1VU1QgTk9UIHVzZSBTSElNIGJhc2VkDQo+ ID4gICAgbGF5ZXJpbmcuICBIb3dldmVyLCBpZiB0aGF0IGlzIHNlcGFyYXRlIFJUUCBzZXNzaW9u cyBvciBCVU5ETEUgaXMNCj4gPiAgICBkZXRlcm1pbmVkIG9uIHdoYXQgd2FzIHByZXNlbnQgaW4g dGhlIG9mZmVyIGFuZCBhbnN3ZXIuICBUaGlzIHdpbGwNCj4gPiAgICBkZXBlbmQgb24gd2hhdCB0 aGUgb2ZmZXJpbmcgcGFydHkgbGlrZXMgdG8gaGFwcGVuLg0KPiA+DQo+ID4gWW91IGxvc3QgbWUg aGVyZS4gSG9wZWZ1bGx5IHNvbWUgIHJld29yZGluZyB3b3VsZCBoZWxwLg0KPiANCj4gSSB3b25k ZXIgaWYgd2hhdCB5b3UgYXJlIGdldHRpbmcgY29uZnVzZWQgb3ZlciBpcyB0aGUgc3RhdGVtZW50 IHRoYXQNCj4gbXVsdGlwbGUgbT0gbGluZXMgd2hlcmUgZWFjaCBtPSBsaW5lcyBjb250YWlucyB0 aGUgc2FtZSBTSUQgd291bGQgZm9ybSBhDQo+IGpvaW50IFJUUCBzZXNzaW9uLiBUaGF0IHdhcyBh IG5vdGlvbiB0aGF0IGlzIGluY2x1ZGVkLCBidXQgYmFzZWQgb24gdGhlDQo+IEJVTkRMRSBkaXNj dXNzaW9ucyBJIHRoaW5rIHNob3VsZCBiZSBhdm9pZGVkIGFzIHRoZSBtYWpvcml0eSBvZiB0aGUN Cj4gZGlmZmljdWx0IGlzc3VlcyB3aXRoIEJVTkRMRSBpcyBkdWUgdG8gaGF2aW5nIG11bHRpcGxl IG09IGxpbmVzIGJlIHBhcnQNCj4gb2YgZGVzY3JpYmluZyBvbmUgUlRQIHNlc3Npb24uDQoNCkFj dHVhbGx5LCBJIHRoaW5rIGl0IGlzIG9rYXkgYW5kIHVzZWZ1bCB0byBkZXNjcmliZSB0aGUgd2F5 ICdzZXNzaW9uLW11eC1pZCcgd29ya3MgaW4gdGhlIHByZXNlbmNlIG9mIGJvdGggQlVORExFIGFu ZCBTSElNLCBhcyBhbiBvZmZlciBtYXkgd2VsbCBpbmNsdWRlIGJvdGggbWV0aG9kcy4gQWx0ZXJu YXRpdmVseSwgeW91IGNvdWxkIG1ha2UgdGhlIHR3byBtdXR1YWxseSBleGNsdXNpdmUuIFRoYXQg cmVtb3ZlcyBzb21lIGNvbXBsZXhpdHksIGJ1dCBJIHRoaW5rIGl0IGlzIGEgY29tcGxleGl0eSB3 ZSBuZWVkIHRvIGFkZHJlc3MgaWYgYm90aCBhcHByb2FjaGVzIGNvbnRpbnVlIHRvIHByb2dyZXNz LiANCk15IHJlbWFpbmluZyBjb21tZW50IGlzIHRoYXQgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBk b2VzIG5vdCBwYXJzZToNCg0KICAgSG93ZXZlciwgaWYgdGhhdCBpcyBzZXBhcmF0ZSBSVFAgc2Vz c2lvbnMgb3IgQlVORExFIGlzDQogICBkZXRlcm1pbmVkIG9uIHdoYXQgd2FzIHByZXNlbnQgaW4g dGhlIG9mZmVyIGFuZCBhbnN3ZXIuDQoNClJld29ya2luZyB0aGF0IHdvdWxkIGJlIGhlbHBmdWws IGFzIHRoaXMgY29udHJpYnV0ZWQgdG8gbXkgaW5pdGlhbCBjb25mdXNpb24uDQoNCkNoZWVycywN CkNoYXJsZXMNCg0KPiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFy Y2ggRUFCL1RWTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAg IHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAg fCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBt YWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg== From magnus.westerlund@ericsson.com Mon Nov 19 05:28:37 2012 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 AA27221F85C2 for ; Mon, 19 Nov 2012 05:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.172 X-Spam-Level: X-Spam-Status: No, score=-106.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLuNnjiQ28so for ; Mon, 19 Nov 2012 05:28:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 73C3B21F85AF for ; Mon, 19 Nov 2012 05:28:36 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-0f-50aa3402971f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.14.11564.2043AA05; Mon, 19 Nov 2012 14:28:35 +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; Mon, 19 Nov 2012 14:28:34 +0100 Message-ID: <50AA3401.6020102@ericsson.com> Date: Mon, 19 Nov 2012 14:28:33 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mario Montagud Climent References: <20121105132002.50214lz37taa88he@webmail.upv.es> In-Reply-To: <20121105132002.50214lz37taa88he@webmail.upv.es> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3RpfZZFWAwa2FrBYve1ayW0xpW8fk wOSxZMlPJo+7/xezBDBFcdmkpOZklqUW6dslcGVsfZdY0KVY8fHUPcYGxg9SXYwcHBICJhJr 36p1MXICmWISF+6tZ+ti5OIQEjjJKDHhcQMjhLOcUWL3nwWMIFW8AtoSfybvYgWxWQRUJW5e Wc8MYrMJWEjc/NHIBmKLCgRL7Dm2FqpeUOLkzCcsILaIgKnEmrN3wGxmAQGJ/2ub2UFsYQE3 iZebD4DNERKwkTjVeoMJxOYUsJWY8usfE8R1khJv379ihujVk5hytYURwpaXaN46G6pXW6Kh qYN1AqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0csNNjMBAPbjlt+4OxlPnRA4xSnOwKInzciXt 9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6Mo9+abm/78qx2M/nmza1RPFNXEqvxbT4tk1 XqEV85cv39StzdF/SvZ5lpyhs0P8tPuC/Ec59ITjeqef/tBzf/ueDZLFb1qPNARdXy9ffUxM tNFkZUXahhybC34/81ou3rh1nCFVdOKmlaHypco9ttbnmUzWC+hyfa/n/HvjkNyjQ99yn8Vt V2Ipzkg01GIuKk4EAGRZa+giAgAA Cc: avt@ietf.org Subject: Re: [AVTCORE] Question about the minimum RTCP report interval 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, 19 Nov 2012 13:28:37 -0000 On 2012-11-05 13:20, Mario Montagud Climent wrote: > > Hi all, > > I would appreciate it very much if you could clarify me a doubt about > the minimum RTCP reporting interval. > > According to RFC 3550, the RTCP report interval is dynamically computed > based on the allocated session bandwidth, the average size of all > (received and sent) RTCP packets, the number of participants in the > session and their role (senders or receivers), or their proportion, and > the unicast or multicast nature of the session (Section 6.2 of RFC 3550). > > Nevertheless, it is also specified that this deterministically computed > RTCP report interval should have a lower bound to avoid having bursts > (cumpling) of RTCP packets when the number of participants is small and > the law of large numbers is not helping to smooth out the traffic > overhead. This would also help to avoid excessive frequent reports > during transient outages like a network partition. The recommended value > in RFC 3550 for that fixed RTCP minimum interval is 5 seconds. > > The RFC 3550 also specifies that in some cases (e.g., if the data rate > is high and the application demands more timely feedback reports) an > implementation may scale the minimum RTCP interval to a smaller value > given by 360 divided by the session bandwidth (in kbps). Consequently, > this yields to an interval smaller than 5 seconds for bandwidths greater > than 72 kbps. In multicast sessions, only active senders may use that > reduced minimum interval, whilst in unicast sessions it also may be used > by receivers. In the above cases, however, the RTCP minimum interval > must be still taken into account during the membership accounting > procedure in order to not prematurely time out participants (who can > indeed be using it) because of inactivity. > > However, RFC 4585 defines an extension to the RTP Audio-Visual Profile > (AVP) that enables receivers to provide, statistically, more immediate > feedback messages to the senders and thus allows for short-term > adaptation and efficient feedback-based repair mechanisms to be > implemented, while maintaining the bandwidth constraints for RTCP and > preserving scalability to large groups. In RFC 4585, the RTCP > transmission interval specified in RFC 3550 is denoted as Regular RTCP > interval. In addition, RFC 4585 specifies that feedback messages can be > reported earlier than the next scheduled Regular RTCP transmission time > if a receiver detects the need to inform about events of interest in the > media stream (e.g., picture or slice loss) close to their occurrence. > Otherwise, the Regular RTCP transmission mode is employed, but the > minimum RTCP report interval of 5 seconds recommended in RFC 3550 is > dropped. > > So, my questions about this are: > > - When using the Regular RTCP reporting rules (RFC 3550) in multicast > scenarios, which option should we select for the minimum RTCP reporting > interval (for a media sender)? Can we use any of the two options for > selection the minimum thresholds (i.e., 5 sec or 360/bw_session_kbps)? > To my understanding you can use any of them. This is actually a potential interoperability issue. > - Likewise, should the sentence "the minimum RTCP report interval of 5 > seconds recommended in RFC 3550 is dropped" from RFC 4585 be applied in > all cases (i.e. not only when using the early RTCP reporting rules)? It applies also for regular reporting and instead the trr-int mechanism is introduced. I would however strongly recommend that one uses 5 seconds in the formula when timing out sources to avoid spurious timing out of sources that uses the 5 seconds if oneself are uses the scaled value. 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 internet-drafts@ietf.org Mon Nov 19 14:51:41 2012 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 ADA9921F86FC; Mon, 19 Nov 2012 14:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-oRVzQatn9H; Mon, 19 Nov 2012 14:51:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864A021F862A; Mon, 19 Nov 2012 14:51:37 -0800 (PST) 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.36 Message-ID: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 14:51:37 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 19 Nov 2012 22:51:44 -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 : Securing the RTP Protocol Framework: Why RTP Does Not Ma= ndate a Single Media Security Solution Author(s) : Colin Perkins Magnus Westerlund Filename : draft-ietf-avt-srtp-not-mandatory-11.txt Pages : 10 Date : 2012-11-19 Abstract: This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Mon Nov 19 14:59:17 2012 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 F022721F8459 for ; Mon, 19 Nov 2012 14:59:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdqOuudin6GW for ; Mon, 19 Nov 2012 14:59:17 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4383621F844B for ; Mon, 19 Nov 2012 14:59:17 -0800 (PST) Received: from [80.176.158.71] (helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TaaJ9-00015d-PN for avt@ietf.org; Mon, 19 Nov 2012 22:59:16 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2012 22:59:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> References: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -12 X-Mythic-Debug: Threshold = On = Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 19 Nov 2012 22:59:18 -0000 This version of the draft updates the recommendations in Section 6 based = on discussion with the Security Area Directors. There are no changes in = the rest of the draft. Colin On 19 Nov 2012, at 22:51, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Securing the RTP Protocol Framework: Why RTP = Does Not Mandate a Single Media Security Solution > Author(s) : Colin Perkins > Magnus Westerlund > Filename : draft-ietf-avt-srtp-not-mandatory-11.txt > Pages : 10 > Date : 2012-11-19 >=20 > Abstract: > This memo discusses the problem of securing real-time multimedia > sessions, and explains why the Real-time Transport Protocol (RTP), > and the associated RTP control protocol (RTCP), do not mandate a > single media security mechanism. Guidelines for designers and > reviewers of future RTP extensions are provided, to ensure that > appropriate security mechanisms are mandated, and that any such > mechanisms are specified in a manner that conforms with the RTP > architecture. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-11 --=20 Colin Perkins http://csperkins.org/ From cris.pascual.gonzalez@gmail.com Tue Nov 20 07:10:47 2012 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 1E40321F8755 for ; Tue, 20 Nov 2012 07:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.768 X-Spam-Level: X-Spam-Status: No, score=-4.768 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcIKbGjTfT0c for ; Tue, 20 Nov 2012 07:10:47 -0800 (PST) Received: from marfik.cc.upv.es (smtpsal1.cc.upv.es [158.42.249.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5813921F8758 for ; Tue, 20 Nov 2012 07:10:46 -0800 (PST) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id qAKFAjwT028281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Nov 2012 16:10:45 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id qAKFAi4c006764 for ; Tue, 20 Nov 2012 16:10:44 +0100 Received: from JLLORET (pptp243-34.vpns.upv.es [158.42.243.34]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id qAKFAhqp015262 for ; Tue, 20 Nov 2012 16:10:43 +0100 Date: Tue, 20 Nov 2012 16:10:43 +0100 Message-Id: <201211201510.qAKFAhqp015262@smtp.upv.es> From: Cristina Pascual To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 20 Nov 2012 08:13:02 -0800 Subject: [AVTCORE] Deadline extension| MMEDIA 2013 || April 22 - 26, 2013 - Venice, Italy 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, 20 Nov 2012 15:10:47 -0000 INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to MMEDIA 2013. The submission deadline is December 8, 2012. Authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== MMEDIA 2013 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS MMEDIA 2013, The Fifth International Conferences on Advances in Multimedia April 22 - 26, 2013 - Venice, Italy General page: http://www.iaria.org/conferences2013/MMEDIA13.html Call for Papers: http://www.iaria.org/conferences2013/CfPMMEDIA13.html - regular papers - short papers (work in progress) - posters Submission page: http://www.iaria.org/conferences2013/SubmitMMEDIA13.html Submission deadline: December 8, 2012 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Print proceedings will be available via Curran Associates, Inc.: http://www.proceedings.com/9769.html Articles will be archived in the free access ThinkMind Digital Library: http://www.thinkmind.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html MMEDIA 2013 Topics (topics and submission details: see CfP on the site) Fundamentals in multimedia Multimedia systems, architecture, and applications; New multimedia platforms; Multimedia architectural specification languages; Theoretical aspects and algorithms for multimedia; Multimedia content delivery networks; Network support for multimedia data; Multimedia data storage; Multimedia meta-modeling techniques and operating systems; Multimedia signal coding and processing (audio, video, image); Multimedia applications (telepresence, triple-play, quadruple-play, ?); Multimedia tools (authoring, analyzing, editing, browsing, ?); Computational multimedia intelligence (fuzzy logic, neural networks, genetic algorithms, ?); Intelligent agents for multimedia content creation, distribution, and analysis; Multimedia networking; Wired and wireless multimedia systems; Distributed multimedia systems; Multisensor data integration and fusion; Multimedia and P2P; Multimedia standards Multimedia content and modeling Interfaces for multimedia creation; Multimedia streaming and services; Image modeling and editing; Audio modeling and transformation; Video modeling and transformation; Image recognition; Multimedia databases; Multimedia coding and encryption; Multimedia modeling for learning content; Multimedia description languages; Image clustering; Media fusion for communication and presentation Self-organizing multimedia architectures Self-organization in multimedia systems; Self-organization in multimedia communities; Self-organized multimedia networks; Multimedia content distribution and consumption; Adaptive multimedia interfaces; Multimedia retrieval Multimedia content-based retrieval and analysis Multimodal data analysis; Multimedia databases; Semi-automatic and automatic methods for multimedia annotation; Image/video/audio databases; Content-based image retrieval; Semantics-based search and integration of multimedia and digital content; Multimedia data modeling, indexing, and mining; Statistical modeling of multimedia data; Multimedia extraction and annotation; Content search/browsing/retrieval; Internet imaging and multimedia; Multimodal content analysis; Multimedia abstraction and summarization; Semantic analysis of multimedia data; Media assimilation and fusion Perception and cognition for multimedia users Quality of experience; Relevance feedback; Human-computer interaction; Multimodal interaction; Multimodal user interfaces; Mobile user-centered interfaces; Peer-to-peer multimedia systems and streaming; Pervasive and interactive multimedia systems (digital TV, mobile systems, gaming,?); Multimedia in personal, sensor and ad-hoc networks; Visualization and virtual reality; Intelligent browsing and visualization; Perception and cognition; Perception and modeling of the environment; Multimedia collaboration; Social networking Multimedia ontology Multimedia semantics; Emergent semantics; Media ontology learning; Ontology for media web mining; Multimedia ontologies; Multimedia information management; Approaches using metadata standards; Conceptual clustering; Modeling and recognition of visual objects and actions Mobile and ubiquitous multimedia Architectures, protocols, and algorithms for multimedia mobility; Middleware and distributed computing support for mobile and ubiquitous multimedia; Mobile and ubiquitous multimedia in intelligent transportation systems; Enabling platforms for mobile multimedia; Roaming and limited bandwidth; Intermittent connectivity; Streaming mobile multimedia; Mobile multimedia software architectures; Mobile multimedia applications and services; Communication and cooperation via mobile multimedia; Business models for mobile multimedia; Provisioning of mobile multimedia services; Context-aware mobile and ubiquitous multimedia; Mobile computer graphics, games and entertainment; Mobile and ubiquitous multimedia in ad hoc networks; Personalization, privacy and security in mobile multimedia; Social and regulatory aspects of mobile multimedia; Multimedia in the Extended Home; Ubiquitous/Seamless content sharing Multimedia services Reliability, availability, serviceability of multimedia services; Multimedia content distribution services; Real-time multimedia services; Audio-visual multimedia services; Multimedia signal processing and communications; Media representation and algorithms; Audio, image, video processing, coding and compression; Multimedia database, content delivery and transport; Multimedia service protocols; Mobility of multimedia services; Internet telephony and hypermedia technologies and systems; Media enabled eCommerce service; Case studies, field trials and evaluation of new multimedia services Multimedia applications Real-time interactive multimedia applications Adaptive and context-aware multimedia applications; Ambiance multimedia applications; Media applications on mobile devices; Multi-modal interaction; Virtual environments; Personalization; Collaboration, contextual metadata, collaborative tagging; Web applications; Multimedia authoring; Multimedia-enabled new applications (eLearning, entertainment,?..); Cooperative networks and applications; Mobile multimedia applications & services; Semantic metadata for mobile applications; Semantics enabled multimedia applications; Semantics enabled networks and middleware for multimedia applications; Wireless ad-hoc and sensor networks/RFID applications Industrial use-cases and applications Multimedia security and content protection Multimedia security (watermark, encryption,? ); Mobile multimedia systems and services; Security, privacy, and cryptographic protocols; Network security issues and protocols; Key management and authentication; Authentication and access control; Intrusion detection and prevention; Content protection and digital rights management; Trusted computing; Information hiding; Protection of user-generated content Multimedia control and management Wireless and mobile multimedia network management; Multimedia measurement, control, and management; Content management and delivery; IP multimedia system operations and management; Managing the quality of experience and quality of service; Measuring the quality of performance in multimedia systems; Mobile multimedia network traffic engineering and optimization; Monitoring and managing mobile multimedia; Resource reservation for multimedia services; Multicast and broadcast multimedia service management; Management of service oriented architectures; Pricing, accounting and billing for multimedia services --------------------------- Committee: http://www.iaria.org/conferences2013/ComMMEDIA13.html ================================================ From wwwrun@rfc-editor.org Fri Nov 23 09:50:12 2012 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 4A45821F84DD; Fri, 23 Nov 2012 09:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHwH6p7VNVFd; Fri, 23 Nov 2012 09:50:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8476721F84DB; Fri, 23 Nov 2012 09:50:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5624FB1E002; Fri, 23 Nov 2012 09:42:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121123174238.5624FB1E002@rfc-editor.org> Date: Fri, 23 Nov 2012 09:42:38 -0800 (PST) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6792 on Guidelines for Use of the RTP Monitoring Framework 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, 23 Nov 2012 17:50:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6792 Title: Guidelines for Use of the RTP Monitoring Framework Author: Q. Wu, Ed., G. Hunt, P. Arden Status: Informational Stream: IETF Date: November 2012 Mailbox: sunseawq@huawei.com, r.geoff.hunt@gmail.com, philip.arden@bt.com Pages: 17 Characters: 42473 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtcore-monarch-22.txt URL: http://www.rfc-editor.org/rfc/rfc6792.txt This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From harald@alvestrand.no Sat Nov 24 15:46:18 2012 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 1DF2021F8472 for ; Sat, 24 Nov 2012 15:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKWxfFHrr+wS for ; Sat, 24 Nov 2012 15:46:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37021F846E for ; Sat, 24 Nov 2012 15:46:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1AC939E091 for ; Sun, 25 Nov 2012 00:46:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVe5Wfb8du77 for ; Sun, 25 Nov 2012 00:46:14 +0100 (CET) Received: from [172.30.42.73] (c-f8f1e555.03-217-73746f1.cust.bredbandsbolaget.se [85.229.241.248]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1FBAE39E020 for ; Sun, 25 Nov 2012 00:46:14 +0100 (CET) Message-ID: <50B15C45.8050600@alvestrand.no> Date: Sun, 25 Nov 2012 00:46:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: avt@ietf.org References: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> In-Reply-To: <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 24 Nov 2012 23:46:18 -0000 On 11/19/2012 11:59 PM, Colin Perkins wrote: > This version of the draft updates the recommendations in Section 6 based on discussion with the Security Area Directors. There are no changes in the rest of the draft. Mostly looks OK to me. One thing I did not understand about the new section 6 .... It describes RTP/AVPF as a profile that is an example of where a single security mechanism is not reasonable to mandate, because it's used in many other contexts. I think that's OK - but isn't it true that RTP/AVPF *disallows* the use of SRTP, since it would then be RTP/SAVPF? This can be confusing to the reader - it may be clearer if one mentions explicitly that the RTP/AVPF, which is a set of building blocks that don't need a security mandate, is used to build RTP/SAVPF, which *is* a security mandate. Or am I the one confused? Harald > > Colin > > > On 19 Nov 2012, at 22:51, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. >> >> Title : Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution >> Author(s) : Colin Perkins >> Magnus Westerlund >> Filename : draft-ietf-avt-srtp-not-mandatory-11.txt >> Pages : 10 >> Date : 2012-11-19 >> >> Abstract: >> This memo discusses the problem of securing real-time multimedia >> sessions, and explains why the Real-time Transport Protocol (RTP), >> and the associated RTP control protocol (RTCP), do not mandate a >> single media security mechanism. Guidelines for designers and >> reviewers of future RTP extensions are provided, to ensure that >> appropriate security mechanisms are mandated, and that any such >> mechanisms are specified in a manner that conforms with the RTP >> architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-11 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-avt-srtp-not-mandatory-11 > From magnus.westerlund@ericsson.com Mon Nov 26 00:08:06 2012 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 A103021F85C5 for ; Mon, 26 Nov 2012 00:08:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaV2yfcNY61G for ; Mon, 26 Nov 2012 00:08:05 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 52FEC21F85B1 for ; Mon, 26 Nov 2012 00:08:04 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-4b-50b323636f56 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9E.C0.11564.36323B05; Mon, 26 Nov 2012 09:08:04 +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; Mon, 26 Nov 2012 09:08:04 +0100 Message-ID: <50B32362.6090005@ericsson.com> Date: Mon, 26 Nov 2012 09:08:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Harald Alvestrand References: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> <50B15C45.8050600@alvestrand.no> In-Reply-To: <50B15C45.8050600@alvestrand.no> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3RjdFeXOAwWNZi5c9K9ktjvV1sTkw eVyZcIXVY8mSn0wBTFFcNimpOZllqUX6dglcGf+uzmYpeCNQMWmLUgPjAd4uRk4OCQETiatT vzBC2GISF+6tZ+ti5OIQEjjJKLG1/RczhLOcUeJf02amLkYODl4BbYmH36xAGlgEVCUu/P7G BmKzCVhI3PzRCGaLCvhKzNrziwnE5hUQlDg58wkLiC0ioCPxcH8DWJxZQEDi/9pmdhBbWMBb YkbHAmYQW0hgGqPE/QZukFWcAroSJ7/YQtwmKbFoWicLRKuexJSrLYwQtrxE89bZUK3aEg1N HawTGIVmIdk8C0nLLCQtCxiZVzGy5yZm5qSXG25iBAbpwS2/dXcwnjoncohRmoNFSZyXK2m/ v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG7hzFPVsrZh+4vExyZ9qDa9G+JcdzNPPL2J4b 2N75NuVTj7uIi0fOmi19BvF/ctzTA75fnNUZLya1pONTkXJ6+ise2wJVS8Zvv90Wil75KCf9 PeTmimU9nZY7F97da6c6rUSO+7hs6V3plToTi3Xe7FH/wc93fm/4yai6F5Y1n8411qTsTWJW YinOSDTUYi4qTgQAN7ZI3SACAAA= Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 26 Nov 2012 08:08:06 -0000 Hi Harald, On 2012-11-25 00:46, Harald Alvestrand wrote: > On 11/19/2012 11:59 PM, Colin Perkins wrote: > One thing I did not understand about the new section 6 .... > It describes RTP/AVPF as a profile that is an example of where a single > security mechanism is not reasonable to mandate, because it's used in > many other contexts. > I think that's OK - but isn't it true that RTP/AVPF *disallows* the use > of SRTP, since it would then be RTP/SAVPF? > > This can be confusing to the reader - it may be clearer if one mentions > explicitly that the RTP/AVPF, which is a set of building blocks that > don't need a security mandate, is used to build RTP/SAVPF, which *is* a > security mandate. > > Or am I the one confused? I guess you are getting tripped up on this sentence: In other cases, though, an RTP profile is applicable to such a wide range of applications that it would not make sense for that profile to mandate particular security building blocks be used (the RTP/AVPF profile [RFC4585] is an example of this type of RTP profile, since it provides building blocks that can be used in different styles of application). This is an example why RTP profiles, independent of which profile it may be is not the appropriate level of putting in the mandatory to implement security solution alternative. And frankly SAVPF and SAVP is only half a security mandate, they lack key-management and without a mandatory to implement key-management solution they do not specify a MTI security solution. And if I count correctly in draft-ietf-avtcore-rtp-security-options there are at least 11 options for keying SRTP. 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 harald@alvestrand.no Mon Nov 26 00:49:31 2012 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 205CC21F8482 for ; Mon, 26 Nov 2012 00:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqpStXZWoY7N for ; Mon, 26 Nov 2012 00:49:30 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6B31721F855D for ; Mon, 26 Nov 2012 00:49:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3231A39E13F; Mon, 26 Nov 2012 09:49:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIrBhAj04PRi; Mon, 26 Nov 2012 09:49:25 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 08CE039E01E; Mon, 26 Nov 2012 09:49:24 +0100 (CET) Message-ID: <50B32D14.2030409@alvestrand.no> Date: Mon, 26 Nov 2012 09:49:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Magnus Westerlund References: <20121119225137.6740.64413.idtracker@ietfa.amsl.com> <5119018B-F424-4F1A-AE37-8840169E499C@csperkins.org> <50B15C45.8050600@alvestrand.no> <50B32362.6090005@ericsson.com> In-Reply-To: <50B32362.6090005@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 26 Nov 2012 08:49:31 -0000 On 11/26/2012 09:08 AM, Magnus Westerlund wrote: > Hi Harald, > > > On 2012-11-25 00:46, Harald Alvestrand wrote: >> On 11/19/2012 11:59 PM, Colin Perkins wrote: >> One thing I did not understand about the new section 6 .... >> It describes RTP/AVPF as a profile that is an example of where a single >> security mechanism is not reasonable to mandate, because it's used in >> many other contexts. >> I think that's OK - but isn't it true that RTP/AVPF *disallows* the use >> of SRTP, since it would then be RTP/SAVPF? >> >> This can be confusing to the reader - it may be clearer if one mentions >> explicitly that the RTP/AVPF, which is a set of building blocks that >> don't need a security mandate, is used to build RTP/SAVPF, which *is* a >> security mandate. >> >> Or am I the one confused? > I guess you are getting tripped up on this sentence: > > In other cases, though, > an RTP profile is applicable to such a wide range of applications > that it would not make sense for that profile to mandate particular > security building blocks be used (the RTP/AVPF profile [RFC4585] is > an example of this type of RTP profile, since it provides building > blocks that can be used in different styles of application). > > This is an example why RTP profiles, independent of which profile it may > be is not the appropriate level of putting in the mandatory to implement > security solution alternative. And frankly SAVPF and SAVP is only half a > security mandate, they lack key-management and without a mandatory to > implement key-management solution they do not specify a MTI security > solution. Yes, my opinion of the usefulness of the RTP "profile" field is sometimes acerbic. SAVP(F) mandates use of SRTP, but that gets you only some of the way. > > And if I count correctly in draft-ietf-avtcore-rtp-security-options > there are at least 11 options for keying SRTP. Sigh. > > 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 mcgrew@cisco.com Mon Nov 26 08:18:33 2012 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 748F421F8569 for ; Mon, 26 Nov 2012 08:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSzihKSG6+V6 for ; Mon, 26 Nov 2012 08:18:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2223D21F8567 for ; Mon, 26 Nov 2012 08:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2941; q=dns/txt; s=iport; t=1353946712; x=1355156312; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5puTG7IbdCesLDA7IuDrosD40afW1eRRW/XKYb/IDDo=; b=ixd8VYIGjjahq/EV1lJZueFa6AHcm8+CdiTGrfvlZlEzy30u42ru/d9L s3i7BD4ik2coAQctyu7WtQr52ooyms30a0GmcmD2Egq6I5Jk6Q6rJouHv +2wSwapvW+YQSbB94g8jOwmmIePacFTgkvmzkJ9E5AyUzE2gcw0t//1dh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOuUs1CtJV2Z/2dsb2JhbABEwCIWc4IeAQEBBAEBAQltDgQBCBgKHSIMCxQRAgQBDQUIE4dyDMAJBASMM4NgYQOIKZ4cgm+CHQ X-IronPort-AV: E=McAfee;i="5400,1158,6907"; a="146240312" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Nov 2012 16:18:31 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAQGIV8W015897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Nov 2012 16:18:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 10:18:31 -0600 From: "David McGrew (mcgrew)" To: Harald Alvestrand , Magnus Westerlund Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.txt Thread-Index: AQHNxqiNoXUNT+0BcES/Anm7lwdigpfyKkCAgAfoyoCAAh6JAIAAC48AgAApp4A= Date: Mon, 26 Nov 2012 16:18:31 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F547799@xmb-rcd-x04.cisco.com> In-Reply-To: <50B32D14.2030409@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 26 Nov 2012 16:18:33 -0000 On 11/26/12 3:49 AM, "Harald Alvestrand" wrote: >On 11/26/2012 09:08 AM, Magnus Westerlund wrote: >> Hi Harald, >> >> >> On 2012-11-25 00:46, Harald Alvestrand wrote: >>> On 11/19/2012 11:59 PM, Colin Perkins wrote: >>> One thing I did not understand about the new section 6 .... >>> It describes RTP/AVPF as a profile that is an example of where a single >>> security mechanism is not reasonable to mandate, because it's used in >>> many other contexts. >>> I think that's OK - but isn't it true that RTP/AVPF *disallows* the use >>> of SRTP, since it would then be RTP/SAVPF? >>> >>> This can be confusing to the reader - it may be clearer if one mentions >>> explicitly that the RTP/AVPF, which is a set of building blocks that >>> don't need a security mandate, is used to build RTP/SAVPF, which *is* a >>> security mandate. >>> >>> Or am I the one confused? >> I guess you are getting tripped up on this sentence: >> >> In other cases, though, >> an RTP profile is applicable to such a wide range of applications >> that it would not make sense for that profile to mandate particular >> security building blocks be used (the RTP/AVPF profile [RFC4585] is >> an example of this type of RTP profile, since it provides building >> blocks that can be used in different styles of application). >> >> This is an example why RTP profiles, independent of which profile it may >> be is not the appropriate level of putting in the mandatory to implement >> security solution alternative. And frankly SAVPF and SAVP is only half a >> security mandate, they lack key-management and without a mandatory to >> implement key-management solution they do not specify a MTI security >> solution. >Yes, my opinion of the usefulness of the RTP "profile" field is >sometimes acerbic. >SAVP(F) mandates use of SRTP, but that gets you only some of the way. >> >> And if I count correctly in draft-ietf-avtcore-rtp-security-options >> there are at least 11 options for keying SRTP. >Sigh. Eleven keying method sounds right; that would be DTLS-SRTP, SDP Security Descriptions, EKT, plus the eight different MIKEY methods. Too many options, but not all of them are standards track. David >> >> 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 From hannes.tschofenig@gmx.net Mon Nov 26 09:22:59 2012 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 8332F21F85AB for ; Mon, 26 Nov 2012 09:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YfoxrwyXj7i for ; Mon, 26 Nov 2012 09:22:51 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 701AF21F8554 for ; Mon, 26 Nov 2012 09:22:50 -0800 (PST) Received: (qmail invoked by alias); 26 Nov 2012 17:22:49 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 26 Nov 2012 18:22:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/G+5URHDfG5/KFkmv3syRuFiyi29jT+zRWZYCKAT aZZWanbueqgre1 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F547799@xmb-rcd-x04.cisco.com> Date: Mon, 26 Nov 2012 19:22:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <747787E65E3FBD4E93F0EB2F14DB556B0F547799@xmb-rcd-x04.cisco.com> To: "David McGrew (mcgrew)" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Harald Alvestrand , "avt@ietf.org" , Magnus Westerlund Subject: Re: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-11.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, 26 Nov 2012 17:23:00 -0000 On Nov 26, 2012, at 6:18 PM, David McGrew (mcgrew) wrote: > Eleven keying method sounds right; that would be DTLS-SRTP, SDP = Security > Descriptions, EKT, plus the eight different MIKEY methods. Too many > options, but not all of them are standards track. Given that everyone was (and still is) allowed to publish their favorite = VoIP media key exchange protocol it is a surprise that we only have so = few. Some of the mechanisms have been published in the IETF only because of a = too restrictive registration policy established by the MIKEY RFC. On the other hand, if you look at the deployment then the situation is a = bit different..= From woohwankim@gmail.com Mon Nov 26 18:45:09 2012 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 16F3921F851B for ; Mon, 26 Nov 2012 18:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZebUjZbCDOUO for ; Mon, 26 Nov 2012 18:45:08 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8C21F8745 for ; Mon, 26 Nov 2012 18:45:08 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so9371006iaf.31 for ; Mon, 26 Nov 2012 18:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=yFAsrQda+Tzl30WYIaTdw4SMKu6hSyyIup+m+sj3Ck8=; b=I1OxfeuvY6P5n0E7r1IEmFSCFs9fDuFkXev3UyNCdMzPljoebhd48tzTk5IC25Kguq IKu6maO7ENpnJ+f9BorJN6mi0HECGjVVI0jfKfH9A2xHPRPWdJwy4D4egNsN/rlo6LCg Wa+wPv85qC6hAei/3ZzPTvMsZRU/j5O8Iio+Z/WbTNSQuXcARUQequ/bXg/J9+Pf0iHd 7tfT9KF/7RzrbeDTCYl0P+yi+v8X52HoqJQAFOWflbiwuHrQqBWetMbGLmtLXvUnVjet CziblweVaehxCTefgdEj9iiCsIrw2VeDKSv81N4+knVy9s8WPoSKg8bFaTXwK3qyf0nm +q7g== MIME-Version: 1.0 Received: by 10.50.16.172 with SMTP id h12mr14142178igd.41.1353984307630; Mon, 26 Nov 2012 18:45:07 -0800 (PST) Sender: woohwankim@gmail.com Received: by 10.64.47.163 with HTTP; Mon, 26 Nov 2012 18:45:07 -0800 (PST) Date: Tue, 27 Nov 2012 11:45:07 +0900 X-Google-Sender-Auth: oQnezZ9ANEMoXhgNK_bEp-jP5fI Message-ID: From: Woo-Hwan Kim To: avt@ietf.org, ekr@rtfm.com Content-Type: multipart/alternative; boundary=f46d04428c6eb0118804cf7109cb Cc: Magnus Westerlund , Daesung Kwon , Je Hong Park Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-aria-srtp-00 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, 27 Nov 2012 02:45:09 -0000 --f46d04428c6eb0118804cf7109cb Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review. Both SEED and ARIA were established as KS(Korean Standard) by the Ministry of Knowledge Economy of Korea. But SEED and ARIA have different application areas each other. While SEED is mainly used for for electronic commerce and financial service, ARIA is for government use and public purpose. As the governmental area is growing recently, we need to standardize SRTP-ARIA even though SRTP-SEED is already defined in RFC 5669. As for the ciphersuites, we intended to provide the same funtionality as SRTP-AES. While preparing TLS-ARIA(RFC 6209), we added all the ciphersuites which are defined for TLS-AES in one document following the opinion of TLS ADs. So, we referred to RFC 6188 which defines CM-AES-192/256 and the I.D.(draft-ietf-avtcore-srtp-aes-gcm) on the GCM-AES-128/256 and CCM-AES-128/256. Thanks. Woo-Hwan Kim > Date: Mon, 5 Nov 2012 13:17:02 -0500 > From: Eric Rescorla > To: avt@ietf.org > Subject: [AVTCORE] Review of draft-ietf-avtcore-aria-srtp-00 > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I have reviewed draft-ietf-avtcore-aria-srtp-00. > > I'm leaving aside the question of whether it's useful to define > another symmetric encryption algorithm for SRTP (my view is generally > no, especially since we have already specified SEED) > but the WG seems to have decided that. > > With that said I don't really understand why you are defining three > key sizes and three counter modes. I would recommend defining only 128 > and 256-bit GCM unless there is some actual reason not to. > > Other than that, this seems like a reasonably plausible draft. > > --f46d04428c6eb0118804cf7109cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0Thanks for the review.
=A0
=A0Both SEED and ARIA were establi= shed=20 as KS(Korean Standard) by the Ministry of Knowledge Economy of Korea.
= =A0But=20 SEED and ARIA have different application areas each other.
=A0While SEED= is=20 mainly used for for electronic commerce and financial service, ARIA is for= =20 government use and public purpose.
=A0As the governmental area is growin= g=20 recently,
=A0we need to standardize SRTP-ARIA even though SRTP-SEED is = already=20 defined in RFC 5669.
=A0
=A0As for the ciphersuites, we intended to p= rovide=20 the same funtionality as SRTP-AES.
=A0While preparing TLS-ARIA(RFC 6209)= , we=20 added all the ciphersuites which are defined for TLS-AES in one document=20
=A0following the opinion of TLS ADs.
=A0So, we referred to RFC 6188 = which=20 defines CM-AES-192/256 and the I.D.(draft-ietf-avtcore-srtp-aes-gcm) on the= =20 GCM-AES-128/256 and CCM-AES-128/256.

Thanks.

Woo-Hwan Kim


> Date: Mon, 5 Nov 2012 13:17:02 -0500
> From: Er= ic Rescorla <ekr@rtfm.com>
> To:=A0avt@ietf.org
> Subject: [AVTCORE] Review of dr= aft-ietf-avtcore-aria-srtp-00=
> Message-ID:
> <CABcZeBNWmUYaMZTo5BTN9_YJATNQERrsNpn_CF5Q4FegOwcYP= w@mail.gmail.com>
> Content-Type: text/plain; chars= et=3DISO-8859-1
>
> I have reviewed draft-ietf-avtc= ore-aria-srtp-00.
>
> I'm leaving aside the quest= ion of whether it's useful to define
> another symmetric encryption al= gorithm for SRTP (my view is generally
> no, especially since we have al= ready specified SEED)
> but the WG seems to have decide= d that.
>
> With that said I don't real= ly understand why you are defining three
> key sizes and three counter mod= es. I would recommend defining only 128
> and 256-bit GCM unless there is= some actual reason not to.
>
> Other than that, this seems lik= e a reasonably plausible draft.
>
> --f46d04428c6eb0118804cf7109cb-- From magnus.westerlund@ericsson.com Tue Nov 27 06:20:54 2012 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 E61A421F8425 for ; Tue, 27 Nov 2012 06:20:51 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Uv8pNvaTMmS for ; Tue, 27 Nov 2012 06:20:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD721F841B for ; Tue, 27 Nov 2012 06:20:49 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-ad-50b4cc3feff3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 7B.21.11564.F3CC4B05; Tue, 27 Nov 2012 15:20: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; Tue, 27 Nov 2012 15:20:47 +0100 Message-ID: <50B4CC3E.6070705@ericsson.com> Date: Tue, 27 Nov 2012 15:20:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMJMWRmVeSWpSXmKPExsUyM+Jvja79mS0BBue/aVq87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNa5p9gLzrJVXGjvZ2pg3M/axcjJISFgInHl5h1GCFtM4sK9 9WxdjFwcQgInGSXeT13KAuEsZ5S4vPYUG0gVr4C2xLOFy9hBbBYBVYkbt5eAxdkELCRu/mgE s0UFfCVm7fnFBFEvKHFy5hMWEFtEQElix6RtzCC2sICbRN/TLWwQmyUlFk3rBKthFtCTmHK1 hRHClpdo3jobrF4IaG9DUwfrBEb+WUjGzkLSMgtJywJG5lWM7LmJmTnp5YabGIEBdXDLb90d jKfOiRxilOZgURLn5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBkant7Qav415PPv6Z eljv1NNXG7cLvd70u36hy/zYsrVP2hJTlFbuD1kktPFi8al5/MJa8y1/KkkVLhF33ba1a3dP hmvsJ+nKzTdD7fVWdMlW7WWdbRkZ+Hhz++1i53kJ944vmZLyrm5C2rH1XYqSbM3XOFRivngv XjElvilUbMkX735Pp9mTdyixFGckGmoxFxUnAgCl8hmy9gEAAA== Subject: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 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, 27 Nov 2012 14:20:54 -0000 WG, This announces the WG last call on AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ Please provide any comments no later than the 12th of December. Also comments of the nature of "I have read it and have no comments and think it should be published" are highly valuable. 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 Nov 27 07:07:55 2012 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 B565621F84E4 for ; Tue, 27 Nov 2012 07:07:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL1AhGFFhdMW for ; Tue, 27 Nov 2012 07:07:54 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9221F8428 for ; Tue, 27 Nov 2012 07:07:54 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-f3-50b4d7492755 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 97.D4.26143.947D4B05; Tue, 27 Nov 2012 16:07:53 +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, 27 Nov 2012 16:07:50 +0100 Message-ID: <50B4D747.4090005@ericsson.com> Date: Tue, 27 Nov 2012 16:07:51 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja7n9S0BBkvXa1u87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIbPfAV72SuW3nnC2MA4ha2LkZNDQsBE4uf8OcwQtpjEhXvr geJcHEICJxkl9n8/zgThLGeUuHRjMztIFa+AtsSPdRtZQGwWAVWJOxeusoLYbAIWEjd/NIJN FRXwlZi15xcTRL2gxMmZT8DqRQSUJHZM2ga2TVjATWJn4z4miM2SEoumdYLVMAvoSUy52sII YctLNG+dDVYvBLS3oamDdQIj/ywkY2chaZmFpGUBI/MqRvbcxMyc9HKjTYzAcDq45bfqDsY7 50QOMUpzsCiJ81pv3eMvJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXFigYndf8aG5YkFJQsm qz3zzvy94zzHldCt9VI/Np77FHwjgNlm49o3ub+yG6c9WckZ6tUh9O5NTrapqllmn9YKpv8G 8b0ThYsWMq/sm2UcP1N2DtPfI4a9C73MTC5sUM8JPp896/nds3ECiY/WRpo2tK2OPbI2fuoO +7aVH1dtzVzhrn2EYYISS3FGoqEWc1FxIgDy8htS9QEAAA== Subject: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 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, 27 Nov 2012 15:07:55 -0000 WG, At the IETF 85th meeting's first AVTCORE session we took a hum for adopting Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) (draft-rescorla-avtcore-6222bis-00) as a WG item with the intention to have it replace RFC 6222. I would like to confirm this call for adoption also on the WG mailing list. So people that didn't provided input into this in the meeting please provide your support or objections no later than the 6th of December. 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 Nov 27 07:32:52 2012 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 0109721F84C4 for ; Tue, 27 Nov 2012 07:32:52 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZUhPaO7kJZQ for ; Tue, 27 Nov 2012 07:32:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA821F84C1 for ; Tue, 27 Nov 2012 07:32:51 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-6e-50b4dd2236b7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D1.1C.11564.22DD4B05; Tue, 27 Nov 2012 16:32:50 +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, 27 Nov 2012 16:32:49 +0100 Message-ID: <50B4DD21.4040102@ericsson.com> Date: Tue, 27 Nov 2012 16:32:49 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvja7S3S0BBqs/CVi87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFW7prEVzGOt2DB5LVMD4zqWLkZODgkBE4nPZ/8yQthiEhfu rWfrYuTiEBI4ySix5vY0FghnOaPE3O777CBVvALaEl/XnASyOThYBFQlVp3LAAmzCVhI3PzR yAZiiwr4Ssza84sJolxQ4uTMJ2DLRASUJHZM2sYMYgsLqEncar0PdYSkxKJpnWA2s4CexJSr LYwQtrxE89bZYPVCQGsbmjpYJzDyz0IydhaSlllIWhYwMq9iZM9NzMxJLzfcxAgMp4Nbfuvu YDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjHG3dk5jsOc6sazi lanZBaU9K676rD59xvDAYwXnZz68AfKXPmYGdUxe1LfAPLXIuqOJk1tXoGTB32DB439u3fet UhJoO+d12HNaaJ1hyrk6b5PdOl45d+zaGdWaL27m1lyaxc6w/N1N99n9V77fnSi8X/jHxMnB c98+eVRkqGWzpeTWid/H+ZVYijMSDbWYi4oTAa8CK0X1AQAA Subject: [AVTCORE] Minutes for AVTCORE at IETF85 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, 27 Nov 2012 15:32:52 -0000 WG, Here is the initial version of the minutes. http://www.ietf.org/proceedings/85/minutes/minutes-85-avtcore please review and provide any comments for things you like us to address. 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 adam@nostrum.com Tue Nov 27 08:54:19 2012 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 8101D21F8666 for ; Tue, 27 Nov 2012 08:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5x5qQ4TiZKc for ; Tue, 27 Nov 2012 08:54:19 -0800 (PST) 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 5E9F621F8623 for ; Tue, 27 Nov 2012 08:54:18 -0800 (PST) Received: from host-4-109.mv.mozilla.com (corp-240.mv.mozilla.com [63.245.220.240]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qARGs4GX079203 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 10:54:04 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50B4F026.5080600@nostrum.com> Date: Tue, 27 Nov 2012 08:53:58 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Magnus Westerlund References: <50B4D747.4090005@ericsson.com> In-Reply-To: <50B4D747.4090005@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 63.245.220.240 is authenticated by a trusted mechanism) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 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, 27 Nov 2012 16:54:19 -0000 I support adoption of this document as a working group item. /a On 11/27/12 07:07, Magnus Westerlund wrote: > WG, > > At the IETF 85th meeting's first AVTCORE session we took a hum for > adopting Guidelines for Choosing RTP Control Protocol (RTCP) Canonical > Names (CNAMEs) (draft-rescorla-avtcore-6222bis-00) as a WG item with the > intention to have it replace RFC 6222. > > I would like to confirm this call for adoption also on the WG mailing > list. So people that didn't provided input into this in the meeting > please provide your support or objections no later than the 6th of December. > > 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 From jonathan@vidyo.com Tue Nov 27 09:31:33 2012 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 CDAAA21F8608 for ; Tue, 27 Nov 2012 09:31:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMxsuhOFlGeD for ; Tue, 27 Nov 2012 09:31:33 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9887D21F8647 for ; Tue, 27 Nov 2012 09:31:32 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DE7F18C0C28 for ; Tue, 27 Nov 2012 12:31:31 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 54FFE8BE2F4 for ; Tue, 27 Nov 2012 12:31:06 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 27 Nov 2012 12:30:49 -0500 From: Jonathan Lennox To: IETF AVTCore WG Date: Tue, 27 Nov 2012 12:31:05 -0500 Thread-Topic: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 Thread-Index: Ac3MwevKDV9SQEkUR6uil24H/A5mtw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 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, 27 Nov 2012 17:31:34 -0000 I have read the draft. It would be useful to have test vectors for the various algorithms, for imp= lementers to validate their implementations. The draft needs to specify how header extension encryption (as specified in= draft-ietf-avtcore-srtp-encrypted-header-ext) is to be done when using the= AES-GCM and AES-CCM algorithms. I believe the consensus was that it should be done using the equivalent CTR= -mode encryption transform, so I'd suggest adding something like the follow= ing text to this draft: [Section Number]. Header Extension Encryption. When RTP Header Extension Encryption [I-D.ietf-avtcore-srtp-encrypted-heade= r-ext] is in use, a separate keystream is generated to encrypt selected RTP= header extension elements. For the AEAD_AES_128_GCM and the AEAD_AES_128_= CCM algorithms, this keystream MUST be generated in the manner defined in [= I-D.ietf-avtcore-srtp-encrypted-header-ext] for the AES_128_CM transform. = For the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, the keystream= MUST be generated in the manner defined for the AES_256_CM transform. -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, November 27, 2012 9:21 AM To: IETF AVTCore WG Subject: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-g= cm-03 WG, This announces the WG last call on AES-GCM and AES-CCM Authenticated Encryp= tion in Secure RTP (SRTP) https://datatracker.ietf.org/doc/draft-ietf-avtco= re-srtp-aes-gcm/ Please provide any comments no later than the 12th of December. Also commen= ts of the nature of "I have read it and have no comments and think it shoul= d be published" are highly valuable. 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 From mcgrew@cisco.com Tue Nov 27 09:47:31 2012 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 0629621F85AD for ; Tue, 27 Nov 2012 09:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMOe+vA6KamX for ; Tue, 27 Nov 2012 09:47:30 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC321F8589 for ; Tue, 27 Nov 2012 09:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2730; q=dns/txt; s=iport; t=1354038450; x=1355248050; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=AN9hIXtTgTL/RB/qpnEUNqZM4hzPLoTh2Jwu5O/VZJM=; b=HeFK+/yg4iD9uBniulvl15RhtWWlDI8XG+/3XjMu9qXMklUoEtfNUG+s Ps55Wa1E9u7lfhOt5n5tGmy96Zai/GfCzd83BiPDuyy7OskONFl7tOiYY TfhKR5hKbKY6EaWnMw4kls8TYY6pS3A4wWSjRHdEykycPrWtIc9bcYz38 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD38tFCtJXG+/2dsb2JhbABFwB4Wc4IeAQEBBAEBAQl5AgQBCBEEAQELHSIMCxQJCAEBBAESCIgFDLAskEUEBIw2g2BhA4gpnhyCcIFkJBg X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146515669" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2012 17:47:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qARHlTSw027563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 17:47:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.66]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 11:47:29 -0600 From: "David McGrew (mcgrew)" To: Jonathan Lennox , IETF AVTCore WG Thread-Topic: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 Thread-Index: Ac3MwevKDV9SQEkUR6uil24H/A5mtwADbkUA Date: Tue, 27 Nov 2012 17:47:28 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F54AA5C@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 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, 27 Nov 2012 17:47:31 -0000 Thanks Jonathan for the review and suggested text. I agree about the header extension encryption. David On 11/27/12 12:31 PM, "Jonathan Lennox" wrote: >I have read the draft. > >It would be useful to have test vectors for the various algorithms, for >implementers to validate their implementations. > >The draft needs to specify how header extension encryption (as specified >in draft-ietf-avtcore-srtp-encrypted-header-ext) is to be done when using >the AES-GCM and AES-CCM algorithms. > >I believe the consensus was that it should be done using the equivalent >CTR-mode encryption transform, so I'd suggest adding something like the >following text to this draft: > >[Section Number]. Header Extension Encryption. > >When RTP Header Extension Encryption >[I-D.ietf-avtcore-srtp-encrypted-header-ext] is in use, a separate >keystream is generated to encrypt selected RTP header extension elements. > For the AEAD_AES_128_GCM and the AEAD_AES_128_CCM algorithms, this >keystream MUST be generated in the manner defined in >[I-D.ietf-avtcore-srtp-encrypted-header-ext] for the AES_128_CM >transform. For the AEAD_AES_256_GCM and the AEAD_AES_256_CCM algorithms, >the keystream MUST be generated in the manner defined for the AES_256_CM >transform. > >-----Original Message----- >From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >Sent: Tuesday, November 27, 2012 9:21 AM >To: IETF AVTCore WG >Subject: [AVTCORE] Working group last call on >draft-ietf-avtcore-srtp-aes-gcm-03 > >WG, > >This announces the WG last call on AES-GCM and AES-CCM Authenticated >Encryption in Secure RTP (SRTP) >https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ > >Please provide any comments no later than the 12th of December. Also >comments of the nature of "I have read it and have no comments and think >it should be published" are highly valuable. > >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 > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt From eckelcu@cisco.com Tue Nov 27 13:21:38 2012 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 D224621F846A for ; Tue, 27 Nov 2012 13:21:38 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXVy4JzwCoLZ for ; Tue, 27 Nov 2012 13:21:38 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6C21F8468 for ; Tue, 27 Nov 2012 13:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1820; q=dns/txt; s=iport; t=1354051298; x=1355260898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qFOlBFmETqG9guEUboPtt0RaAOzciubHICMq12rmz9E=; b=mgDAwU9qAx+pVjStzZk/X5wdCO7ldtr6kSQBWxOQUgE1M5bqZN980yeU cWcSWVwLOp0xVp7dkJI5dgapNbD6UEBxoxWxpJ2ZHVa3g4TberMtl0Fu4 Bn6GQsJADyxkYbOx8s/4w19hvcY3L2IEtsycoIEBIzIuv7OEX8eNPLKdn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAA4utVCtJXHA/2dsb2JhbABFwB4Wc4IeAQEBBAEBAQkRUQsMAgICAQgRBAEBAQodBxsMCxQJCAIEAQ0FCIgEAQyvWpA4BASMNoNgYQOIKZ4cgnCCIA X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146855085" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 27 Nov 2012 21:21:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qARLLbkt027150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 21:21:37 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.65]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 15:21:37 -0600 From: "Charles Eckel (eckelcu)" To: Adam Roach , Magnus Westerlund Thread-Topic: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 Thread-Index: AQHNzLEAxbel5Vak80mSdzEjwQtx+Jf+SskA///mJ1A= Date: Tue, 27 Nov 2012 21:21:36 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046CA5A4@xmb-aln-x08.cisco.com> References: <50B4D747.4090005@ericsson.com> <50B4F026.5080600@nostrum.com> In-Reply-To: <50B4F026.5080600@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 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, 27 Nov 2012 21:21:38 -0000 +1 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Adam Roach > Sent: Tuesday, November 27, 2012 8:54 AM > To: Magnus Westerlund > Cc: IETF AVTCore WG > Subject: Re: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore= - > 6222bis-00 >=20 > I support adoption of this document as a working group item. >=20 > /a >=20 > On 11/27/12 07:07, Magnus Westerlund wrote: > > WG, > > > > At the IETF 85th meeting's first AVTCORE session we took a hum for > > adopting Guidelines for Choosing RTP Control Protocol (RTCP) Canonical > > Names (CNAMEs) (draft-rescorla-avtcore-6222bis-00) as a WG item with > the > > intention to have it replace RFC 6222. > > > > I would like to confirm this call for adoption also on the WG mailing > > list. So people that didn't provided input into this in the meeting > > please provide your support or objections no later than the 6th of > December. > > > > 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 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From csp@csperkins.org Tue Nov 27 14:22:06 2012 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 4968721F8665 for ; Tue, 27 Nov 2012 14:22:06 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-39IncWSYQd for ; Tue, 27 Nov 2012 14:22:04 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9540821F8639 for ; Tue, 27 Nov 2012 14:21:56 -0800 (PST) Received: from [80.176.158.71] (helo=[192.168.0.11]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TdTXO-0006Aq-D7; Tue, 27 Nov 2012 22:21:54 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <50B4D747.4090005@ericsson.com> Date: Tue, 27 Nov 2012 22:21:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6C9C42CA-DEA5-44A5-B3E5-5C65D4374C87@csperkins.org> References: <50B4D747.4090005@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -14 X-Mythic-Debug: Threshold = On = Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 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, 27 Nov 2012 22:22:06 -0000 On 27 Nov 2012, at 15:07, Magnus Westerlund wrote: > At the IETF 85th meeting's first AVTCORE session we took a hum for > adopting Guidelines for Choosing RTP Control Protocol (RTCP) Canonical > Names (CNAMEs) (draft-rescorla-avtcore-6222bis-00) as a WG item with = the intention to have it replace RFC 6222. >=20 > I would like to confirm this call for adoption also on the WG mailing > list. So people that didn't provided input into this in the meeting > please provide your support or objections no later than the 6th of = December. I have read the draft, and support it being adopted as a working draft = item. --=20 Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Tue Nov 27 22:40:24 2012 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 A767021F8442 for ; Tue, 27 Nov 2012 22:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVQdKBCsq6zW for ; Tue, 27 Nov 2012 22:40:24 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C80B821F8879 for ; Tue, 27 Nov 2012 22:40:23 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so2517417wgb.13 for ; Tue, 27 Nov 2012 22:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=Sep/90p51MTEfJSC14QdqhjFIPrAISsSzUHh1c3zlFA=; b=jbQQpHxKtNWWP6po4qUErl+dbZf57LPKoyX2zC114GGMlku/M6yzuP4PBf73SlNvc2 /ozFOcUM3vyWwBo+PaE9ZzWXxLZTfAe/FXlMtvAMK7rjN4kmXneqXIuqs2mJQQEN03QO CU5ZdG0BzFBvG0lK8kTV7QeWbOL7Hm7tXd34wrvB/jxn6/zDFu54FU8ylhHmx6V9m1Qy 3BtF5hPFYjq/9YDx2UOvt6bYaePb9StESQxzVMxWc/tjdB1x2sDy65k9fUN2CejbgcHH jc+DUJx9Krxx0djkK2K/ascywEjeg07uaS1TKzH9tMvj4LebP+jsZufwzzIJEPFIrFvH SkUA== Received: by 10.216.200.89 with SMTP id y67mr5780053wen.208.1354084819496; Tue, 27 Nov 2012 22:40:19 -0800 (PST) Received: from RoniE ([109.64.71.197]) by mx.google.com with ESMTPS id ey2sm6344313wib.9.2012.11.27.22.40.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 22:40:18 -0800 (PST) From: "Roni Even" To: Date: Wed, 28 Nov 2012 08:37:43 +0200 Message-ID: <04b701cdcd32$e18c2750$a4a475f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B8_01CDCD43.A5156C80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3NMr6FWNMq2fV1TbiWYfaPrC+jfQ== Content-Language: en-us Subject: [AVTCORE] confirmation of adoption of draft-terriberry-avp-codecs-00 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, 28 Nov 2012 06:40:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B8_01CDCD43.A5156C80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WG, At the IETF 85th meeting's second AVTCORE session we took a hum for adopting Update to Recommended Codecs for the AVP RTP Profile (draft-terriberry-avp-codecs-00) as a WG item with the intention to update RFC3551. I would like to confirm this call for adoption also on the WG mailing list. So people that didn't provided input into this in the meeting please provide your support or objections no later than December 10th. Thanks Roni ------=_NextPart_000_04B8_01CDCD43.A5156C80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

At the =
IETF 85th meeting's second AVTCORE session we took a hum for adopting =
Update to =
Recommended Codecs for the AVP RTP Profile

(draft-terriberry-avp-codecs-00) as a WG item with = the intention to update  RFC3551.

 

I = would like to confirm this call for adoption also on the WG mailing = list. So people that didn't provided input into this in the meeting = please provide your support or objections no later than December = 10th.

 

Thanks

Roni

------=_NextPart_000_04B8_01CDCD43.A5156C80-- From wwwrun@rfc-editor.org Wed Nov 28 06:39:40 2012 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 6C65F21F8810 for ; Wed, 28 Nov 2012 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxsSrC7z2OWL for ; Wed, 28 Nov 2012 06:39:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EDF4C21F87B0 for ; Wed, 28 Nov 2012 06:39:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E05F3B1E004; Wed, 28 Nov 2012 06:31:49 -0800 (PST) To: mbaugher@cisco.com, elisabetta.carrara@ericsson.com, mcgrew@cisco.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20121128143149.E05F3B1E004@rfc-editor.org> Date: Wed, 28 Nov 2012 06:31:49 -0800 (PST) X-Mailman-Approved-At: Wed, 28 Nov 2012 08:34:41 -0800 Cc: matthias.schertler@gmx.net, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [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: Wed, 28 Nov 2012 14:39:40 -0000 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 bill.wu@huawei.com Wed Nov 28 16:51:01 2012 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 0AD3821F8438 for ; Wed, 28 Nov 2012 16:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZf8y0w+AcOZ for ; Wed, 28 Nov 2012 16:51:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB221F8431 for ; Wed, 28 Nov 2012 16:50:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANH72500; Thu, 29 Nov 2012 00:50:58 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 00:49:54 +0000 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 08:50:05 +0800 Received: from w53375 (10.138.41.149) by szxeml462-hub.china.huawei.com (10.82.67.205) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Nov 2012 08:49:57 +0800 Message-ID: From: Qin Wu To: Magnus Westerlund References: <50B4D747.4090005@ericsson.com> <6C9C42CA-DEA5-44A5-B3E5-5C65D4374C87@csperkins.org> Date: Thu, 29 Nov 2012 08:49:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Confirmation of adoption ofdraft-rescorla-avtcore-6222bis-00 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, 29 Nov 2012 00:51:01 -0000 U3VwcG9ydC4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQ29saW4gUGVy a2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPg0KVG86ICJNYWdudXMgV2VzdGVybHVuZCIgPG1hZ251 cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCkNjOiAiSUVURiBBVlRDb3JlIFdHIiA8YXZ0QGll dGYub3JnPg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxMiA2OjIxIEFNDQpTdWJq ZWN0OiBSZTogW0FWVENPUkVdIENvbmZpcm1hdGlvbiBvZiBhZG9wdGlvbiBvZmRyYWZ0LXJlc2Nv cmxhLWF2dGNvcmUtNjIyMmJpcy0wMA0KDQoNCj4gT24gMjcgTm92IDIwMTIsIGF0IDE1OjA3LCBN YWdudXMgV2VzdGVybHVuZCB3cm90ZToNCj4+IEF0IHRoZSBJRVRGIDg1dGggbWVldGluZydzIGZp cnN0IEFWVENPUkUgc2Vzc2lvbiB3ZSB0b29rIGEgaHVtIGZvcg0KPj4gYWRvcHRpbmcgR3VpZGVs aW5lcyBmb3IgQ2hvb3NpbmcgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIENhbm9uaWNhbA0K Pj4gTmFtZXMgKENOQU1FcykgKGRyYWZ0LXJlc2NvcmxhLWF2dGNvcmUtNjIyMmJpcy0wMCkgYXMg YSBXRyBpdGVtIHdpdGggdGhlIGludGVudGlvbiB0byBoYXZlIGl0IHJlcGxhY2UgUkZDIDYyMjIu DQo+PiANCj4+IEkgd291bGQgbGlrZSB0byBjb25maXJtIHRoaXMgY2FsbCBmb3IgYWRvcHRpb24g YWxzbyBvbiB0aGUgV0cgbWFpbGluZw0KPj4gbGlzdC4gU28gcGVvcGxlIHRoYXQgZGlkbid0IHBy b3ZpZGVkIGlucHV0IGludG8gdGhpcyBpbiB0aGUgbWVldGluZw0KPj4gcGxlYXNlIHByb3ZpZGUg eW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbnMgbm8gbGF0ZXIgdGhhbiB0aGUgNnRoIG9mIERlY2Vt YmVyLg0KPiANCj4gDQo+IEkgaGF2ZSByZWFkIHRoZSBkcmFmdCwgYW5kIHN1cHBvcnQgaXQgYmVp bmcgYWRvcHRlZCBhcyBhIHdvcmtpbmcgZHJhZnQgaXRlbS4NCj4gDQo+IC0tIA0KPiBDb2xpbiBQ ZXJraW5zDQo+IGh0dHA6Ly9jc3BlcmtpbnMub3JnLw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPiBhdnRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ=