Re: [AVTCORE] RTP Header Extension Encryption

Harald Alvestrand <harald@alvestrand.no> Thu, 17 September 2020 12:42 UTC

Return-Path: <harald@alvestrand.no>
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 80F713A0A01 for <avt@ietfa.amsl.com>; Thu, 17 Sep 2020 05:42:34 -0700 (PDT)
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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 9SiXNArwyUhz for <avt@ietfa.amsl.com>; Thu, 17 Sep 2020 05:42:32 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33113A09EA for <avt@ietf.org>; Thu, 17 Sep 2020 05:42:32 -0700 (PDT)
Received: from [192.168.3.157] (unknown [188.113.93.42]) by mork.alvestrand.no (Postfix) with ESMTPSA id C0CFB7C5D82; Thu, 17 Sep 2020 14:42:30 +0200 (CEST)
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "magnus.westerlund=40ericsson.com@dmarc.ietf.org" <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "avt@ietf.org" <avt@ietf.org>
References: <CAOW+2dvo8z422LFeP5S652bq8RkF-SKhik=aXYXpTe9zqBX5yw@mail.gmail.com> <CAOW+2dt_A+A1AVnTUQyB4sTG5hMCv7Gf3-rrBB89LR-oacX=Rg@mail.gmail.com> <c390c256-3b4f-5c4d-0e2f-a784acec663c@alum.mit.edu> <CAOW+2dvAJSvAZmwNdYyGASj8Y5dptt8L6B9YrU3RMNrwP2ShGA@mail.gmail.com> <e94134bc-e411-1bdb-44cf-3cdf34f38044@alum.mit.edu> <a94e06f512bea37100179f6601df363ef9ad207e.camel@ericsson.com> <db1eb25e-a9ca-7005-a547-bd0ac9d67b4b@alvestrand.no> <f43686a846de09961d1c582f901655a93df384cc.camel@ericsson.com> <361477055a9b40788080613459f6675147bce9d6.camel@ericsson.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <7ab7efea-d79b-7870-1feb-e499179ca7a8@alvestrand.no>
Date: Thu, 17 Sep 2020 14:42:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <361477055a9b40788080613459f6675147bce9d6.camel@ericsson.com>
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/avt/pkXnFBgnpoaZcw8_5zHRaLGhS04>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 17 Sep 2020 12:42:35 -0000

On 9/17/20 10:26 AM, Magnus Westerlund wrote:
> Hi,
>
> A Clarification to the RTP session definition.
>
>>>> The term in the RTP vocabulary that makes sense are to have header
>>>> encryption
>>>> configuration be applied on the RTP session.
>>>>
>>>> A boundle group will be one RTP session as they share BUNDLE Transport
>>>> parameters.
>>>
>>> I think this is wrong. An RTP session can cover multiple transports (and
>>> will, if you don't use BUNDLE).
>> In what context? Yes, the generalized definition of an RTP session is the set
>> of
>> RTP + RTCP packets sent and received over a set of transport receivers and
>> transport destination as specified by some type of addressing.
> That share SSRC space. It is the SSRC space that is the core of the RTP session.


Yep.

When using WebRTC, we are using BUNDLE, and the BUNDLE spec says that 
media sections can move into and out of bundles.

When they move, there's nothing anywhere that says they change SSRCs.

So my interpretation is that everything inside a WebRTC media 
description (unless it refuses bundling altogether) has to be part of 
the same RTP session.


>
>> However, in a SDP using Offer/Answer if you have two or more media
>> descriptions
>> that has different UDP ports and not use bundle then you will get multiple RTP
>> sessions.
>>
>> Section 9.1 in BUNDLE (
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/) is
>> explicit about that one BUNDLE group is one RTP session. If you fail to
>> establish this bundle group you will have multiple RTP sessions with indepdent
>> SSRC spaces.
>>
>> If you put things on the SDP session level then you could jointly configure
>> all
>> of the created RTP sessions, but they will be multiple RTP sessions.
>>
>   
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Mobile +46 73 0949079
> Torshamnsgatan 23           |
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>