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

Roman Shpount <roman@telurix.com> Thu, 08 September 2011 15:49 UTC

Return-Path: <roman@telurix.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 97E5121F8557 for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 HVTAiItol4HS for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:49:10 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3021F84DA for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:49:10 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4729011pzk.18 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 08:50:59 -0700 (PDT)
Received: by 10.68.33.228 with SMTP id u4mr1288426pbi.58.1315497059283; Thu, 08 Sep 2011 08:50:59 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i4sm13830898pbr.4.2011.09.08.08.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 08:50:58 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4728896pzk.18 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 08:50:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.43.8 with SMTP id s8mr1374937pbl.389.1315497057186; Thu, 08 Sep 2011 08:50:57 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 08:50:57 -0700 (PDT)
In-Reply-To: <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> <C3759687E4991243A1A0BD44EAC8230339CA68F054@BE235.mail.lan>
Date: Thu, 8 Sep 2011 11:50:57 -0400
Message-ID: <CAD5OKxthG65Gu5HspqZiXCqAekj_zS-7k4X0HLj-Yaq5DKg-vA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: multipart/alternative; boundary=bcaec5395f24cbf5a504ac700617
Cc: Randell Jesup <randell-ietf@jesup.org>, "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 15:49:11 -0000

I think we should provide a way in JavaScript API to specify if encryption
is required. We should be able to negotiate an open channel connection as
well as encrypted one, if for not other reason then for debugging. It would
be extremely hard to debug and troubleshoot any issues if all communications
are encrypted.

On the Offer/Answer side of the question, I don't think the question is to
support or not support offer answer. I think what we should try to
accomplish is a JavaScript API that allows to create solutions that will
interop with offer answer. We can have API methods that provide additional
media negotiation capabilities and it will be up to an application to decide
if offer/answer interoperability is required for it or if other more feature
complete or convenient API should be used. Not all the calls originated from
the RTC client will need to be connected to old PSTN devices, but ability to
be able to connect to old PSTN devices without using a media proxy is highly
desired.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <jonathan@vidyo.com>; wrote:

> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>