Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 05 April 2012 11:14 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811D21F872A for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 04:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.499
X-Spam-Level:
X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_39=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkGs+FeYrZYO for <rtcweb@ietfa.amsl.com>; Thu, 5 Apr 2012 04:14:20 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9C82A21F869A for <rtcweb@ietf.org>; Thu, 5 Apr 2012 04:14:19 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-8a-4f7d7e893645
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 53.3E.25560.98E7D7F4; Thu, 5 Apr 2012 13:14:17 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 5 Apr 2012 13:14:17 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Iñaki Baz Castillo <ibc@aliax.net>, Roman Shpount <roman@telurix.com>
Date: Thu, 05 Apr 2012 13:14:17 +0200
Thread-Topic: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
Thread-Index: Ac0TCyYmp6MwdX5GQYiyzCiscN+u/AAEc4jQ
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42CA74D4@ESESSCMS0356.eemea.ericsson.se>
References: <CALiegfmz6tgm9WF3KWEK5qwaBGADKFyit=egB36zkjZXNKdeHw@mail.gmail.com> <CALiegfnA8_ntYd5f935P_E6vvMwjrzt+j6UhB9vjmo6h-RzfPA@mail.gmail.com> <CAD5OKxsxrDdsoV18KB1gZSsUBPno-k2zs4E2FTUaoUBdXfh5yA@mail.gmail.com> <CAE6kErhTOFP1qna-OKRmJzM=Rssc0UEXTyDgSyKmh2AM+PuviA@mail.gmail.com> <CAD5OKxuuC1q9uCnREqi_-i0unT=6Uza+oYsCWtanbSjmSi5_DQ@mail.gmail.com> <CALiegf=qo4uWjSBx6F5PmN_vqtbqYzQ9e5igqe_YJPKj0BHQvg@mail.gmail.com>
In-Reply-To: <CALiegf=qo4uWjSBx6F5PmN_vqtbqYzQ9e5igqe_YJPKj0BHQvg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2012 11:14:21 -0000
> 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: ...and, in general we should not specify procedures which require an intermediary to trigger and send re-INVITEs in the first place, because that itself can then cause lots of issues. Regards, Christer > 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 ;) > 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". > 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). > 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. Regards. -- Iñaki Baz Castillo <ibc@aliax.net> _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… jesse
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roni Even
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Ravindran, Parthasarathi
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Christer Holmberg
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Randell Jesup
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Roman Shpount
- Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRT… Iñaki Baz Castillo