Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

Roman Shpount <> Thu, 05 April 2012 13:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C24121F858F for <>; Thu, 5 Apr 2012 06:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5vO4+gXi4qLT for <>; Thu, 5 Apr 2012 06:53:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E75221F8577 for <>; Thu, 5 Apr 2012 06:53:23 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1496305pbb.31 for <>; Thu, 05 Apr 2012 06:53:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=F2YWlil47VIB8pjnQ+9p7gFby0HV8l9zLyqpNoYBgBU=; b=pOWlDnmphZzcX0FAp0urkTemOgRfXVFAvjykXr3OAUDv4dtpunM51PNNEmxSyqYSjl TA4s4pn68KKiA+cb04wskoVTl/1vjpwsJa7PWS9hKPw96I5d2mXvymc+MLa6n/Wf2L0P 2t/SZfmS4xTYRnbAmpE1fO0EolD+7VTCuXMCFhL+ZQ4OXhgEKTJk60SUI7bAfEx6yZRr mnZLo6Fz/EO8QX8AIBa8zZmXFT+6RxI5ZUQOfC/S69d+NRLdAm1lcsq2AUBk4eCXvUj8 SD7KNTSekUrF7czU9bAZcVyWwsKyZhT1PZTNvzdDWePQRzYlerGWGh+l3e7DzDp+fqxv y/MQ==
Received: by with SMTP id sj8mr3847944pbc.101.1333634003098; Thu, 05 Apr 2012 06:53:23 -0700 (PDT)
Received: from ( []) by with ESMTPS id l4sm3333139pbl.27.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Apr 2012 06:53:22 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so1496270pbb.31 for <>; Thu, 05 Apr 2012 06:53:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id uh4mr2348679pbc.78.1333634000948; Thu, 05 Apr 2012 06:53:20 -0700 (PDT)
Received: by with HTTP; Thu, 5 Apr 2012 06:53:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Thu, 05 Apr 2012 09:53:20 -0400
Message-ID: <>
From: Roman Shpount <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="047d7b33da10e30f4504bceedcbc"
X-Gm-Message-State: ALoCoQl0LFuG/L+6N8ycrq7ElibkX/WtVY4hrbc0ckFi5oL6I144ZTbLzT2sEI6T1ww3MNZpLemm
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
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, 05 Apr 2012 13:53:24 -0000

On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <> wrote:

> 2012/4/5 Roman Shpount <>:
> > On the more serious note, very few SIP end points offer working ICE
> support.
> > So, in a large sense, interop with them is not an option.
> For me there is a BIG difference when a kind of B2BUA is required
> (which involves signaling "transaction"). That's the barrier IMHO.
> ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see:

This picture is not entirely correct -- ICE Lite proxy should be on both
SIP and Media path.

The problem arises when media encrypt/decrypt is required, and evenr
> more when a key update in RTP (like the DTLS EKT update) must be
> converted into a signaling re-INVITE by a super Signaling+Media B2BUA:
Not sure why key update needs to be converted into signaling if media is
re-encrypted. Key updates on both sides of the proxy are independent. Such
proxy can also change SDES-SRTP key on each re-INVITE initiated by either
side, but apart from doing actual encryption/decryption, operation wise it
should not be any different then ICE-Lite proxy.

> > Out of the ones
> > that do support ICE and SRTP, very few are actually connected directly
> to a
> > public internet. Most of them are connected to some sort of PBX or an IP
> > type service. So, in reality you do not need to bridge every IP phone
> with
> > WebRTC.
> That is a *very* limited scope of what WebRTC can provide. An IT
> department should be able to deploy its own WebRTC infrastructure (a
> Web+WebSocket server) within its "local" network, so browsers
> accessing to such a local website share the network with SIP/XMPP
> phones/devices/softphones.
> Please don't imagine WebRTC and SIP interop as the communication
> between two islands ;)

I actually do imagine WebRTC/SIP interop as two islands. If we need to
proxy media and convert Web+WebSocket into SIP this is a definition of
island bridge for me.

 > If a few PBX and hosted centrex vendors will add support for WebRTC
> > required features, we will get compatibility with existing end points.
> Pure SIP proxies do exist. A PBX is not always needed, so again, SIP
> world does not require to be "an island".

Once  again, if SIP proxy is combined with media proxy, you can bridge SIP
and WebRTC, even if DTLS-SRTP is used.

>  > To support the rest you will need to deploy some sort of gateway.
> Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent
> mails about SDES and DTLS).
Once again, we still need a gateway to support ICE. If end point is adding
ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.

> > hurdle (I am trying to be politically correct here). WebRTC enabled end
> > points, on the other hand, will offer significant benefits to traditional
> > SIP phones, since they will allow development of higher quality
> integrated
> > real time communications services. I hope this will drive a much quicker
> > standard adoption.
> The problem is that there is a *NEW* SRTP related spec for WebRTC:
> Maybe it could also become a standard for SIP? I hope, but currently
> it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a
> island.
Same as above.

P.S. I actually do not like DTLS-SRTP, since it does not have a large
installed base, comes with too many features, slows down call setup, will
requirecomplex interop and such. At the same time I do not think that
interop with legacy SDES-SRTP is a reason not to use it. I believe we
should design a new key exchange method, that can be mapped to SDES-SRTP
via signaling alone, addresses SDES-SRTP issues (transmitting keys over
clear channel in signaling, replay of signaling) without introducing all
the problems related to DTLS-SRTP. Any number of methods using public key
based exchange over signaling and ICE should do the trick.
Roman Shpount