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

[Roman Shpount <[e-mail]>]

On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 2012/4/5 Roman Shpount <[e-mail]>:
> > 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:
>
>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png


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:
>
>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png
>
>
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
> PBX
> > 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:
>
>  http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03
>
> 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