Re: [rtcweb] No Interim on SDES at this juncture

Hadriel Kaplan <hadriel.kaplan@oracle.com> Wed, 12 June 2013 15:09 UTC

Return-Path: <hadriel.kaplan@oracle.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 4CFB521F96EF for <rtcweb@ietfa.amsl.com>; Wed, 12 Jun 2013 08:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 gTkG-fp7rneW for <rtcweb@ietfa.amsl.com>; Wed, 12 Jun 2013 08:09:14 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C8FA621F963F for <rtcweb@ietf.org>; Wed, 12 Jun 2013 08:09:14 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5CF9Axm012140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jun 2013 15:09:11 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5CF9C2c027243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 15:09:12 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5CF9Buv022239; Wed, 12 Jun 2013 15:09:11 GMT
Received: from [10.1.21.23] (/10.5.21.23) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 08:09:11 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <768F0EF2-D5A5-46B0-9108-36D1F3838B37@iii.ca>
Date: Wed, 12 Jun 2013 11:09:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E42FA850-AF5F-4785-A3E6-5686451F9062@oracle.com>
References: <CA+9kkMDnjCNXGV0GU7x6gbbZMf4WiEuVvCRY8_Fix5tmdOB-Kg@mail.gmail.com> <AD220324-EEE7-4800-8512-FD7BADA9EC34@oracle.com> <768F0EF2-D5A5-46B0-9108-36D1F3838B37@iii.ca>
To: Cullen Jennings <fluffy@iii.ca>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Interim on SDES at this juncture
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: Wed, 12 Jun 2013 15:09:21 -0000

I was being sarcastic.  The previous two IETF meeting agenda times were ostensibly too full to have the SDES discussion due to the MTI video codec discussion.  Instead we spent the time talking about IdP, which is a possible future need, rather than a current actual interoperability issue - which is what SRTP key exchange actually is.  At the last Sipit, one of the only interop issues found was incompatible SRTP key exchange.

Hopefully there will be some standards-developing organization (SDO) out there that is responsible for media-plane interoperability of WebRTC hosts that can tackle the problem.  So far I've only found two SDOs that both seem to focus on browser APIs and what goes in HTTP.

-hadriel


On Jun 12, 2013, at 3:58 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> 
> On Jun 12, 2013, at 11:25 AM, Hadriel Kaplan <hadriel.kaplan@oracle.com> wrote:
> 
>> I don't expect there to be time in Berlin for it either, since I expect that time to be dedicated to choosing an MTI Video Codec.
> 
> I doubt the MTI codec issue will be discussed in Berlin because several people have expressed the thought that the outcome of Nokia vs HTC / Google trial over VP8 will change their opinion so it seem we will wait yet some more for this information to become available. 
>