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

"Fabio Pietrosanti (naif)" <> Thu, 03 May 2012 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCEF521F861A for <>; Thu, 3 May 2012 00:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IK0dAwKjEytm for <>; Thu, 3 May 2012 00:19:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0767321F860F for <>; Thu, 3 May 2012 00:19:20 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so969662wgb.13 for <>; Thu, 03 May 2012 00:19:19 -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:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:x-gm-message-state; bh=uV/srZM7I7WL30ri4LjxSRcCZH/ePNQFt7/dHl1VJUE=; b=JWdht65qIAZnAXKPacStcOdX0lKU1LV69005HsFZSe9+oE+XKKnwL2IlhCvfQAXIaI McS9QI5mFwqZI5K1awWJ8J82M7/IvZzWBXTzmZE0dt16xAz1/SuupEGrSYuA+Z16bdZ9 Z/EOoLgXnCGz2T+U4OkJ6q3Apvx3EPPMEfPrmkGfQwNcu3I+490zzNYK1BSpSaTdVHF4 7wt142MTWEEp61hdrTCkB+ntqfUS4ZhHXn5UWAd2bgdlBZxCkU+rohY/HdNCTaQvIrry lzC5AtUnQkVX2ytxecoZEdHK8FuClpToGD8lfif3ofAtUJu8Je8Qfjjt7FnfAuz9Wl31 ItyA==
Received: by with SMTP id x9mr397630wiw.18.1336029559520; Thu, 03 May 2012 00:19:19 -0700 (PDT)
Received: from sonyvaiop13.local ( []) by with ESMTPS id gg2sm712004wib.7.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 00:19:18 -0700 (PDT)
Sender: Fabio Pietrosanti <>
Message-ID: <>
Date: Thu, 03 May 2012 09:19:16 +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
To: "Ravindran, Parthasarathi" <>
References: <><><BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl><><><><><><><><> <> <> <013101cd288c$09328250$1b9786f0$@com> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlx4z5+RC+IGpTf5SHTwpsurtvbzZeysOtXhRAD5ZEtjBQq6Ym1B+QP+Os4h1t6ni+LibSG
Cc: "" <>
Subject: Re: [rtcweb] interworking with non-WEBRTC endpoints SDES-SRTP + DTLS-SRTP [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: Thu, 03 May 2012 07:19:21 -0000


maybe it's just the "signaling provider" that will tell to the browser
what to use:

- simpler interoperable SDES/SRTP (saying to the user "send SRTP here
IP:Port with that Key)
- stronger non-interoperable DTLS-SRTP (saying to the user "go

For example if the signaling provider know that it's providing:
a) A call to a center call
b) Call trough PSTN gateway (web call to PSTN)
c) Voicemail access
d) Financial call (stock brokerage)
e) Enterprise call (that would just need to proxy all calls)

then the signaling provider will notice to the user's WebRTC stack
SDES/SRTP in a *very simple* way without ICE/DTLS-SRTP and all that
protocol complexity.

Instead if that specific VoIP uses does not require a VoIP server to
provide value added services (transcoding, conferencing, bridging to
other telephony networks, recording, whatever) it would just goes as

Some previous link on the topic:

* On DTLS-SRTP trust model (and consideration for SDES-SRTP)

* End-to-end encryption vs end-to-end authentication (DTLS-SRTP / SDES-SRTP)

*  DTLS-SRTP with end-to-end security: Short Authentication String


On 5/3/12 7:23 AM, Ravindran, Parthasarathi wrote:
> Fabio,
> Could you please explain how to differentiate through protocol means that the peer is site (gateway) or endpoint (webbrowser).
> Thanks
> Partha