IETF Logo Mail Archive

Re: [rtcweb] Use Case draft - legacy interop

Bernard Aboba <bernard_aboba@hotmail.com> Sat, 05 May 2012 16:44 UTC

Return-Path: <bernard_aboba@hotmail.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 4C23A21F85D2 for <rtcweb@ietfa.amsl.com>; Sat, 5 May 2012 09:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.215
X-Spam-Level:
X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 jAZ8cm1PDHYZ for <rtcweb@ietfa.amsl.com>; Sat, 5 May 2012 09:44:29 -0700 (PDT)
Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id B991721F85C4 for <rtcweb@ietf.org>; Sat, 5 May 2012 09:44:29 -0700 (PDT)
Received: from BLU169-W112 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 5 May 2012 09:44:29 -0700
Message-ID: <BLU169-W112FF9C8E63297F9281FE6F932D0@phx.gbl>
Content-Type: multipart/alternative; boundary="_90fbff1c-ba1e-4808-9656-d98a385a7e13_"
X-Originating-IP: [24.16.96.166]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: ibc@aliax.net
Date: Sat, 05 May 2012 09:44:29 -0700
Importance: Normal
In-Reply-To: <0db701cd2adb$98082f10$c8188d30$@com>
References: <CA+9kkMCYArLPRP3c00UdOja64WRT6ghN0PSy7XvM_wbxBBB+vA@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F066@NAHALD.us.int.genesyslab.com> <BLU169-W7C59E1EDB4CB06B648577932B0@phx.gbl> <387F9047F55E8C42850AD6B3A7A03C6C0E23AFFF@inba-mail01.sonusnet.com> <2E496AC9-63A0-464A-A628-7407ED8DD9C4@phonefromhere.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23B16B@inba-mail01.sonusnet.com> <E2714FBC-D06B-4A12-9E07-C49EBF55084C@phonefromhere.com> <4F9EC0B2.10903@alcatel-lucent.com> <101C6067BEC68246B0C3F6843BCCC1E31299282765@MCHP058A.global-ad.net> <CAJNg7VKENERKAFA-n5KeoeBNmGgHrnzDOU0BzC9+fSdsuGwdEw@mail.gmail.com> <E17CAD772E76C742B645BD4DC602CD810616F24F@NAHALD.us.int.genesyslab.com> <4FA0F43E.4020308@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F336@NAHALD.us.int.genesyslab.com> <4FA1575C.4050508@ericsson.com> <E17CAD772E76C742B645BD4DC602CD810616F4BF@NAHALD.us.int.genesyslab.com> <4FA37A1E.4080806@alvestrand.no>, <CALiegf=H5QH_YY-cJ4z29wChWZ-VoQpHvsZCeaJPjTgVp+km3Q@mai, l.gmail.com>, <0db701cd2adb$98082f10$c8188d30$@com>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 May 2012 16:44:29.0379 (UTC) FILETIME=[56F7A930:01CD2ADE]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Use Case draft - legacy interop
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: Sat, 05 May 2012 16:44:30 -0000

Inaki said: 


> If I have a SIP phone implementing ICE and DTLS-SRTP (which is
> standarized for SIP regardless it has null impementation), will my SIP
> phone be able to *directly* talk in the media plane with a WebRTC
> browser? or not?

[BA] While I believe that the answer to this question should be required to be "yes", I do not think we can yet say whether this will be true or not. 

For example, for interoperation to be possible, the "continuing consent" mechanism used in ICE would need to be backward compatible with existing implementations. 

This is not the case for the mechanism proposed in draft-muthu-behave-consent-freshness. 

Similarly, we would need to ensure that the DTLS-SRTP functionality specified in WebRTC could be used to interoperate with existing implementations, which as I understand it, support EKT.

v2.23.0 | Report a Bug | By Email