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

Roman Shpount <roman@telurix.com> Mon, 12 September 2011 02:56 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 DCE9C21F8546 for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 19:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.039
X-Spam-Level:
X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
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 HayGFrSezbp3 for <rtcweb@ietfa.amsl.com>; Sun, 11 Sep 2011 19:56:13 -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 3E02B21F854F for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:56:13 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21401865pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:58:15 -0700 (PDT)
Received: by 10.68.52.136 with SMTP id t8mr1461792pbo.244.1315796290984; Sun, 11 Sep 2011 19:58:10 -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 i1sm40055932pbe.1.2011.09.11.19.58.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 19:58:09 -0700 (PDT)
Received: by pzk33 with SMTP id 33so21401546pzk.18 for <rtcweb@ietf.org>; Sun, 11 Sep 2011 19:58:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.31.71 with SMTP id y7mr1810434pbh.121.1315796288982; Sun, 11 Sep 2011 19:58:08 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 19:58:08 -0700 (PDT)
In-Reply-To: <4E6CB9F7.2060208@mozilla.com>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.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> <CAOJ7v-2u0UuNXh7bzmZFwiSucbsh=Ps=C3ZM5M3cJrXRmZgODA@mail.gmail.com> <CAKhHsXHXCkNdjtpxCSCk+ABbtxY15GEgouE6X6-sn-LqhnidQw@mail.gmail.com> <4E6A56D4.2030602@skype.net> <CABcZeBOdP6cAqBoiSV-Vdv1_EK3DfgnMamT3t3ccjDOMfELfBw@mail.gmail.com> <CAKhHsXFdU1ZaKQF8hbsOxwTS-_RfmFqQhgzGe=K4mRp+wz+_nQ@mail.gmail.com> <4E6A81EC.3080002@jesup.org> <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> <4E6C16FF.1000706@jesup.org> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA829D@ESESSCMS0362.eemea.ericsson.se> <4E6CB9F7.2060208@mozilla.com>
Date: Sun, 11 Sep 2011 22:58:08 -0400
Message-ID: <CAD5OKxssKpF0i-+HmN+3f5nOdxasgwC-WEMPkiiO9iycBezmkQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "Timothy B. Terriberry" <tterriberry@mozilla.com>
Content-Type: multipart/alternative; boundary=bcaec520f2eb66d0eb04acb5b247
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: Mon, 12 Sep 2011 02:56:14 -0000

I guess what I do not understand in this discussion is why do we need to
negotiate all of this in the offer/answer. We need something that can
interop with offer answer, but no more then that. The client JavaScript
application should have control and ability to specify what kind of offer is
generated. We can use the exisitng HTTP connection to get all the additional
restrictions and options for the call. It is normally known to the
application if the security is needed and supported. The functionality of
figuring out device capabilities and user intent of this call (secure call
to the bank or public video chat) should be left to the application and
should not be part of this specification. What's currently is missing is
ability to transmit and receive media. The rest of the features, such as
getting events including new call event from the server, sending events to
the server, maintaining a persistent connection from behind firewall and NAT
is already present in the current web infrastructure. We do not need a new
signaling protocol or standard. We do not need to add an existing signaling
protocol not implemented by the browser such as SIP. It adds no new
functionality and makes standard bigger and more difficult to comply. All
that is needed is media.
_____________
Roman Shpount


On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry <
tterriberry@mozilla.com> wrote:

> * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP)
>> should be set by the web app
>>
>
> Why wouldn't this devolve to, "Don't communicate anything. Instead, try to
> create a PeerConnection with DTLS-SRTP, and when that fails, try to create a
> second one with NONE," in the actual webapp.
>
> Or, more likely, since NONE will have a better chance of working with
> legacy devices, "Try to create a PeerConnection with NONE, and when that
> fails, try to create a second one with DTLS-SRTP." Assuming anyone bothers
> with the second step. Having the choice of SDES-SRTP or DTLS-SRTP will also
> make it more likely people won't bother with either, as they won't know
> which one to use. We can try to create incentives with browser chrome, but
> there's only so much that can do.
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>