Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

Harald Alvestrand <harald@alvestrand.no> Sat, 29 October 2011 16:18 UTC

Return-Path: <harald@alvestrand.no>
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 342BE21F8ACA for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 09:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level:
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 2kbB-32ZynDt for <rtcweb@ietfa.amsl.com>; Sat, 29 Oct 2011 09:18:52 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4A421F8AC9 for <rtcweb@ietf.org>; Sat, 29 Oct 2011 09:18:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E821139E162; Sat, 29 Oct 2011 18:18:51 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qne0BqL4btC; Sat, 29 Oct 2011 18:18:51 +0200 (CEST)
Received: from [192.168.6.21] (unknown [24.104.44.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CD22939E088; Sat, 29 Oct 2011 18:18:50 +0200 (CEST)
Message-ID: <4EAC276B.6040309@alvestrand.no>
Date: Sat, 29 Oct 2011 09:18:51 -0700
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Iñaki Baz Castillo <ibc@aliax.net>
References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <CALiegfnVaZjh1K+brd180Z9Ufheau3v6OJe6Ejv8P7wzw6ROQw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <CAD5OKxu=3FvnUDV5m1TW8n+7D+B6ihp_g7TXKtJVaVW3gtiySQ@mail.gmail.com> <4EAC24A2.70401@alvestrand.no> <CALiegfm5ayY_MDeAnNsCz0BqcCu3hBHO-Vz_z7HAiPnuVjRanA@mail.gmail.com>
In-Reply-To: <CALiegfm5ayY_MDeAnNsCz0BqcCu3hBHO-Vz_z7HAiPnuVjRanA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]
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: Sat, 29 Oct 2011 16:18:53 -0000

On 10/29/2011 09:14 AM, Iñaki Baz Castillo wrote:
> 2011/10/29 Harald Alvestrand<harald@alvestrand.no>:
>> Of course we could mandate DTLS-SRTP key negotiation.....
> SIPit29 summary says:
>
>> 80% of the endpoints present supported SRTP using sdes.
>> There were no dtls-srtp implementations at this SIPit.
> Just a comment. Of coure the current status of SRTP implementations in
> SIP world should not be the only argument for WebRTC.
>
>
I was partially joking.... I wanted to point out that the argument for 
supporting SIP-style forking and the argument for supporting SDES or 
non-encrypted RTP is based in the same "legacy interop" desire.

I don't think we can satisfy all desires in that area.