Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE: Use Case draft]

"Fabio Pietrosanti (naif)" <> Wed, 02 May 2012 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D88811E8080 for <>; Wed, 2 May 2012 13:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hfR9tkMSOz+j for <>; Wed, 2 May 2012 13:53:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 73A4111E80B5 for <>; Wed, 2 May 2012 13:53:40 -0700 (PDT)
Received: by werb10 with SMTP id b10so865101wer.31 for <>; Wed, 02 May 2012 13:53:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=b9XtVbC3H7Lh3Ujl79wpcW2oeYw8CFrQ5O2znWG9zvE=; b=g5wk1zM947ZQHYxahAHeu11fayU5pt2ZNa3AatmIDYS9bydePQRKNY0eyT4RXxXLC+ 1QB6OUUEyla0y2G5qeKgjUU6KdvA6SfWUL0eCbnmdIQGxzJKCVJBxrBloHc5i37FRXYc 1d0Jtfd72w6x1f2k5XEafFC4lYQCTtzikhxYH8VJts0PAPnT03jVkuLejiobuHwj3iAP /P8nT875T5lCQ4WZgo80RW3FHTA2t3VmF7dHX7I3Fk1tX5XpNE4tZ0M+tGx0OFGokDEv ESWZyl+6RO5vFDZimX6T2jxjIH32CVUn0tNx4JWd4Dm2i0NJhp85r4GhlAxGq5h/qSOX RNyg==
Received: by with SMTP id hb8mr17506811wib.8.1335992015575; Wed, 02 May 2012 13:53:35 -0700 (PDT)
Received: from sonyvaiop13.local ( []) by with ESMTPS id k6sm46591443wiy.7.2012. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 13:53:34 -0700 (PDT)
Sender: Fabio Pietrosanti <>
Message-ID: <>
Date: Wed, 02 May 2012 22:53:33 +0200
From: "Fabio Pietrosanti (naif)" <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
References: <><><BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl><><><><><><><><> <> <> <013101cd288c$09328250$1b9786f0$@com>
In-Reply-To: <013101cd288c$09328250$1b9786f0$@com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnng93221+039PNYTryZANf0q/WAfSpg1bso/cJFmYn2brZzfmJ3jQ5h5IOUgFrY9PAxcwb
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints [was RE: Use Case draft]
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: Wed, 02 May 2012 20:53:41 -0000

On 5/2/12 7:50 PM, Dan Wing wrote:
> However, when I presented slide 7, there were objections at the 
> microphone that this model 'is broken'.  I would like to understand 
> the objections so we can reach consensus on how interworking from
> WEBRTC to non-WEBRTC is expected to occur.

IMHO it would be much easier, as described in tons of previous email, to
use different Key Management for different requirements:

- SDES + SRTP for end-to-site (peer to gateway)
- DTLS-SRTP for end-to-end (peer to peer)

It would be a simpler approach for:

- Security (the user know the security level)
- Interoperability (Use standard protocols for the need to interoperate)

That way the "simpler, legacy, standard" technology would be used for
all voip "server applications" while the new burning (yet not used by
anyone) DTLS-SRTP will be used for peer-to-peer calls.

Please DO NOT reinvent the wheel for what's already existing and deployed.

Doing so, it's like going against the natural human behavior, it would
just represent a failure.