From internet-drafts@ietf.org Mon Feb 4 10:14:55 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1F421F8AB6; Mon, 4 Feb 2013 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 sQQntS-KZdSm; Mon, 4 Feb 2013 10:14:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836521F8A72; Mon, 4 Feb 2013 10:14:54 -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.37 Message-ID: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 10:14:54 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-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: Mon, 04 Feb 2013 18:14:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure R= TP (SRTP) Author(s) : David A. McGrew Kevin M. Igoe Filename : draft-ietf-avtcore-srtp-aes-gcm-04.txt Pages : 28 Date : 2013-02-04 Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jonathan@vidyo.com Mon Feb 4 15:00:12 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E3C21F89CE for ; Mon, 4 Feb 2013 15:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.465 X-Spam-Level: X-Spam-Status: No, score=-1.465 tagged_above=-999 required=5 tests=[AWL=1.134, 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 XbS8RRpWTmVk for ; Mon, 4 Feb 2013 15:00:12 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 36CC421F8B58 for ; Mon, 4 Feb 2013 15:00:12 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 98B987A3AE3 for ; Mon, 4 Feb 2013 17:31:31 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 29B697A3A28 for ; Mon, 4 Feb 2013 17:31:31 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 4 Feb 2013 18:00:11 -0500 From: Jonathan Lennox To: IETF AVTCore WG Date: Mon, 4 Feb 2013 18:00:10 -0500 Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-04.txt Thread-Index: Ac4DK2F0PJQ1DoW0Q/6gsstHgzDJYg== Message-ID: <461FB470-9F33-4B72-BDCC-402E44208789@vidyo.com> References: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> In-Reply-To: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> 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: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-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: Mon, 04 Feb 2013 23:00:12 -0000 This new version still doesn't appear to have any text about header extensi= on encryption. Is there a reason this was omitted? On Feb 4, 2013, at 1:14 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Core Maintenance W= orking Group of the IETF. >=20 > Title : AES-GCM and AES-CCM Authenticated Encryption in Secure= RTP (SRTP) > Author(s) : David A. McGrew > Kevin M. Igoe > Filename : draft-ietf-avtcore-srtp-aes-gcm-04.txt > Pages : 28 > Date : 2013-02-04 >=20 > Abstract: > This document defines how AES-GCM and AES-CCM Authenticated > Encryption with Associated Data algorithms can be used to provide > confidentiality and data authentication in the SRTP protocol. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 -- Jonathan Lennox jonathan@vidyo.com From ron.even.tlv@gmail.com Fri Feb 8 03:33:45 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7B621F8806 for ; Fri, 8 Feb 2013 03:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=0.932, 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 1GdRrZv1wLKl for ; Fri, 8 Feb 2013 03:33:44 -0800 (PST) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4747121F87FA for ; Fri, 8 Feb 2013 03:33:44 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id a12so1602903eaa.27 for ; Fri, 08 Feb 2013 03:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=eE15DbxcDInRX0kJ4P6jbexeSX0freFw78vaHmTHPuA=; b=lBxDc2t/WKJenKgUzaoF8E3tfl0bfaFV2pFi/zN4JjnSrWNkLfrbs/ASSCmm86UYq8 /RihKJ5TSlBKydA16CY2H/Z6f+lGbTRRggtcS1I8pYF175HVMswtub5vmU5vQeuPMO9/ bgWPkJaTsGJF7SbURExeQ2lhgMa4BAFc9rzeWgTwwOOOMzkj3rv4Yi7mProf+0dUx+sm Vg4ixn7j/UMqZwP/CGonrmgKRbMEMq5+aZpqg4SzNYJ7cYZc0vJsNoe3f+8pvQAQ3r2k 2a0fJa5avJIK6XLltJqRs5+hjS42xXXTAOLqb+HRGRftselFWteZQri67k6VIxOe2NYS 4+FA== X-Received: by 10.14.174.197 with SMTP id x45mr15191627eel.5.1360323223380; Fri, 08 Feb 2013 03:33:43 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id q42sm37580909eem.14.2013.02.08.03.33.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Feb 2013 03:33:41 -0800 (PST) From: "Roni Even" To: Date: Fri, 8 Feb 2013 13:30:50 +0200 Message-ID: <05df01ce05ef$c1406ab0$43c14010$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E0_01CE0600.84C9FE00" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4F778oIviUUR4KTG2SvV3F7sTw/A== Content-Language: en-us Subject: [AVTCORE] AVTcore sessions in Orlando (IETF86) - preliminary agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 11:33:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05E0_01CE0600.84C9FE00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please also send the WG chairs requests for agenda time. avtcore Session 1 (2:00:00) Tuesday, Afternoon Session I 1300-1500 Room Name: Caribbean 4 --------------------------------------------- avtcore Session 2 (1:00:00) Thursday, Afternoon Session III 1740-1840 Room Name: Caribbean 5 --------------------------------------------- Other important dates to note: * 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool . * 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool . * 2013-02-27 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . Thanks Roni Even AVTcore co-chair ------=_NextPart_000_05E0_01CE0600.84C9FE00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please also = send the WG chairs requests for agenda time.

 

    avtcore Session 1 = (2:00:00)

    = Tuesday, Afternoon Session I 1300-1500

    Room Name: Caribbean = 4

    = ---------------------------------------------

    avtcore Session 2 = (1:00:00)

    = Thursday, Afternoon Session III 1740-1840

    Room Name: Caribbean = 5

    = ---------------------------------------------

 

Other = important dates to note:

 

 

Thanks

Roni = Even

AVTcore = co-chair

 

------=_NextPart_000_05E0_01CE0600.84C9FE00-- From kmigoe@nsa.gov Fri Feb 8 08:11:45 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD83E21F8AC3 for ; Fri, 8 Feb 2013 08:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YKeTa5Dmw8uG for ; Fri, 8 Feb 2013 08:11:30 -0800 (PST) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id A29D121F8ADB for ; Fri, 8 Feb 2013 08:11:29 -0800 (PST) X-TM-IMSS-Message-ID: <1a058a8d00070014@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 1a058a8d00070014 ; Fri, 8 Feb 2013 11:12:11 -0500 Received: from MSMR-GH1-UEA05.corp.nsa.gov (10.215.228.28) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 8 Feb 2013 11:11:25 -0500 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA05.corp.nsa.gov ([10.215.228.28]) with mapi id 14.01.0289.001; Fri, 8 Feb 2013 11:11:24 -0500 From: "Igoe, Kevin M." To: 'Jonathan Lennox' , IETF AVTCore WG Thread-Topic: header extensions and draft-ietf-avtcore-srtp-aes-gcm-04.txt Thread-Index: AQHOBhbwHlJ7EBP010qUNWkgdxexEQ== Date: Fri, 8 Feb 2013 16:11:23 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8@MSMR-GH1-UEA03.corp.nsa.gov> References: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> <461FB470-9F33-4B72-BDCC-402E44208789@vidyo.com> <3C4AAD4B5304AB44A6BA85173B4675CA69669890@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.153] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8MSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: [AVTCORE] header extensions and draft-ietf-avtcore-srtp-aes-gcm-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: Fri, 08 Feb 2013 16:11:46 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8MSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the header extensions are to use the same key as the AEAD but with different salts, I've got a problem with preventing IV reuse. Currently the IV's are formed by 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | SRTP Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ Figure 1: AES-GCM and AES-CCM SRTP Initialization Vector formation. and your proposal for header extensions seems to call for the IV to be 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ We MUST insure the IV's are all distinct, so even between packets with different SSRC, ROC and SEQ we must insure base_0 XOR SRTP_SALT !=3D base_1 XOR HE_SALT_1 where base_i =3D 0x0000 || SSRC_i || ROC_i || SEQ_i. We have a problem whenever HE_SALT XOR SRTP_SALT =3D base_0 XOR base_1. I believe we can avoid this by playing games with the most significant bytes of the SALT {and hence of the IV, since he base starts with 0x00). For SRTP, force the msB of the SRTP salt to be 0x0000 by taking the msB of the SRTP salt to be 0x00: 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |00| SRTP Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | SRTP Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ so the high order byte of the IV is 0x00, When we are using a 1-byte extentsion element headers, the extension starts with the byte HH =3D ID ||L (both ID and L are 4 bits each), so we proceed as below: 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |HH| HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ so the first nibble of the IV is the ID. For 2-byte extension headers, we have an 8-bit ID, so we use 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |ID| HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ and hence the first byte of the IV is the ID. Since the ID is never allowed to be zero, and recalling that a given session never mixes 1-byte and 2-byte extensions, the inclusion of the ID directly in the IV insures all of the IV's are distinct. I presume the ID and length fields are to be sent in the clear? I'd recommend that AEAD treat them as AAD. Indeed, it would be prudent to have AEAD treat the encrypted header extension data field as AAD. This eliminates all sorts of potential spoofing attack worries. What do you think? From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Wednesday, February 06, 2013 5:23 PM To: Igoe, Kevin M. Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-04.txt Sorry, I was probably too brief in my comment. I was specifically referrin= g to draft-ietf-avtcore-srtp-encrypted-header-ext (currently in AD review),= which works out all these issues but adds a requirement that new SRTP encr= yption transforms define how they generate the encrypted header keystream. I've attached my e-mail exchange with David from the aes-gcm WGLC, which in= cludes text I proposed be added to the aes-gcm draft. On Feb 6, 2013, at 3:44 PM, Igoe, Kevin M. wrote: > I'm not sure I understand header extensions well enough to come up with > a "one size fits all" solution. Which parts are to be treated as PT > to be encrypted and authenticated, which as additional authenticated data > to be only authenticated, and which as raw data? Will this change form > one flavor of extension to another? I hope to tap your expertise on > these points. > > RFC 5283 talks about the presence and format of a header extension being > negotiated out-of-band. The best solution I can think of is that this > out-of-band negotiation should also decide how AEAD will treat the variou= s > fields in the header extension. If that is sufficient for our needs, the= n > I believe we can add that in w/o too much trouble. But I really don't wa= nt > to get bogged down in how the out-of-band negotiation is to be done. > > Another point I'd like your input on: does the requirement that the AEAD > authentication tag MUST be validated before any of the cipher is decrypte= d > or any of the AAD be processed in any way cause problems for existing hea= der > extensions? > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Jonathan Lennox >> Sent: Monday, February 04, 2013 6:00 PM >> To: IETF AVTCore WG >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm- >> 04.txt >> >> This new version still doesn't appear to have any text about header >> extension encryption. Is there a reason this was omitted? >> >> On Feb 4, 2013, at 1:14 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 : AES-GCM and AES-CCM Authenticated Encryption in >> Secure RTP (SRTP) >>> Author(s) : David A. McGrew >>> Kevin M. Igoe >>> Filename : draft-ietf-avtcore-srtp-aes-gcm-04.txt >>> Pages : 28 >>> Date : 2013-02-04 >>> >>> Abstract: >>> This document defines how AES-GCM and AES-CCM Authenticated >>> Encryption with Associated Data algorithms can be used to provide >>> confidentiality and data authentication in the SRTP protocol. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-04 >>> >>> >>> 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 >>> >> >> -- >> Jonathan Lennox >> jonathan@vidyo.com >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt -- Jonathan Lennox jonathan@vidyo.com --_000_3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8MSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the header extensions are to use the same= key as the

AEAD but with different salts, I’ve go= t a problem with

preventing IV reuse.  Currently the IV&= #8217;s are formed by

 

       &n= bsp;       0  0  0  0  0&= nbsp; 0  0  0  0  0  1  1

       &n= bsp;       0  1  2  3  4&= nbsp; 5  6  7  8  9  0  1

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;     |00|00|    SSRC   |&n= bsp;    ROC   | SEQ |---+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

        &= nbsp;    |      SRTP Encryptio= n Salt         |->(+)

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;     |       Initiali= zation Vector       |<--+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

 

       &n= bsp;   Figure 1: AES-GCM and AES-CCM SRTP

       &n= bsp;            = ; Initialization Vector formation.

 

and your proposal for header extensions seem= s to call for

the IV to be

 

       &n= bsp;       0  0  0  0  0&= nbsp; 0  0  0  0  0  1  1

       &n= bsp;       0  1  2  3  4&= nbsp; 5  6  7  8  9  0  1

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;     |00|00|    SSRC   |&n= bsp;    ROC   | SEQ |---+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

        &= nbsp;    |       HE Encry= ption Salt          |->(= 3;)

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;     |       Initiali= zation Vector       |<--+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

 

We MUST insure the IV’s are all distin= ct, so even between packets

with different SSRC, ROC and SEQ we must ins= ure

 

     base_0 XOR SRTP_SAL= T !=3D base_1 XOR HE_SALT_1

 

where base_i =3D 0x0000 || SSRC_i || ROC_i |= | SEQ_i.

 

We have a problem whenever HE_SALT XOR SRTP_= SALT =3D base_0 XOR base_1.

 

I believe we can avoid this by playing games= with the most significant

bytes of the SALT {and hence of the IV, sinc= e he base starts with 0x00). 

 

For SRTP, force the msB of the SRTP salt to = be 0x0000 by taking

the msB of the SRTP salt to be 0x00:

 

       &n= bsp;       0  0  0  0  0&= nbsp; 0  0  0  0  0  1  1

       &n= bsp;       0  1  2  3  4&= nbsp; 5  6  7  8  9  0  1

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;     |00|00|    SSRC   |&n= bsp;    ROC   | SEQ |---+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

        &= nbsp;    |00|     SRTP Encryption S= alt        |->(+)

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;     |    SRTP Initialization Vector=      |<--+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

 

so the high order byte of the IV is 0x00,

 

When we are using a 1-byte extentsion elemen= t headers,

the extension starts with the byte HH =3D ID= ||L (both ID

and L are 4 bits each), so we proceed as bel= ow:

 

       &n= bsp;       0  0  0  0  0&= nbsp; 0  0  0  0  0  1  1

       &n= bsp;       0  1  2  3  4&= nbsp; 5  6  7  8  9  0  1

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;     |00|00|    SSRC   |&n= bsp;    ROC   | SEQ |---+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

        &= nbsp;    |HH|     HE Encryption Sal= t         |->(+)<= /span>

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;     |    HE Initialization Vector&n= bsp;      |<--+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

 

so the first nibble of the IV is the ID.

 

For 2-byte extension headers, we have an 8-b= it ID, so we use

 

 

       &n= bsp;       0  0  0  0  0&= nbsp; 0  0  0  0  0  1  1

       &n= bsp;       0  1  2  3  4&= nbsp; 5  6  7  8  9  0  1

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;     |00|00|    SSRC   |&n= bsp;    ROC   | SEQ |---+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

        &= nbsp;    |ID|     HE Encryption Sal= t         |->(+)<= /span>

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;            = ;            &n= bsp;            = ;        |

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+   |=

       &n= bsp;     |    HE Initialization Vector&n= bsp;      |<--+

       &n= bsp;     +--+--+--+--+--+--+= ;--+--+--+--+--+--+

       &n= bsp;      

and hence the first byte of the IV is the ID= .

 

Since the ID is never allowed to be zero, an= d recalling that a given

session never mixes 1-byte and 2-byte extens= ions, the inclusion of the ID

directly in the IV insures all of the IVR= 17;s are distinct.

 

I presume the ID and length fields are to be= sent in the clear?

I’d recommend that AEAD treat them as = AAD.  Indeed, it would be

prudent to have AEAD treat the encrypted hea= der extension data

field as AAD.  This eliminates all sort= s of potential spoofing

attack worries.

 

What do you think?

 

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Jonathan= Lennox [mailto:jonathan@vidyo.com]
Sent: Wednesday, February 06, 2013 5:23 PM
To: Igoe, Kevin M.
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-0= 4.txt

 

Sorry, I was probably too brief in my comment.  I was spec= ifically referring to draft-ietf-avtcore-srtp-encrypted-header-ext (current= ly in AD review), which works out all these issues but adds a requirement that new SRTP encryption transforms define h= ow they generate the encrypted header keystream.

I've attached my e-mail exchange with David from the aes-gcm WGLC, which in= cludes text I proposed be added to the aes-gcm draft.



On Feb 6, 2013, at 3:44 PM, Igoe, Kevin M. wrote:

> I'm not sure I understand header extensions well enough to come up wit= h
> a "one size fits all" solution.  Which parts are to be = treated as PT
> to be encrypted and authenticated, which as additional authenticated d= ata
> to be only authenticated, and which as raw data?  Will this chang= e form
> one flavor of extension to another?  I hope to tap your expertise= on
> these points.
>
> RFC 5283 talks about the presence and format of a header extension bei= ng
> negotiated out-of-band.  The best solution I can think of is that= this
> out-of-band negotiation should also decide how AEAD will treat the var= ious
> fields in the header extension.  If that is sufficient for our ne= eds, then
> I believe we can add that in w/o too much trouble.  But I really = don't want
> to get bogged down in how the out-of-band negotiation is to be done. >
> Another point I'd like your input on: does the requirement that the AE= AD
> authentication tag MUST be validated before any of the cipher is decry= pted
> or any of the AAD be processed in any way cause problems for existing = header
> extensions?
>
>> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
>> Jonathan Lennox
>> Sent: Monday, February 04, 2013 6:00 PM
>> To: IETF AVTCore WG
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm= -
>> 04.txt
>>
>> This new version still doesn't appear to have any text about heade= r
>> extension encryption.  Is there a reason this was omitted? >>
>> On Feb 4, 2013, at 1:14 PM, <internet-drafts@ietf.org> wrote= :
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Audio/Video Transport Core >> Maintenance Working Group of the IETF.
>>>
>>>      Title    &nb= sp;      : AES-GCM and AES-CCM Authenticated Encry= ption in
>> Secure RTP (SRTP)
>>>      Author(s)    = ;   : David A. McGrew
>>>          &nb= sp;            =   Kevin M. Igoe
>>>      Filename    =     : draft-ietf-avtcore-srtp-aes-gcm-04.txt
>>>      Pages    &nb= sp;      : 28
>>>      Date    &nbs= p;       : 2013-02-04
>>>
>>> Abstract:
>>>  This document defines how AES-GCM and AES-CCM Authentica= ted
>>>  Encryption with Associated Data algorithms can be used t= o provide
>>>  confidentiality and data authentication in the SRTP prot= ocol.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes= -gcm
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-04 >>>
>>>
>>> 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
>>>
>>
>> --
>> Jonathan Lennox
>> jonathan@vidyo.com
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.= ietf.org/mailman/listinfo/avt

--
Jonathan Lennox
jonathan@vidyo.com

--_000_3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8MSMRGH1UEA03cor_-- From jonathan@vidyo.com Fri Feb 8 09:07:28 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693E21F8609 for ; Fri, 8 Feb 2013 09:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, 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 ywxf4cczXby6 for ; Fri, 8 Feb 2013 09:07:26 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 653AF21F854E for ; Fri, 8 Feb 2013 09:07:25 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E4DDC416A90; Fri, 8 Feb 2013 06:10:29 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DF439416A4A; Fri, 8 Feb 2013 06:10:12 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 8 Feb 2013 12:07:07 -0500 From: Jonathan Lennox To: "Igoe, Kevin M." Date: Fri, 8 Feb 2013 12:07:05 -0500 Thread-Topic: header extensions and draft-ietf-avtcore-srtp-aes-gcm-04.txt Thread-Index: Ac4GHrkzEp7mybBhS0GGernBf6Sx6Q== Message-ID: References: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> <461FB470-9F33-4B72-BDCC-402E44208789@vidyo.com> <3C4AAD4B5304AB44A6BA85173B4675CA69669890@MSMR-GH1-UEA03.corp.nsa.gov> <3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AB84A13899B64BBFAEB478128DC1B967vidyocom_" MIME-Version: 1.0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] header extensions and draft-ietf-avtcore-srtp-aes-gcm-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: Fri, 08 Feb 2013 17:07:28 -0000 --_000_AB84A13899B64BBFAEB478128DC1B967vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In draft-ietf-avtcore-srtp-encrypted-header-ext, header extensions run the = KDF separately (with a different value for the label parameter) to generate= a different encryption key and salt than is used for the payload. AEAD us= es the same KDF logic as core 3711 to generate its session keys from the ma= ster keys, right? If that's the case, then assuming the KDF is secure, I t= hink this shouldn't be a problem -- the AEAD encryption and the header exte= nsion keystream use different session keys. On Feb 8, 2013, at 11:11 AM, Igoe, Kevin M. wrote: If the header extensions are to use the same key as the AEAD but with different salts, I=92ve got a problem with preventing IV reuse. Currently the IV=92s are formed by 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | SRTP Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ Figure 1: AES-GCM and AES-CCM SRTP Initialization Vector formation. and your proposal for header extensions seems to call for the IV to be 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ We MUST insure the IV=92s are all distinct, so even between packets with different SSRC, ROC and SEQ we must insure base_0 XOR SRTP_SALT !=3D base_1 XOR HE_SALT_1 where base_i =3D 0x0000 || SSRC_i || ROC_i || SEQ_i. We have a problem whenever HE_SALT XOR SRTP_SALT =3D base_0 XOR base_1. I believe we can avoid this by playing games with the most significant bytes of the SALT {and hence of the IV, since he base starts with 0x00). For SRTP, force the msB of the SRTP salt to be 0x0000 by taking the msB of the SRTP salt to be 0x00: 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |00| SRTP Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | SRTP Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ so the high order byte of the IV is 0x00, When we are using a 1-byte extentsion element headers, the extension starts with the byte HH =3D ID ||L (both ID and L are 4 bits each), so we proceed as below: 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |HH| HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ so the first nibble of the IV is the ID. For 2-byte extension headers, we have an 8-bit ID, so we use 0 0 0 0 0 0 0 0 0 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC | ROC | SEQ |---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | |ID| HE Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | HE Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ and hence the first byte of the IV is the ID. Since the ID is never allowed to be zero, and recalling that a given session never mixes 1-byte and 2-byte extensions, the inclusion of the ID directly in the IV insures all of the IV=92s are distinct. I presume the ID and length fields are to be sent in the clear? I=92d recommend that AEAD treat them as AAD. Indeed, it would be prudent to have AEAD treat the encrypted header extension data field as AAD. This eliminates all sorts of potential spoofing attack worries. What do you think? From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: Wednesday, February 06, 2013 5:23 PM To: Igoe, Kevin M. Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-04.txt Sorry, I was probably too brief in my comment. I was specifically referrin= g to draft-ietf-avtcore-srtp-encrypted-header-ext (currently in AD review),= which works out all these issues but adds a requirement that new SRTP encr= yption transforms define how they generate the encrypted header keystream. I've attached my e-mail exchange with David from the aes-gcm WGLC, which in= cludes text I proposed be added to the aes-gcm draft. On Feb 6, 2013, at 3:44 PM, Igoe, Kevin M. wrote: > I'm not sure I understand header extensions well enough to come up with > a "one size fits all" solution. Which parts are to be treated as PT > to be encrypted and authenticated, which as additional authenticated data > to be only authenticated, and which as raw data? Will this change form > one flavor of extension to another? I hope to tap your expertise on > these points. > > RFC 5283 talks about the presence and format of a header extension being > negotiated out-of-band. The best solution I can think of is that this > out-of-band negotiation should also decide how AEAD will treat the variou= s > fields in the header extension. If that is sufficient for our needs, the= n > I believe we can add that in w/o too much trouble. But I really don't wa= nt > to get bogged down in how the out-of-band negotiation is to be done. > > Another point I'd like your input on: does the requirement that the AEAD > authentication tag MUST be validated before any of the cipher is decrypte= d > or any of the AAD be processed in any way cause problems for existing hea= der > extensions? > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-boun= ces@ietf.org] On Behalf Of >> Jonathan Lennox >> Sent: Monday, February 04, 2013 6:00 PM >> To: IETF AVTCore WG >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm- >> 04.txt >> >> This new version still doesn't appear to have any text about header >> extension encryption. Is there a reason this was omitted? >> >> On Feb 4, 2013, at 1:14 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 : AES-GCM and AES-CCM Authenticated Encryption in >> Secure RTP (SRTP) >>> Author(s) : David A. McGrew >>> Kevin M. Igoe >>> Filename : draft-ietf-avtcore-srtp-aes-gcm-04.txt >>> Pages : 28 >>> Date : 2013-02-04 >>> >>> Abstract: >>> This document defines how AES-GCM and AES-CCM Authenticated >>> Encryption with Associated Data algorithms can be used to provide >>> confidentiality and data authentication in the SRTP protocol. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-04 >>> >>> >>> 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 >>> >> >> -- >> Jonathan Lennox >> jonathan@vidyo.com >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt -- Jonathan Lennox jonathan@vidyo.com -- Jonathan Lennox jonathan@vidyo.com --_000_AB84A13899B64BBFAEB478128DC1B967vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If the header extensions are to use the = same key as the
AEAD but with different= salts, I=92ve got a problem with
preve= nting IV reuse.  Currently the IV=92s are formed by<= /div>
 
  &n= bsp;            0&nb= sp; 0  0  0  0  0  0  0  0  0 = 1  1
    &nbs= p;          0  1  2&= nbsp; 3  4  5  6  7  8  9  0  1
       =       +--+--+--+--+--+--+--+--+--+--+--+--+
<= span style=3D"font-size: 11pt; font-family: 'Courier New'; color: rgb(31, 7= 3, 125); ">          &nbs= p;  +--+--+--+--+--+--+--+--+--+--+--+--+   |
         = ;            &n= bsp;            = ;            &n= bsp;      |
&n= bsp;            +--+= --+--+--+--+--+--+--+--+--+--+--+   |
            = ; |      SRTP Encryption Salt   &nb= sp;     |->(+)
            = ; +--+--+--+--+--+--+--+--+--+--+--+--+   |
          =             &nb= sp;            =             &nb= sp;     |
 &nb= sp;           +--+--+--+-= -+--+--+--+--+--+--+--+--+   |
 &n= bsp;           +--+--+--+= --+--+--+--+--+--+--+--+--+
 =
       &= nbsp;   Figure 1: AES-GCM and AES-CCM SRTP
          &= nbsp;          Initialization = Vector formation.
 
and your proposal for header extensions seems to call= for
the IV to be
 
   = ;            0 = 0  0  0  0  0  0  0  0  0  1&= nbsp; 1
     &= nbsp;         0  1  2&nbs= p; 3  4  5  6  7  8  9  0  1
        =      |00|00|    SSRC   | =     ROC   | SEQ |---+
           &= nbsp; +--+--+--+--+--+--+--+--+--+--+--+--+   |=
         &n= bsp;            = ;            &n= bsp;            = ;      |
 = ;            +--+--+= --+--+--+--+--+--+--+--+--+--+   |
            &n= bsp;|       HE Encryption Salt   &n= bsp;      |->(+)
<= span style=3D"font-size: 11pt; font-family: 'Courier New'; color: rgb(31, 7= 3, 125); ">          &nbs= p;  +--+--+--+--+--+--+--+--+--+--+--+--+   |
         = ;            &n= bsp;            = ;            &n= bsp;      |
&n= bsp;            +--+= --+--+--+--+--+--+--+--+--+--+--+   |
           =   |       Initialization Vector &nb= sp;     |<--+
&n= bsp;            +--+= --+--+--+--+--+--+--+--+--+--+--+
=  
We MUST insure the IV=92s are all dis= tinct, so even between packets
with dif= ferent SSRC, ROC and SEQ we must insure
     base= _0 XOR SRTP_SALT !=3D base_1 XOR HE_SALT_1
 
where base_i =3D 0x0000 || S= SRC_i || ROC_i || SEQ_i.
 
We have a problem whenever HE_SALT XOR SRTP_SA= LT =3D base_0 XOR base_1.
 
bytes of the = SALT {and hence of the IV, since he base starts with 0x00). 
 
For S= RTP, force the msB of the SRTP salt to be 0x0000 by taking
the msB of the SRTP salt to be 0x00:<= /div>
 
  &n= bsp;            0&nb= sp; 0  0  0  0  0  0  0  0  0 = 1  1
    &nbs= p;          0  1  2&= nbsp; 3  4  5  6  7  8  9  0  1
       =       +--+--+--+--+--+--+--+--+--+--+--+--+
<= span style=3D"font-size: 11pt; font-family: 'Courier New'; color: rgb(31, 7= 3, 125); ">          &nbs= p;  +--+--+--+--+--+--+--+--+--+--+--+--+   |
         = ;            &n= bsp;            = ;            &n= bsp;      |
&n= bsp;            +--+= --+--+--+--+--+--+--+--+--+--+--+   |
            = ; |00|     SRTP Encryption Salt    =     |->(+)
 = ;            +--+--+= --+--+--+--+--+--+--+--+--+--+   |
           &nb= sp;            =             &nb= sp;            =     |
   =           +--+--+--+--+--+--+-= -+--+--+--+--+--+   |
 &= nbsp;           | &n= bsp;  SRTP Initialization Vector     |<--+=
       &= nbsp;     +--+--+--+--+--+--+--+--+--+--+--+--+
 
so = the high order byte of the IV is 0x00,
 
When we are using a 1-byte exte= ntsion element headers,
the extension s= tarts with the byte HH =3D ID ||L (both ID
and L are 4 bits each), so we proceed as below:
=
 
   &= nbsp;           0  0=   0  0  0  0  0  0  0  0  1&nb= sp; 1
     &nb= sp;         0  1  2 = 3  4  5  6  7  8  9  0  1
        = ;     +--+--+--+--+--+--+--+--+--+--+--+--+<= /span>
        &n= bsp;    |00|00|    SSRC   | &n= bsp;   ROC   | SEQ |---+
           &nb= sp; +--+--+--+--+--+--+--+--+--+--+--+--+   |
         &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     |
 &= nbsp;           +--+--+--= +--+--+--+--+--+--+--+--+--+   |
            &nbs= p;|HH|     HE Encryption Salt     &= nbsp;   |->(+)
 =             +--+--+-= -+--+--+--+--+--+--+--+--+--+   |
           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   |
   &= nbsp;         +--+--+--+--+--+--+--= +--+--+--+--+--+   |
 &n= bsp;           | &nb= sp;  HE Initialization Vector       |<= ;--+
     &nbs= p;       +--+--+--+--+--+--+--+--+--+--+--+--= +
 
so the first nibble of the IV is the ID.
 
For 2-byte extension hea= ders, we have an 8-bit ID, so we use
 
 
           =     0  0  0  0  0  0  0  = 0  0  0  1  1
 = ;            &n= bsp; 0  1  2  3  4  5  6  7  8 = ; 9  0  1
   &= nbsp;         +--+--+--+--+--+--+--= +--+--+--+--+--+
   &nbs= p;         |00|00|   = ; SSRC   |     ROC   | SEQ |---+
       = ;      +--+--+--+--+--+--+--+--+--+--+--+--+ =   |
     =             &nb= sp;            =             &nb= sp;          |
         =     +--+--+--+--+--+--+--+--+--+--+--+--+   |=
        =      |ID|     HE Encryption Sa= lt         |->(+)
         = ;    +--+--+--+--+--+--+--+--+--+--+--+--+   |
       =             &nb= sp;            =             &nb= sp;        |
           =   +--+--+--+--+--+--+--+--+--+--+--+--+   |
         &= nbsp;   |    HE Initialization Vector   =     |<--+
 =             +--+--+-= -+--+--+--+--+--+--+--+--+--+
 &nb= sp;            =
and hence the first byte of the IV is = the ID.
 
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">= Since the ID is never allowed to be zero, and recalling that a = given
session never mixes 1-byte and 2-= byte extensions, the inclusion of the ID
 
I presume= the ID and length fields are to be sent in the clear?
I=92d recommend that AEAD treat them as AAD.  Indeed, = it would be
prudent to have AEAD treat = the encrypted header extension data
fie= ld as AAD.  This eliminates all sorts of potential spoofing=
attack worries.
What do you think?=
 
=  
 
 
 
From:&nb= sp;Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent: Wednesday, February 06, 2013 5:23 PM
To: Igoe, Kevin M.
Subject= : Re: [AVTCORE] I-D A= ction: draft-ietf-avtcore-srtp-aes-gcm-04.txt
=
 

Sorry, I was probably too brief in my comment.  I was sp= ecifically referring to draft-ietf-avtcore-srtp-encrypted-header-ext (curre= ntly in AD review), which works out all these issues but adds a requirement= that new SRTP encryption transforms define how they generate the encrypted= header keystream.

I've attached my e-mail exchange with David from = the aes-gcm WGLC, which includes text I proposed be added to the aes-gcm dr= aft.



On Feb 6, 2013, at 3:44 PM, Igoe, Kevin M. w= rote:

> I'm not sure I understand header extensions well enough t= o come up with
> a "one size fits all" solution.  Which parts ar= e to be treated as PT
> to be encrypted and authenticated, which as a= dditional authenticated data 
> to be only authenticated, and which as raw data?  Will th= is change form 
> o= ne flavor of extension to another?  I hope to tap your expertise on> these points.
> 
> RFC 5283 talks about the presence and format of a header extens= ion being 
> negoti= ated out-of-band.  The best solution I can think of is that this
&g= t; out-of-band negotiation should also decide how AEAD will treat the vario= us
> fields in the header extension.  If that is sufficient for = our needs, then 
> = I believe we can add that in w/o too much trouble.  But I really don't= want 
> to get bog= ged down in how the out-of-band negotiation is to be done.
> 
> Another point I'd like y= our input on: does the requirement that the AEAD 
> authentication tag MUST be validated befor= e any of the cipher is decrypted = ;
> or any of the AAD be processed in any way cause problems f= or existing header 
&g= t; extensions?
> >> -----Original Message-----
>> From: avt-bounces@ietf.org [mailto:av= t-bounces@ietf.org] On Behalf Of
>> Jonathan Lennox
>>= ; Sent: Monday, February 04, 2013 6:00 PM
>> To: IETF AVTCore WG>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-g= cm-
>> 04.txt
>>&nb= sp;
>> This new version still doesn't appear to have any te= xt about header
>> extension encryption.  Is there a reason t= his was omitted?
>> 
>> On Feb 4, 2013, at 1:14 PM, <inter= net-drafts@ietf.org> wrote:
>> 
>>> 
>>> A New Internet-Draft is available from the o= n-line Internet-Drafts
>> directories.
>>> This draft = is a work item of the Audio/Video Transport Core
>> Maintenance Wo= rking Group of the IETF.
>>> 
>>>      Title &= nbsp;         : AES-GCM and AES-CCM= Authenticated Encryption in
>> Secure RTP (SRTP)
>>>&= nbsp;     Author(s)      = : David A. McGrew
>>>       = ;            &n= bsp;     Kevin M. Igoe
>>>   = ;   Filename        : draft-ie= tf-avtcore-srtp-aes-gcm-04.txt
>>>     = ; Pages           : 28>>>      Date    &nb= sp;       : 2013-02-04
>>> 
>>> Abstract:
&= gt;>>  This document defines how AES-GCM and AES-CCM Authenticat= ed
>>>  Encryption with Associated Data algorithms can be = used to provide
>>>  confidentiality and data authenticati= on in the SRTP protocol.
>>> 
>>> = ;
>>> =
>>> The IETF datatracker status page for this draft is:
>= ;>> https://datatracker.ietf.org/doc/dra= ft-ietf-avtcore-srtp-aes-gcm
>>> 
>>> There's also a htmlized version av= ailable at:
>>> http://tools.ietf.org= /html/draft-ietf-avtcore-srtp-aes-gcm-04
>>> 
>>> A diff from the previo= us version is available at:
>>>  
>= ;>> 
>>>= ; Internet-Drafts are also available by anonymous FTP at:
>>> f= tp://ftp.ietf.org/internet-drafts/
>>> 
>>> ____________________________= ___________________
>>> Audio/Video Transport Core Maintenance<= br>>>> &nb= sp;https://www.ietf.org/mailman/listi= nfo/avt
>>> 
>> 
>&= gt; --
>> Jonathan Lennox
>> jonathan@vidyo.com
>> 
>> 
>> ___________________________= ____________________
>> Audio/Video Transport Core Maintenance
= >> avt@iet= f.org
>> https://www.ietf.org/mailman/listinfo/avt
--
Jonathan Lennox
jonathan@vidyo.com

<= /div>
--
Jonathan Lennox
jonathan@vidyo.com

= --_000_AB84A13899B64BBFAEB478128DC1B967vidyocom_-- From internet-drafts@ietf.org Fri Feb 8 09:15:15 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4722521F8B6D; Fri, 8 Feb 2013 09:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUjjG+WUxgN1; Fri, 8 Feb 2013 09:15:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649E021F8B6E; Fri, 8 Feb 2013 09:15:14 -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.37 Message-ID: <20130208171514.13325.16330.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 09:15:14 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:15:15 -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 : Encryption of Header Extensions in the Secure Real-Time = Transport Protocol (SRTP) Author(s) : Jonathan Lennox Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt Pages : 17 Date : 2013-02-08 Abstract: The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-Time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header-e= xt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-encrypted-header= -ext-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jonathan@vidyo.com Fri Feb 8 09:23:59 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ECA21F8A64 for ; Fri, 8 Feb 2013 09:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 vrVskC0NCGMI for ; Fri, 8 Feb 2013 09:23:59 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2143221F8A5F for ; Fri, 8 Feb 2013 09:23:59 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D6ACF41699C for ; Fri, 8 Feb 2013 06:27:03 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 83B8041695D for ; Fri, 8 Feb 2013 06:26:56 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Fri, 8 Feb 2013 12:23:51 -0500 From: Jonathan Lennox To: IETF AVTCore WG Date: Fri, 8 Feb 2013 12:23:50 -0500 Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt Thread-Index: Ac4GIQ9bq9AVGSrnRGSY9c8JrUO7Kg== Message-ID: <579E797D-9A53-4439-AF4B-D945A9C407CE@vidyo.com> References: <20130208171514.13325.16330.idtracker@ietfa.amsl.com> In-Reply-To: <20130208171514.13325.16330.idtracker@ietfa.amsl.com> 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: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:23:59 -0000 Hello, all -- This version of the srtp-encrypted-header-ext draft addresses issues brough= t up in IESG review: https://datatracker.ietf.org/doc/draft-ietf-avtcore-sr= tp-encrypted-header-ext/ballot/ . There are no protocol changes. The only significant normative change is to= make it clear that offering both encrypted and unencrypted forms of the sa= me header extension is only for backward compatibility: you MUST NOT ever n= egotiate to use, or actually send, both encrypted and unencrypted forms of = the same header extension. See the diff for the full list of changes. On Feb 8, 2013, at 12:15 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Audio/Video Transport Core Maintenance W= orking Group of the IETF. >=20 > Title : Encryption of Header Extensions in the Secure Real-Tim= e Transport Protocol (SRTP) > Author(s) : Jonathan Lennox > Filename : draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt > Pages : 17 > Date : 2013-02-08 >=20 > Abstract: > The Secure Real-Time Transport Protocol (SRTP) provides > authentication, but not encryption, of the headers of Real-Time > Transport Protocol (RTP) packets. However, RTP header extensions may > carry sensitive information for which participants in multimedia > sessions want confidentiality. This document provides a mechanism, > extending the mechanisms of SRTP, to selectively encrypt RTP header > extensions in SRTP. >=20 > This document updates RFC 3711, the Secure Real-Time Transport > Protocol specification, to require that all future SRTP encryption > transforms specify how RTP header extensions are to be encrypted. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header= -ext >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-0= 5 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-encrypted-head= er-ext-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 -- Jonathan Lennox jonathan@vidyo.com From magnus.westerlund@ericsson.com Mon Feb 11 01:28:47 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADD021F8667 for ; Mon, 11 Feb 2013 01:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=1.736, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 y4e1GVtPlNDy for ; Mon, 11 Feb 2013 01:28:47 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 165E021F865B for ; Mon, 11 Feb 2013 01:28:46 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-d3-5118b9cd46d9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F9.5D.32353.DC9B8115; Mon, 11 Feb 2013 10:28:46 +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; Mon, 11 Feb 2013 10:28:44 +0100 Message-ID: <5118B9CB.1060902@ericsson.com> Date: Mon, 11 Feb 2013 10:28:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvje65nRKBBldncVi87FnJbrHy23VW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSvjw4/NrAUX2Sv+bLrJ3MC4mq2LkYNDQsBE Ys0KxS5GTiBTTOLCvfVAYS4OIYGTjBL7v/xhgXCWM0pcvX6LCaSKV0Bb4uyT6+wgNouAqsSB FYuZQWw2AQuJmz8a2UBsUYFgiQ0HV0HVC0qcnPmEBcQWEVCS2DFpG1g9s4CzxLy5h1lBbGEB Y4kXR18wQhwkLrHmDQdEiZ7ElKstjBC2vETz1tlgrUJAJzQ0dbBOYBSYhWTDLCQts5C0LGBk XsXInpuYmZNebr6JERh4B7f8NtjBuOm+2CFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmp xYcYmTg4pRqAaljf7k7sPxzU7vqtx+DQWh7VLLu16xp91m8yUf0TJ3BjguyReX9++aq+cEs+ V7jEYDvzsg9GMc+W/Du/a/I5b83faT1/lnJw223Y0naf97mk9PWWl0uu1844kOq888tK7kD7 earaBR+vtOiqOCc+t7eQP5bT6ZdXn/5SMCWhvnnW2aTJqqJKLMUZiYZazEXFiQCPaYRNCgIA AA== Cc: "avtcore-chairs@tools.ietf.org" Subject: [AVTCORE] Conference invitations on the mailing list X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 09:28:47 -0000 WG, Distributing invitations to conferences or meetings on this mailing list is highly limited. We chair only accept things with a core focus on multi-media transport. Thus if you want to submit an invitation to the list please send the mail privately to the chairs first for approval (mail:avtcore-chairs@tools.ietf.org). Anyone submitting an invitation without first getting an approval will be have their future postings moderated. Anyone getting moderated will get a notice of this. Regards Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From iesg-secretary@ietf.org Tue Feb 12 12:47:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9963C21F884B; Tue, 12 Feb 2013 12:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeuzooRjkZXl; Tue, 12 Feb 2013 12:47:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB2221F8AC0; Tue, 12 Feb 2013 12:47:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212204712.31893.97353.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 12:47:12 -0800 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)' to Proposed Standard (draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 20:47:13 -0000 The IESG has approved the following document: - 'Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)' (draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-encrypted-header-ext/ Technical Summary: The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-Time Transport Protocol specification, to require that all SRTP encryption transforms specify how RTP header extensions are to be encrypted. Working Group Summary: This document went through two working group last call. As a result of the first one there were proposals to add some technical changes that were consented in the second working group last call. Document Quality: The document got good reviews from AVTCORE members including SRTP and security experts. Personnel: Roni Even is the Document Shepherd and the Responsible Area Director is Robert Sparks. From csp@csperkins.org Tue Feb 12 16:18:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A521F8964 for ; Tue, 12 Feb 2013 16:18:46 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-AeSV29GMiy for ; Tue, 12 Feb 2013 16:18:45 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4C21F88CF for ; Tue, 12 Feb 2013 16:18:45 -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 1U5Q3d-0005rJ-7C; Wed, 13 Feb 2013 00:18:41 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_863F9FC3-C2EF-48AA-99D5-3435096D7DE9" From: Colin Perkins In-Reply-To: Date: Wed, 13 Feb 2013 00:18:40 +0000 Message-Id: <2B95330E-6BF9-4F14-9F36-9E2CDF48A96D@csperkins.org> References: <20121022221624.7138.24306.idtracker@ietfa.amsl.com> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -12 X-Mythic-Debug: Threshold = On = 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: Wed, 13 Feb 2013 00:18:46 -0000 --Apple-Mail=_863F9FC3-C2EF-48AA-99D5-3435096D7DE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Kevin, Thanks for these comments. I've incorporated most of them into the draft = ready for the next version, which will be submitted before the deadline. = Some comments inline. On 5 Nov 2012, at 21:56, Kevin Gross wrote: > Comments on this draft. Some I mentioned in the session today. Smaller = ones I did not. ... > 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. Participants was misleading: what matters is the number of SSRC values, = which can be greater than two in a unicast session if the participants = send multiple media streams. ... > p.7 The following text may need work: >=20 > "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."=20 >=20 > 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. Agree. I expanded this text slightly, but more might need to be said. > 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. If this were a congestion control algorithm, I'd probably agree that we = should be more aggressive in stopping transmission here, but the circuit = breaker is supposed to be conservative when it fires, to encompass all = reasonable congestion control behaviours. As such, I think it is better = that the draft allow the option of reducing offered load as a response = here, rather than mandate ceasing transmission immediately. > 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. None of these circuit breakers work if RTCP is not implemented. I'll = clarify at the start of section 4. > 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. In progress. Cheers, Colin --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_863F9FC3-C2EF-48AA-99D5-3435096D7DE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Kevin,

Thanks for these comments. I've incorporated = most of them into the draft ready for the next version, which will be = submitted before the deadline. Some comments = inline.

On 5 Nov 2012, at 21:56, = Kevin Gross wrote:
Comments on this = draft. Some I mentioned in the session today. Smaller ones I = did not.
...
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.

Participants was = misleading: what matters is the number of SSRC values, which can be = greater than two in a unicast session if the participants send multiple = media streams.

...
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.

Agree. I expanded this text slightly, but more might need to be = said.

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.

If this were a congestion = control algorithm, I'd probably agree that we should be more aggressive = in stopping transmission here, but the circuit breaker is supposed to be = conservative when it fires, to encompass all reasonable congestion = control behaviours. As such, I think it is better that the draft allow = the option of reducing offered load as a response here, rather than = mandate ceasing transmission = immediately.

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.

None of these circuit = breakers work if RTCP is not implemented. I'll clarify at the start of = section 4.

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.

In = progress.

Cheers,
Colin


-- 
Colin Perkins



= --Apple-Mail=_863F9FC3-C2EF-48AA-99D5-3435096D7DE9-- From ron.even.tlv@gmail.com Wed Feb 13 05:19:23 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6965F21F8871 for ; Wed, 13 Feb 2013 05:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.862 X-Spam-Level: X-Spam-Status: No, score=-2.862 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRZEdUHGuE22 for ; Wed, 13 Feb 2013 05:19:22 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4326121F87D2 for ; Wed, 13 Feb 2013 05:19:22 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d4so599402eek.36 for ; Wed, 13 Feb 2013 05:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=KT5Uc8/9+slo91aMSINtWGf7TfZTSth3rJjDxZdNtBI=; b=J2R4BXyZmsCtgKy1bMXG326cnESGKMCJXi2+PcI6nZISi4Ub7OlGYGVw0Gn0r1CYAA miPwJ+ck5azP2xzAbCq62gNdsQi07TTGE9byP7U+v9dZlAqIFDIGy8Ol1EBgYLMoBaYR 1DLxi5dljVvfIjMlnURAH2uogbHmSpJfcQQmDunWHuZvjoi2ZiKeFGHvt4ObaE2qs62m X2lPlgOB2h5X2yTkmb1ffFDf0lTDt6qIMKq1lNsyGbuMYDj54DCzEZb6Krhkvs+/1z/T 6G8zT+iCaP1soYl4D0nGNOhA0tuyizrU8YSPp5EZ2bPU1k31cLQKlW5PW4yYMYjFrNXx 2oOA== X-Received: by 10.14.184.68 with SMTP id r44mr5816454eem.40.1360761561297; Wed, 13 Feb 2013 05:19:21 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id s3sm2625011eem.4.2013.02.13.05.19.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 05:19:20 -0800 (PST) From: "Roni Even" To: Date: Wed, 13 Feb 2013 15:16:11 +0200 Message-ID: <000001ce09ec$4cda7480$e68f5d80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CE09FD.1063E0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4J7AkORgc9d0V6RaK2WJhWuNfLVw== Content-Language: en-us Cc: Magnus Westerlund Subject: [AVTCORE] Request for agenda time at IETF86 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, 13 Feb 2013 13:19:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CE09FD.1063E0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda for AVTcore. Please send request for agenda time to the WG chairs avtcore Session 1 (2:00:00) Tuesday, Afternoon Session I 1300-1500 Room Name: Caribbean 4 --------------------------------------------- avtcore Session 2 (1:00:00) Thursday, Afternoon Session III 1740-1840 Room Name: Caribbean 5 --------------------------------------------- Thanks Roni Even AVTcore co-chair ------=_NextPart_000_0001_01CE09FD.1063E0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the preliminary agenda for AVTcore. = Please send request for agenda time to the WG = chairs

 

    avtcore Session 1 = (2:00:00)

    = Tuesday, Afternoon Session I 1300-1500

    Room Name: Caribbean = 4

    = ---------------------------------------------

    avtcore Session 2 = (1:00:00)

    = Thursday, Afternoon Session III 1740-1840

    Room Name: Caribbean = 5

    = ---------------------------------------------

 

 

Thanks

Roni = Even

AVTcore = co-chair

 

------=_NextPart_000_0001_01CE09FD.1063E0C0-- From kevin.gross@avanw.com Mon Feb 18 08:49:09 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2555E21F8BEB for ; Mon, 18 Feb 2013 08:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[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 Fu2vRvJLBkDy for ; Mon, 18 Feb 2013 08:49:06 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id D041B21F8BDB for ; Mon, 18 Feb 2013 08:49:05 -0800 (PST) Received: (qmail 30937 invoked by uid 0); 18 Feb 2013 16:48:43 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy3.bluehost.com with SMTP; 18 Feb 2013 16:48:43 -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=EAN4bb66SGlIUIiyjOTbWIK86BU4SIHywpQWSx2R0aQ=; b=d9UbnWSkA0IbzGGTyfZl+aIKr88eTZ7tox1M1KZUHCRVtHExwnqDtpNyCpo7FxQn+NMcG3CMaCWkMwJbEaruDi6JUROJCsG8F9A9E52BF8YcDiQ+MG2cegUR7U4gN/PJ; Received: from [209.85.223.174] (port=61188 helo=mail-ie0-f174.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U7TtT-0002AT-7Y for avt@ietf.org; Mon, 18 Feb 2013 09:48:43 -0700 Received: by mail-ie0-f174.google.com with SMTP id k10so7332807iea.5 for ; Mon, 18 Feb 2013 08:48:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.192.138 with SMTP id hg10mr7476905igc.95.1361206122144; Mon, 18 Feb 2013 08:48:42 -0800 (PST) Received: by 10.50.183.163 with HTTP; Mon, 18 Feb 2013 08:48:41 -0800 (PST) In-Reply-To: <2B95330E-6BF9-4F14-9F36-9E2CDF48A96D@csperkins.org> References: <20121022221624.7138.24306.idtracker@ietfa.amsl.com> <2B95330E-6BF9-4F14-9F36-9E2CDF48A96D@csperkins.org> Date: Mon, 18 Feb 2013 09:48:41 -0700 Message-ID: From: Kevin Gross To: Colin Perkins Content-Type: multipart/alternative; boundary=14dae93407176063ca04d6027fa4 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.174 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org 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, 18 Feb 2013 16:49:09 -0000 --14dae93407176063ca04d6027fa4 Content-Type: text/plain; charset=ISO-8859-1 Because the circuit breaker is conservative, my assessment is that things are clearly badly busted when the breaker trips. In this case, over the duration of 3 RRs, not a single RTP packet has been delivered. If this is due to moderate congestion or flow control, you'd expect at least a few of the packets to get through. If none are getting through, there is either a connectivity problem or possibly congestive collapse. In neither case is reducing rate by a factor of 10 a useful response. Have I missed something? What sort of failure scenario are you thinking of where the reduced rate would be successful? I am also concerned about scope. Circuit breakers are a safety net and should not interfere with congestion management techniques as they are developed. Circuit breakers should conservatively detect faults and trip. They should not half-trip or automatically reset themselves. On Tue, Feb 12, 2013 at 5:18 PM, Colin Perkins wrote: > 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. > > > If this were a congestion control algorithm, I'd probably agree that we > should be more aggressive in stopping transmission here, but the circuit > breaker is supposed to be conservative when it fires, to encompass all > reasonable congestion control behaviours. As such, I think it is better > that the draft allow the option of reducing offered load as a response > here, rather than mandate ceasing transmission immediately. > > --14dae93407176063ca04d6027fa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Because the circuit breaker is conservative, my assessment is that things a= re clearly badly busted when the breaker trips. In this case, over the dura= tion of 3 RRs, not a single RTP packet has been delivered. If this is due t= o moderate congestion or flow control, you'd expect at least a few of t= he packets to get through. If none are getting through, there is either a c= onnectivity problem or possibly congestive collapse. In neither case is red= ucing rate by a factor of 10 a useful response. Have I missed something? Wh= at sort of failure scenario are you thinking of where the reduced rate woul= d be=A0successful?

I am also concerned about scope. Circuit breakers are a safe= ty net and should not=A0interfere=A0with congestion management techniques a= s they are developed.=A0Circuit=A0breakers should conservatively detect fau= lts and trip. They should not half-trip or automatically reset themselves.<= /div>

On Tue, Feb 12, 2013 at 5:18 PM, Colin = Perkins <csp@csperkins.org> wrote:
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.

If this were a congestion control al= gorithm, I'd probably agree that we should be more aggressive in stoppi= ng transmission here, but the circuit breaker is supposed to be conservativ= e when it fires, to encompass all reasonable congestion control behaviours.= As such, I think it is better that the draft allow the option of reducing = offered load as a response here, rather than mandate ceasing transmission i= mmediately.


--14dae93407176063ca04d6027fa4-- From kevin.gross@avanw.com Mon Feb 18 12:49:01 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5913321F8C31 for ; Mon, 18 Feb 2013 12:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, SARE_LWSHORTT=1.24, 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 yxxBfIV+ADUv for ; Mon, 18 Feb 2013 12:49:00 -0800 (PST) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 0BC6B21F8C18 for ; Mon, 18 Feb 2013 12:49:00 -0800 (PST) Received: (qmail 19786 invoked by uid 0); 18 Feb 2013 20:48:59 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy14.unifiedlayer.com with SMTP; 18 Feb 2013 20:48:59 -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=qQnMBNSGnzP8j2uWLabrccODbPmY2dqYndQNiLQwiFg=; b=aOgO1a9HbNwWdA3G5tGzh/sxq2LbRbUHqUT2QZv8gKuuMCCMUTV88oEVwb0v1kD6F/DD1w0kRUQKApGl/4A3nsEaiDgsN945Rrt6zUvtCmQV4pR4oU6FK7cxaVVJftJK; Received: from [209.85.210.178] (port=56389 helo=mail-ia0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U7Xdz-0004Qm-AC for avt@ietf.org; Mon, 18 Feb 2013 13:48:59 -0700 Received: by mail-ia0-f178.google.com with SMTP id y26so5577582iab.9 for ; Mon, 18 Feb 2013 12:48:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.201.73 with SMTP id ez9mr5961666icb.29.1361220538301; Mon, 18 Feb 2013 12:48:58 -0800 (PST) Received: by 10.50.183.163 with HTTP; Mon, 18 Feb 2013 12:48:58 -0800 (PST) In-Reply-To: <509CEBAF.1030305@ericsson.com> References: <509CEBAF.1030305@ericsson.com> Date: Mon, 18 Feb 2013 13:48:58 -0700 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf301cc498a57cec04d605dacd X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.178 authed with kevin.gross@avanw.com} Cc: IETF AVTCore WG Subject: Re: [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: Mon, 18 Feb 2013 20:49:01 -0000 --20cf301cc498a57cec04d605dacd Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review Magnus, I've prepared, but have not yet published, a new draft addressing these comments as described below. Are there any issues with the proposed resolutions or any other comments from anyone else on this draft before I post the update? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Fri, Nov 9, 2012 at 4:40 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > 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. > Fixed. > > 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. > Reworked definitions section and some ambiguous terminology use in the draft to clarify difference between RTP media stream and SDP media stream. > > 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. > To eliminate ambiguity, we've improved the definition of traceable time to reference TAI. I've also added a note explaining that UTC is TAI with leap seconds added occasionally to compensate for slowing of earth's rotation. Either UTC or TAI is a valid traceable time. TAI is an average of atomic timekeeping all across the world (including Sweden, I assume). The various measurements are compared and combined and used to correct locally generated time so that all important world time standards progress together. If Sweden disconnects from TAI, clocks generated there will no longer be considered "traceable". Don't do it! > 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 > Added clksrc-ext. > > 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 ".". > This was taken from RFC 2396. '.' is the root in DNS names though it is often omitted. > > 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? > This was taken from RFC 2396. We think it best to follow that model unless there's a good reason to do otherwise. > > 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? > I added explicit discussion of "source level" in section 4.8. The "source level" definition in section 3 includes a reference 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? > > A clock identifier is not the same thing as a CNAME. We're simply borrowing the methods described in RFC 6222 to create a unique identifier. As per RFC 6222, a long term CNAME may be a MAC address. The MAC address is not a good clock identifier for a device that supports multiple clocks through a single network interface. The short term identifier does not have this problem. 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. > > Added mediaclock-ext for this. > 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. > > I have added a new signaling considerations section to the document. --20cf301cc498a57cec04d605dacd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the review Magnus,

I've prepared, but hav= e not yet published, a new draft addressing these comments as described bel= ow.

Are there any issues with the proposed resolutions o= r any other comments from anyone else on this draft before I post the updat= e?

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


On Fri, Nov 9, 2012 at 4:40 AM, Magnus Westerlund=A0<magnus.westerlund@ericsson.com>=A0wrote:
Hi,

I have review the Clock Source document draft-i= etf-avtcore-clksrc-01 and
have the following comments:

1. General comment on all the use of ha= nging lists. Please put in some
separator characters like ":" = between the label and the bullet text.

Fixed.=A0

2. Section 3. media stream

Yes, it is made clea= r above that this is SDP terminology. But as "media
stream" is also used for the sequnce of packets comming from an SSRC i= n
RTP I think it is prudent to call this type of media stream "SDP = media
stream" to avoid confusion in the reader.

Reworked definit= ions section and some ambiguous=A0terminology=A0use in the draft to clarify= difference between RTP media stream and SDP media stream.

3. Section 4.6
This is really a question of how traceable clocks wor= ks. I know in
Sweden we have "Swedish Time" which is produced = by a governmental body
using a number of time production centers and tim= e sources. Several of
the time sources are also used to help produce UTC. Commonly the
differe= nce 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
diffe= rent sources of traceable time.

For example, my home computer's = clocks runs of the Swedish strata one
NTP servers, but I think it is tra= ceable also.

To = eliminate ambiguity, we've improved the definition of traceable time to= reference TAI. I've also added a note explaining that UTC is TAI with = leap seconds added occasionally to compensate for slowing of earth's ro= tation. Either UTC or TAI is a valid traceable time.

TAI is an average of atomic timekeeping all across the world (includin= g Sweden, I assume). The various=A0measurements=A0are compared and combined= and used to correct locally generated time so that all important world tim= e standards progress together.

If Sweden disconnects from TAI, clocks generated there = will no longer be considered "traceable". Don't do it!
<= div>

4. Section 4.8:

=A0 =A0clksrc =3D ntp / ptp / g= ps / gal / local / private

I think this should ad a syntax element that make clear the syntax of a=
future extension shall have. An example:

=A0 =A0clksrc =3D ntp /= ptp / gps / gal / local / private / clksrc-ext

=A0 =A0clksrc-ext = =3D token ; token as in SDP

The similar extensibility I think should exist in the following rules:<= br>
ptp-version
ptp-server

Added clksrc-ext.

5. Section 4.8:

hostname =A0 =A0 =A0=3D =A0*( domainlabel "= ." ) toplabel [ "." ]

Where is this rule taken from. = I try to remember why you need a hostname
to end on a ".".
=

This was taken from RFC 2396.= '.' is the root in DNS names though it is often omitted.

6. Section 4.8
=A0 =A0 port =3D 1*DIGIT

I would recommend tha= t we restrict the port number to 5 digits maximum
length, i.e. =A0 =A0 p= ort =3D 1*5DIGIT

Or do you see any need for totally unlimited number= of digits?

Thi= s was taken from RFC 2396. We think it best to follow that model unless the= re's a good reason to do otherwise.

7. I wonder if it should be more explicit that the a=3Dclksrc attribute=
actually are defined to usage at the source (a=3DSSRC) level in the
= definition text by including a mention of source-specific and a ref to
R= FC 5576?

I a= dded explicit discussion of "source level" in section 4.8. The &q= uot;source level" definition in section 3 includes a reference to RFC = 5576.=A0

8. Section 5.3:

=A0 =A0In a given system, master clock identifie= rs must be unique. =A0Such
=A0 =A0identifiers MAY be manually configured= , however 17 octet string
=A0 =A0identifiers SHOULD be generated accordi= ng to the "short-term
=A0 =A0persistent 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?
<= br>
A clock identif= ier is not the same thing as a CNAME. We're simply borrowing the method= s described in RFC 6222 to create a unique identifier. As per RFC 6222, a l= ong term CNAME may be a MAC address. The MAC address is not a good clock id= entifier for a device that supports multiple clocks through a single networ= k interface. The short term identifier does not have this problem.

9. Section 5.4:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mediaclock =3D refclk= / streamid / sender

I think the above ABNF syntax rules shall inclu= de a syntax definition
for future extensions of the attribute.

Added mediaclock-ext for this.=A0
=A0
10. Section 4 and 5:

The SDP attribut= es are lacking clear rules for interpretation in a SDP
Offer/Answer context and thus also the declarative usage should be
contr= asted and clear.

I have added a new signaling considerations section to the document.
<= /div>
--20cf301cc498a57cec04d605dacd-- From wwwrun@rfc-editor.org Mon Feb 18 23:42:47 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86A21F85A0 for ; Mon, 18 Feb 2013 23:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.287, 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 IhlzYqRd8xyf for ; Mon, 18 Feb 2013 23:42:46 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BA40921F8450 for ; Mon, 18 Feb 2013 23:42:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 79BD0B1E002; Mon, 18 Feb 2013 23:42:01 -0800 (PST) To: schulzrinne@cs.columbia.edu, tom.taylor.stds@gmail.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20130219074201.79BD0B1E002@rfc-editor.org> Date: Mon, 18 Feb 2013 23:42:01 -0800 (PST) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 07:42:47 -0000 The following errata report has been submitted for RFC4733, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 -------------------------------------- Type: Technical Reported by: Xavier Marjou Section: 2.1 Original Text ------------- Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. Corrected Text -------------- Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. Notes ----- RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). 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. -------------------------------------- RFC4733 (draft-ietf-avt-rfc2833bis-15) -------------------------------------- Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals Publication Date : December 2006 Author(s) : H. Schulzrinne, T. Taylor Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Tue Feb 19 15:11:58 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1BD21F8A74; Tue, 19 Feb 2013 15:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 WY0t-PVKXMCt; Tue, 19 Feb 2013 15:11:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08821F8A52; Tue, 19 Feb 2013 15:11:57 -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.40 Message-ID: <20130219231157.13725.71182.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 15:11:57 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:11:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP and Leap Seconds Author(s) : Kevin Gross Ray van Brandenburg Filename : draft-ietf-avtcore-leap-second-02.txt Pages : 8 Date : 2013-02-19 Abstract: This document discusses issues that arise when RTP sessions span Universal Coordinate Time (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-leap-second-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Tue Feb 19 16:04:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C29721F8750 for ; Tue, 19 Feb 2013 16:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=0.274, 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 Xj5OntGMM8JS for ; Tue, 19 Feb 2013 16:04:40 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 8AB0F21F87A5 for ; Tue, 19 Feb 2013 16:04:40 -0800 (PST) Received: (qmail 28863 invoked by uid 0); 20 Feb 2013 00:04:11 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 20 Feb 2013 00:04:11 -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=TOUEiCMU3bhxS6OyHLxfbj4eur9alZXNFc8/hbX7cWU=; b=CRfW8TQwpOe603cpDwqVUIgHzp75f2NtTIb9a10prWVbVKisBLtT/Gfhx3qlmq2/WANbvZ4oHRvE9UKcwtp5lbD3VniAnzSJVPeSI8JmAQyDqHBiJW2F1ZK9ie1I8nih; Received: from [209.85.223.175] (port=38427 helo=mail-ie0-f175.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U7xAR-0004LW-KN for avt@ietf.org; Tue, 19 Feb 2013 17:04:11 -0700 Received: by mail-ie0-f175.google.com with SMTP id c12so9120178ieb.6 for ; Tue, 19 Feb 2013 16:04:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.122.66 with SMTP id m2mr8371323icr.15.1361318650568; Tue, 19 Feb 2013 16:04:10 -0800 (PST) Received: by 10.50.183.163 with HTTP; Tue, 19 Feb 2013 16:04:10 -0800 (PST) In-Reply-To: <20130219231157.13725.71182.idtracker@ietfa.amsl.com> References: <20130219231157.13725.71182.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 17:04:10 -0700 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=20cf3003bbb697dfbd04d61cb226 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.175 authed with kevin.gross@avanw.com} Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-02.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, 20 Feb 2013 00:04:43 -0000 --20cf3003bbb697dfbd04d61cb226 Content-Type: text/plain; charset=ISO-8859-1 This new version addresses comments from Magnus, discussion at IETF85 and other improvements. Specifically: 1. Indicate that this updates RFC 3550 in introduction 2. Clarify that leap seconds are inserted at the end of the UTC day, not the local day 3. Clarify nature of NTP clock freeze during leap second 4. Add discussion of negative leap seconds 5. Allow senders and receivers to assume, for the purpose of suspending and ignoring sender reports, that a leap second occurs at the end of every month 6. Suggest senders send receiver reports in place of suspended sender reports to avoid RTCP timeouts 7. Populate Security Considerations section with discussion of wall-clock and leap-second schedule manipulation 8. Separate normative and informative references Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Feb 19, 2013 at 4:11 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 and Leap Seconds > Author(s) : Kevin Gross > Ray van Brandenburg > Filename : draft-ietf-avtcore-leap-second-02.txt > Pages : 8 > Date : 2013-02-19 > > Abstract: > This document discusses issues that arise when RTP sessions span > Universal Coordinate Time (UTC) leap seconds. It updates RFC 3550 to > describe how RTP senders and receivers should behave in the presence > of leap seconds. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-leap-second-02 > > > 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 > --20cf3003bbb697dfbd04d61cb226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This new version addresses comments from Magnus, discussion at IETF85 and o= ther improvements. Specifically:
  1. Indicate that this updates RFC= 3550 in introduction
  2. Clarify that leap seconds are inserted at the= end of the UTC day, not the local day
  3. Clarify nature of NTP clock freeze during leap second
  4. Add discu= ssion of negative leap seconds
  5. Allow senders and receivers to assum= e, for the purpose of suspending and ignoring sender reports, that a leap s= econd occurs at the end of every month
  6. Suggest senders send receiver reports in place of suspended sender repo= rts to avoid RTCP timeouts
  7. Populate Security Considerations section= with discussion of wall-clock and leap-second schedule manipulation
  8. Separate normative and informative references
= Kevin Gross
+1-303-447-0517
Media Network Consultant
<= div>AVA Networks -=A0ww= w.AVAnw.com,=A0www.X1= 92.org


On Tue, Feb 19, 2013 at 4:11 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 and Leap Seconds
=A0 =A0 =A0 =A0 Author(s) =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 Filename =A0 =A0 =A0 =A0: draft-ietf-avtcore-leap-second-02= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-19

Abstract:
=A0 =A0This document discusses issues that arise when RTP sessions span
=A0 =A0Universal Coordinate Time (UTC) leap seconds. =A0It updates RFC 3550= to
=A0 =A0describe how RTP senders and receivers should behave in the presence=
=A0 =A0of leap seconds.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap= -second

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-0= 2

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtco= re-leap-second-02


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

--20cf3003bbb697dfbd04d61cb226-- From internet-drafts@ietf.org Tue Feb 19 19:22:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7621F8818; Tue, 19 Feb 2013 19:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.385 X-Spam-Level: X-Spam-Status: No, score=-98.385 tagged_above=-999 required=5 tests=[AWL=-4.118, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, 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 w6i4wyhTC6Yf; Tue, 19 Feb 2013 19:22:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1589C21F88EA; Tue, 19 Feb 2013 19:22:13 -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.40 Message-ID: <20130220032213.7831.78003.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 19:22:13 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-02.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, 20 Feb 2013 03:22:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-02.txt Pages : 23 Date : 2013-02-19 Abstract: NTP timestamps are used by several RTP protocols for synchronisation and statistical measurements. 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-clksrc-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Tue Feb 19 19:36:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9F21F87A5 for ; Tue, 19 Feb 2013 19:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.577 X-Spam-Level: ** X-Spam-Status: No, score=2.577 tagged_above=-999 required=5 tests=[AWL=-3.779, 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 1afqxoTmr5Dv for ; Tue, 19 Feb 2013 19:36:26 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id CA85021F87A4 for ; Tue, 19 Feb 2013 19:36:26 -0800 (PST) Received: (qmail 9345 invoked by uid 0); 20 Feb 2013 03:36:03 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 20 Feb 2013 03:36:03 -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=qc0YdLaVCozwNoZL1pLOwYCLDK9u/zWlq7WW7s/lh2o=; b=JiSpEtGjNJAIWL3HwdT/aZAw0/HaB/7Gfvtoqh11z6+oeTDZ4pA/xFnjj6Qt481toqTcFh8AHRzlbbHC/oJ2Yc6SCZk8wDCeqojvt+nojedebi/4ftnrv4KA3srSLyr6; Received: from [209.85.223.178] (port=55145 helo=mail-ie0-f178.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U80TT-0008NV-7p for avt@ietf.org; Tue, 19 Feb 2013 20:36:03 -0700 Received: by mail-ie0-f178.google.com with SMTP id c13so9238577ieb.23 for ; Tue, 19 Feb 2013 19:36:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.187.197 with SMTP id fu5mr9440446igc.95.1361331362380; Tue, 19 Feb 2013 19:36:02 -0800 (PST) Received: by 10.50.183.163 with HTTP; Tue, 19 Feb 2013 19:36:02 -0800 (PST) In-Reply-To: <20130220032213.7831.78003.idtracker@ietfa.amsl.com> References: <20130220032213.7831.78003.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 20:36:02 -0700 Message-ID: From: Kevin Gross To: avt@ietf.org Content-Type: multipart/alternative; boundary=14dae9340a9546bc6704d61fa87d X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.178 authed with kevin.gross@avanw.com} Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-02.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, 20 Feb 2013 03:36:27 -0000 --14dae9340a9546bc6704d61fa87d Content-Type: text/plain; charset=ISO-8859-1 This new version addresses comments from Magnus, discussion at IETF85 and includes other minor improvements. Specifically: 1. Fixed nits 2. Added Signaling Considerations section to discuss offer/answer and other uses of the signaling 3. Added Security Considerations section 4. Added extension clues to ABNF grammar 5. Corrected some terminology issues 6. Removed synchronization quality signaling 7. Reworked media clock grammar slightly for self-consistency and consistency with reference clock signaling 8. Tie "traceable" signaling to TAI Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Feb 19, 2013 at 8:22 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-02.txt > Pages : 23 > Date : 2013-02-19 > > Abstract: > NTP timestamps are used by several RTP protocols for synchronisation > and statistical measurements. 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-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-02 > > > 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 > --14dae9340a9546bc6704d61fa87d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This new version addresses comments from Magnus, discussion at IETF85 and i= ncludes other minor improvements. Specifically:
  1. Fixed nits
    2. =
  2. Added Signaling Considerations section to discuss offer/answer and othe= r uses of the signaling
  3. Added Security Considerations section
  4. Added extension clues to = ABNF grammar
  5. Corrected some terminology issues
  6. Removed sync= hronization quality signaling
  7. Reworked media clock grammar slightly= =A0for self-consistency and consistency with reference clock signaling
  8. Tie "traceable" signaling to TAI

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


On Tue, Feb 19, 2013 at 8:22 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-02.txt<= br> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 23
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-02-19

Abstract:
=A0 =A0NTP timestamps are used by several RTP protocols for synchronisation=
=A0 =A0and statistical measurements. =A0This memo specifies SDP signalling<= br> =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-02

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


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

--14dae9340a9546bc6704d61fa87d-- From John.Fletcher@bbc.co.uk Wed Feb 20 04:27:00 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4403821F8798 for ; Wed, 20 Feb 2013 04:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.74 X-Spam-Level: X-Spam-Status: No, score=-108.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 NxjXvuNJmkQ7 for ; Wed, 20 Feb 2013 04:26:59 -0800 (PST) Received: from mailout1.thls.bbc.co.uk (mailout1.thls.bbc.co.uk [132.185.240.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9110D21F87C4 for ; Wed, 20 Feb 2013 04:26:59 -0800 (PST) Received: from BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) by mailout1.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id r1KCQvLu017896 for ; Wed, 20 Feb 2013 12:26:57 GMT Received: from BGB01XUD1011.national.core.bbc.co.uk ([169.254.10.123]) by BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) with mapi id 14.01.0355.002; Wed, 20 Feb 2013 12:26:56 +0000 From: John Fletcher To: "'avt@ietf.org'" Thread-Topic: Comments on draft-ietf-avtcore-leap-second-02 Thread-Index: Ac4PW+oi7Zd97RwzRKeER76zH4tAEA== Date: Wed, 20 Feb 2013 12:26:54 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.18] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 12:27:00 -0000 I reviewed draft-ietf-avtcore-leap-second-02 and have the following minor c= omments: Abstract - "Coordinated Universal Time" rather than "Universal Coordinate T= ime" Sections 3.1, 3.2, 3.3 - I suggest referring explicitly to "positive leap s= econd" rather than just "leap second" References - The current version of ITU Rec. TF.460 is TF.460-6 (02/02) Regards, John Fletcher -- ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From magnus.westerlund@ericsson.com Wed Feb 20 05:59:32 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941DC21F86CD for ; Wed, 20 Feb 2013 05:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.854 X-Spam-Level: X-Spam-Status: No, score=-105.854 tagged_above=-999 required=5 tests=[AWL=0.395, 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 kJ9DD-QeMDbi for ; Wed, 20 Feb 2013 05:59:31 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EB5D821F85CC for ; Wed, 20 Feb 2013 05:59:30 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-ba-5124d6c16670 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 40.C8.19728.1C6D4215; Wed, 20 Feb 2013 14:59:29 +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; Wed, 20 Feb 2013 14:59:29 +0100 Message-ID: <5124D6B9.6060706@ericsson.com> Date: Wed, 20 Feb 2013 14:59:21 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <20121015142026.6075.9386.idtracker@ietfa.amsl.com> <507C1C7C.8080007@ericsson.com> <5F7BCCF5541B7444830A2288ABBEBC96218D0E7C54@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC96218D0E7C54@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvje7BayqBBu1N1hZ/Wn8xWrzsWcnu wOTR+mwvq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIWbKgo2GVacWPye6YGxl9aXYycHBICJhLd H4+zQdhiEhfurQeyuTiEBE4ySqz5+JIdwlnOKDF/7S9GkCpeAW2JTadfsYPYLAKqEj9adrOC 2GwCFhI3fzSCTRIVCJbYcHAVE0S9oMTJmU9YQGwRAQ+J+wuOgdUwCyhJzF36mhnEFhaIlXhz dQHU5s2MEnvWHABr4BRIkDiz7xdQEQfQeeISa95wQPTqSUy52sIIYctLNG+dDTZHCOi2hqYO 1gmMQrOQrJ6FpGUWkpYFjMyrGNlzEzNz0suNNjECQ/Xglt+qOxjvnBM5xCjNwaIkzhvueiFA SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6N9wZ7uO+JO1XNeHDuwpiAmJMTnRcSN+wvvMGvf uXI2bPvxD/v31c8TZFD44BTGd/xp06va4IwHT0xmTVw/fS/DRRm7lB0BBmrXZrCcb/h7I/cV b8klzcjdxy7elVV5FCtwWqCp+AHftMuc6q+8J8myvc+ZaHkvJ2jj9zOvTUsTNE+lMpZM/7dZ iaU4I9FQi7moOBEAGTgpVSMCAAA= 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, 20 Feb 2013 13:59:32 -0000 Hi Albert, I am very sorry for the long time until I replied to this. It took a long time until I started editing in comments and preparing a new version of the draft. Please see inline for my comments on your valuable comments. On 2012-10-16 17:01, Schwarz, Albrecht (Albrecht) wrote: > Dear All! > > RFC 5117 was already a good progress wrt RFC 1889/3550, but is still > at some areas too high-level in my opinion. Thus, I support any > update activity of RFC 5117. Based on your comments, I conclude that you desire a standards track specification for the behavior for all RTP and RTCP fields including all existing extensions how to process them in each topology. >From my perspective, this document is not that document. It is an important high level discussion tool, but it is not a specification for how the behavior must be. > > BTW: this was also recently discussed in ITU-T SG16 Q3; there's a > work item on "RTP topology dependent RTCP handling by H.248 Media > Gateways with IP Terminations", called H.248.RTPTOPO. The latest > draft may be downloaded via > http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-21.zip > > Concerning >> - What do you think a topology discussion should contain. There >> will be variations over the different topologies in this document. > > 1) Terminology What's still missing is an explicit definition for > "RTP topology". Should be added in section 2. The definition should > answer the question "what constitutes exactly an RTP topology"? There > are different interpretations, such as "number and type of media > interfaces" towards a characterization of an RTP topology based on > the six properties of section 4.1. But even such properties should be > made more precise in my opinion. I don't think I can provide an definition of an RTP topology that is more precise than: A method for interconnecting RTP entities and its processing behavior of RTP and RTCP is called an RTP topology. > > 2) RTP topology dependent RTP media packet handling Comprehensive > summary - which RTP header elements may or may not be modified under > a particular RTP topology - whether RTP payload may or may not be > modified under a particular RTP topology I think doing what you suggest would take this document way beyond its informational status into an RFC 3550 update with processing rules. What I have done is an attempt to clarify what I consider as the important aspects that needs to be discussed on a high level and which I think reflects the aspects discussed in the comparisions: - How it interconnect RTP/RTCP aware entities - How RTP entities process the encoded media present in the RTP flows - How it manages identity and visibility of any other RTP entities and their media sources. > > 3) RTP topology dependent RTCP packet handling Comprehensive summary > - which RTCP elements may or may not be modified under a particular > RTP topology The existing text provides partial information, > sometimes too high level. It's also fairly difficult or even > impossible to consider all possible RTCP information types under a > particular topology, leading to (4): See 2) > > 4) Introduction of an RTCP service concept Well known problem: a RTP > transport translator shall be also used as measurement and reporting > point of RTCP XR type of performance metrics. => Contradiction: > different handling of RTCP basic and extension reports, SSRC usage, > ...:-( Possible solution: define different levels of RTCP services, > such as > a) basic RTCP service (given by RFC 3550 core protocol) > b) RTP profile dependent RTCP service (given by RTP profile specification) > c) supplementary RTCP service (such as RFC 3611, 5760, 6051, ...) > > Above problem could be then solved by coupling (a) and (b) type of > RTCP services with the RTP topology, and consider (c) as "overlay" > (and topology independent). See also Draft H.248.RTPTOPO. I don't understand which problem you are bringing up. Is your problem that middleboxes treats different extensions differently, for example doesn't forward them? I see RTP as a tool box, when building a service you actually have to specify what expected behavior you want out of the system components, and in the case of RTP, middleboxes also needs to be specified. Yes, RTP might not provide the most clear tool specifications when it comes to behavior so that you can point to it and say. I want this and this behavior. Yes, such updates could be done in the AVTCORE WG. However, it is not this document. If you needs this I would recommend you to try to determine interest for this and start up work on this. > > > 5) Missing RTP topologies There are two further topologies, which > we've observed in middle boxes, SBCs, H.323 gateways, H.248 IP-IP > gateways, but missing in RFC 5117: > > a) Back-to-Back RTP Endsystem (B2BRE): e.g. a topology within the > end-to-end path of the PtP topology. Please note that clause 3.1 does > not describe the B2BRE topology. E.g., RTP end-to-end path between A > - MB - B (with MB as middle box) A = RTP topology "RTP endsystem" > (RFC 3550 notation; now perhaps "endpoint") B = ditto MB = RTP > topology "B2BRE" This is having the Middlebox have two different RTP sessions. Then function as an application gateway. I think this may be worth discussing as it has some significant implications on the session. > > The MP separates the e2e RTP network in two domains, e.g. a > separation of the SSRC space. > > b) Topology "transparent forwarding" e.g. required for SRTP-to-SRTP > forwarding see definition in H.248.RTPTOPO I fail to see what is different for this topology compared to the transport translator in the special case that it has only two single end-points in the RTP session. If the middlebox in a point to point scenario only rewrites the transport layer information this happens without the RTP level really needs to be aware of it. This behavior is common, and can be achieved using TURN servers, media anchoring SBG etc. This was already present in Section 3.4.1, however I am looking at pulling this out to a new sub-section for point to point with middleboxes. That is also where I plan to add some discussion on B2B RTP sessions. Thanks 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 aallison@nab.org Wed Feb 20 06:38:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC2A21F87E4 for ; Wed, 20 Feb 2013 06:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnNfTmmPbWU6 for ; Wed, 20 Feb 2013 06:38:49 -0800 (PST) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by ietfa.amsl.com (Postfix) with ESMTP id 830FB21F87D7 for ; Wed, 20 Feb 2013 06:38:49 -0800 (PST) Received: from unknown [208.97.234.91] (EHLO NABSREX027324.NAB.ORG) by p01c12o145.mxlogic.net(mxl_mta-7.0.0-0) with ESMTP id 2ffd4215.0.60308.00-306.138654.p01c12o145.mxlogic.net (envelope-from ); Wed, 20 Feb 2013 07:38:49 -0700 (MST) X-MXL-Hash: 5124dff96f3463a9-b9dd03533883363d5ca048ba341d4f435a3a68f7 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Feb 2013 09:38:41 -0500 Message-ID: <71C9EC0544D1F64D8B7D91EDCC6220200D3C959D@NABSREX027324.NAB.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-02 Thread-Index: Ac4Pd/o3CuH5eJAETJuZXej1kzfJIQ== From: "Art Allison" To: X-AnalysisOut: [v=2.0 cv=UtLUwZMB c=1 sm=1 a=tFGTPFZixTZ3yCXJchW01Q==:17 a] X-AnalysisOut: [=LsjFi0dg7PUA:10 a=BvPfnLs-15kA:10 a=BLceEmwcHowA:10 a=kj9] X-AnalysisOut: [zAlcOel0A:10 a=g0FpLpFZAAAA:8 a=uCUPCwGLCVYA:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=aSRvjw2BAAAA:8 a=9uOXDsI2AAAA:8 a=H2u__FOoLHHh25b] X-AnalysisOut: [mzXQA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=_jAYm6HYijML] X-AnalysisOut: [RVBd:21 a=8SOw4Wcyap9P-KcB:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 14:38:54 -0000 Correct, and the use of the abbreviation UTC is indeed correct. This is a classic standards compromise as unanimous agreement could not be achieved by the ITU on using either the English word order, CUT, or the French word order, TUC, so the compromise to use neither was reached. Art Allison=20 -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of John Fletcher Sent: Wednesday, February 20, 2013 7:27 AM To: 'avt@ietf.org' Subject: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-02 I reviewed draft-ietf-avtcore-leap-second-02 and have the following minor comments: Abstract - "Coordinated Universal Time" rather than "Universal Coordinate Time" Sections 3.1, 3.2, 3.3 - I suggest referring explicitly to "positive leap second" rather than just "leap second" References - The current version of ITU Rec. TF.460 is TF.460-6 (02/02) Regards, John Fletcher -- ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From John.Fletcher@bbc.co.uk Wed Feb 20 07:56:49 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08421F869E for ; Wed, 20 Feb 2013 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.492 X-Spam-Level: X-Spam-Status: No, score=-107.492 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8SvKBpNdNP0r for ; Wed, 20 Feb 2013 07:56:48 -0800 (PST) Received: from mailout0.thls.bbc.co.uk (mailout0.thls.bbc.co.uk [132.185.240.35]) by ietfa.amsl.com (Postfix) with ESMTP id 398BF21F8816 for ; Wed, 20 Feb 2013 07:56:47 -0800 (PST) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout0.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id r1KFuiMv004324 for ; Wed, 20 Feb 2013 15:56:44 GMT Received: from BGB01XUD1011.national.core.bbc.co.uk ([169.254.10.123]) by BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) with mapi id 14.01.0355.002; Wed, 20 Feb 2013 15:56:43 +0000 From: John Fletcher To: "avt@ietf.org" Thread-Topic: Comments on draft-ietf-avtcore-clksrc-02 Thread-Index: Ac4Pft/1DfF/CWiBTciGpjK1JiCusw== Date: Wed, 20 Feb 2013 15:56:43 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.14.18] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:56:49 -0000 I have reviewed draft-ietf-avtcore-clksrc-02 and have the following comment= s: Abstract - Suggest use of the term "NTP format" to make it clear that the s= ource of the timestamp may not have been NTP, e.g. it might have been PTP. Introduction - A better/alternative reference for "genlock" is SMPTE ST 318= -1999. Introduction - AES11 (DARS) is preferred over "word clock" as an audio refe= rence signal. Section 4 - Suggest mentioning PTP as well as NTP as examples of network ti= me protocols. Section 4.7 - Would it be worth including items for PTP grandmaster paramet= ers clockClass, clockAccuracy and timeSource? Even if clocks had a differe= nt grandmaster, they might still be considered equivalent if both locked to= a primary reference time source. Regards, John Fletcher ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From magnus.westerlund@ericsson.com Thu Feb 21 05:28:16 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACC021F8438 for ; Thu, 21 Feb 2013 05:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.365, 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 Tbsbd1YPApCh for ; Thu, 21 Feb 2013 05:28:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 265BE21F8936 for ; Thu, 21 Feb 2013 05:28:12 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-51-512620eb78b2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.17.19728.BE026215; Thu, 21 Feb 2013 14:28:11 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 21 Feb 2013 14:28:12 +0100 Message-ID: <512620EB.5000307@ericsson.com> Date: Thu, 21 Feb 2013 14:28:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.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.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Rve1glqgwby75hYve1ayW/xtZ3Zg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MhYdeM9csF2k4tXbeawNjIsEuhg5OSQETCSW bDjMCGGLSVy4t56ti5GLQ0jgJKPE5uNXWSGc5YwSVyctYgOp4hXQlvi17BwTiM0ioCox5dEt FhCbTcBC4uaPRrAaUYFgiQ0HVzFB1AtKnJz5BKxGREBN4vXaz0A1HBzMAioSbw8XgoSFBWIl Nv67AbWrm1Fi9bludpAaTqCZk74kgpgSAuISa95wgJQzC+hJTLnawghhy0s0b53NDGILAV3W 0NTBOoFRaBaSxbOQtMxC0rKAkXkVI3tuYmZOernRJkZgmB7c8lt1B+OdcyKHGKU5WJTEecNd LwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNym7L9FOrehddIP5zbuR/obih9KXNVpqXWc tsLxzN1pXyQ/NXn+4ireFyzodu1XurXrmf/XlFPfTJ76W/f11FabbJeOLq3+fa6b2yy9NXrE klXjDKZP75jIGCX8uCuz8Cl7o1eM/4HoBeU1T8R4b+5M4NLZw/Hx+gvrqm3nqhbeqJwctVKj RomlOCPRUIu5qDgRAHu+uzghAgAA 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: Thu, 21 Feb 2013 13:28:17 -0000 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). Ok, I will start adding, but I likely need reviewers to help hint where it needs to be further discussed. > 2. I did not fully understand the SSRC behavior for source projecting > middlebox and how it is different from the topologies in 3.5. I have tried to make clearer examples. However, I don't know which aspect that you are uncertain about. The source projecting mixer will expose all the other RTP media streams that the endpoint doesn't produce themselves towards them. The SSRC values actually used may be remapped. Then there can exist control logic that selects the RTP streams to translate and transmit towards a given end-point. Cheers Magnus > > In general the document is good starting point, the SSRC issues are > discussed but need more review. > I have some other comments but they are more topology specific. > > Roni Even > As individual > > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: 15 October, 2012 4:24 PM > To: IETF AVTCore WG > Subject: [AVTCORE] Fwd: I-D Action: > draft-westerlund-avtcore-rtp-topologies-update-01.txt > > WG, > > As individual > > We have submitted two versions of this draft. The 00 is an XML2RFC generated > version from the text present in RFC 5117. The 01 version is a first update. > This focus on the RTP topologies present in the draft. The text is kind of > rough, so I would suggest that you focus on the questions: > > - Are this the topologies the document should describe? Missing, redundant > etc. > - What do you think a topology discussion should contain. There will be > variations over the different topologies in this document. > > Cheers > > Magnus Westerlund > > > -- 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 Aidan.Williams@audinate.com Thu Feb 21 21:36:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAC621E805F for ; Thu, 21 Feb 2013 21:36: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 szb8TeBq-ItQ for ; Thu, 21 Feb 2013 21:36:47 -0800 (PST) Received: from sydney.audinate.com (sydney.audinate.com [150.101.200.21]) by ietfa.amsl.com (Postfix) with ESMTP id 866E021E805D for ; Thu, 21 Feb 2013 21:36:46 -0800 (PST) Received: from zimbra.audinate.com (zimbra.audinate.com [10.12.0.6]) by sydney.audinate.com (Postfix) with ESMTP id 14F5818028E; Fri, 22 Feb 2013 16:36:44 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by zimbra.audinate.com (Postfix) with ESMTP id F0DE17684AE; Fri, 22 Feb 2013 16:36:43 +1100 (EST) X-Virus-Scanned: amavisd-new at zimbra.audinate.com Received: from zimbra.audinate.com ([127.0.0.1]) by localhost (zimbra.audinate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L59QNOuZEKTB; Fri, 22 Feb 2013 16:36:41 +1100 (EST) Received: from zimbra.audinate.com (localhost [127.0.0.1]) by zimbra.audinate.com (Postfix) with ESMTP id E7F5B768483; Fri, 22 Feb 2013 16:36:41 +1100 (EST) Date: Fri, 22 Feb 2013 16:36:40 +1100 (EST) From: Aidan Williams To: John Fletcher Message-ID: <4921008.765.1361511397205.JavaMail.aidan@praxis.local> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_763_26654773.1361511397204" X-Originating-IP: [10.12.0.106] X-Mailer: Zimbra 6.0.16_GA_2998 (Zimbra Desktop/7.2.1_11637_Mac) Cc: avt@ietf.org Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 05:36:48 -0000 ------=_Part_763_26654773.1361511397204 Content-Type: multipart/related; boundary="----=_Part_764_1551538.1361511397204" ------=_Part_764_1551538.1361511397204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi John, Thanks for your comments and reference suggestions. ... > Section 4.7 - Would it be worth including items for PTP grandmaster > parameters clockClass, clockAccuracy and timeSource? Even if clocks > had a different grandmaster, they might still be considered > equivalent if both locked to a primary reference time source. To allow PTP, NTP or local clocks locked to primary sources to be considered equivalent, the signalling supports the "traceable" keyword. "Traceable" means that the clock is ultimately sourced from TAI. Clocks that are signalled as as traceable can be considered equivalent (see section 4.6). regards aidan ____ :wq! ------=_Part_764_1551538.1361511397204-- ------=_Part_763_26654773.1361511397204-- From internet-drafts@ietf.org Fri Feb 22 06:08:19 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE6721F8EAF; Fri, 22 Feb 2013 06:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 Et52ptHYiZb3; Fri, 22 Feb 2013 06:08:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D7A21F8ECA; Fri, 22 Feb 2013 06:08:19 -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.40 Message-ID: <20130222140819.29309.8524.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 06:08:19 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:08:20 -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 : AES-GCM and AES-CCM Authenticated Encryption in Secure R= TP (SRTP) Author(s) : David A. McGrew Kevin M. Igoe Filename : draft-ietf-avtcore-srtp-aes-gcm-05.txt Pages : 29 Date : 2013-02-22 Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kevin.gross@avanw.com Sat Feb 23 10:52:09 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1955921F8F36 for ; Sat, 23 Feb 2013 10:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=0.443, 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 Jt92BHnD0HOT for ; Sat, 23 Feb 2013 10:52:08 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 591C021F8F15 for ; Sat, 23 Feb 2013 10:52:08 -0800 (PST) Received: (qmail 14670 invoked by uid 0); 23 Feb 2013 18:51:47 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy3.bluehost.com with SMTP; 23 Feb 2013 18:51:47 -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=e+y3hEiutLfJy7n3ZUgvkyimzOyTzmd+QSynDCDCKdM=; b=gZLnPC4v7jA0xqYke47m+dHqsnQNI8NjMSaZArLks5hx58fUx/961VeDfC4LYJKgASZrURQr7U0VaVhkMkqG4Todkx5Y+/ol85np58xIVmA/zxfDhKLgkFKPdf/JYLwy; Received: from [209.85.210.169] (port=65128 helo=mail-ia0-f169.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1U9KCI-0002JU-Tb for avt@ietf.org; Sat, 23 Feb 2013 11:51:46 -0700 Received: by mail-ia0-f169.google.com with SMTP id j5so1489074iaf.0 for ; Sat, 23 Feb 2013 10:51:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.108.235 with SMTP id hn11mr1081569igb.107.1361645506085; Sat, 23 Feb 2013 10:51:46 -0800 (PST) Received: by 10.50.183.163 with HTTP; Sat, 23 Feb 2013 10:51:46 -0800 (PST) In-Reply-To: References: Date: Sat, 23 Feb 2013 11:51:46 -0700 Message-ID: From: Kevin Gross To: John Fletcher Content-Type: multipart/alternative; boundary=f46d0402aeefb342f004d668cc9c X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.169 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-leap-second-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:52:09 -0000 --f46d0402aeefb342f004d668cc9c Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review John. These look like good improvements and I will publish a new version after IETF86 incorporating these and any other suggestions I receive. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Wed, Feb 20, 2013 at 5:26 AM, John Fletcher wrote: > I reviewed draft-ietf-avtcore-leap-second-02 and have the following minor > comments: > > Abstract - "Coordinated Universal Time" rather than "Universal Coordinate > Time" > > Sections 3.1, 3.2, 3.3 - I suggest referring explicitly to "positive leap > second" rather than just "leap second" > > References - The current version of ITU Rec. TF.460 is TF.460-6 (02/02) > > > Regards, > John Fletcher > -- > > > > ----------------------------- > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and > may contain personal views which are not the views of the BBC unless > specifically stated. > If you have received it in > error, please delete it from your system. > Do not use, copy or disclose the > information in any way nor act in reliance on it and notify the sender > immediately. > Please note that the BBC monitors e-mails > sent or received. > Further communication will signify your consent to > this. > ----------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d0402aeefb342f004d668cc9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the review John. These look like good=A0improvements=A0and I wil= l publish a new version after IETF86 incorporating these and any other=A0su= ggestions I receive.

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


On Wed, Feb 20, 2013 at 5:26 AM, John Fl= etcher <John.Fletcher@bbc.co.uk> wrote:
I reviewed draft-ietf-avtcore-leap-second-02 and have the following minor c= omments:

Abstract - "Coordinated Universal Time" rather than "Univers= al Coordinate Time"

Sections 3.1, 3.2, 3.3 - I suggest referring explicitly to "positive l= eap second" rather than just "leap second"

References - The current version of ITU Rec. TF.460 is TF.460-6 (02/02)


Regards,
John Fletcher
--



-----------------------------
http://www.bbc.co.uk=
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specif= ically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d0402aeefb342f004d668cc9c-- From csp@csperkins.org Sat Feb 23 10:57:51 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAF621F86E8 for ; Sat, 23 Feb 2013 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 f2PaHNzT3tJ2 for ; Sat, 23 Feb 2013 10:57:50 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBB21F86C2 for ; Sat, 23 Feb 2013 10:57:50 -0800 (PST) Received: from [80.176.158.71] (port=40926 helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1U9KHx-0007zg-EN; Sat, 23 Feb 2013 18:57:38 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5CC8F49-ED07-4C3B-9E36-0CA1D302D0F4" From: Colin Perkins In-Reply-To: Date: Sat, 23 Feb 2013 18:57:35 +0000 Message-Id: <183330F1-1D37-4C48-BC15-FAF91DC8B34C@csperkins.org> References: <20121022221624.7138.24306.idtracker@ietfa.amsl.com> <2B95330E-6BF9-4F14-9F36-9E2CDF48A96D@csperkins.org> To: Kevin Gross X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = 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: Sat, 23 Feb 2013 18:57:51 -0000 --Apple-Mail=_E5CC8F49-ED07-4C3B-9E36-0CA1D302D0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Kevin, If the problem is congestion collapse, then a factor of ten reduction in = sending rate may well help. However, I see your point, and will change = the draft to only suggest ceasing transmission for this circuit breaker. Colin On 18 Feb 2013, at 16:48, Kevin Gross wrote: > Because the circuit breaker is conservative, my assessment is that = things are clearly badly busted when the breaker trips. In this case, = over the duration of 3 RRs, not a single RTP packet has been delivered. = If this is due to moderate congestion or flow control, you'd expect at = least a few of the packets to get through. If none are getting through, = there is either a connectivity problem or possibly congestive collapse. = In neither case is reducing rate by a factor of 10 a useful response. = Have I missed something? What sort of failure scenario are you thinking = of where the reduced rate would be successful? >=20 > I am also concerned about scope. Circuit breakers are a safety net and = should not interfere with congestion management techniques as they are = developed. Circuit breakers should conservatively detect faults and = trip. They should not half-trip or automatically reset themselves. >=20 > On Tue, Feb 12, 2013 at 5:18 PM, Colin Perkins = wrote: >> 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. >=20 > If this were a congestion control algorithm, I'd probably agree that = we should be more aggressive in stopping transmission here, but the = circuit breaker is supposed to be conservative when it fires, to = encompass all reasonable congestion control behaviours. As such, I think = it is better that the draft allow the option of reducing offered load as = a response here, rather than mandate ceasing transmission immediately. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_E5CC8F49-ED07-4C3B-9E36-0CA1D302D0F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Because the circuit breaker is = conservative, my assessment is that things are clearly badly busted when = the breaker trips. In this case, over the duration of 3 RRs, not a = single RTP packet has been delivered. If this is due to moderate = congestion or flow control, you'd expect at least a few of the packets = to get through. If none are getting through, there is either a = connectivity problem or possibly congestive collapse. In neither case is = reducing rate by a factor of 10 a useful response. Have I missed = something? What sort of failure scenario are you thinking of where the = reduced rate would be successful?

I am also concerned about scope. Circuit breakers are a = safety net and should not interfere with congestion management = techniques as they are developed. Circuit breakers should = conservatively detect faults and trip. They should not half-trip or = automatically reset themselves.

On Tue, Feb 12, 2013 at 5:18 PM, = Colin Perkins <csp@csperkins.org> wrote:
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.

If this were a congestion control = algorithm, I'd probably agree that we should be more aggressive in = stopping transmission here, but the circuit breaker is supposed to be = conservative when it fires, to encompass all reasonable congestion = control behaviours. As such, I think it is better that the draft allow = the option of reducing offered load as a response here, rather than = mandate ceasing transmission = immediately.
=


-- 
Colin Perkins



= --Apple-Mail=_E5CC8F49-ED07-4C3B-9E36-0CA1D302D0F4-- From internet-drafts@ietf.org Mon Feb 25 07:00:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2521F945B; Mon, 25 Feb 2013 07:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 mRLRcfTHB8+8; Mon, 25 Feb 2013 07:00:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E821321F945C; Mon, 25 Feb 2013 07:00:49 -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.40 Message-ID: <20130225150049.15238.29759.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:00:49 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-circuit-breakers-02.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, 25 Feb 2013 15:00:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Multimedia Congestion Control: Circuit Breakers for Unic= ast RTP Sessions Author(s) : Colin Perkins Varun Singh Filename : draft-ietf-avtcore-rtp-circuit-breakers-02.txt Pages : 17 Date : 2013-02-25 Abstract: The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP "circuit-breakers". Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-circuit-breakers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-circuit-breakers-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-circuit-breakers-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Feb 25 08:28:08 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7821F925F for ; Mon, 25 Feb 2013 08:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.934 X-Spam-Level: X-Spam-Status: No, score=-105.934 tagged_above=-999 required=5 tests=[AWL=0.315, 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 zR7-vrbmN4zf for ; Mon, 25 Feb 2013 08:28:07 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF5021F9269 for ; Mon, 25 Feb 2013 08:28:03 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-5c-512b910c0145 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 98.FA.32353.C019B215; Mon, 25 Feb 2013 17:27:56 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Feb 2013 17:27:55 +0100 Message-ID: <512B910B.7020305@ericsson.com> Date: Mon, 25 Feb 2013 17:27:55 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF AVTCore WG References: <20130225162426.8557.62476.idtracker@ietfa.amsl.com> In-Reply-To: <20130225162426.8557.62476.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130225162426.8557.62476.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------040801050706030805060605" X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURjAObt3u9eVebSpnwoZC6E0H5WkQaQlkoTh64/Cglw5fDRNpplQ yDKTGIppDnVJ+UKdJstpvtBA85HNTDHRqSsVhZVZmmAPXbbdO8L++33n/r7H+c6lCTsd15lO SE4TS5NFEiGPT5ZeNN7x3F3gEeGTX4z9P+WqqEAUUl39ixOOovknY8WShHSx1PtUDD/+aftj KiX/eEavvJKUoWFvObKiAfvCtELBZdkBRj+oeWa2w0MISt6GyRHfxLUIXhVlc8wfrLEHrNdr STOT2A2eVGxTZuZhf9D9vGtKpml7HAW6qn2sbgtDpYuMLsBCaC9sJcy8F4dB3bCey/YKBN3C KnNuhU/D9LKCMpcB7AjPvtDsaKHQ3FDITEDgcOge03LYVA+QZT3gPkS2yh3dlDs0lr2gaCIb sewKbStlBMsS+POykPz/nG/iHARFQyuMBDgGdJ06UsmsohNBU/G4JWhCoK4wWixfmNOMU/+s LW2jJVAgWPi+waSQ2EhAV5kMsSnuUPtmkpmQxIdgeyCHq2Qu1YJgezOddQ5CiWrU5Jv3YQON vQeUlqeqnprgsGwN2qJBHsu3oW7znqWxDkHeuyyCDZoRjMjnGYuH98PnNRVlLirALqBdslEy b3IOSgxTlqIC+DoxT7B9HaBDn8EuOBBm6iotI7tB7ux9y1WEsJ3ziCpHx+oRlSRKkMTd8tMg 0+/Z07Lp0440Hx16kQtNCh2tLwSPhtvhOFGa+LpYnCKWXpHelIhTexGHtnKWIdfOnkyv7BBj 5MSS57J9/9FZQ8Mu+zZDYlCfQRaTXHVmMmxu6X2s6jcRcV4Q6he6Ut8a9drLySn4xrfmxPzy imsFAT/GzlbMepf5K4efR/anX/K9WjOgh+5Bft7lIAGsdmyp3RYbX8wkdZ3QZ27UjKxHUwOD awF7Dms2vfqybdVCMjVedMSdkKaK/gLT0/urbAMAAA== Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-02.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, 25 Feb 2013 16:28:08 -0000 --------------040801050706030805060605 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit We have submitted an update of the Topologies draft. It attempts to resolve most of the comments we have received. It also restructures things a bit, by including PtP scenarions where middleboxes are included. Cheers Magnus --------------040801050706030805060605 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-rtp-topologies-update-02_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-westerlund-avtcore-rtp-topologies-update-0"; filename*1="2_txt.eml" X-Mozilla-Keys: Received: from esessmw0197.eemea.ericsson.se (153.88.115.87) by ESESSHC003.ericsson.se (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 25 Feb 2013 17:24:42 +0100 Received: from sesbmg11.ericsson.net (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.89) with Microsoft SMTP Server id 8.3.279.1; Mon, 25 Feb 2013 17:24:38 +0100 X-AuditID: c1b4fb39-b7fa76d000000f89-99-512b9042d30c Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by sesbmg11.ericsson.net (Symantec Mail Security) with SMTP id 12.12.03977.3409B215; Mon, 25 Feb 2013 17:24:38 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2D921F9555; Mon, 25 Feb 2013 08:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1361809469; bh=BiJDfoB5fbsdn9aA6bJQEhi+EgDFtcMRiJiG7DBOYXg=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=cABr6d1KEUgxrq+09kf79gJeQ3gH3Kkmhxn3MqB+6yYv0Tr4Syry6l7+nwsEDSO8D XJMIU9IAcKqlnFv1lggl+xsGlQ7mdDfcJge8YELcsn41ZTsrg738wRroQCscegefWZ +q2IclBBJJS1WYRsUJIvJQiyixZRPg06+S+f7rPU= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169221F9555 for ; Mon, 25 Feb 2013 08:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 zlNuW9pPYFNJ for ; Mon, 25 Feb 2013 08:24:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307F521F9510 for ; Mon, 25 Feb 2013 08:24:26 -0800 (PST) From: To: Subject: I-D Action: draft-westerlund-avtcore-rtp-topologies-update-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225162426.8557.62476.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 08:24:26 -0800 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: i-d-announce-bounces@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa0hTYRjedza349qxz83L6yqjmVFa2iDqdBMriAqC+mMlSG113JZzys6K RUE2a5WkaNE0maPG6KKGYYMtikCLhaOrpSkzKzRZVguCwrKwnZ3Z5d/z8Vxf+Eih3CdWkozV wphNGqNKLBUVtmozl2ysz92+dDyIadsrr4Q+NjRC0MdsLN32bgPd2zFM0GOOn2I65BqS0E3O 7xK68cRaeuJ2e0KhdNOPr33ibahYumYfYzQcZMz5BXuk+vDZD6jy/gxrxF5ShXyJNSiRBLwM 3nQ+l/A4DZ4Od4hrkJSUYz+Ce99fI/7RiODro8sS7iHCv4Rwx1mFeEsOXAm+JDgswotgKmBP 4B1eBOF3tfHchdB07WnUQEbxTLjenTVd5xnoI3icBM/CE3F8GK5OVkv4nBCCEZcnvukmgtMd 7SJOReFk6LkwGsNinAlt447YohScAc0PW2LFCrwFmsID8dQUiPS9FfIj0uDWKysfUwihq+74 AdlwZuhE/DAVTNnPxfdnQE3taAxjjMHluRXTy6Mah2Mwppfh9dASGSa4nTJcjcDW7ErgumR4 HRyfLOI1i2DwiSuuL4DWRq+kHmU3/3MNh4V4MVy8/UXM47ng++QUXkTCVpTKMqy2XKdW5zFm w16WrTDlmRhLJ4r+li7v5Eo/cntWdKMMklClUu9P5m6XJ2kr9h3Sa1j9bvMBI8N2o1mkSJVO +UOebXKs01iYMoapZMzT7GySVAG1tS7qTDYzOsZaajBa/tIEmdiNgJSpUqhRTkOxlZpy1qDj +SCap0ynxjgCc4T+gOmPd/o/96I5SgWFBAKBXBbtLTdY/ufHUTqJVApKzaXIDCbLn/TxaDER LXanxIotmr+UsgqpCZfrwaja7YyMLGDaJXu3zN215FtSYOi8cKwjPShYnteTX+xeVxzKVj/P 6n/hqK7baaur+HKposxXpq+aKjlcGnwc2JxqqC9JNLztD6D9M/XDn+ffWL3q7o4EZ0PR1o3W Ux+9L7KUR2v9fkVXWwQ3ZDqOhNK09on84GRO8jJaJWL1GnWO0MxqfgNTFfu0ygMAAA== Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: esessmw0197.eemea.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Topologies Author(s) : Magnus Westerlund Stephan Wenger Filename : draft-westerlund-avtcore-rtp-topologies-update-02.txt Pages : 37 Date : 2013-02-25 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and are intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-rtp-topologies-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-topologies-update-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-westerlund-avtcore-rtp-topologies-update-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------040801050706030805060605-- From internet-drafts@ietf.org Mon Feb 25 13:26:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213E21E809D; Mon, 25 Feb 2013 13:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 jt6UhtF0gdSs; Mon, 25 Feb 2013 13:26:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DA321E80F2; Mon, 25 Feb 2013 13:26:12 -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.40 Message-ID: <20130225212612.15657.15564.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:26:12 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-media-rtp-session-02.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, 25 Feb 2013 21:26:13 -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 : Multiple Media Types in an RTP Session Author(s) : Magnus Westerlund Colin Perkins Jonathan Lennox Filename : draft-ietf-avtcore-multi-media-rtp-session-02.txt Pages : 22 Date : 2013-02-25 Abstract: This document specifies how an RTP session can contain media streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-multi-media-rtp-sessi= on-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 15:45:37 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029E821E8188; Mon, 25 Feb 2013 15:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DulXC-mNsTlG; Mon, 25 Feb 2013 15:45:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855DE21E8179; Mon, 25 Feb 2013 15:45:35 -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.40 Message-ID: <20130225234535.9047.4984.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:45:35 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-02.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, 25 Feb 2013 23:45:37 -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 : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-02.txt Pages : 28 Date : 2013-02-25 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 15:55:09 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6121E818A; Mon, 25 Feb 2013 15:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5d5YHylM4QZ; Mon, 25 Feb 2013 15:55:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCF51F0D0B; Mon, 25 Feb 2013 15:55:06 -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.40 Message-ID: <20130225235506.11217.53358.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:55:06 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-12.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, 25 Feb 2013 23:55:09 -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-12.txt Pages : 10 Date : 2013-02-25 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/