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

Jonathan Lennox <jonathan@vidyo.com> Thu, 08 September 2011 12:19 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F216B21F8B7F for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 05:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qG-2uIWVqXf for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 05:19:31 -0700 (PDT)
Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7C21E21F8B7D for <rtcweb@ietf.org>; Thu, 8 Sep 2011 05:19:31 -0700 (PDT)
Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A7A18553B4C; Thu, 8 Sep 2011 08:21:19 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 45B4A553B59; Thu, 8 Sep 2011 08:21:19 -0400 (EDT)
Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 8 Sep 2011 08:21:18 -0400
From: Jonathan Lennox <jonathan@vidyo.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 8 Sep 2011 08:21:17 -0400
Thread-Topic: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]
Thread-Index: AcxtrdxMz9T5EPlJRReppyAV+Xdn8AAQw9BAAAulCRA=
Message-ID: <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <BE60FA11-8FFF-48E5-9F83-4D84A7FBE2BE@vidyo.com> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 12:19:32 -0000

Indeed.

More generally, the question is: should it be possible to send an offer that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other RTP profiles to support legacy devices?

If yes, then either browsers need to support CapNeg, or RTCWeb needs to use something other than SDP Offer/Answer.

If no, then supporting interop, without a media gateway, with other non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) becomes IMO a lot less compelling.
	
-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Thursday, September 08, 2011 2:35 AM
To: Randell Jesup; Jonathan Lennox
Cc: rtcweb@ietf.org
Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]

 
Hi,

>>>You could make forced-encryption the default, and allow the 
>>>application control over whether to allow it is turned off for 
>>>specific cases, like a PSTN call, or under the server's control.
>>>Signalling is secure, so it could even use a direct optional 
>>>downgrade from SAVP* to AVP* (i.e.
>>>similar to the best-effort-strp draft)
>>This has implications for the parallel thread about the use of SDP 
>>offer/answer.
>>
>>The solution MMUSIC has standardized for best-effort SRTP is SDP 
>>CapNeg, RFC 5939.  Do we want to require CapNeg support in browsers?
> 
>Yeah, ok, I'm not going there.  :-)  It's probably not needed for this 
>use-case anyways.

The same question exists for AVPF, which has been suggested to be mandated.

Regards,

Christer