IETF Logo Mail Archive

Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

Suhas Nandakumar <suhasietf@gmail.com> Fri, 26 April 2013 16:36 UTC

Return-Path: <suhasietf@gmail.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 5CC1E21F9A5A for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 09:36:16 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 TUnvq0DiS1pe for <rtcweb@ietfa.amsl.com>; Fri, 26 Apr 2013 09:36:15 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0221F9A54 for <rtcweb@ietf.org>; Fri, 26 Apr 2013 09:36:14 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id h11so830696wiv.2 for <rtcweb@ietf.org>; Fri, 26 Apr 2013 09:36:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ej795VgCajfWBEZrOVf8Gm0AyICAuHTmC8FfTkXV70I=; b=rgLQlnsyOtwNV19x2GR30nrFdavDksxO0+eOzY72nZIrPGkC7YKb4Se2z5A5cusOFM 9yGnwCRXKNREausKrtJKZWsPwu10ms3OPxpBL3KDx07ygt3kfkvsBs2x84jlH40Dt2a5 amEgmCdrg+ybUmB9JgKZVLnWmzT9cyimk43N3GKjWKezA7S19hAtuhxxBbgbPOIzgwUA i23wkCrmM1mTICPiUDU4XlTiTm7Or4z8ODAM6wx7DuqMoT9Ea4dwrGimfsMERVFTkWvL ucMOYNf6QkBHlSP2qsCZawE8+PjT5YpQ79UGJUQUvBR4/nMft71VtAZOsb88hfNmeIl+ vP9A==
MIME-Version: 1.0
X-Received: by 10.180.85.103 with SMTP id g7mr5169047wiz.23.1366994173948; Fri, 26 Apr 2013 09:36:13 -0700 (PDT)
Received: by 10.194.139.79 with HTTP; Fri, 26 Apr 2013 09:36:13 -0700 (PDT)
In-Reply-To: <AF40C6D6-01B4-4BF6-9AF8-2552B660C2A3@phonefromhere.com>
References: <3FA2E46D-C98E-4FC0-9F1D-AD595A861CE1@iii.ca> <CABkgnnVky++ZF1uaM8p4xtzvDQH7HMCaL8N2ZV3dZDYnv-NvzQ@mail.gmail.com> <AF40C6D6-01B4-4BF6-9AF8-2552B660C2A3@phonefromhere.com>
Date: Fri, 26 Apr 2013 09:36:13 -0700
Message-ID: <CAMRcRGQ3OxAFpctz_ULHKkm+ehKb1Q=iiU4oVyXV4jgmrB5ceA@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Tim Panton <tim@phonefromhere.com>
Content-Type: multipart/alternative; boundary="f46d043bdce62770f104db462265"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb
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: Fri, 26 Apr 2013 16:36:16 -0000

Tim,

   I disagree with the argument on the interop that  a media gateway is
always required. Cisco for example have been shipping devices that work
fine with webrtc browsers that do H.264 without needing a media gateway. I
am sure this is true for examples other than Cisco.

Thanks
Suhas Nandakumar


On Fri, Apr 26, 2013 at 4:11 AM, Tim Panton <tim@phonefromhere.com> wrote:

>
> On 26 Apr 2013, at 00:01, Martin Thomson wrote:
>
> > The case for SDES has thus far been summarized as (borrowing Adam's
> words):
> >
> > (1) Those required for interop with legacy devices, and
> > (2) those which we are prohibited by RFC 2804 from considering.
> >
> > Reason (1) is a fairly big deal.  There are other reasons:
>
> I don't buy the interop argument.
> There are (as we have all now discovered) no legacy devices that do SRTP
> (SDES only) and Ice/STUN/rtcp-mux/bundle
> as required to consume the UDP that chrome (for example) generates. We
> will _always_ need a media gateway in front of
> any current legacy devices to de-ice/de-mux/ etc the media streams from
> webRTC.
>
> (Note: I refuse to take into account the oxymoronic 'future legacy'
> devices that current legacy providers may build at some point in the
> future).
>
> So the question is how heavy does that media gateway have to be?
> Does adding DTLS as a key exchange method make they exorbitant to build?
> It turns out that it doesn't.
>
> Remembering that DTLS is only used here as a key-exchange
> protocol you can just put a DTLS filter in your UDP layer (alongside the
> ICE /demux code) and pop the SRTP keys out of it.
> Those keys can then be used by current SRTP hardware and software.
>
> So the overhead is limited to the key-exchange itself. It will make call
> set-up mor expensive, but as someone pointed out there are
> a few websites that seem to cope with https - so I dare say we will learn
> to live with it.
>
> Tim.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email