Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Christer Holmberg <> Sun, 31 May 2015 07:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8779F1ACE2A for <>; Sun, 31 May 2015 00:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8MmwwOuLfnEs for <>; Sun, 31 May 2015 00:02:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9296E1ACDD5 for <>; Sun, 31 May 2015 00:02:42 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-18-556ab21017bb
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 49.39.04401.012BA655; Sun, 31 May 2015 09:02:40 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Sun, 31 May 2015 09:02:39 +0200
From: Christer Holmberg <>
To: Roman Shpount <>
Thread-Topic: [MMUSIC] Bundling data channel and RTP? - Text proposal
Date: Sun, 31 May 2015 07:02:39 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3VldgU1aowcevohZf3jeyWBzc7Gcx dfljFosVGw6wWsy4MJXZgdWj9dleVo+/7z8weSxZ8pPJY8X5mSwet6YUBLBGcdmkpOZklqUW 6dslcGU83FNUMEus4u28tywNjBdEuxg5OSQETCQ2z/nHDGGLSVy4t56ti5GLQ0jgKKPEm/PP 2SGcxYwSj05tY+pi5OBgE7CQ6P6nDdIgIqAq8ff7ZCaQGmaBE4wSP2fvYAdJCAu4SPxa0sMC UeQqseL5b2aQIhGBSYwS579PZwNJsAB1r9jUAVbEK+Ar0f1lDiuILSRwil2i42gEyDJOgUCJ 00fyQcKMQNd9P7WGCcRmFhCXuPVkPhPE1QISS/ach/pAVOLl43+sELaSxIrtlxhBxjALaEqs 36UP0aooMaX7ITvEVkGJkzOfsExgFJuFZOoshI5ZSDpmIelYwMiyilG0OLU4KTfdyFgvtSgz ubg4P08vL7VkEyMw5g5u+a26g/HyG8dDjAIcjEo8vArZWaFCrIllxZW5hxilOViUxHk9u0JC hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD6/jD9e/bYLd1Qvh0/ix5tECky+sDyr/95psKs 93eWJ/xvrTkkFdHsxDq3r77d+sdB5cfn7Q6pBXjvCJbeIHCgfdWnuIe5K9YmzAzpDmhmCc7U WsE7mz84RCFewZr9dduUle2La7Rfh865/9rZWdFrn5rrwiDDMyfspyfcXS9z6lqmytYWtfVK LMUZiYZazEXFiQDick4rmgIAAA==
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 31 May 2015 07:02:44 -0000


>>> I would suggest "use_srtp" extension must always be enabled for DTLS session used in bundle.
>> Assuming SRTP is supported, I assume. If a node doesn't support SRTP to 
>> begin with, or if an application is never going to offer (or accept if offered) 
>> SRTP, I guess there is no reason to mandate "use_srtp".
>> Now, there are statements in RFC 5764 saying e.g.:
>>       "This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]."
>> That of course makes sense for a non-BUNDLE DTLS connection, but I wonder 
>> whether we somehow explicitly need to say that it doesn't apply for BUNDLE?
> Another big question how would current browser implementations handle a DTLS 
> connection without "use_srtp" extension. I have a strong suspicion that DTLS session 
> setup will fail without this extension present.
> I think, WebRTC enabled browsers currently export SRTP key material during 
> session setup even if no SRTP traffic is ever sent or received by this connection 
> and fail the entire connection if key export fails. This, most likely, can be modified 
> to only export SRTP key material when SRTP session is actually created and 
> defining some sort of fall back procedure when a media track is actually 
> added to a connection without "use_srtp" (either failure or require renegotiation with new transport).

Anyone from the browser community that can comment on this?

> To conclude, the group can either decide that all DTLS sessions in bundle should be setup 
> with "use_srtp" extension and keep the current implementations working as they are 
> currently coded, or allow not to include this extension and fix the implementations.

Currently, I am not aware of any scenarios where people would use BUNDLE without SRTP - or at least using clients that wouldn't support SRTP.

But, as the current trend seems to be to put more and more protocols on DTLS, I think one can assume that there will also be use-cases without SRTP in future.