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

Randell Jesup <randell-ietf@jesup.org> Sun, 11 September 2011 02:04 UTC

Return-Path: <randell-ietf@jesup.org>
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 DA7FB21F87FC for <rtcweb@ietfa.amsl.com>; Sat, 10 Sep 2011 19:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 b7i35Vltm9Et for <rtcweb@ietfa.amsl.com>; Sat, 10 Sep 2011 19:04:46 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27921F87F0 for <rtcweb@ietf.org>; Sat, 10 Sep 2011 19:04:45 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R2ZRU-0007Ox-M4 for rtcweb@ietf.org; Sat, 10 Sep 2011 21:06:44 -0500
Message-ID: <4E6C16FF.1000706@jesup.org>
Date: Sat, 10 Sep 2011 22:03:43 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <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> <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>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
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: Sun, 11 Sep 2011 02:04:47 -0000

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
randell-ietf@jesup.org