Re: [rtcweb] SBC hardware and SHA1

Dzonatas Sol <> Fri, 30 September 2011 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F10B421F8696 for <>; Fri, 30 Sep 2011 12:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.793
X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1ttsgriNNCGh for <>; Fri, 30 Sep 2011 12:29:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D794A21F867F for <>; Fri, 30 Sep 2011 12:29:45 -0700 (PDT)
Received: by ywa6 with SMTP id 6so2215101ywa.31 for <>; Fri, 30 Sep 2011 12:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o75akZwMhDUJrdnkggR916ebF8L76hoplsI/9wSV6Ig=; b=wO3coohILarJUKRym3yXBW/w44xsdPkrm4+UoHJ83z9zPp7FxdzlVCmm1U4bzZo34M oPkWfrcrCj6lKkzkYmykfJNrEgpEBLidGkN1bhtfKD2NZMqcvhyORISqvGeJjoKjENOj DvhdklfWhXVOwiRTDCgDgd1Jb3m0gJ9eNGwfc=
Received: by with SMTP id w3mr29149308pbu.130.1317411158501; Fri, 30 Sep 2011 12:32:38 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id ml4sm21202663pbc.0.2011. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 12:32:37 -0700 (PDT)
Message-ID: <>
Date: Fri, 30 Sep 2011 12:35:02 -0700
From: Dzonatas Sol <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] SBC hardware and SHA1
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Sep 2011 19:29:49 -0000

On 09/30/2011 09:50 AM, Cameron Byrne wrote:
> On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan<>  wrote:
>> On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote:
>> Hadriel,
>> While on the topic of the hardware, I would like to ask how these systems
>> handle DTLS and SRTP.
>> Assuming you mean terminating the SRTP, I only know of one hardware-based
>> SBC that claims support for terminating DTLS-SRTP, but I don't know if it's
>> real or slideware. �I know of a couple software-based ones that do. (you can
>> probably google it to find out who)
>> But in general the most popular support by far is for SDES-based keying.
>> �There are a couple of off-the-shelf chip solutions for large-scale SRTP
>> that handle it as a bump-in-the wire, but they need to be told the keys per
>> stream and don't handle DTLS inline themselves to do so, so naturally SDES
>> made it a lot easier to use them. �Having said that, I do believe that more
>> SBC vendors in the US market will be supporting DTLS-SRTP in the future
>> because the US government has it mandated in some agency or other I've been
>> told. �Whether other governments will do the same I don't know. (then again
>> the US government mandates a lot that never gets used in practice)
>> Also, someone asked on this list if SBC vendors support SRTP to begin with.
>> �Almost every SBC vendor I know of does support SRTP (at least with SDES
>> keying), but it usually costs more to do so, because it's done in dedicated
>> hardware. �So most deployed SBC systems don't do SRTP, because the people
>> buying/deploying them have decided they don't need it and don't want to pay
>> for it. �It's more popular in specific vertical markets, but overall it's
>> definitely a minority today.
>> -hadriel
> As a service provider, i cannot imagine rolling out a solution that
> lacks encryption.

Perhaps node.js would be easier for browsers such that the browser's JS 
API can forward-to node.js where available. I'd imagine despite the 
choice of browser flavor that something like "use local node.js for 
encryption" in each may be ideal over direct to cloud/SBC. That may be 
easier for this WG for select innovation.

Either that, or let browsers run API regression against JS-UNIX (i.e. 
jslinux) with RTP and with hardcoded SHA validators in /dev. This may be 
more ideal for B2B portability and manufacturer automation, yet it may 
seem anti-game despite being more federal-ready.

I can imagine the JS API that includes encryption with real-time 
constraints. I have no interest in JS other than it helps convey that idea.

>   Cost of bad press and unmet user expectations is
> higher than a few extra boxes. If you choose not to encrypt, well...
> that becomes a differentiation for those that do.
> We have already bought and paid for SRTP in our existing IMS/SIP
> applications that exist on the Internet and will mandate it for
> anything we do with RTCWeb too, it's policy.
> Cameron
> _______________________________________________
> rtcweb mailing list


<i>The wheel.</i metro-link=t dzonatasolyndra>