Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

Stefan Håkansson LK <> Sun, 11 September 2011 08:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A42221F84D8 for <>; Sun, 11 Sep 2011 01:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OAsH1bV0Whe for <>; Sun, 11 Sep 2011 01:48:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 977E621F84D7 for <>; Sun, 11 Sep 2011 01:48:46 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-c0-4e6c76667b8a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 75.04.20773.6667C6E4; Sun, 11 Sep 2011 10:50:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Sun, 11 Sep 2011 10:50:46 +0200
From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= <>
To: Randell Jesup <>, "" <>
Date: Sun, 11 Sep 2011 10:49:16 +0200
Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
Thread-Index: AcxwJ3hLpGVDydVTR3u4B0FWN8AJqgAODe0T
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan> <> <> <> <> <> <>, <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Sep 2011 08:48:48 -0000

In my mind I had built a slightly different model of how this would work. In essence, the SDP o/a would not be allowed to negotiate encryption or not, that should be set when creating the PeerConnection object:

* The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app when a PeerConnection object is created (possibly part of the configuration string)
* One pre-requisite for the PeerConnection to enter the “open” state (and for streams to be set up) must be that the same level of protection is selected by both peer apps
* We should never allow any SDP o/a to negotiate away from the selected level of protection.

This would work just fine in the most common use cases as it is the same app, served by the same server, running in both browsers, and since support of NONE, SDES-SRTP and DTLS-SRTP in browsers should be mandated. The service provider/app developer decides.

The tricky part would be interop. But if we take the ‘browser to browser, but the app coming from different sources’ case, the two teams developing the apps must communicate any way to make them interop. Agreeing on whether to use NONE, SDES-SRTP or DTLS-SRTP is just one detail to agree on.

Developers of apps to interop with legacy must acquire enough info about the system to interop with to make the right setting of PeerConnection for the specific case.

Remember, the primary target for this activity is browser-to-browser. This should be simple and straightforward for the app developer. That the app developer would have to think a bit more for interop cases is quite OK IMO.

From: [] On Behalf Of Randell Jesup []
Sent: Sunday, September 11, 2011 4:03 AM
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

On 9/10/2011 8:16 PM, Christer Holmberg wrote:
>> The exact same thing could arise if we had somebody with an urgent
>> desire to do secure media with fallback to insecure media in SIP.
>> All the arguments against capneg would be exactly the same.
>> The problem is that people aren't finding capneg a usable solution to
>> this problem, just the way that people didn't find SDPng a solution to
>> the inadequacies of SDP.
>> While it is possible for rtcweb to adopt its own solution to the
>> problem, that only solves half the problem. And it then creates an
>> interop problem with SIP.
> A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed.
> Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP.

I think what you've speced here is basically similar to the
draft-best-effort-srtp proposal.

Randell Jesup

rtcweb mailing list