IETF Logo Mail Archive

Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 10 November 2014 02:49 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA41A88AD for <avt@ietfa.amsl.com>; Sun, 9 Nov 2014 18:49:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.493
X-Spam-Level:
X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zm2Mr3ReUf8y for <avt@ietfa.amsl.com>; Sun, 9 Nov 2014 18:49:07 -0800 (PST)
Received: from BLU004-OMC2S22.hotmail.com (blu004-omc2s22.hotmail.com [65.55.111.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6171A88A8 for <avt@ietf.org>; Sun, 9 Nov 2014 18:49:06 -0800 (PST)
Received: from BLU406-EAS54 ([65.55.111.72]) by BLU004-OMC2S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 9 Nov 2014 18:49:06 -0800
X-TMN: [At3uJCsx7nX9snyKF1+L7gHu6nKWyAsY]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS5463A27F693B9C54A38A7893800@phx.gbl>
Content-Type: multipart/alternative; boundary="Apple-Mail-C8EF9E9C-235E-43B8-BC94-F4A914B5081C"
Content-Transfer-Encoding: 7bit
References: <00db01cffc02$d2420570$76c61050$@gmail.com> <BLU406-EAS383384AE62B39AFD34A534093830@phx.gbl> <67E33217-A222-4B34-846D-79231DB463D9@vidyo.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <67E33217-A222-4B34-846D-79231DB463D9@vidyo.com>
Date: Sun, 09 Nov 2014 16:49:01 -1000
To: Jonathan Lennox <jonathan@vidyo.com>
X-OriginalArrivalTime: 10 Nov 2014 02:49:06.0507 (UTC) FILETIME=[E50899B0:01CFFC90]
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/qVwLEjWCrPkVlK8Idbi5dGIX68g
Cc: IETF AVTCore WG <avt@ietf.org>
Subject: Re: [AVTCORE] comment on draft-jones-avtcore-private-media-reqts-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Nov 2014 02:49:08 -0000

On Nov 9, 2014, at 1:33 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>> And even then there are probably some cases it wouldn’t be able to cover, like the ability for an SFU to pull apart or synthesize RED packets for audio.

[BA] which is a reminder that this impacts audio conferencing as well. It is not possible to mix audio payloads that cannot be decrypted and decoded. With RFC 6464 and endpoint mixing, forwarding can be viable, but forget about transcoding in the middlebox.

v2.23.0 | Report a Bug | By Email