[MMUSIC] Query: Usage of enrypted vs unencrypted RTP extensions

Harald Alvestrand <harald@alvestrand.no> Fri, 21 February 2020 13:28 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB312010E for <mmusic@ietfa.amsl.com>; Fri, 21 Feb 2020 05:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 BhZW3pf4L_Rb for <mmusic@ietfa.amsl.com>; Fri, 21 Feb 2020 05:28:20 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472181200D6 for <mmusic@ietf.org>; Fri, 21 Feb 2020 05:28:20 -0800 (PST)
Received: from [192.168.3.157] (unknown [82.194.207.93]) by mork.alvestrand.no (Postfix) with ESMTPSA id 347AF7C52EB for <mmusic@ietf.org>; Fri, 21 Feb 2020 14:28:18 +0100 (CET)
To: mmusic@ietf.org
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <00b36a9a-a035-5dc5-a868-47cb8aced8be@alvestrand.no>
Date: Fri, 21 Feb 2020 14:28:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/raMvp_hSwowFsQH-VslPTUBBAEw>
Subject: [MMUSIC] Query: Usage of enrypted vs unencrypted RTP extensions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 13:28:23 -0000

I recently encountered an interesting piece of code with regard to 
encrypted RTP header extensions.

It seemed to say that "if you enable encryption, every header extension 
will be offered in an encrypted and unencrypted variant, and the 
answerer can choose which ones to use".

1) does anyone want that?

2) does anyone depend on that?

It would seem more logical that the initiator of a call would have a 
strong opinion on whether encryption should be on or off, and only the 
version preferred should be offered.

This also saves some numbers, in case one wants to use 1-byte header 
extension numbering.

The context it came up in may end up in designing an API for controlling 
header extension encryption in WebRTC - so it's important to cover the 
use cases that are, in fact, in use.

Inquiring minds want to know....


Harald