From harald@alvestrand.no Mon Jan 2 04:47:47 2012 Return-Path: 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 2091A21F8E2E for ; Mon, 2 Jan 2012 04:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.091 X-Spam-Level: X-Spam-Status: No, score=-108.091 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 5aTZPZrVRUoc for ; Mon, 2 Jan 2012 04:47:46 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B966F21F8E2D for ; Mon, 2 Jan 2012 04:47:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8C53339E112 for ; Mon, 2 Jan 2012 13:47:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiDWVT8jNXXc for ; Mon, 2 Jan 2012 13:47:42 +0100 (CET) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1126D39E13F for ; Mon, 2 Jan 2012 13:47:42 +0100 (CET) Message-ID: <4F01A790.4060704@alvestrand.no> Date: Mon, 02 Jan 2012 13:48:16 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030305040300040208020005" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Mon, 02 Jan 2012 12:47:47 -0000 This is a multi-part message in MIME format. --------------030305040300040208020005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At the risk of resurrecting a dead horse On 12/14/2011 03:41 PM, Xavier Marjou wrote: > Is there any scientific reference comparing the performances (cpu) of > a SRTP communication vs an RTP communication on a smartphone device, > or on an interworking network server? The feedback I have is that SRTP > overhead is significant, at least on interworking network servers > handling several calls in parallel. One example is > http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS which gives figures, > perhaps non-optimized, but figures anyway: > > > 00:59:38.531 os_core_unix.c pjlib 0.9.0-trunk for POSIX initialized > MIPS test, with CPU=180Mhz, 198.0 MIPS > Clock Item Time CPU MIPS > Rate (usec) (%) > 8KHz codec encode/decode - L16/8000/1 1704 0.170 0.34 > 8KHz stream TX/RX - G.711 6786 0.679 1.34 > 8KHz stream TX/RX - G.711 SRTP 32bit 21688 2.169 4.29 > 8KHz stream TX/RX - G.711 SRTP 32bit +auth 33501 3.350 6.63 > 8KHz stream TX/RX - G.711 SRTP 80bit 21725 2.172 4.30 > 8KHz stream TX/RX - G.711 SRTP 80bit +auth 33551 3.355 6.64 Note that the codec used here (G.711) is hardly a complex encoder; it can be implemented using a lookup table, which is probably small enough to serve out of cache. The first line seems to have been included by a copy/paste error. A different cut'n'paste from the same table: 8KHz codec encode/decode - G.711 2701 0.270 0.53 8KHz codec encode/decode - GSM 75750 7.575 15.00 8KHz codec encode/decode - iLBC 2856203 285.620 565.53 8KHz codec encode/decode - Speex 8Khz 436162 43.616 86.36 8KHz codec encode/decode - L16/8000/1 1704 0.170 0.34 8KHz stream TX/RX - G.711 6786 0.679 1.34 8KHz stream TX/RX - G.711 SRTP 32bit 21688 2.169 4.29 8KHz stream TX/RX - G.711 SRTP 32bit +auth 33501 3.350 6.63 8KHz stream TX/RX - G.711 SRTP 80bit 21725 2.172 4.30 8KHz stream TX/RX - G.711 SRTP 80bit +auth 33551 3.355 6.64 8KHz stream TX/RX - GSM 82035 8.203 16.24 8KHz stream TX/RX - GSM SRTP 32bit 90890 9.089 18.00 8KHz stream TX/RX - GSM SRTP 32bit + auth 99334 9.933 19.67 8KHz stream TX/RX - GSM SRTP 80bit 90893 9.089 18.00 8KHz stream TX/RX - GSM SRTP 80bit + auth 99356 9.936 19.67 So if someone wishes to do GSM, the overhead of SRTP is on the order of 10%; if they do iLBC, the overhead is microscopic. On this particular platform and implementation. --------------030305040300040208020005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At the risk of resurrecting a dead horse

On 12/14/2011 03:41 PM, Xavier Marjou wrote: 
Is there any scientific reference comparing the performances (cpu) of
a SRTP communication vs an RTP communication on a smartphone device,
or on an interworking network server? The feedback I have is that SRTP
overhead is significant, at least on interworking network servers
handling several calls in parallel. One example is
http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS which gives figures,
perhaps non-optimized, but figures anyway:


00:59:38.531 os_core_unix.c pjlib 0.9.0-trunk for POSIX initialized
MIPS test, with CPU=180Mhz,  198.0 MIPS
Clock  Item                                      Time     CPU    MIPS
 Rate                                           (usec)    (%)
 8KHz codec encode/decode - L16/8000/1           1704    0.170    0.34
 8KHz stream TX/RX - G.711                       6786    0.679    1.34
 8KHz stream TX/RX - G.711 SRTP 32bit           21688    2.169    4.29
 8KHz stream TX/RX - G.711 SRTP 32bit +auth     33501    3.350    6.63
 8KHz stream TX/RX - G.711 SRTP 80bit           21725    2.172    4.30
 8KHz stream TX/RX - G.711 SRTP 80bit +auth     33551    3.355    6.64
Note that the codec used here (G.711) is hardly a complex encoder; it can be implemented using a lookup table, which is probably small enough to serve out of cache.
The first line seems to have been included by a copy/paste error.

A different cut'n'paste from the same table:

 8KHz codec encode/decode - G.711                2701    0.270    0.53
 8KHz codec encode/decode - GSM                 75750    7.575   15.00
 8KHz codec encode/decode - iLBC              2856203  285.620  565.53
 8KHz codec encode/decode - Speex 8Khz         436162   43.616   86.36
 8KHz codec encode/decode - L16/8000/1           1704    0.170    0.34
 8KHz stream TX/RX - G.711                       6786    0.679    1.34
 8KHz stream TX/RX - G.711 SRTP 32bit           21688    2.169    4.29
 8KHz stream TX/RX - G.711 SRTP 32bit +auth     33501    3.350    6.63
 8KHz stream TX/RX - G.711 SRTP 80bit           21725    2.172    4.30
 8KHz stream TX/RX - G.711 SRTP 80bit +auth     33551    3.355    6.64
 8KHz stream TX/RX - GSM                        82035    8.203   16.24
 8KHz stream TX/RX - GSM SRTP 32bit             90890    9.089   18.00
 8KHz stream TX/RX - GSM SRTP 32bit + auth      99334    9.933   19.67
 8KHz stream TX/RX - GSM SRTP 80bit             90893    9.089   18.00
 8KHz stream TX/RX - GSM SRTP 80bit + auth      99356    9.936   19.67

So if someone wishes to do GSM, the overhead of SRTP is on the order of 10%; if they do iLBC, the overhead is microscopic. On this particular platform and implementation.

--------------030305040300040208020005-- From randell-ietf@jesup.org Mon Jan 2 22:32:35 2012 Return-Path: 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 F2F2821F851B for ; Mon, 2 Jan 2012 22:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 AXm9c+J3fAhN for ; Mon, 2 Jan 2012 22:32:35 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC321F84D9 for ; Mon, 2 Jan 2012 22:32:35 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RhxvG-0004PK-Cy for rtcweb@ietf.org; Tue, 03 Jan 2012 00:32:34 -0600 Message-ID: <4F02A061.60905@jesup.org> Date: Tue, 03 Jan 2012 01:29:53 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> In-Reply-To: <4F01A790.4060704@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 06:32:36 -0000 On 1/2/2012 7:48 AM, Harald Alvestrand wrote: > At the risk of resurrecting a dead horse > > On 12/14/2011 03:41 PM, Xavier Marjou wrote: >> Is there any scientific reference comparing the performances (cpu) of >> a SRTP communication vs an RTP communication on a smartphone device, >> or on an interworking network server? The feedback I have is that SRTP >> overhead is significant, at least on interworking network servers >> handling several calls in parallel. One example is >> http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS which gives figures, >> perhaps non-optimized, but figures anyway: >> >> >> 00:59:38.531 os_core_unix.c pjlib 0.9.0-trunk for POSIX initialized >> MIPS test, with CPU=180Mhz, 198.0 MIPS >> Clock Item Time CPU MIPS >> Rate (usec) (%) > A different cut'n'paste from the same table: > > 8KHz codec encode/decode - G.711 2701 0.270 0.53 > 8KHz codec encode/decode - GSM 75750 7.575 15.00 > 8KHz codec encode/decode - iLBC 2856203 285.620 565.53 > 8KHz codec encode/decode - Speex 8Khz 436162 43.616 86.36 > 8KHz codec encode/decode - L16/8000/1 1704 0.170 0.34 > 8KHz stream TX/RX - G.711 6786 0.679 1.34 > 8KHz stream TX/RX - G.711 SRTP 32bit 21688 2.169 4.29 > 8KHz stream TX/RX - G.711 SRTP 32bit +auth 33501 3.350 6.63 > 8KHz stream TX/RX - G.711 SRTP 80bit 21725 2.172 4.30 > 8KHz stream TX/RX - G.711 SRTP 80bit +auth 33551 3.355 6.64 > 8KHz stream TX/RX - GSM 82035 8.203 16.24 > 8KHz stream TX/RX - GSM SRTP 32bit 90890 9.089 18.00 > 8KHz stream TX/RX - GSM SRTP 32bit + auth 99334 9.933 19.67 > 8KHz stream TX/RX - GSM SRTP 80bit 90893 9.089 18.00 > 8KHz stream TX/RX - GSM SRTP 80bit + auth 99356 9.936 19.67 > > > So if someone wishes to do GSM, the overhead of SRTP is on the order of > 10%; if they do iLBC, the overhead is microscopic. On this particular > platform and implementation. Two things: 1) the numbers are odd (cache effects?) - SRTP+AUTH takes an additional 2.7% cpu for GSM, but an additional 1.7% on GSM. 2) the iLBC number is non-sensical for an optimized implementation and is almost certainly the floating-point implementation from the spec (and perhaps even on hardware without FP support). I'll also note a 180MHz MIPS processor is very slow by modern standards. Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM (and that's arguably too low, perhaps significantly too low). -- Randell Jesup randell-ietf@jesup.org From Markus.Isomaki@nokia.com Tue Jan 3 04:55:41 2012 Return-Path: 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 C665121F851C for ; Tue, 3 Jan 2012 04:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5jVslQtazcmA for ; Tue, 3 Jan 2012 04:55:41 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id AF33D21F84AA for ; Tue, 3 Jan 2012 04:55:40 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q03CtSon005121; Tue, 3 Jan 2012 14:55:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 14:55:36 +0200 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.245]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Tue, 3 Jan 2012 13:55:35 +0100 From: To: , Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWLY43bKnjgikyLRdBKEOrBxJXbEiEAgABFYgCAHbzFAIABKJ2AgAB4xIA= Date: Tue, 3 Jan 2012 12:55:35 +0000 Message-ID: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> In-Reply-To: <4F02A061.60905@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.83.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2012 12:55:36.0584 (UTC) FILETIME=[FCC63080:01CCCA16] X-Nokia-AV: Clean Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 12:55:41 -0000 Hi, Randell Jesup wrote: > >I'll also note a 180MHz MIPS processor is very slow by modern standards. > Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM >(and that's arguably too low, perhaps significantly too low). > Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connect= ivity, even the low-end ones seem to have at least 600 MHz ARM. Anything th= at I could imagine running WebRTC, in terms of real products, will have an = even faster CPU.=20 Nokia has had phones with SIP and SRTP for several years, so I doubt that w= ill be an issue. It's all the other stuff that WebRTC will need that will b= e much more challenging. Markus=20 From randell-ietf@jesup.org Tue Jan 3 11:58:31 2012 Return-Path: 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 313E31F0C3B for ; Tue, 3 Jan 2012 11:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11] 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 XG6IzWFK7t7w for ; Tue, 3 Jan 2012 11:58:30 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A3CAC1F0C3E for ; Tue, 3 Jan 2012 11:58:30 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RiAVC-0002Xe-1N for rtcweb@ietf.org; Tue, 03 Jan 2012 13:58:30 -0600 Message-ID: <4F035DD5.3050305@jesup.org> Date: Tue, 03 Jan 2012 14:58:13 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 19:58:31 -0000 On 1/3/2012 7:55 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > Randell Jesup wrote: >> >> I'll also note a 180MHz MIPS processor is very slow by modern standards. >> Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM >> (and that's arguably too low, perhaps significantly too low). >> > > Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connectivity, even the low-end ones seem to have at least 600 MHz ARM. Anything that I could imagine running WebRTC, in terms of real products, will have an even faster CPU. > > Nokia has had phones with SIP and SRTP for several years, so I doubt that will be an issue. It's all the other stuff that WebRTC will need that will be much more challenging. I chose 300MHz because that's the speed of the ARM in a first-generation DaVinci and some of the older OMAPs I believe. Agreed, not really current devices likely to get webrtc - though support for lower-spec devices does enable people wanting to build really inexpensive web devices (wired or wireless). And lower overhead also means lower battery use (though Justin reminds me that the CPU isn't the limiting factor here usually; it's the display and wireless link). I should note that audio SRTP overhead isn't really the issue; it's the overhead for encrypting/decrypting far larger streams of video, and the SRTP overhead is (mostly) proportional to bitrate, so large resolution and/or low-compression streams will use more overhead. Note: while I'm discussing nits here, I am in overall favor of SRTP-required, if for no other reason than to head off bid-down attacks. I'd love to have the option of not using it in very specific scenarios (PSTN gateway, internal corporate network or one with an PBX that doesn't support a keying scheme we do), but I've yet to see a solution for those that doesn't hurt other use-cases. (And I've tried to find a way.) (And yes, SRTP doesn't help you much if you're MITM'd - see ekr's identity stuff & BrowserID for that.) -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Tue Jan 3 14:38:57 2012 Return-Path: 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 D408111E80A3 for ; Tue, 3 Jan 2012 14:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.31 X-Spam-Level: X-Spam-Status: No, score=-101.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 fTNTBnywh1ag for ; Tue, 3 Jan 2012 14:38:57 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 191BE11E8093 for ; Tue, 3 Jan 2012 14:38:56 -0800 (PST) Received: by obcuz6 with SMTP id uz6so15096662obc.31 for ; Tue, 03 Jan 2012 14:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=LqKw9aDUOsRQWW48Q4xA0+TTKpFgnfciXJDMWPR1Ea0=; b=sQfaj38iUy0/X9+mN8KdujKzrpJYdb3zSxSY3mdbCyQ+A3xtAkUhIXBdpP/T+K57co o858DF8DTzkef9JTnKEQ== Received: by 10.50.219.226 with SMTP id pr2mr63524843igc.30.1325630336510; Tue, 03 Jan 2012 14:38:56 -0800 (PST) Received: by 10.50.219.226 with SMTP id pr2mr63524832igc.30.1325630336284; Tue, 03 Jan 2012 14:38:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.16.135 with HTTP; Tue, 3 Jan 2012 14:38:35 -0800 (PST) In-Reply-To: <4F035DD5.3050305@jesup.org> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> From: Justin Uberti Date: Tue, 3 Jan 2012 17:38:35 -0500 Message-ID: To: Randell Jesup X-System-Of-Record: true Content-Type: multipart/alternative; boundary=f46d042dfcd54c363504b5a75d32 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 22:38:57 -0000 --f46d042dfcd54c363504b5a75d32 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 3, 2012 at 2:58 PM, Randell Jesup wrote: > On 1/3/2012 7:55 AM, Markus.Isomaki@nokia.com wrote: > >> Hi, >> >> Randell Jesup wrote: >> >>> >>> I'll also note a 180MHz MIPS processor is very slow by modern standards. >>> Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM >>> (and that's arguably too low, perhaps significantly too low). >>> >>> >> Looking at the specs of any recent smartphones with Wi-Fi and/or 3G >> connectivity, even the low-end ones seem to have at least 600 MHz ARM. >> Anything that I could imagine running WebRTC, in terms of real products, >> will have an even faster CPU. >> >> Nokia has had phones with SIP and SRTP for several years, so I doubt that >> will be an issue. It's all the other stuff that WebRTC will need that will >> be much more challenging. >> > > I chose 300MHz because that's the speed of the ARM in a first-generation > DaVinci and some of the older OMAPs I believe. Agreed, not really current > devices likely to get webrtc - though support for lower-spec devices does > enable people wanting to build really inexpensive web devices (wired or > wireless). And lower overhead also means lower battery use (though Justin > reminds me that the CPU isn't the limiting factor here usually; it's the > display and wireless link). > > I should note that audio SRTP overhead isn't really the issue; it's the > overhead for encrypting/decrypting far larger streams of video, and the > SRTP overhead is (mostly) proportional to bitrate, so large resolution > and/or low-compression streams will use more overhead. > I would argue that if you're processing video streams, SRTP overhead pales compared to the heavy encode/decode lifting. > > Note: while I'm discussing nits here, I am in overall favor of > SRTP-required, if for no other reason than to head off bid-down attacks. > I'd love to have the option of not using it in very specific scenarios > (PSTN gateway, internal corporate network or one with an PBX that doesn't > support a keying scheme we do), but I've yet to see a solution for those > that doesn't hurt other use-cases. (And I've tried to find a way.) > If we make SRTP mandatory to use, people will figure out a way to make SRTP work in their scenarios. If we don't, people will continue to use the same old objections as to why they can't deploy SRTP. SRTP isn't a panacea, but I think we have a chance to take a big step forward here. > > (And yes, SRTP doesn't help you much if you're MITM'd - see ekr's identity > stuff & BrowserID for that.) > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --f46d042dfcd54c363504b5a75d32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 3, 2012 at 2:58 PM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote:
On 1/3/2012 7:55 AM, Markus.Isomaki@nokia.com wrote:
Hi,

Randell Jesup wrote:

I'll also note a 180MHz MIPS processor is very slow by modern standards= .
=C2=A0Our "lowest-spec" CPU should probably be the equivalent of= a 300MHz ARM
(and that's arguably too low, perhaps significantly too low).


Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connect= ivity, even the low-end ones seem to have at least 600 MHz ARM. Anything th= at I could imagine running WebRTC, in terms of real products, will have an = even faster CPU.

Nokia has had phones with SIP and SRTP for several years, so I doubt that w= ill be an issue. It's all the other stuff that WebRTC will need that wi= ll be much more challenging.

I chose 300MHz because that's the speed of the ARM in a first-generatio= n DaVinci and some of the older OMAPs I believe. =C2=A0Agreed, not really c= urrent devices likely to get webrtc - though support for lower-spec devices= does enable people wanting to build really inexpensive web devices (wired = or wireless). =C2=A0And lower overhead also means lower battery use (though= Justin reminds me that the CPU isn't the limiting factor here usually;= it's the display and wireless link).

I should note that audio SRTP overhead isn't really the issue; it's= the overhead for encrypting/decrypting far larger streams of video, and th= e SRTP overhead is (mostly) proportional to bitrate, so large resolution an= d/or low-compression streams will use more overhead.

I would argue that if you're processin= g video streams, SRTP overhead pales compared to the heavy encode/decode li= fting.=C2=A0
=C2=A0

Note: while I'm discussing nits here, I am in overall favor of SRTP-req= uired, if for no other reason than to head off bid-down attacks. =C2=A0I= 9;d love to have the option of not using it in very specific scenarios (PST= N gateway, internal corporate network or one with an PBX that doesn't s= upport a keying scheme we do), but I've yet to see a solution for those= that doesn't hurt other use-cases. =C2=A0(And I've tried to find a= way.)

If we make SRTP mandatory to use, people w= ill figure out a way to make SRTP work in their scenarios. If we don't,= people will continue to use the same old objections as to why they can'= ;t deploy SRTP.

SRTP isn't a panacea, but I think we have a chance = to take a big step forward here.
=C2=A0

(And yes, SRTP doesn't help you much if you're MITM'd - see ekr= 's identity stuff & BrowserID for that.)

--
Randell Jesup
randell-ietf@je= sup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--f46d042dfcd54c363504b5a75d32-- From bernard_aboba@hotmail.com Tue Jan 3 15:08:53 2012 Return-Path: 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 A9CE511E80AF for ; Tue, 3 Jan 2012 15:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.79 X-Spam-Level: X-Spam-Status: No, score=-101.79 tagged_above=-999 required=5 tests=[AWL=0.808, 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 qWZumCEe0nri for ; Tue, 3 Jan 2012 15:08:53 -0800 (PST) Received: from blu0-omc1-s17.blu0.hotmail.com (blu0-omc1-s17.blu0.hotmail.com [65.55.116.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1267C21F8440 for ; Tue, 3 Jan 2012 15:08:52 -0800 (PST) Received: from BLU152-W46 ([65.55.116.9]) by blu0-omc1-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 15:08:52 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_bac056ba-285d-450d-b187-387d1e5d4802_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Tue, 3 Jan 2012 15:08:52 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2012 23:08:52.0753 (UTC) FILETIME=[A9000010:01CCCA6C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 23:08:53 -0000 --_bac056ba-285d-450d-b187-387d1e5d4802_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Justin Uberti said: "If we make SRTP mandatory to use=2C people will figure out a way to make S= RTP work in their scenarios. If we don't=2C people will continue to use the= same old objections as to why they can't deploy SRTP. SRTP isn't a panacea=2C but I think we have a chance to take a big step for= ward here." [BA] In practice=2C the details of precisely how this is implemented make a= difference.=20 For example=2C it is quite different to require SRTP in all circumstances= =2C versus say=2C recommending that SRTP be preferred by default but allowi= ng RTP to be negotiated (via RFC 5939 or simple fallback). =20 Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not fall= ing back or allowing negotiation of RTP/AVP(F)) would not preclude gateways= from translating to RTP/AVP(F)=2C without user knowledge. =20 This would result in an illusion of security=2C compared with an actual neg= otiation which would apprise the user as to whether security is actually in= place.=20 = --_bac056ba-285d-450d-b187-387d1e5d4802_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Justin Uberti said:

"If we make SRTP mandatory to use=2C people will figure out a way to mak= e SRTP work in their scenarios. If we don't=2C people will continue to use = the same old objections as to why they can't deploy SRTP.

SRTP isn't a panacea=2C but I think we have a chance to= take a big step forward here."

[BA] In practice=2C the details of p= recisely how this is implemented make a difference.

For example=2C = it is quite different to require SRTP in all circumstances=2C versus say=2C= recommending that SRTP be preferred by default but allowing RTP to be nego= tiated (via RFC 5939 or simple fallback). =3B

Requiring SRTP in= all circumstances (e.g. offering RTP/SAVP(F) and not falling back or allow= ing negotiation of RTP/AVP(F)) would not preclude gateways from translating= to RTP/AVP(F)=2C without user knowledge. =3B

This would result= in an illusion of security=2C compared with an actual negotiation which wo= uld apprise the user as to whether security is actually in place.

<= br>
= --_bac056ba-285d-450d-b187-387d1e5d4802_-- From bernard_aboba@hotmail.com Tue Jan 3 15:59:42 2012 Return-Path: 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 619CE1F0C56 for ; Tue, 3 Jan 2012 15:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.864 X-Spam-Level: X-Spam-Status: No, score=-100.864 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_50=0.001, 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 Lvm6kPzNMsTO for ; Tue, 3 Jan 2012 15:59:41 -0800 (PST) Received: from blu0-omc1-s10.blu0.hotmail.com (blu0-omc1-s10.blu0.hotmail.com [65.55.116.21]) by ietfa.amsl.com (Postfix) with ESMTP id B35B81F0C50 for ; Tue, 3 Jan 2012 15:59:41 -0800 (PST) Received: from BLU152-W55 ([65.55.116.7]) by blu0-omc1-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 15:59:41 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_63a3dfe9-76c3-47ad-964d-2d71e0adcf2a_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Tue, 3 Jan 2012 15:59:40 -0800 Importance: Normal In-Reply-To: <683bfb1d-d142-4e86-9506-7d90ea27f44c@zimbra1.shared.sjc1.mozilla.com> References: , <683bfb1d-d142-4e86-9506-7d90ea27f44c@zimbra1.shared.sjc1.mozilla.com> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jan 2012 23:59:41.0426 (UTC) FILETIME=[C2269520:01CCCA73] Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 03 Jan 2012 23:59:42 -0000 --_63a3dfe9-76c3-47ad-964d-2d71e0adcf2a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris Blizzard said: "That really depends on how it's presented to users." [BA] The choice is either not to provide any information to users=2C or to = provide information in some form.=20 If there is no information provided=2C then the user would not know whether= media security is really in place or not. =20 While that might lead to suitably low expectations (e.g. users should assum= e no security=2C even if SRTP is used)=2C the conversation had talked about= setting a higher bar.=20 If information is provided=2C then it would seem desirable for that informa= tion to be reflective of the level of security in place. If not=2C why bo= ther? = --_63a3dfe9-76c3-47ad-964d-2d71e0adcf2a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chris Blizzard said:

"That really depends on how it's presented= to users."

[BA] The choice is either not to provide any information= to users=2C or to provide information in some form.

If there is no= information provided=2C then the user would not know whether media securit= y is really in place or not.  =3B

While that might lead to suit= ably low expectations (e.g. users should assume no security=2C even if SRTP= is used)=2C the conversation had talked about setting a higher bar.
If information is provided=2C then it would seem desirable for that infor= mation to be reflective of the level of security in place. =3B =3B = If not=2C why bother?
= --_63a3dfe9-76c3-47ad-964d-2d71e0adcf2a_-- From ted.ietf@gmail.com Tue Jan 3 16:02:59 2012 Return-Path: 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 694AA1F0C70 for ; Tue, 3 Jan 2012 16:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 45BAkaM1hkVT for ; Tue, 3 Jan 2012 16:02:59 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C96E611E80B3 for ; Tue, 3 Jan 2012 16:02:58 -0800 (PST) Received: by qadz3 with SMTP id z3so10916519qad.10 for ; Tue, 03 Jan 2012 16:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zvRNjy6gfnvue3pBOVmSjktqxAhh6N2Z+Wi2JpKSgQM=; b=o+c73AyIR+hMhxYS/cBWNsSDYQDd/5GuL9vs0CbR/R7Nfe9VXRub1RSb6gVEYA73RL 5xqCS1d2vb4PEor1ftGRu6RxsK+8oiXMSdLUYyB6jcTKGOeXMBsY3hPwSOdjtCNa9/We EeMTws3bimDJvW8d2A/kU6aXbq8v3LEnRfk30= MIME-Version: 1.0 Received: by 10.224.217.10 with SMTP id hk10mr5280920qab.15.1325635378385; Tue, 03 Jan 2012 16:02:58 -0800 (PST) Received: by 10.229.88.75 with HTTP; Tue, 3 Jan 2012 16:02:58 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Tue, 3 Jan 2012 16:02:58 -0800 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 00:02:59 -0000 On Tue, Jan 3, 2012 at 3:08 PM, Bernard Aboba wrote: > Justin Uberti said: > > Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not > falling back or allowing negotiation of RTP/AVP(F)) would not preclude > gateways from translating to RTP/AVP(F), without user knowledge. > > This would result in an illusion of security, compared with an actual > negotiation which would apprise the user as to whether security is actually > in place. > I'm a little lost. In a gateway implemented in a back-to-back user agent, won't you end up with the same illusion? The case I think you're talking about is this: UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 Do you expect that the gateway would be refuse to use SRTP on one side if it intended not to use it on the other? That seems pretty unlikely to me personally, especially in cases where the gateway is to the PSTN or a standard SIP system. Or do you expect that the negotiation would be extended so that the gateway somehow indicates that it will not SRTP on side two to side one? If the requirement is SRTP always for WEBRTC, then a b2bUA would have to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC applications, but that seems to be what we want. What am I missing? Ted > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From ekr@rtfm.com Tue Jan 3 16:20:20 2012 Return-Path: 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 8C24B21F84F6 for ; Tue, 3 Jan 2012 16:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.177 X-Spam-Level: X-Spam-Status: No, score=-101.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_WEPROVIDEC=1, RCVD_IN_DNSWL_LOW=-1, 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 Bwn6Z+Sv7o1N for ; Tue, 3 Jan 2012 16:20:20 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1B21F84E6 for ; Tue, 3 Jan 2012 16:20:15 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so14221124vcb.31 for ; Tue, 03 Jan 2012 16:20:11 -0800 (PST) Received: by 10.220.156.201 with SMTP id y9mr11461470vcw.22.1325636411171; Tue, 03 Jan 2012 16:20:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.95.110 with HTTP; Tue, 3 Jan 2012 16:19:30 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> From: Eric Rescorla Date: Tue, 3 Jan 2012 16:19:30 -0800 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 00:20:20 -0000 On Tue, Jan 3, 2012 at 4:02 PM, Ted Hardie wrote: > On Tue, Jan 3, 2012 at 3:08 PM, Bernard Aboba = wrote: >> Justin Uberti said: >> > >> Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not >> falling back or allowing negotiation of RTP/AVP(F)) would not preclude >> gateways from translating to RTP/AVP(F), without user knowledge. >> >> This would result in an illusion of security, compared with an actual >> negotiation which would apprise the user as to whether security is actua= lly >> in place. >> > I'm a little lost. =A0In a gateway implemented in a back-to-back user > agent, won't you end up with the same > illusion? > > The case I think you're talking about is this: > > UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 > > Do you expect that the gateway would be refuse to use SRTP on one side > if it intended not to use it on the other? =A0That seems pretty unlikely > to me personally, especially in cases where the gateway is to the PSTN > or a standard SIP system. =A0Or do you expect that the negotiation would > be extended so that the gateway somehow indicates that it will not > SRTP on side two to side one? > > If the requirement is SRTP always for WEBRTC, then a b2bUA would have > to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC > applications, but that seems to be what we want. > > What am I missing? I, too, am confused. Without using the words SRTP, here's the functionality I want, starting fro= m first principles. When I have a call, I would like to know to the extent possible: (a) Who the entity on the other end is. (b) That the call is secure to that entity, i.e., that we provide confidentiality and integrity for the data. Obviously, once the data is delivered to the entity on the other side, I ca= n no longer know what the security properties are. At best, they can simply assert those properties, whether via some technical mechanism or via a non-technical mechanism ("I promise to keep this conversation secret and I'm willing to sign an NDA"). That's out of scope for the security serv= ices we know how to offer. Now, it's clearly the case that there are settings in which there is a gap between the entity I want to be talking to and the entity that the technolo= gy allows me to provide a secure association to. One such example, as Ted suggests, is a gateway to the PSTN, which does not provide a secure channel. What I would like at that point is to be able to: (a) know that I am talking to the gateway and be able to distinguish this case from that where I am talking directly to the entity of interest. (b) have confidentiality and integrity provided for my data in transit to t= he gateway. Obviously, this has the potential to be misleading if the UI is done badly, but that seems like a result of having a system with differential security properties, not the result of having always-on crypto for the first hop link. The only way I know to not have people be potentially confused is to only have one security level, but since we've already established that it can't always be secure to the target entity, the only way to have one security level is to have it be never secure, which also seems rather undesirable. -Ekr From bernard_aboba@hotmail.com Tue Jan 3 16:28:21 2012 Return-Path: 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 4DA5F21F85C5 for ; Tue, 3 Jan 2012 16:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.055 X-Spam-Level: X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.543, 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 MBcwYHXr6pwA for ; Tue, 3 Jan 2012 16:28:20 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id A676721F85C1 for ; Tue, 3 Jan 2012 16:28:20 -0800 (PST) Received: from BLU152-W53 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 16:28:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_c2945da9-06f4-4551-acca-4064e41dfaa2_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Tue, 3 Jan 2012 16:28:19 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no>, <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 00:28:20.0250 (UTC) FILETIME=[C2A64FA0:01CCCA77] Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 00:28:21 -0000 --_c2945da9-06f4-4551-acca-4064e41dfaa2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted Hardie said:=20 > I'm a little lost. In a gateway implemented in a back-to-back user > agent=2C won't you end up with the same illusion? >=20 > The case I think you're talking about is this: >=20 > UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 >=20 > Do you expect that the gateway would be refuse to use SRTP on one side > if it intended not to use it on the other?=20 [BA] If the SBC needed to enable communication with a legacy endpoint=2C th= en it might want to negotiate security compatible with that endpoint.=20 Today there are PSTN gateways that support SRTP with SDES=2C but interop is= =20 frequently an issue (I've had to debug interop issues countless times)=2C s= o=20 I've often had to advise customers to turn SRTP off until an issue was reso= lved.=20 Few PSTN gateways support any flavor of end-to-end security today (e.g. ZRT= P=2C DTLS/SRTP=2C etc.)=2C=20 so a failover option is even more likely in that case.=20 > If the requirement is SRTP always for WEBRTC=2C then a b2bUA would have > to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC > applications=2C but that seems to be what we want. [BA] What you're missing is what legacy systems actually implement (see the= SIPIt reports).=20 = --_c2945da9-06f4-4551-acca-4064e41dfaa2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ted Hardie said:

>=3B I'm a little lost. In a gateway i= mplemented in a back-to-back user
>=3B agent=2C won't you end up with = the same illusion?
>=3B
>=3B The case I think you're talking abo= ut is this:
>=3B
>=3B UA--1<=3B-Connection1->=3BB2BUA/Gatewa= y<=3B-Connection-2->=3BUA-2
>=3B
>=3B Do you expect that the= gateway would be refuse to use SRTP on one side
>=3B if it intended n= ot to use it on the other?


[BA] If the SBC needed to enable communication with a legacy endpoint=2C th= en it
might want to negotiate security compatible with that endpoint.
Today there are PSTN gateways that support SRTP with SDES=2C but intero= p is
frequently an issue (I've had to debug interop issues countless ti= mes)=2C so
I've often had to advise customers to turn SRTP off until an= issue was resolved.

Few PSTN gateways support any flavor of end-to= -end security today (e.g. ZRTP=2C DTLS/SRTP=2C etc.)=2C
so a failover o= ption is even more likely in that case.

>=3B If the requirement i= s SRTP always for WEBRTC=2C then a b2bUA would have
>=3B to run SRTP o= n boths ides if both UA-1 and UA-2 were WEBRTC
>=3B applications=2C bu= t that seems to be what we want.

[BA] What you're missing is what le= gacy systems actually implement (see the SIPIt reports).
=
= --_c2945da9-06f4-4551-acca-4064e41dfaa2_-- From ekr@rtfm.com Tue Jan 3 16:42:32 2012 Return-Path: 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 86BA411E80AB for ; Tue, 3 Jan 2012 16:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 VgU0Bd+yIjGB for ; Tue, 3 Jan 2012 16:42:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C232011E8093 for ; Tue, 3 Jan 2012 16:42:31 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so13126318vbb.31 for ; Tue, 03 Jan 2012 16:42:31 -0800 (PST) Received: by 10.52.67.229 with SMTP id q5mr25538642vdt.14.1325637751186; Tue, 03 Jan 2012 16:42:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.95.110 with HTTP; Tue, 3 Jan 2012 16:41:50 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> From: Eric Rescorla Date: Tue, 3 Jan 2012 16:41:50 -0800 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 00:42:32 -0000 On Tue, Jan 3, 2012 at 4:28 PM, Bernard Aboba wrote: > > Ted Hardie said: > >> I'm a little lost. In a gateway implemented in a back-to-back user >> agent, won't you end up with the same illusion? >> >> The case I think you're talking about is this: >> >> UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 >> >> Do you expect that the gateway would be refuse to use SRTP on one side >> if it intended not to use it on the other? > > > [BA] If the SBC needed to enable communication with a legacy endpoint, then > it > might want to negotiate security compatible with that endpoint. > > Today there are PSTN gateways that support SRTP with SDES, but interop is > frequently an issue (I've had to debug interop issues countless times), so > I've often had to advise customers to turn SRTP off until an issue was > resolved. > > Few PSTN gateways support any flavor of end-to-end security today (e.g. > ZRTP, DTLS/SRTP, etc.), > so a failover option is even more likely in that case. > >> If the requirement is SRTP always for WEBRTC, then a b2bUA would have >> to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC >> applications, but that seems to be what we want. > > [BA] What you're missing is what legacy systems actually implement (see the > SIPIt reports). In the interest of clarity, when I say that I would require SRTP for WebRTC, what I mean is that if you wish to have your WebRTC client talk to a PSTN gateway that doesn't support SRTP, you would need to have a gateway in between. E.g., UA-1 <--- SRTP ---> WebRTC GW <--- RTP --> PSTN GW <---- PSTN I don't know what others have in their hands, but it's not my intent to levy a requirement for crypto through the entire RTP pathway, let alone to endpoints which don't even speak RTP. Of course, in the case above, whatever your UA displayed about the identity of the target would be somewhat disappointing. -Ekr From bernard_aboba@hotmail.com Tue Jan 3 16:57:21 2012 Return-Path: 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 3F59121F85B0 for ; Tue, 3 Jan 2012 16:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.482, 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 NsYNSh6tudw0 for ; Tue, 3 Jan 2012 16:57:20 -0800 (PST) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id AB97D21F85A9 for ; Tue, 3 Jan 2012 16:57:20 -0800 (PST) Received: from BLU152-W53 ([65.55.116.72]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 16:57:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_089d6939-677b-40b3-8945-fd88eceeed90_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , , Date: Tue, 3 Jan 2012 16:57:19 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 00:57:20.0243 (UTC) FILETIME=[CFC42C30:01CCCA7B] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 00:57:21 -0000 --_089d6939-677b-40b3-8945-fd88eceeed90_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Markus Isomaki said:=20 > Looking at the specs of any recent smartphones with Wi-Fi and/or 3G conne= ctivity=2C even the low-end ones seem to have at least 600 MHz ARM. Anythin= g that I could imagine running WebRTC=2C in terms of real products=2C will = have an even faster CPU.=20 [BA] I agree that computational load is a non-issue. I've deployed very in= expensive devices (e.g. ATAs costing less than $100) that support SRTP (alb= eit only with simple keying mechanisms like SDES). =20 In practice=2C it's not SRTP computational load=2C but interop particularly= in keying mechanisms where the issue is. I've had to advise customers to = turn SRTP off on devices that claim to support it=2C due to interop issues = (e.g. SDES). =20 There is some support out there for ZRTP=2C but few DTLS/SRTP implementatio= ns. =20 = --_089d6939-677b-40b3-8945-fd88eceeed90_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Markus Isomaki said:

>=3B Looking at the specs of any recent= smartphones with Wi-Fi and/or 3G connectivity=2C even the low-end ones see= m to have at least 600 MHz ARM. Anything that I could imagine running WebRT= C=2C in terms of real products=2C will have an even faster CPU.

[BA= ] I agree that computational load is a non-issue. =3B I've deployed ver= y inexpensive devices (e.g. ATAs costing less than $100) that support SRTP = (albeit only with simple keying mechanisms like SDES).  =3B

In = practice=2C it's not SRTP computational load=2C but interop particularly in= keying mechanisms where the issue is. =3B I've had to advise customers= to turn SRTP off on devices that claim to support it=2C due to interop iss= ues (e.g. SDES). =3B

There is some support out there for ZRTP= =2C but few DTLS/SRTP implementations.  =3B
= --_089d6939-677b-40b3-8945-fd88eceeed90_-- From randell-ietf@jesup.org Wed Jan 4 01:11:47 2012 Return-Path: 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 594B221F86D5 for ; Wed, 4 Jan 2012 01:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599] 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 S0fezxWYFwgD for ; Wed, 4 Jan 2012 01:11:46 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B55CC21F8654 for ; Wed, 4 Jan 2012 01:11:46 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RiMsr-0005zC-5e for rtcweb@ietf.org; Wed, 04 Jan 2012 03:11:46 -0600 Message-ID: <4F0417BC.6020906@jesup.org> Date: Wed, 04 Jan 2012 04:11:24 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 09:11:47 -0000 On 1/3/2012 7:41 PM, Eric Rescorla wrote: > On Tue, Jan 3, 2012 at 4:28 PM, Bernard Aboba wrote: >> >> Ted Hardie said: >> >>> I'm a little lost. In a gateway implemented in a back-to-back user >>> agent, won't you end up with the same illusion? >>> >>> The case I think you're talking about is this: >>> >>> UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 >>> >>> Do you expect that the gateway would be refuse to use SRTP on one side >>> if it intended not to use it on the other? >> >> >> [BA] If the SBC needed to enable communication with a legacy endpoint, then >> it >> might want to negotiate security compatible with that endpoint. Only if it expects to remove itself from the media path. If it's going to remain on the media path (and I believe for a number of reasons that's required), this is a non-issue. I think it has to be on the media path due to the ICE and 'consent' requirement. If we didn't have that, then we could *consider* allowing no-SRTP and get a benefit from it (i.e. avoidance of requiring a gateway to talk to non-webrtc destinations). However, I see no viable way to obtain such a benefit without significant compromise to security and/or some of the use-cases, and/or without presuming unlikely changes from legacy infrastructure (though some PBXes might). I spent a while on this, because the benefit is real - not in reducing overhead, but in reducing delay in some/many cases (if the gateway isn't close-to-colocated with one or another of the endpoints). Cullen and I talked about it offline as well. The best I came up with was not a viable solution, IMHO, and you open up the risk of bid-down attacks if you're not careful. > In the interest of clarity, when I say that I would require SRTP for WebRTC, > what I mean is that if you wish to have your WebRTC client talk to a PSTN > gateway that doesn't support SRTP, you would need to have a gateway > in between. E.g., > > UA-1<--- SRTP ---> WebRTC GW<--- RTP --> PSTN GW<---- PSTN > > I don't know what others have in their hands, but it's not my intent to levy > a requirement for crypto through the entire RTP pathway, let alone to > endpoints which don't even speak RTP. Of course, in the case above, > whatever your UA displayed about the identity of the target would be > somewhat disappointing. :-) -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Wed Jan 4 14:28:18 2012 Return-Path: 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 9B0C611E80E2 for ; Wed, 4 Jan 2012 14:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1x0PB7lpFH0z for ; Wed, 4 Jan 2012 14:28:17 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC08511E80C1 for ; Wed, 4 Jan 2012 14:28:17 -0800 (PST) Received: by obcuz6 with SMTP id uz6so16541054obc.31 for ; Wed, 04 Jan 2012 14:28:17 -0800 (PST) Received: by 10.50.181.197 with SMTP id dy5mr69708351igc.13.1325716097168; Wed, 04 Jan 2012 14:28:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id yg2sm119680607igb.1.2012.01.04.14.28.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 14:28:15 -0800 (PST) Received: by dajz8 with SMTP id z8so16662449daj.31 for ; Wed, 04 Jan 2012 14:28:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.191.202 with SMTP id ha10mr7760010pbc.112.1325716093289; Wed, 04 Jan 2012 14:28:13 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 4 Jan 2012 14:28:12 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 17:28:12 -0500 Message-ID: From: Roman Shpount To: juberti@google.com Content-Type: multipart/alternative; boundary=e89a8ff1c396d0436204b5bb5427 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 22:28:18 -0000 --e89a8ff1c396d0436204b5bb5427 Content-Type: text/plain; charset=ISO-8859-1 > > Justin Uberti said: > > "If we make SRTP mandatory to use, people will figure out a way to make > SRTP work in their scenarios. If we don't, people will continue to use the > same old objections as to why they can't deploy SRTP. > > > I thought our goal is to design a web based real time communication network with the widest possible set of capabilities. I never thought that the goal of this group is to promote other architectural agendas, even the ones as such as spreading communications security. Security of communications would be defined by the application developer. If application developer designs something that is meant to be insecure (like place all calls through a middle server that will record everything and publish it on an open web site), it would be. I do not understand why application developer with WebRTC should not have an option to communicate without SRTP. Ability for developer to specify that RTP is allowed for certain connection takes nothing from security of WebRTC, and makes a lot of issues (such as interop, getting initial application developed and tested, etc) a lot simpler. I do believe that SRTP CPU load argument is nonsense (especially with newer CPUs where there is hardware AES offload), but I the only argument I heard so far for mandatory SRTP use was that future WebRTC developers are so incompetent and ignorant that they will never use SRTP unless we force them. Make it simple to specify that SRTP is required via an API, make it default, and developers will use it. As long as WebRTC connection does not automatically fall back to RTP if SRTP connection is required and cannot be established, I simply don't see what the problem is. _____________ Roman Shpount --e89a8ff1c396d0436204b5bb5427 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin Uberti said:

"If we make SRTP = mandatory to use, people will figure out a way to make SRTP work in their s= cenarios. If we don't, people will continue to use the same old objecti= ons as to why they can't deploy SRTP.



I thought = our goal is to design a web based real time communication network with the = widest possible set of capabilities. I never thought that the goal of this = group is to promote other architectural agendas, even the ones as such as s= preading communications security. Security of communications would be defin= ed by the application developer. If application developer designs something= that is meant to be insecure (like place all calls through a middle server= that will record everything and publish it on an open web site), it would = be. I do not understand why application developer with WebRTC should not ha= ve an option to communicate without SRTP. Ability for developer to specify = that RTP is allowed for certain connection takes nothing from security of W= ebRTC, and makes a lot of issues (such as interop, getting initial applicat= ion developed and tested, etc) a lot simpler.

I do believe that SRTP CPU load argument is nonsense (especially with n= ewer CPUs where there is hardware AES offload), but I the only argument I h= eard so far for mandatory SRTP use was that future WebRTC developers are so= incompetent and ignorant that they will never use SRTP unless we force the= m. Make it simple to specify that SRTP is required via an API, make it defa= ult, and developers will use it. As long as WebRTC connection does not auto= matically fall back to RTP if SRTP connection is required and cannot be est= ablished, I simply don't see what the problem is.
_____________
Roman Shpount
--e89a8ff1c396d0436204b5bb5427-- From alan.b.johnston@gmail.com Wed Jan 4 15:09:24 2012 Return-Path: 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 32B5321F87CD for ; Wed, 4 Jan 2012 15:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 is7e7lomK8Bf for ; Wed, 4 Jan 2012 15:09:23 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 938EA21F87CA for ; Wed, 4 Jan 2012 15:09:23 -0800 (PST) Received: by obcuz6 with SMTP id uz6so16586750obc.31 for ; Wed, 04 Jan 2012 15:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NUuMJUkRMoHnbrUG2Ka69K4oaM+KXivVExyIuW3yGKQ=; b=Gv+BVhN/ySHyo5HrBQ30vRMw+CWm1LuolG7Xzcm4AgNfBwx+/P047F/t2M4VuwLPb3 ixPoNK3MZzDdwd039k2CiGIBzi0lxZslEJclIL6BY/pA9VLyJFgDB+6rDdht75i1R03s C+TZSJ0IGkA4OwK2JBGuQ/vxUMr0+hkjE3asQ= MIME-Version: 1.0 Received: by 10.182.40.98 with SMTP id w2mr49551883obk.36.1325718563238; Wed, 04 Jan 2012 15:09:23 -0800 (PST) Received: by 10.182.182.35 with HTTP; Wed, 4 Jan 2012 15:09:23 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 17:09:23 -0600 Message-ID: From: Alan Johnston To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 23:09:24 -0000 Here is the problem - allowing RTP opens up WebRTC to a bid down attack on media security. There are few good ways to prevent this bid down attack, and none of them work given the lack of standardization and control over WebRTC signaling. Also, allowing both RTP and SRTP is a user interface nightmare for the browsers. They have had all kinds of problems in the past with simple HTTP/HTTPS, and this will be even uglier. Mandating SRTP avoids both these problems. - Alan - On Wed, Jan 4, 2012 at 4:28 PM, Roman Shpount wrote: >> Justin Uberti said: >> >> "If we make SRTP mandatory to use, people will figure out a way to make >> SRTP work in their scenarios. If we don't, people will continue to use the >> same old objections as to why they can't deploy SRTP. >> >> > > I thought our goal is to design a web based real time communication network > with the widest possible set of capabilities. I never thought that the goal > of this group is to promote other architectural agendas, even the ones as > such as spreading communications security. Security of communications would > be defined by the application developer. If application developer designs > something that is meant to be insecure (like place all calls through a > middle server that will record everything and publish it on an open web > site), it would be. I do not understand why application developer with > WebRTC should not have an option to communicate without SRTP. Ability for > developer to specify that RTP is allowed for certain connection takes > nothing from security of WebRTC, and makes a lot of issues (such as interop, > getting initial application developed and tested, etc) a lot simpler. > > I do believe that SRTP CPU load argument is nonsense (especially with newer > CPUs where there is hardware AES offload), but I the only argument I heard > so far for mandatory SRTP use was that future WebRTC developers are so > incompetent and ignorant that they will never use SRTP unless we force them. > Make it simple to specify that SRTP is required via an API, make it default, > and developers will use it. As long as WebRTC connection does not > automatically fall back to RTP if SRTP connection is required and cannot be > established, I simply don't see what the problem is. > _____________ > Roman Shpount > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From roman@telurix.com Wed Jan 4 15:24:01 2012 Return-Path: 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 9EEFA11E8112 for ; Wed, 4 Jan 2012 15:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 a7zlTO1xd9TS for ; Wed, 4 Jan 2012 15:24:01 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2D11E8111 for ; Wed, 4 Jan 2012 15:24:00 -0800 (PST) Received: by obcuz6 with SMTP id uz6so16601129obc.31 for ; Wed, 04 Jan 2012 15:24:00 -0800 (PST) Received: by 10.50.214.42 with SMTP id nx10mr51842146igc.0.1325719440509; Wed, 04 Jan 2012 15:24:00 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id 5sm17053519ibe.8.2012.01.04.15.23.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 15:23:59 -0800 (PST) Received: by pbdd12 with SMTP id d12so15551487pbd.31 for ; Wed, 04 Jan 2012 15:23:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.4 with SMTP id h4mr54593796pbv.27.1325719437705; Wed, 04 Jan 2012 15:23:57 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 4 Jan 2012 15:23:57 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 18:23:57 -0500 Message-ID: From: Roman Shpount To: Alan Johnston Content-Type: multipart/alternative; boundary=f46d0417071d28007904b5bc1c91 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 04 Jan 2012 23:24:01 -0000 --f46d0417071d28007904b5bc1c91 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 4, 2012 at 6:09 PM, Alan Johnston wrote: > Here is the problem - allowing RTP opens up WebRTC to a bid down > attack on media security. There are few good ways to prevent this bid > down attack, and none of them work given the lack of standardization > and control over WebRTC signaling. > > If create connection API request does not specifically allow RTP connection, it should not be negotiated. The only possible bid down attack would be due to replacement of JavaScript (or some other cross site scripting issue). In this case security would already be compromised. So, what exact problem are we solving here by removing allow RTP option from the API? > Also, allowing both RTP and SRTP is a user interface nightmare for the > browsers. They have had all kinds of problems in the past with simple > HTTP/HTTPS, and this will be even uglier. > > What does this have to do with user interface? This is an API (application decision). User either trusts the application to provide security, or not. I am not sure HTTP/HTTPS analogy applies here since we are dealing with much more complex applications here, so either application developer will design something that is secure, or not. User has no way to verify this. Unless we provide some end-to-end security verification methods (which are not part of SRTP as it is defined now), user interface is almost pointless, since all it can say that secure connection is established to some unknown remote party. _____________ Roman Shpount --f46d0417071d28007904b5bc1c91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 4, 2012 at 6:09 PM, Alan Johnsto= n <alan.b= .johnston@gmail.com> wrote:
Here is the problem - allowing RTP opens up WebRTC to a bid down
attack on media security. =A0There are few good ways to prevent this bid down attack, and none of them work given the lack of standardization
and control over WebRTC signaling.

If create connection API request does not specificall= y allow RTP connection, it should not be negotiated. The only possible bid = down attack would be due to replacement of JavaScript (or some other cross = site scripting issue). In this case security would already be compromised. = So, what exact problem are we solving here by removing allow RTP option fro= m the API?

=A0
Also, allowing both RTP and SRTP is a user interface nightmare for the
browsers. =A0They have had all kinds of problems in the past with simple HTTP/HTTPS, and this will be even uglier.


What does this have to do with user interface? T= his is an API (application decision). User either trusts the application to= provide security, or not. I am not sure HTTP/HTTPS analogy applies here si= nce we are dealing with much more complex applications here, so either appl= ication developer will design something that is secure, or not. User has no= way to verify this. Unless we provide some end-to-end security verificatio= n methods (which are not part of SRTP as it is defined now), user interface= is almost pointless, since all it can say that secure connection is establ= ished to some unknown remote party.
_____________
Roman Shpount
--f46d0417071d28007904b5bc1c91-- From ted.ietf@gmail.com Wed Jan 4 16:02:39 2012 Return-Path: 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 7372611E80CE for ; Wed, 4 Jan 2012 16:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] 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 7OeGgPqcrlM0 for ; Wed, 4 Jan 2012 16:02:38 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC84F11E80C1 for ; Wed, 4 Jan 2012 16:02:38 -0800 (PST) Received: by qcsf15 with SMTP id f15so12785263qcs.31 for ; Wed, 04 Jan 2012 16:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NgmUKislJUhan5kYTfL8RbhUmLEtoVxBhS1gNh4H9UM=; b=FcAgmakR00xtiaphl+VoBVWgw3zB52PluKxR50sVyXyVtnBN3AEk1MHwV4IknIUPGi HUh62TLlirMED3Z/5xW2QBXFqPvNPXTuGTLc5dQFvMgtBLfNrf9Yfg8QtBW0ngfLD9CD CdBQ/N7s/fdx2HOWeCK2fD1/i/wR4tWG7lGMM= MIME-Version: 1.0 Received: by 10.229.77.20 with SMTP id e20mr21699161qck.88.1325721758314; Wed, 04 Jan 2012 16:02:38 -0800 (PST) Received: by 10.229.88.75 with HTTP; Wed, 4 Jan 2012 16:02:38 -0800 (PST) Date: Wed, 4 Jan 2012 16:02:38 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Logistics for the upcoming interim X-BeenThere: rtcweb@ietf.org 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 Jan 2012 00:02:39 -0000 Howdy, Though the formal announcement seems to be a bit stuck in limbo, we are still moving forward with the logistics for the interim on 31st of this month and the 1st of Feb. The location will be at Google's office campus in Mountain View, California. At the moment, we're scheduled for a room called "Beacon Rock" in building GWC5 (that's "Google West Campus,building 5)". A Google search for directions to "Google Bldg GWC5 Lobby, Mountain View, CA 94043" will direct you to the correct place to check in. I do not yet have call in information, and it does not appear likely that we will have in-room video conferencing support, but I will give updates as we get them. We are currently planning to provide both breakfast and lunch. If you can let me know via email that you plan to come, I would appreciate it, so I can size the meals appropriately. I may also be able to make check-in a bit easier if I have your name in advance. We'll obviously try to make things work for anyone who walks in, but any help you can give on notification is appreciated. A tentative schedule for the interim is: Day 1 (January 31st, 2012) Signaling: 3 hours on JSEP 1 hour on ROAP Lunch 2 hours for Signaling discussion Data Channel: 2 hours Day 2 (February 1st, 2012) 2.5 hours on Security 1 hour wrap-up & AOB. Lunch Shift over to RTCWEB in W3C context. Agenda bashing welcome now. Volunteer scribes, presenters, and so on even more welcome. thanks, Ted, Cullen, Magnus From bernard_aboba@hotmail.com Wed Jan 4 17:13:58 2012 Return-Path: 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 C44BD21F879F for ; Wed, 4 Jan 2012 17:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.334, 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 rijNUCI9tA3G for ; Wed, 4 Jan 2012 17:13:58 -0800 (PST) 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 B6BB721F85AF for ; Wed, 4 Jan 2012 17:13:57 -0800 (PST) Received: from BLU152-W11 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 17:13:57 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0c93deb6-fcea-466a-9f33-f50ef0ab7a7f_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 17:13:56 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 01:13:57.0088 (UTC) FILETIME=[4C586600:01CCCB47] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 01:13:58 -0000 --_0c93deb6-fcea-466a-9f33-f50ef0ab7a7f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Here is the problem - allowing RTP opens up WebRTC to a bid down > attack on media security.=20 [BA] There are a number of potential approaches that can minimize the potential for bid-down while still preventing interoperability failure.=20 Even if we assume all hosts implement SRTP with perfect interoperability such approaches would still be necessary=2C if only to permit debugging and minimize interop problems with respect to key management.=20 As an example=2C it is possible to constrain an initial offer (e.g. require RTP/SAVP(F) with some key management scheme)=2C while allowing fallback in the event of failure.=20 The fallback could be to a scheme with lesser but still passable security (e.g. from RTP/SAVP(F) with ZRTP or DTLS/SRTP to SDES)=2C or it could be all the way to RTP/AVP(F) if policy permits it and the user approves. =20 > Mandating SRTP avoids both these problems. [BA] If the problem were so easy to solve=2C why is AVT moving forward on http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ? The reality is that RTCWEB cannot avoid grappling with the issues articulat= ed in that document=2C given the wide range of RTCWEB usage scenarios and the= =20 current state of implementations. =20 By itself=2C mandating SRTP accomplishes as little (or even less) than mand= ating IPsec=20 did within IPv6. At the time of that debate=2C IKEv1 was widely implemente= d and even IKEv2 was more widely implemented than either ZRTP or DTLS/SRTP are today. Yet because of the wide range of usage scenarios "one size fits all" key management didn't work there=2C and as AVT has alre= ady=20 recognized=2C it isn't likely to work here either.=20 So yes=2C we can mandate SRTP. In theory it isn't hard to implement and th= e computational cost is low. But let's not kid ourselves that this gets us v= ery far down the road to security and interoperability in a wide range of RTCWEB=20 scenarios. Accomplishing this is with a single key management scheme is=20 unlikely=2C for the reasons draft-ietf-avt-srtp-not-mandatory describes. = And if you accept that (as AVT WG appears to)=2C then we are left with the same qu= estion=2C just one layer up.=20 = --_0c93deb6-fcea-466a-9f33-f50ef0ab7a7f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Here is the problem - allowing RTP opens up WebRTC to a bid down
=
>=3B attack on media security.

[BA] =3B There are a numb= er of potential approaches that can minimize the
potential for bid-down = while still preventing interoperability failure.

Even if we assume = all hosts implement SRTP with perfect interoperability
such approaches w= ould still be necessary=2C if only to permit debugging and
minimize inte= rop problems with respect to key management.

As an example=2C it is= possible to constrain an initial offer (e.g.
require RTP/SAVP(F) with s= ome key management scheme)=2C while
allowing fallback in the event of fa= ilure.

The fallback could be to a scheme with lesser but still pass= able security
(e.g. from RTP/SAVP(F) with ZRTP or DTLS/SRTP to SDES)=2C = or it could
be all the way to RTP/AVP(F) if policy permits it and the us= er approves. =3B

>=3B Mandating SRTP avoids both these proble= ms.

[BA] If the problem were so easy to solve=2C why is AVT moving f= orward on
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ?=

The reality is that RTCWEB cannot avoid grappling with the issues a= rticulated
in that document=2C given the wide range of RTCWEB usage scen= arios and the
current state of implementations. =3B =3B
By itself=2C mandating SRTP accomplishes as little (or even less) than man= dating IPsec
did within IPv6. =3B At the time of that debate=2C IKE= v1 was widely implemented and even
IKEv2 was more widely implemented tha= n either ZRTP or DTLS/SRTP
are today. =3B Yet because of the wide ra= nge of usage scenarios
"one size fits all" key management didn't work th= ere=2C and as AVT has already
recognized=2C it isn't likely to work her= e either.

So yes=2C we can mandate SRTP. =3B In theory it isn't= hard to implement and the
computational cost is low. =3B But let's = not kid ourselves that this gets us very far
down the road to security a= nd interoperability =3B in a wide range of RTCWEB
scenarios. = =3B Accomplishing this is with a single key management scheme is
unlike= ly=2C for the reasons draft-ietf-avt-srtp-not-mandatory describes. =3B&= nbsp=3B And if
you accept that (as AVT WG appears to)=2C then we are lef= t with the same question=2C
just one layer up.




= --_0c93deb6-fcea-466a-9f33-f50ef0ab7a7f_-- From ted.ietf@gmail.com Wed Jan 4 17:23:05 2012 Return-Path: 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 EF2A211E80B9 for ; Wed, 4 Jan 2012 17:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0fuYXz0KoXmy for ; Wed, 4 Jan 2012 17:23:05 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EA52711E8079 for ; Wed, 4 Jan 2012 17:23:04 -0800 (PST) Received: by qadz3 with SMTP id z3so45138qad.10 for ; Wed, 04 Jan 2012 17:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=chh482h9k5708KLXxVOYi3TAiqxirli4WgqhpbWxDek=; b=xXOJLrH3IKltfIZZQx448Ksif8Bb+tMgIz5M1dMePd2du304ZayErdtGcnZSFAoHUh hI584tNsql/IwHtZOidvKFKJdmZVqTdg9kYXV8RXIDQkSnSzZ+ZuQWSb7TVoBlFYfYOg aI7pTmhxItBa/BSf/RhrSvMs9aDSOiSZMnzWk= MIME-Version: 1.0 Received: by 10.224.100.129 with SMTP id y1mr327294qan.28.1325726584502; Wed, 04 Jan 2012 17:23:04 -0800 (PST) Received: by 10.229.88.75 with HTTP; Wed, 4 Jan 2012 17:23:04 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 17:23:04 -0800 Message-ID: From: Ted Hardie To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 01:23:06 -0000 On Wed, Jan 4, 2012 at 3:23 PM, Roman Shpount wrote: >> > If create connection API request does not specifically allow RTP connection, > it should not be negotiated. The only possible bid down attack would be due > to replacement of JavaScript (or some other cross site scripting issue). In > this case security would already be compromised. So, what exact problem are > we solving here by removing allow RTP option from the API? > I think the bid-down attack being discussed is one in which the user prefers SRTP but accepts RTP; in those cases an attacker can remove SRTP from the set offered of offered choices and force an insecure communication to occur by having the answerer appear to prefer to RTP (when, in fact, they saw only an RTP choice in the offer). At least as far as I can see, this attack is unrelated to the replacement of the Javascript application. regards, Ted > From ted.ietf@gmail.com Wed Jan 4 17:32:26 2012 Return-Path: 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 A008921F860E for ; Wed, 4 Jan 2012 17:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 0v-RvvGyPx10 for ; Wed, 4 Jan 2012 17:32:26 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D58F21F860F for ; Wed, 4 Jan 2012 17:32:25 -0800 (PST) Received: by qcsf15 with SMTP id f15so30122qcs.31 for ; Wed, 04 Jan 2012 17:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2vMVVjLSuZzZseZyL3/O+usZQverqpZVoO6JQbxk6/c=; b=OO5puKxjzsWJ7roVyCnpOHPtHL6KaZ/lwNqjNz/Lu3nkmRRTYeGqpXY/kX3tT0p6fX Y+PO3XlcMjXXTxKZB5E0BupjH1KsBdRPlDjl8Rl84alf7sAZ7dYWdWAcFmTO1Qi/7+XE ow8rj0OSHaY/FkL/u6hpzTJNY1AZ24GTmm9x4= MIME-Version: 1.0 Received: by 10.229.78.215 with SMTP id m23mr21879030qck.108.1325727143293; Wed, 04 Jan 2012 17:32:23 -0800 (PST) Received: by 10.229.88.75 with HTTP; Wed, 4 Jan 2012 17:32:23 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 17:32:23 -0800 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 01:32:26 -0000 On Wed, Jan 4, 2012 at 5:13 PM, Bernard Aboba w= rote: >> Here is the problem - allowing RTP opens up WebRTC to a bid down >> attack on media security. > > [BA]=A0 There are a number of potential approaches that can minimize the > potential for bid-down while still preventing interoperability failure. > Are they easier or harder to deploy than SRTP? >> Mandating SRTP avoids both these problems. > > [BA] If the problem were so easy to solve, why is AVT moving forward on > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ? As the document pretty clearly states, because RTP is used in a variety of deployment scenarios, including any source multicast (see section 2). At least my personal reading is also not that the document recommends against consistently securing the confidentiality and integrity of RTP where possible; it simply points out that there are other security methods available in some networks (e.g. 3GPP networks) and that there are some deployments where it is not. So far, I have not heard use cases for RTCWEB that include deployments where it is not possible. If you could provide text for the use case/scenarios draft that illustrates one and explain why, that would be very useful in moving this discussion forward. Until then, I think the Danvers Doctrine pretty plainly pushes us to make SRTP mandatory to implement. The key question is whether is whether it is: always on; default on; negotiated on. I am not personally persuaded that "negotiated on" makes for easier debugging of the resulting system, at least in the common case. To me, it increases the number of possible attacks and thus the code needed to mitigate them. Just my personal opinion, without hats. thanks, Ted From bernard_aboba@hotmail.com Wed Jan 4 17:35:43 2012 Return-Path: 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 91AD01F0C44 for ; Wed, 4 Jan 2012 17:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 QCt3Ls9bBcXG for ; Wed, 4 Jan 2012 17:35:43 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8131F0C43 for ; Wed, 4 Jan 2012 17:35:42 -0800 (PST) Received: from BLU152-W58 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 17:35:42 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_94b370a7-52bd-4a92-b156-1af0fdb72101_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 17:35:42 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 01:35:42.0871 (UTC) FILETIME=[56A71270:01CCCB4A] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 01:35:43 -0000 --_94b370a7-52bd-4a92-b156-1af0fdb72101_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted Hardie said:=20 > I think the bid-down attack being discussed is one in which the user > prefers SRTP but accepts RTP=3B in those cases an attacker can remove > SRTP from the set offered of offered choices and force an insecure > communication to occur by having the answerer appear to prefer to RTP > (when=2C in fact=2C they saw only an RTP choice in the offer). At least > as far as I can see=2C this attack is unrelated to the replacement of > the Javascript application. [BA] An alternative is to force an initial offer preferring RTP/SAVP(F).=20 That way=2C if both endpoints support SRTP and the offered key management scheme=2C it is guaranteed to be negotiated. Only if the preferred option = is not mutually supported could an alternative be selected.=20 = --_94b370a7-52bd-4a92-b156-1af0fdb72101_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ted Hardie said:

>=3B I think the bid-down attack being disc= ussed is one in which the user
>=3B prefers SRTP but accepts RTP=3B in= those cases an attacker can remove
>=3B SRTP from the set offered of = offered choices and force an insecure
>=3B communication to occur by h= aving the answerer appear to prefer to RTP
>=3B (when=2C in fact=2C th= ey saw only an RTP choice in the offer). At least
>=3B as far as I ca= n see=2C this attack is unrelated to the replacement of
>=3B the Javas= cript application.

[BA] An alternative is to force an initial offer = preferring RTP/SAVP(F).
That way=2C if both endpoints support SRTP and = the offered key management
scheme=2C it is guaranteed to be negotiated.&= nbsp=3B Only if the preferred option is
not mutually supported could an = alternative be selected.
= --_94b370a7-52bd-4a92-b156-1af0fdb72101_-- From roman@telurix.com Wed Jan 4 19:25:16 2012 Return-Path: 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 EE22A21F86DA for ; Wed, 4 Jan 2012 19:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ApDVsYzd+LaT for ; Wed, 4 Jan 2012 19:25:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2993821F86E6 for ; Wed, 4 Jan 2012 19:25:15 -0800 (PST) Received: by iabz21 with SMTP id z21so214930iab.31 for ; Wed, 04 Jan 2012 19:25:15 -0800 (PST) Received: by 10.50.236.67 with SMTP id us3mr773146igc.14.1325733915579; Wed, 04 Jan 2012 19:25:15 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id r18sm196366580ibh.4.2012.01.04.19.25.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 19:25:14 -0800 (PST) Received: by dajz8 with SMTP id z8so82612daj.31 for ; Wed, 04 Jan 2012 19:25:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.41 with SMTP id q9mr838078pbv.129.1325733913232; Wed, 04 Jan 2012 19:25:13 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 4 Jan 2012 19:25:13 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Wed, 4 Jan 2012 22:25:13 -0500 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d040f9c9cf7070a04b5bf7aee Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 03:25:17 -0000 --f46d040f9c9cf7070a04b5bf7aee Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba wrote: > [BA] An alternative is to force an initial offer preferring RTP/SAVP(F). > That way, if both endpoints support SRTP and the offered key management > scheme, it is guaranteed to be negotiated. Only if the preferred option is > not mutually supported could an alternative be selected. > > I would actually prefer a situation where a deliberate decision by application developer is required to allow RTP. By default, SRTP only connection should be accepted with no option to bid down (ie offer with RTP/SAVP(F) only and no null codec). If developer specifies that non-secure connections are allowed, only then RTP/AVP should be present in the offer or accepted in the answer (with crypto attributes or some other way to specify that AVPS is also supported). This way there no "accidental" RTP connections. _____________ Roman Shpount --f46d040f9c9cf7070a04b5bf7aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 4, 2012 at 8:35 PM= , Bernard Aboba <bernard_aboba@hotmail.com> wrote:
[BA] An alternative is to force an initial offer preferring RTP/SAVP(F= ).
That way, if both endpoints support SRTP and the offered key managem= ent
scheme, it is guaranteed to be negotiated.=A0 Only if the preferred = option is
not mutually supported could an alternative be selected.

=

I would actually prefer a situation where a delibera= te decision by application developer is required to allow RTP. By default, = SRTP only connection should be accepted with no option to bid down (ie offe= r with RTP/SAVP(F) only and no null codec). If developer specifies that non= -secure connections are allowed, only then RTP/AVP should be present in the= offer or accepted in the answer (with crypto attributes or some other way = to specify that AVPS is also supported). This way there no "accidental= " RTP connections.
_____________
Roman Shpount


--f46d040f9c9cf7070a04b5bf7aee-- From juberti@google.com Wed Jan 4 19:36:50 2012 Return-Path: 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 1772811E809D for ; Wed, 4 Jan 2012 19:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 UXZ+Q0NmZ+s1 for ; Wed, 4 Jan 2012 19:36:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E84B11E80A2 for ; Wed, 4 Jan 2012 19:36:47 -0800 (PST) Received: by iabz21 with SMTP id z21so228940iab.31 for ; Wed, 04 Jan 2012 19:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=xuEbl3PWGy38bMeEZYaLuu1RYNWC5mhzA1OTkE0pYJs=; b=bd7nzJfZbpPwo4rXQVgdRV6caWD3PeaMarmG3EKpFWoNm+5UXY7qwnijFjlo9hf0oq b2GaAfiPlIAQ4Zf1QoJlX4OWCQFmxxDBykeKfM8Nta7BOfLolkCCxR67humGX+jiYR8i y7h3LdL2q+RKEYQKHwWu8NHgm0t64sRYkN/hM= Received: by 10.50.189.199 with SMTP id gk7mr749081igc.30.1325734606997; Wed, 04 Jan 2012 19:36:46 -0800 (PST) Received: by 10.50.189.199 with SMTP id gk7mr749067igc.30.1325734606829; Wed, 04 Jan 2012 19:36:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.196.93 with HTTP; Wed, 4 Jan 2012 19:36:25 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> From: Justin Uberti Date: Wed, 4 Jan 2012 22:36:25 -0500 Message-ID: To: Ted Hardie X-System-Of-Record: true Content-Type: multipart/alternative; boundary=14dae9340b394e785e04b5bfa4a7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 03:36:50 -0000 --14dae9340b394e785e04b5bfa4a7 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 4, 2012 at 8:32 PM, Ted Hardie wrote: > On Wed, Jan 4, 2012 at 5:13 PM, Bernard Aboba > wrote: > >> Here is the problem - allowing RTP opens up WebRTC to a bid down > >> attack on media security. > > > > [BA] There are a number of potential approaches that can minimize the > > potential for bid-down while still preventing interoperability failure. > > > > Are they easier or harder to deploy than SRTP? > > >> Mandating SRTP avoids both these problems. > > > > [BA] If the problem were so easy to solve, why is AVT moving forward on > > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ? > > As the document pretty clearly states, because RTP is used in a > variety of deployment scenarios, including any source multicast (see > section 2). At least my personal reading is also not that the > document recommends against consistently securing the confidentiality > and integrity of RTP where possible; it simply points out that there > are other security methods available in some networks (e.g. 3GPP > networks) and that there are some deployments where it is not. > > So far, I have not heard use cases for RTCWEB that include deployments > where it is not possible. If you could provide text for the use > case/scenarios draft that illustrates one and explain why, that would > be very useful in moving this discussion forward. > > Until then, I think the Danvers Doctrine pretty plainly pushes us to > make SRTP mandatory to implement. The key question is whether is > whether it is: always on; default on; negotiated on. I am not > personally persuaded that "negotiated on" makes for easier debugging > of the resulting system, at least in the common case. To me, it > increases the number of possible attacks and thus the code needed to > mitigate them. > This argument about debugging keeps coming up, and although I am not persuaded by this argument, it is not a completely unreasonable request. However, I don't think this needs to be controllable from JS. One could easily imagine a plain-RTP option being available from a developer options dialog or console, for use by developers in debugging specific problems with their service. --14dae9340b394e785e04b5bfa4a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 4, 2012 at 8:32 PM, Ted Hard= ie <ted.ietf@gmail.com> wrote:
On Wed, Jan 4, 2012 at 5:13 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:
>> Here is the problem - allowing RTP opens up WebRTC to a bid down >> attack on media security.
>
> [BA]=C2=A0 There are a number of potential approaches that can minimiz= e the
> potential for bid-down while still preventing interoperability failure= .
>

Are they easier or harder to deploy than SRTP?

>> Mandating SRTP avoids both these problems.
>
> [BA] If the problem were so easy to solve, why is AVT moving forward o= n
> http://tools.ietf.org/html/draft-ietf-avt-srtp-not-man= datory ?

As the document pretty clearly states, because RTP is used in a
variety of deployment scenarios, including any source multicast (see
section 2). =C2=A0At least my personal reading is also not that the
document recommends against consistently securing the confidentiality
and integrity of RTP where possible; it simply points out that there
are other security methods available in some networks (e.g. 3GPP
networks) and that there are some deployments where it is not.

So far, I have not heard use cases for RTCWEB that include deployments
where it is not possible. =C2=A0If you could provide text for the use
case/scenarios draft that illustrates one and explain why, that would
be very useful in moving this discussion forward.

Until then, I think the Danvers Doctrine pretty plainly pushes us to
make SRTP mandatory to implement. =C2=A0The key question is whether is
whether it is: =C2=A0always on; default on; negotiated on. =C2=A0I am not personally persuaded that "negotiated on" makes for easier debugg= ing
of the resulting system, at least in the common case. =C2=A0To me, it
increases the number of possible attacks and thus the code needed to
mitigate them.

This argument about debu= gging keeps coming up, and although I am not persuaded by this argument, it= is not a completely unreasonable request. However, I don't think this = needs to be controllable from JS. One could easily imagine a plain-RTP opti= on being available from a developer options dialog or console, for use by d= evelopers in debugging specific problems with their service.
--14dae9340b394e785e04b5bfa4a7-- From randell-ietf@jesup.org Wed Jan 4 20:46:18 2012 Return-Path: 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 52D7F5E8001 for ; Wed, 4 Jan 2012 20:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] 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 UVbzUgh+ouJy for ; Wed, 4 Jan 2012 20:46:17 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 33C9F11E808E for ; Wed, 4 Jan 2012 20:46:17 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RifDT-0006yf-Jy for rtcweb@ietf.org; Wed, 04 Jan 2012 22:46:15 -0600 Message-ID: <4F052B03.8090101@jesup.org> Date: Wed, 04 Jan 2012 23:45:55 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 04:46:18 -0000 On 1/4/2012 10:25 PM, Roman Shpount wrote: > > On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba > wrote: > > [BA] An alternative is to force an initial offer preferring > RTP/SAVP(F). > That way, if both endpoints support SRTP and the offered key management > scheme, it is guaranteed to be negotiated. Only if the preferred > option is > not mutually supported could an alternative be selected. > > > I would actually prefer a situation where a deliberate decision by > application developer is required to allow RTP. By default, SRTP only > connection should be accepted with no option to bid down (ie offer with > RTP/SAVP(F) only and no null codec). If developer specifies that > non-secure connections are allowed, only then RTP/AVP should be present > in the offer or accepted in the answer (with crypto attributes or some > other way to specify that AVPS is also supported). This way there no > "accidental" RTP connections. As Eric R. would probably tell you, you not only have to worry about bid-down attacks (and they're important), but also the "threat model" for rtcweb is that we don't trust: a) the JS application b) the service provider/website to maintain security and privacy for our conversation. The JS application may be malicious or may have been subverted without knowledge of the provider, or the provider may have been compromised (by an attacker or by legal force) even if they're not actively evil. If you mandate SRTP (and use DTLS-SRTP), then the application and the website never have access to the keys, and you have end-to-end security (modulo gateways). If you combine that with the identity mechanisms from ekr's draft/presentation at Taipei, and you have verified, no MITM, end-to-end encryption. (Without identity info, we have no way to detect a MITM attack, especially if brokered by the service provider.) Side note: SDES generally has the same problem; the JS app and service provider/website have access to the keys. (With some pain we might be able to encrypt the SDES keys themselves, but I'm not sure that's practical.) The "interop with legacy needs no SRTP or optional SRTP" argument fails if we have to go through a gateway to get to legacy equipment anyways. And though I've tried hard to find a practical way around it, the 'consent' requirements handled by using ICE/etc end up requiring us to use a gateway. If you're using a gateway to talk to legacy devices and/or PSTN gateways, you can include SRTP in the gateway for the webrtc side. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Wed Jan 4 22:57:28 2012 Return-Path: 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 1824C1F0C3F for ; Wed, 4 Jan 2012 22:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xCFf9cVKrMOQ for ; Wed, 4 Jan 2012 22:57:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E72EE1F0C38 for ; Wed, 4 Jan 2012 22:57:26 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-5b-4f0549d5cb37 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.75.23425.5D9450F4; Thu, 5 Jan 2012 07:57:25 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 5 Jan 2012 07:57:24 +0100 Message-ID: <4F0549CF.8060006@ericsson.com> Date: Thu, 5 Jan 2012 07:57:19 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 06:57:28 -0000 On 01/05/2012 04:25 AM, Roman Shpount wrote: > > On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba > wrote: > > [BA] An alternative is to force an initial offer preferring > RTP/SAVP(F). > That way, if both endpoints support SRTP and the offered key management > scheme, it is guaranteed to be negotiated. Only if the preferred > option is > not mutually supported could an alternative be selected. > > > I would actually prefer a situation where a deliberate decision by > application developer is required to allow RTP. By default, SRTP only > connection should be accepted with no option to bid down (ie offer with > RTP/SAVP(F) only and no null codec). If developer specifies that > non-secure connections are allowed, only then RTP/AVP should be present > in the offer or accepted in the answer (with crypto attributes or some > other way to specify that AVPS is also supported). This way there no > "accidental" RTP connections. FWIW I proposed some time earlier that the application, when creating the PeerConnection object, could say that RTP is allowed (default is not-allowed). If this is not done no RTP would be offered nor accepted. Of course this does not help if you don't trust the application. > _____________ > Roman Shpount > > From pravindran@sonusnet.com Wed Jan 4 23:17:11 2012 Return-Path: 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 04B5F21F85A0 for ; Wed, 4 Jan 2012 23:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 P47eudih5wBi for ; Wed, 4 Jan 2012 23:17:10 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9EC21F859B for ; Wed, 4 Jan 2012 23:17:10 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q057HoTR010498; Thu, 5 Jan 2012 02:17:51 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 02:17:07 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 12:47:56 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 12:47:55 +0530 From: "Ravindran, Parthasarathi" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAEEoCAACFIAIAAA4cAgAAemYCAABaMgIAAcFRA Date: Thu, 5 Jan 2012 07:17:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> In-Reply-To: <4F052B03.8090101@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 07:17:56.0240 (UTC) FILETIME=[257E8900:01CCCB7A] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 07:17:11 -0000 Randell, I agree that SRTP has to be mandated-to-implement for the reasons which you= have mentioned and also agree that SRTP fallback should not be accepted by= default to avoid bid-down attack. The only possible solution for RTP media in WebRTC is to provide the user c= onfiguration in the browser (WebRTC client) to allow the trust website to c= reate RTP media based session. In this model, (browser) user provides the c= onsent to pass RTP media and user will know the implications. In case untru= sted website asks for RTP session through JavaScript, those request will be= declined. Hope it is inline with trusted model as user is responsible for = RTP session and not JavaScript or web-server.=20 RTP mechanism shall be used in the trusted site & network like intranet, En= terprise application. The need of RTP session is to reduce WebRTC-GW cost i= n performing SRTP-RTP.=20 I understand that it adds up complication in browser implementation as brow= ser has to consider both SRTP & RTP based on the configuration. It is more = like pop-up is blocked in browser by default in the browser except for pers= onal banking website based on user configuration. My point is that WebRTC client should be flexible for different deployment = rather than considering every URL is untrusted. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Thursday, January 05, 2012 10:16 AM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] SRTP not mandatory-to-use > >On 1/4/2012 10:25 PM, Roman Shpount wrote: >> >> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba >> > wrote: >> >> [BA] An alternative is to force an initial offer preferring >> RTP/SAVP(F). >> That way, if both endpoints support SRTP and the offered key >management >> scheme, it is guaranteed to be negotiated. Only if the preferred >> option is >> not mutually supported could an alternative be selected. >> >> >> I would actually prefer a situation where a deliberate decision by >> application developer is required to allow RTP. By default, SRTP only >> connection should be accepted with no option to bid down (ie offer >> with >> RTP/SAVP(F) only and no null codec). If developer specifies that >> non-secure connections are allowed, only then RTP/AVP should be >> present in the offer or accepted in the answer (with crypto attributes >> or some other way to specify that AVPS is also supported). This way >> there no "accidental" RTP connections. > >As Eric R. would probably tell you, you not only have to worry about >bid-down attacks (and they're important), but also the "threat model" >for rtcweb is that we don't trust: >a) the JS application >b) the service provider/website >to maintain security and privacy for our conversation. The JS >application may be malicious or may have been subverted without >knowledge of the provider, or the provider may have been compromised (by >an attacker or by legal force) even if they're not actively evil. > >If you mandate SRTP (and use DTLS-SRTP), then the application and the >website never have access to the keys, and you have end-to-end security >(modulo gateways). If you combine that with the identity mechanisms >from ekr's draft/presentation at Taipei, and you have verified, no MITM, >end-to-end encryption. (Without identity info, we have no way to detect >a MITM attack, especially if brokered by the service provider.) Side >note: SDES generally has the same problem; the JS app and service >provider/website have access to the keys. (With some pain we might be >able to encrypt the SDES keys themselves, but I'm not sure that's >practical.) > >The "interop with legacy needs no SRTP or optional SRTP" argument fails >if we have to go through a gateway to get to legacy equipment anyways. >And though I've tried hard to find a practical way around it, the >'consent' requirements handled by using ICE/etc end up requiring us to >use a gateway. If you're using a gateway to talk to legacy devices >and/or PSTN gateways, you can include SRTP in the gateway for the webrtc >side. > > >-- >Randell Jesup >randell-ietf@jesup.org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Jan 4 23:20:36 2012 Return-Path: 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 B455421F85C6 for ; Wed, 4 Jan 2012 23:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.345 X-Spam-Level: X-Spam-Status: No, score=-109.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lpa431LwCyBN for ; Wed, 4 Jan 2012 23:20:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1821821F85BF for ; Wed, 4 Jan 2012 23:20:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A2A539E16F; Thu, 5 Jan 2012 08:20:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+2k7NxqPbIS; Thu, 5 Jan 2012 08:20:34 +0100 (CET) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0667639E082; Thu, 5 Jan 2012 08:20:34 +0100 (CET) Message-ID: <4F054F74.5080904@alvestrand.no> Date: Thu, 05 Jan 2012 08:21:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Bernard Aboba References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 07:20:36 -0000 On 01/05/2012 02:13 AM, Bernard Aboba wrote: > > > Mandating SRTP avoids both these problems. > > [BA] If the problem were so easy to solve, why is AVT moving forward on > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ? > Because srtp-not-mandatory is pushing the token to the next layer up. In particular, quoting from -07: When it comes to fulfilling the "MUST Implement" strong security for a specific application, it will fall on that application to actually consider what building blocks it is required to support. To maximize interoperability it is desirable if certain applications, or classes of application with similar requirements, agree on what data security mechanisms and key-management should be used. If such agreement is not possible, there will be increased cost, either in the lack of interoperability, or in the need to implement more solutions. Unfortunately this situation, if not handled reasonably well, can result in a failure to satisfy the requirement of providing the users with an option of turning on strong security when desired. We're the next layer up. From bernard_aboba@hotmail.com Wed Jan 4 23:42:28 2012 Return-Path: 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 40AE221F85D4 for ; Wed, 4 Jan 2012 23:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.289, 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 A69VkXnVBkpM for ; Wed, 4 Jan 2012 23:42:27 -0800 (PST) Received: from blu0-omc4-s29.blu0.hotmail.com (blu0-omc4-s29.blu0.hotmail.com [65.55.111.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48C21F85BE for ; Wed, 4 Jan 2012 23:42:27 -0800 (PST) Received: from BLU152-W63 ([65.55.111.137]) by blu0-omc4-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 23:42:27 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d85fc532-a32b-452b-9974-70ff7d63566f_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 23:42:26 -0800 Importance: Normal In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , , , , , , <4F052B03.8090101@jesup.org>, <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 07:42:27.0259 (UTC) FILETIME=[924A38B0:01CCCB7D] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 07:42:28 -0000 --_d85fc532-a32b-452b-9974-70ff7d63566f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > If you mandate SRTP (and use DTLS-SRTP)=2C then the application and the > website never have access to the keys=2C and you have end-to-end security > (modulo gateways). =20 [BA] That depends very much on the exact design of the system. Within RTCWEB the term "DTLS/SRTP" is potentially describing a system different from the framework used in SIP=2C if signaling is done out of ban= d (e.g. we're not assuming that RFC 4474 is being implemented).=20 If signalling is out of scope (e.g. SIP is handled in Javascript)=2C then o= ne cannot make=20 the same claims about overall system security as one could with a SIP imple= mentation.=20 The same thing is true with respect to ICE=2C by the way -- once you remove= signalling from the scope=2C the security properties change (e.g. the browser doesn't = get to examine the SDP offer/answer exchange if signaling is done out-of-band). =20 > If you combine that with the identity mechanisms > from ekr's draft/presentation at Taipei=2C and you have verified=2C no MI= TM=2C > end-to-end encryption. =20 [BA] I would characterize the current draft as lacking in details=2C frankl= y. Do we=20 really think that this will be implemented in version 1.0? If not=2C then = what keying mechanism do we use along with the "mandatory to use SRTP"? From my perspective=2C making SRTP "mandatory to use" is not very helpful unless we are clear about how the keying is done. We don't need to repeat the IPsec/= IPv6 experience.=20 = --_d85fc532-a32b-452b-9974-70ff7d63566f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B If you mandate SRTP (and use DTLS-SRTP)=2C then the applica= tion and the
>=3B website never have access to the keys=2C and you hav= e end-to-end security
>=3B (modulo gateways).

[BA] That depen= ds very much on the exact design of the system. =3B Within
RTCWEB th= e term "DTLS/SRTP" is potentially describing a system
different from the= framework used in SIP=2C if signaling is done out of band (e.g.
we're n= ot assuming that RFC 4474 is being implemented).

If signalling is o= ut of scope (e.g. SIP is handled in Javascript)=2C then one cannot make the same claims about overall system security as one could with a SIP impl= ementation.
The same thing is true with respect to ICE=2C by the way --= once you remove signalling
from the scope=2C the security properties ch= ange (e.g. the browser doesn't get to examine
the SDP offer/answer excha= nge if signaling is done out-of-band). =3B

>=3B If you combin= e that with the identity mechanisms
>=3B from ekr's draft/presentation= at Taipei=2C and you have verified=2C no MITM=2C
>=3B end-to-end encr= yption.

[BA] I would characterize the current draft as lacking in = details=2C frankly. =3B =3B Do we
really think that this will b= e implemented in version 1.0? =3B If not=2C then what keying
mechani= sm do we use along with the "mandatory to use SRTP"? =3B From my
pe= rspective=2C making SRTP "mandatory to use" is not very helpful unless weare clear about how the keying is done. =3B We don't need to repeat t= he IPsec/IPv6
experience.

= --_d85fc532-a32b-452b-9974-70ff7d63566f_-- From bernard_aboba@hotmail.com Wed Jan 4 23:48:12 2012 Return-Path: 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 0985121F8539 for ; Wed, 4 Jan 2012 23:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.327 X-Spam-Level: X-Spam-Status: No, score=-102.327 tagged_above=-999 required=5 tests=[AWL=0.271, 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 7CeAbby0Hb4M for ; Wed, 4 Jan 2012 23:48:11 -0800 (PST) Received: from blu0-omc3-s10.blu0.hotmail.com (blu0-omc3-s10.blu0.hotmail.com [65.55.116.85]) by ietfa.amsl.com (Postfix) with ESMTP id 724EE21F8519 for ; Wed, 4 Jan 2012 23:48:11 -0800 (PST) Received: from BLU152-W9 ([65.55.116.72]) by blu0-omc3-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 23:48:11 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a0e684e3-2e6b-4a1a-9143-d81b9c4e8e7d_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 23:48:10 -0800 Importance: Normal In-Reply-To: <4F0549CF.8060006@ericsson.com> References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , , , , , , <4F0549CF.8060006@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 07:48:11.0066 (UTC) FILETIME=[5F3701A0:01CCCB7E] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 07:48:12 -0000 --_a0e684e3-2e6b-4a1a-9143-d81b9c4e8e7d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: > FWIW I proposed some time earlier that the application=2C when creating=20 > the PeerConnection object=2C could say that RTP is allowed (default is=20 > not-allowed). If this is not done no RTP would be offered nor accepted. [BA] We need to be a bit more clear about what we mean here. Hadriel has pointed out that RFC 5939 is rarely implemented. Given that=2C we need to be clear if we're talking about offering *both* RTP/SAVP(F) (preferred) and RTP/SAVP=2C or just RTP/SAVP(F)=2C with the ability to do another offer= /answer if that fails. Obviously the implementation complexity=2C delays=2C etc. w= ill differ between these approaches.=20 = --_a0e684e3-2e6b-4a1a-9143-d81b9c4e8e7d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
>=3B FWIW I proposed some time earlier that the appl= ication=2C when creating
>=3B the PeerConnection object=2C could say = that RTP is allowed (default is
>=3B not-allowed). If this is not don= e no RTP would be offered nor accepted.

[BA] We need to be a bit mor= e clear about what we mean here. =3B Hadriel
has pointed out that RF= C 5939 is rarely implemented. =3B Given that=2C we need
to be clear = if we're talking about offering *both* RTP/SAVP(F) (preferred)
and RTP/S= AVP=2C or just RTP/SAVP(F)=2C with the ability to do another offer/answerif that fails. =3B Obviously the implementation complexity=2C delays= =2C etc. will differ
between these approaches.
= --_a0e684e3-2e6b-4a1a-9143-d81b9c4e8e7d_-- From bernard_aboba@hotmail.com Thu Jan 5 00:03:40 2012 Return-Path: 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 AFC9521F8622 for ; Thu, 5 Jan 2012 00:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.54 X-Spam-Level: X-Spam-Status: No, score=-101.54 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, SARE_UNSUB16=1.291, 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 ltdNa15oXqOf for ; Thu, 5 Jan 2012 00:03:40 -0800 (PST) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5F21F8623 for ; Thu, 5 Jan 2012 00:03:39 -0800 (PST) Received: from BLU152-W45 ([65.55.116.7]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 00:03:39 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0405c3de-e55f-46cc-bb96-7335e9f087dc_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Thu, 5 Jan 2012 00:03:39 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org> , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 08:03:39.0356 (UTC) FILETIME=[8884D1C0:01CCCB80] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 08:03:40 -0000 --_0405c3de-e55f-46cc-bb96-7335e9f087dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Justin said: Are they easier or harder to deploy than SRTP? [BA] Having been involved in deployment of millions of SRTP endpoints=2C I = wouldn't say SRTP is hard to deploy. Virtually *all* the pain comes from k= ey management.=20 The same thing is true of IKE/IPsec by the way. When people complain about= IPsec=2C they almost always are talking about an IKE issue.=20 Justin said: "If you could provide text for the use case/scenarios draft that illustrates one and explain why=2C that would be very useful in moving this discussion forward." [BA] It's not hard to come up with scenarios where SRTP might be fine=2C bu= t DTLS/SRTP would be burdensome. PSTN gateways are a good example of that. Some support SRTP today=2C and a= lmost all of these do SDES. If we insisted=2C we could probably get some vendors to support ICE too. But ask= ing for DTLS/SRTP (especially a variant different from the one implemented in SIP) is highly unlikely.=20 Justin said:=20 "Until then=2C I think the Danvers Doctrine pretty plainly pushes us to make SRTP mandatory to implement." [BA] No objection to mandating implementation here. SRTP is implemented in= sub-$100 devices=2C so it's no big deal.=20 The key question is whether is whether it is: always on=3B default on=3B n= egotiated on. I am not personally persuaded that "negotiated on" makes for easier debugging of the resulting system=2C at least in the common case.=20 [BA] I'm not sure how we can avoid the possibility of "negotiation" in sign= aling unless we adopt a pure media security approach (e.g. ZRTP).=20 As long as it is possible to use offer/answer=2C you'll have the potential = to "negotiate" SDES=2C DTLS/SRTP (SIP Flavor)=2C etc.=20 Justin said: "To me=2C it increases the number of possible attacks and thus the code nee= ded to mitigate them." [BA] Are you saying that a DTLS/SRTP variant integrated with Oath or other = identity schemes would require minimal code and would interoperate seamless= ly??? Much more likely is that browser vendors would each support their own favor= ite identity service (as they've done with location) and we'd end up with a= non-interoperable yet "standard" solution. =20 No thanks.=20 = --_0405c3de-e55f-46cc-bb96-7335e9f087dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Justin said:

Are they easier or harder to deploy than SRTP?

[BA] Having been involved in deployment of millions of SRTP endpoi= nts=2C I wouldn't say SRTP is hard to deploy. =3B Virtually *all* the p= ain comes from key management.

The same thing is true of IKE/IPsec = by the way. =3B When people complain about IPsec=2C they almost always = are talking about an IKE issue.


Justin said:

"If you cou= ld provide text for the use
case/scenarios draft that illustrates one and explain why=2C that would
be very useful in moving this discussion forward."

[BA] It's not har= d to come up with scenarios where SRTP might be fine=2C but DTLS/SRTP would= be burdensome.

PSTN gateways are a good example of that. =3B So= me support SRTP today=2C and almost all of these do SDES. =3B If we
= insisted=2C we could probably get some vendors to support ICE too. =3B = But asking for DTLS/SRTP (especially a variant
different from the one im= plemented in SIP) is highly unlikely.

Justin said:

"Until then=2C I think the Danvers Doctrine pretty plainly pushes us to
make SRTP mandatory to implement."

[BA] No objection to mandating im= plementation here. =3B SRTP is implemented in sub-$100 devices=2C so it= 's no big deal.


The key question is whether is whether it is: &= nbsp=3Balways on=3B default on=3B negotiated on.  =3BI am not
personally persuaded that "negotiated on" makes for easier debugging
of the resulting system=2C at least in the common case.

[BA] I'm no= t sure how we can avoid the possibility of "negotiation" in signaling unles= s we adopt a pure media security approach (e.g. ZRTP).
As long as it is= possible to use offer/answer=2C you'll have the potential to "negotiate" S= DES=2C DTLS/SRTP (SIP Flavor)=2C etc.


Justin said:

"To m= e=2C it increases the number of possible attacks and thus the code needed t= o mitigate them."

[BA] Are you saying that a DTLS/SRTP variant integ= rated with Oath or other identity schemes would require minimal code and wo= uld interoperate seamlessly???

Much more likely is that browser vend= ors would each support their own favorite identity service (as they've done= with location) and we'd end up with a non-interoperable yet "standard" sol= ution. =3B

No thanks.
=
= --_0405c3de-e55f-46cc-bb96-7335e9f087dc_-- From roman@telurix.com Thu Jan 5 03:56:51 2012 Return-Path: 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 F02F821F87B0 for ; Thu, 5 Jan 2012 03:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 sDA+WQ76Mv2Z for ; Thu, 5 Jan 2012 03:56:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9B21F87A2 for ; Thu, 5 Jan 2012 03:56:50 -0800 (PST) Received: by obcuz6 with SMTP id uz6so579491obc.31 for ; Thu, 05 Jan 2012 03:56:50 -0800 (PST) Received: by 10.50.168.2 with SMTP id zs2mr2174957igb.21.1325764610492; Thu, 05 Jan 2012 03:56:50 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id i2sm91909735igq.6.2012.01.05.03.56.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 03:56:48 -0800 (PST) Received: by pbdd12 with SMTP id d12so360822pbd.31 for ; Thu, 05 Jan 2012 03:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.164 with SMTP id e4mr4529778pbv.95.1325764607071; Thu, 05 Jan 2012 03:56:47 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 5 Jan 2012 03:56:46 -0800 (PST) In-Reply-To: <4F052B03.8090101@jesup.org> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> Date: Thu, 5 Jan 2012 06:56:46 -0500 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=f46d040f9ba675d44904b5c6a00d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 11:56:52 -0000 --f46d040f9ba675d44904b5c6a00d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 4, 2012 at 11:45 PM, Randell Jesup wrote: > As Eric R. would probably tell you, you not only have to worry about > bid-down attacks (and they're important), but also the "threat model" for > rtcweb is that we don't trust: > a) the JS application > b) the service provider/website > to maintain security and privacy for our conversation. The JS application > may be malicious or may have been subverted without knowledge of the > provider, or the provider may have been compromised (by an attacker or by > legal force) even if they're not actively evil. > > I agree that there are a lot of other threat models, but none of this is addressed with a standard SRTP. If we design a different protocol (or key management schema) and create an appropriate UI to give access to this we can solve these problems. But, as most of us already know with HTTPS, users will not care/know enough to use this new UI to actually verify anything, so we will be dealing with the same set of security problems. So, from this point of view I am not sure these problems can (and should be solved). Also, keep in min that while adding identity to communication we should still allow for anonymous calls. If you mandate SRTP (and use DTLS-SRTP), then the application and the > website never have access to the keys, and you have end-to-end security > (modulo gateways). If you combine that with the identity mechanisms from > ekr's draft/presentation at Taipei, and you have verified, no MITM, > end-to-end encryption. (Without identity info, we have no way to detect a > MITM attack, especially if brokered by the service provider.) > Side note: SDES generally has the same problem; the JS app and service > provider/website have access to the keys. (With some pain we might be able > to encrypt the SDES keys themselves, but I'm not sure that's practical.) > > The "interop with legacy needs no SRTP or optional SRTP" argument fails if > we have to go through a gateway to get to legacy equipment anyways. And > though I've tried hard to find a practical way around it, the 'consent' > requirements handled by using ICE/etc end up requiring us to use a gateway. > If you're using a gateway to talk to legacy devices and/or PSTN gateways, > you can include SRTP in the gateway for the webrtc side. > > We are actually talking here about things that do not yet exist (like end-to-end identity in SRTP) or never saw any real deployment (like DTLS-SRTP). At this point we might as well design a new protocol. Let's replace ICE while we are at it, and have a protocol that does key exchange, media consent (including bandwidth and media type consent which is not part of anything now) in one transaction. I know it is tempting to use layered approach, but each layer we add slows down the connection time and compromises interop and security. At least this way a WebRTC implementer would not need to support 10 random parts of 50 different RFCs. I agree with your point on legacy gateways. My main concern is a barrier to entry in implementation of anything that communicates with WebRTC. The more things needs to be implemented, working, and tested at the same time, the harder it is to implement. With current approach, SRTP, ICE, RTP, and codec support need to start working together. If we have an ability to turn off SRTP, the other components are much easier to debug. If we provide no access to key exchange, it would be almost impossible to identify bad payload due to bad codec or media processing failure generated by a third party component. I have to do interop with new implementations which support encryption on the regular basis. Most of the communications from third parties start with "can we turn the encryption off for debugging?" or "can we turn the encryption off during development?". _____________ Roman Shpount --f46d040f9ba675d44904b5c6a00d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 4, 2012 at= 11:45 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
As Eric R. would probably tell you, you not only have to worry about bid-do= wn attacks (and they're important), but also the "threat model&quo= t; for rtcweb is that we don't trust:
a) the JS application
b) the service provider/website
to maintain security and privacy for our conversation. =A0The JS applicatio= n may be malicious or may have been subverted without knowledge of the prov= ider, or the provider may have been compromised (by an attacker or by legal= force) even if they're not actively evil.


I agree that there are a lot of other threat mode= ls, but none of this is addressed with a standard SRTP. If we design a diff= erent protocol (or key management schema) and create an appropriate UI to g= ive access to this we can solve these problems. But, as most of us already = know with HTTPS, users will not care/know enough to use this new UI to actu= ally verify anything, so we will be dealing with the same set of security p= roblems. So, from this point of view I am not sure these problems can (and = should be solved). Also, keep in min that while adding identity to communic= ation we should still allow for anonymous calls.

If you mandate SRTP (and use DTLS-SRTP), then the application and the websi= te never have access to the keys, and you have end-to-end security (modulo = gateways). =A0If you combine that with the identity mechanisms from ekr'= ;s draft/presentation at Taipei, and you have verified, no MITM, end-to-end= encryption. =A0(Without identity info, we have no way to detect a MITM att= ack, especially if brokered by the service provider.)
Side note: SDES generally has the same problem; the JS app and service prov= ider/website have access to the keys. =A0(With some pain we might be able t= o encrypt the SDES keys themselves, but I'm not sure that's practic= al.)

The "interop with legacy needs no SRTP or optional SRTP" argument= fails if we have to go through a gateway to get to legacy equipment anyway= s. And though I've tried hard to find a practical way around it, the &#= 39;consent' requirements handled by using ICE/etc end up requiring us t= o use a gateway. If you're using a gateway to talk to legacy devices an= d/or PSTN gateways, you can include SRTP in the gateway for the webrtc side= .


We are actually talking here abo= ut things that do not yet exist (like end-to-end identity in SRTP) or never= saw any real deployment (like DTLS-SRTP). At this point we might as well d= esign a new protocol. Let's replace ICE while we are at it, and have a = protocol that does key exchange, media consent (including bandwidth and med= ia type consent which is not part of anything now) in one transaction. I kn= ow it is tempting to use layered approach, but each layer we add slows down= the connection time and compromises interop and security. At least this wa= y a WebRTC implementer would not need to support 10 random parts of 50 diff= erent RFCs.

I agree with your point on legacy gateways. My main concern is a barrie= r to entry in implementation of anything that communicates with WebRTC. The= more things needs to be implemented, working, and tested at the same time,= the harder it is to implement. With current approach, SRTP, ICE, RTP, and = codec support need to start working together. If we have an ability to turn= off SRTP, the other components are much easier to debug. If we provide no = access to key exchange, it would be almost impossible to identify bad paylo= ad due to bad codec or media processing failure generated by a third party = component. I have to do interop with new implementations which support encr= yption on the regular basis. Most of the communications from third parties = start with "can we turn the encryption off for debugging?" or &q= uot;can we turn the encryption off during development?".
_____________
Roman Shpount
--f46d040f9ba675d44904b5c6a00d-- From bernard_aboba@hotmail.com Thu Jan 5 07:18:38 2012 Return-Path: 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 D9E7A21F8750 for ; Thu, 5 Jan 2012 07:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 hP1+1pqaqVBw for ; Thu, 5 Jan 2012 07:18:38 -0800 (PST) Received: from dub0-omc1-s15.dub0.hotmail.com (dub0-omc1-s15.dub0.hotmail.com [157.55.0.214]) by ietfa.amsl.com (Postfix) with ESMTP id 2314521F8719 for ; Thu, 5 Jan 2012 07:18:37 -0800 (PST) Received: from DUB0-P3-EAS41 ([157.55.0.237]) by dub0-omc1-s15.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 07:18:33 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 5 Jan 2012 07:19:31 -0800 To: Roman Shpount MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 05 Jan 2012 15:18:33.0583 (UTC) FILETIME=[49E3DFF0:01CCCBBD] Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 15:18:39 -0000 On Jan 5, 2012, at 3:56, "Roman Shpount" =20 >=20 > At this point we might as well design a new protocol. [BA] That seems like a precipitous conclusion, given that we haven't even co= me up with a set of requirements and evaluated existing protocols against th= em. On the other hand, the security draft contains "modified" versions of ex= isting schemes (thrown in without WG consensus), so it's not like that is de= fensible either. > My main concern is a barrier to entry in implementation of anything that c= ommunicates with WebRTC.=20 WebRTC will by nature have a high bar. The question is if the bar is high t= hat we still have interop issues 5+ years from now.= From fluffy@cisco.com Thu Jan 5 08:56:03 2012 Return-Path: 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 F117021F882B for ; Thu, 5 Jan 2012 08:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.99 X-Spam-Level: X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jq0+Oi4wg0TV for ; Thu, 5 Jan 2012 08:56:03 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6893521F8804 for ; Thu, 5 Jan 2012 08:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=914; q=dns/txt; s=iport; t=1325782563; x=1326992163; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=My8sbPgVNCy4bp8EVQeyAEJ4VHibMgHtmyOmYQLpJ5M=; b=aPS5bW5+MboxNSrIqO9pELTcuP9VkMioGchzxUySjduMsoeg0dwxORZh zdG2f5pX5xdeu39ryv3kRlVCjiNIUg0xdgsFwG7hGlKydDAOHXGuNBER9 DSlxh7IipseXHPNHKCGhUfKFnXDD3scH5fHL2LBPli45NcV5qW+ecBCOf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAM/UBU+rRDoG/2dsb2JhbABCggWqeIEFgXIBAQEDARIBJz8QCw44VwYuB4dYl3EBnhGLLmMEiDmMTYVPjQY X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; d="scan'208";a="23893549" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 05 Jan 2012 16:56:03 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q05Gu2hR016602; Thu, 5 Jan 2012 16:56:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 5 Jan 2012 09:56:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 16:56:04 -0000 On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: >=20 > This argument about debugging keeps coming up, and although I am not = persuaded by this argument, it is not a completely unreasonable request. = However, I don't think this needs to be controllable from JS. One could = easily imagine a plain-RTP option being available from a developer = options dialog or console, for use by developers in debugging specific = problems with their service. > _______________________________________________ I think the best solution for the debugging issue is to allow SRTP to = negotiate a NULL cipher in special cases such as Justin described above. = This keeps what you are debugging as close as possible to the version = when debugging is turned off. I like Justin's idea of having to enable = this in the browser and not having it under JS control.=20 Cullen (in my individual contributor role) From kpfleming@digium.com Thu Jan 5 09:07:20 2012 Return-Path: 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 50DE421F858A for ; Thu, 5 Jan 2012 09:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 g2QftBKkddK2 for ; Thu, 5 Jan 2012 09:07:19 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8521F8589 for ; Thu, 5 Jan 2012 09:07:19 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Riqmc-0005LU-AU for rtcweb@ietf.org; Thu, 05 Jan 2012 11:07:18 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 47F95D8005 for ; Thu, 5 Jan 2012 11:07:18 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eV0ZcacHDUG for ; Thu, 5 Jan 2012 11:07:17 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id BC2D7D8002 for ; Thu, 5 Jan 2012 11:07:17 -0600 (CST) Message-ID: <4F05D8C5.10806@digium.com> Date: Thu, 05 Jan 2012 11:07:17 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> In-Reply-To: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 17:07:20 -0000 On 01/05/2012 10:56 AM, Cullen Jennings wrote: > > On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: > >> >> This argument about debugging keeps coming up, and although I am not persuaded by this argument, it is not a completely unreasonable request. However, I don't think this needs to be controllable from JS. One could easily imagine a plain-RTP option being available from a developer options dialog or console, for use by developers in debugging specific problems with their service. >> _______________________________________________ > > I think the best solution for the debugging issue is to allow SRTP to negotiate a NULL cipher in special cases such as Justin described above. This keeps what you are debugging as close as possible to the version when debugging is turned off. I like Justin's idea of having to enable this in the browser and not having it under JS control. +1, unless I get more votes, in which case +all-of-my-votes -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From alan.b.johnston@gmail.com Thu Jan 5 09:08:16 2012 Return-Path: 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 1874F21F865E for ; Thu, 5 Jan 2012 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.542 X-Spam-Level: X-Spam-Status: No, score=-103.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 CZD4tqwK-20f for ; Thu, 5 Jan 2012 09:08:15 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 333E421F85B4 for ; Thu, 5 Jan 2012 09:08:15 -0800 (PST) Received: by obcuz6 with SMTP id uz6so986437obc.31 for ; Thu, 05 Jan 2012 09:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AxkH/VGc+FHkIQIEvBg/XsTfE/T5sxdreRKeBouBoeA=; b=fPX/SSCS5LduuQkQGa5HooqzQ8oUA8xqUlyEG96qRzsWpLrzaT8eQoK1xTrXhogp8K 4oyPmFXcsiytBnNIsUer/Mk8dHaWAWMfaUXAiHgLDoQEC89PDm+fpErWg9Yck4oNG3Ug TtcBce2VGzvh2u3PG+qO+7mQPtt5IJCTus3GQ= MIME-Version: 1.0 Received: by 10.182.220.40 with SMTP id pt8mr2063598obc.46.1325783294867; Thu, 05 Jan 2012 09:08:14 -0800 (PST) Received: by 10.182.182.35 with HTTP; Thu, 5 Jan 2012 09:08:14 -0800 (PST) In-Reply-To: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> Date: Thu, 5 Jan 2012 11:08:14 -0600 Message-ID: From: Alan Johnston To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 17:08:16 -0000 On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings wrote: > > On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: > >> >> This argument about debugging keeps coming up, and although I am not per= suaded by this argument, it is not a completely unreasonable request. Howev= er, I don't think this needs to be controllable from JS. One could easily i= magine a plain-RTP option being available from a developer options dialog o= r console, for use by developers in debugging specific problems with their = service. >> _______________________________________________ > > I think the best solution for the debugging issue is to allow SRTP to neg= otiate a NULL cipher in special cases such as Justin described above. This = keeps what you are debugging as close as possible to the version when debug= ging is turned off. I like Justin's idea of having to enable this in the br= owser and not having it under JS control. > > Cullen (in my individual contributor role) This seems like the right way to do this. - Alan - > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ted.ietf@gmail.com Thu Jan 5 09:12:25 2012 Return-Path: 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 CFBFF21F868D for ; Thu, 5 Jan 2012 09:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 pTjDPqf93f6G for ; Thu, 5 Jan 2012 09:12:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A40D121F85B0 for ; Thu, 5 Jan 2012 09:12:24 -0800 (PST) Received: by yenm7 with SMTP id m7so309369yen.31 for ; Thu, 05 Jan 2012 09:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LTNSks7g4LlwCbk9+UAa1HO3kyMxfWWuuiXO4UJtit4=; b=uOgYbhe2ik55nKWyrV7nDuV9kuXWqVbjWcrgnjEzbkaT2f2s3gIH9BHLkOWrigGpgs 3iJ1WpYGrSGPOmcLp7cU/dxs6Fj8E6kWoU09xTemqIbJ5SRrhhdKT8NQqexFGpNZR9lo +sBhGXHPheBbz4frJ1ZGOfasce5bUwBtLummU= MIME-Version: 1.0 Received: by 10.236.139.193 with SMTP id c41mr2749145yhj.24.1325783542375; Thu, 05 Jan 2012 09:12:22 -0800 (PST) Received: by 10.236.155.132 with HTTP; Thu, 5 Jan 2012 09:12:22 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Date: Thu, 5 Jan 2012 09:12:22 -0800 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 17:12:26 -0000 Hi Bernard, The threading must have gotten mixed up here, because the responses below are to me, not Justin. Some further discussion in-line. On Thu, Jan 5, 2012 at 12:03 AM, Bernard Aboba wrote: > > Justin said: > > > Are they easier or harder to deploy than SRTP? > > [BA] Having been involved in deployment of millions of SRTP endpoints, I > wouldn't say SRTP is hard to deploy.=A0 Virtually *all* the pain comes fr= om > key management. > > The same thing is true of IKE/IPsec by the way.=A0 When people complain a= bout > IPsec, they almost always are talking about an IKE issue. > > Thanks for the clarification. But if we accept the current threat model (untrusted JS, where we wish to avoid revealing the SRTP keys to the application), I'm not sure that there is any way to avoid this pain. > Justin said: > > "If you could provide text for the use > case/scenarios draft that illustrates one and explain why, that would > be very useful in moving this discussion forward." > > [BA] It's not hard to come up with scenarios where SRTP might be fine, bu= t > DTLS/SRTP would be burdensome. > > PSTN gateways are a good example of that.=A0 Some support SRTP today, and > almost all of these do SDES.=A0 If we > insisted, we could probably get some vendors to support ICE too.=A0 But a= sking > for DTLS/SRTP (especially a variant > different from the one implemented in SIP) is highly unlikely. > I agree that increasing the number of variants will be a pain for gateway operators. If there is something currently is deployed and meets the threat model, I am sure that there would be interest. But shifting to something that reveals the keys to an untrusted part of the system seems to be the wrong approach for solving the problem, at least to me personally. > Justin said: > > "Until then, I think the Danvers Doctrine pretty plainly pushes us to > make SRTP mandatory to implement." > > [BA] No objection to mandating implementation here.=A0 SRTP is implemente= d in > sub-$100 devices, so it's no big deal. > > > The key question is whether is whether it is: =A0always on; default on; > negotiated on. =A0I am not > personally persuaded that "negotiated on" makes for easier debugging > of the resulting system, at least in the common case. > > [BA] I'm not sure how we can avoid the possibility of "negotiation" in > signaling unless we adopt a pure media security approach (e.g. ZRTP). > As long as it is possible to use offer/answer, you'll have the potential = to > "negotiate" SDES, DTLS/SRTP (SIP Flavor), etc. > Well, we've agreed to offer/answer as the basic model, but I think we're still discussing whether that means that includes negotiation of SRTP vs. RTP. > > Justin said: > > "To me, it increases the number of possible attacks and thus the code nee= ded > to mitigate them." > > [BA] Are you saying that a DTLS/SRTP variant integrated with Oath or othe= r > identity schemes would require minimal code and would interoperate > seamlessly??? > Nope, I'm saying that supporting that *plus* a negotiation that allows for vanilla RTP means we have to add other protections against bid down attacks. Those protections men more code. Hope that clarifies things, Ted From randell-ietf@jesup.org Thu Jan 5 09:29:24 2012 Return-Path: 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 644B421F886D for ; Thu, 5 Jan 2012 09:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] 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 CkAbVqcP4Jst for ; Thu, 5 Jan 2012 09:29:22 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B831421F8852 for ; Thu, 5 Jan 2012 09:29:21 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rir7w-0004UB-Qa for rtcweb@ietf.org; Thu, 05 Jan 2012 11:29:20 -0600 Message-ID: <4F05DDD9.3090305@jesup.org> Date: Thu, 05 Jan 2012 12:28:57 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 17:29:24 -0000 On 1/5/2012 2:17 AM, Ravindran, Parthasarathi wrote: > Randell, > > I agree that SRTP has to be mandated-to-implement for the reasons which you have mentioned and also agree that SRTP fallback should not be accepted by default to avoid bid-down attack. > > The only possible solution for RTP media in WebRTC is to provide the user configuration in the browser (WebRTC client) to allow the trust website to create RTP media based session. In this model, (browser) user provides the consent to pass RTP media and user will know the implications. In case untrusted website asks for RTP session through JavaScript, those request will be declined. Hope it is inline with trusted model as user is responsible for RTP session and not JavaScript or web-server. > > RTP mechanism shall be used in the trusted site& network like intranet, Enterprise application. The need of RTP session is to reduce WebRTC-GW cost in performing SRTP-RTP. "and user will know the implications " Right. ;-) > I understand that it adds up complication in browser implementation as browser has to consider both SRTP& RTP based on the configuration. It is more like pop-up is blocked in browser by default in the browser except for personal banking website based on user configuration. And those sorts of things and exception-mechanisms are a real problem for most users, UI-wise. Users don't generally understand the issues or what they're agreeing to, no matter how scary we make the warnings. It helps some, but often confuses as many users as it helps. This is reinforced every time I play remote-IT-person over the phone with my stepmother. As for SRTP costs: The SRTP cost for the client is low enough not to be an issue (measurable, but within reason on any expected hardware). The SRTP cost on a server hosting a large number of connections (and mostly just routing them) may be significant to a service provider -- for example, games where 'broadcast' announcements to large numbers of connected users have to be encrypted for each connection, or a hangout-like conference where streams are sent to a central location and resent to a large number of other members (especially in the without-mixing case). In these cases, the server has to encode and/or decode a medium to large number of streams, but isn't doing heavy processing of the decoded media, so SRTP cost is a much larger factor. Similar aspects apply to WebRTC gateways, at least run on commodity hardware - media data isn't being processed, just streams forwarded with decryption/encryption (and ICE, which should be in the noise). So, an argument can be made (from a performance of the server/gateway point-of-view) that there's some justification for plain RTP, at least in a few use cases. However, even in those there are often privacy issues - for example, in a Hangout-like app allowing video to be passed around without encryption is a privacy risk in general, and users aren't well set up to evaluate the risks (and even more importantly, the difference in risk in different situations). So, even though there are cost optimizations to pure RTP for servers, they don't (to me) justify allowing plain RTP in webrtc in general. The added risk to the user of snooping (which is hard to explain to the user) is significant; and what is the payoff? Mostly it's slightly reduced gateway/server costs (since I don't think we can eliminate a webrtc->legacy gateway due to the consent requirement). If we could eliminate that, then you'd also get a bonus of lower delay in interop (or much lower in some cases). Since I don't see that happening, the benefits are relatively low and the risk to users (and possible UI confusion) is higher. > > My point is that WebRTC client should be flexible for different deployment rather than considering every URL is untrusted. > > Thanks > Partha > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Randell Jesup >> Sent: Thursday, January 05, 2012 10:16 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] SRTP not mandatory-to-use >> >> On 1/4/2012 10:25 PM, Roman Shpount wrote: >>> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba >>> > wrote: >>> >>> [BA] An alternative is to force an initial offer preferring >>> RTP/SAVP(F). >>> That way, if both endpoints support SRTP and the offered key >> management >>> scheme, it is guaranteed to be negotiated. Only if the preferred >>> option is >>> not mutually supported could an alternative be selected. >>> >>> >>> I would actually prefer a situation where a deliberate decision by >>> application developer is required to allow RTP. By default, SRTP only >>> connection should be accepted with no option to bid down (ie offer >>> with >>> RTP/SAVP(F) only and no null codec). If developer specifies that >>> non-secure connections are allowed, only then RTP/AVP should be >>> present in the offer or accepted in the answer (with crypto attributes >>> or some other way to specify that AVPS is also supported). This way >>> there no "accidental" RTP connections. >> As Eric R. would probably tell you, you not only have to worry about >> bid-down attacks (and they're important), but also the "threat model" >> for rtcweb is that we don't trust: >> a) the JS application >> b) the service provider/website >> to maintain security and privacy for our conversation. The JS >> application may be malicious or may have been subverted without >> knowledge of the provider, or the provider may have been compromised (by >> an attacker or by legal force) even if they're not actively evil. >> >> If you mandate SRTP (and use DTLS-SRTP), then the application and the >> website never have access to the keys, and you have end-to-end security >> (modulo gateways). If you combine that with the identity mechanisms > >from ekr's draft/presentation at Taipei, and you have verified, no MITM, >> end-to-end encryption. (Without identity info, we have no way to detect >> a MITM attack, especially if brokered by the service provider.) Side >> note: SDES generally has the same problem; the JS app and service >> provider/website have access to the keys. (With some pain we might be >> able to encrypt the SDES keys themselves, but I'm not sure that's >> practical.) >> >> The "interop with legacy needs no SRTP or optional SRTP" argument fails >> if we have to go through a gateway to get to legacy equipment anyways. >> And though I've tried hard to find a practical way around it, the >> 'consent' requirements handled by using ICE/etc end up requiring us to >> use a gateway. If you're using a gateway to talk to legacy devices >> and/or PSTN gateways, you can include SRTP in the gateway for the webrtc >> side. >> >> >> -- >> Randell Jesup >> randell-ietf@jesup.org >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Thu Jan 5 10:01:10 2012 Return-Path: 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 367BB21F87FF for ; Thu, 5 Jan 2012 10:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.888 X-Spam-Level: X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315, 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 K4jH7NMGwNDI for ; Thu, 5 Jan 2012 10:01:09 -0800 (PST) Received: from blu0-omc1-s3.blu0.hotmail.com (blu0-omc1-s3.blu0.hotmail.com [65.55.116.14]) by ietfa.amsl.com (Postfix) with ESMTP id 635E821F87F6 for ; Thu, 5 Jan 2012 10:01:06 -0800 (PST) Received: from BLU0-P2-EAS129 ([65.55.116.7]) by blu0-omc1-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 10:01:06 -0800 X-Originating-IP: [74.92.226.89] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 5 Jan 2012 10:02:05 -0800 To: Ted Hardie MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 05 Jan 2012 18:01:06.0471 (UTC) FILETIME=[FF107B70:01CCCBD3] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 18:01:10 -0000 Comments below. On Jan 5, 2012, at 9:12, "Ted Hardie" wrote: > Hi Bernard, >=20 > The threading must have gotten mixed up here, because the responses > below are to me, not Justin. Some further discussion in-line. >=20 > On Thu, Jan 5, 2012 at 12:03 AM, Bernard Aboba > wrote: >>=20 >> Justin said: >>=20 >>=20 >> Are they easier or harder to deploy than SRTP? >>=20 >> [BA] Having been involved in deployment of millions of SRTP endpoints, I >> wouldn't say SRTP is hard to deploy. Virtually *all* the pain comes from= >> key management. >>=20 >> The same thing is true of IKE/IPsec by the way. When people complain abo= ut >> IPsec, they almost always are talking about an IKE issue. >>=20 >>=20 >=20 > Thanks for the clarification. But if we accept the current threat > model (untrusted JS, where we wish to avoid revealing the SRTP keys to > the application), I'm not sure that there is any way to avoid this. >=20 > I agree that increasing the number of variants will be a pain for > gateway operators. If there is something currently is deployed and > meets the threat model, I am sure that there would be interest. But > shifting to something that reveals the keys to an untrusted part of > the system seems to be the wrong approach for solving the problem, at > least to me. [BA] It might help to articulate the trust model in more detail. I understan= d the JS and web server arguments but with things like SBCs the notion can g= et muddled, particularly if media termination is envisaged. =20 >>=20 >> [BA] No objection to mandating implementation here. SRTP is implemented i= n >> sub-$100 devices, so it's no big deal. >=20 > Well, we've agreed to offer/answer as the basic model, but I think > we're still discussing whether that means that includes negotiation of > SRTP vs. RTP. >=20 > Nope, I'm saying that supporting that *plus* a negotiation that allows > for vanilla RTP means we have to add other protections against bid > down attacks. Those protections men more code. >=20 > Hope that clarifies things, >=20 > Ted [BA] Yes, it does. Maybe it would help to separate parts of this discussion= (SRTP vs. RTP, key mgmt, etc.). =20= From bernard_aboba@hotmail.com Thu Jan 5 10:29:15 2012 Return-Path: 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 6B1A221F87E8 for ; Thu, 5 Jan 2012 10:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.046 X-Spam-Level: X-Spam-Status: No, score=-101.046 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 8+Z1FDVY-5vC for ; Thu, 5 Jan 2012 10:29:14 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by ietfa.amsl.com (Postfix) with ESMTP id 732CE21F8819 for ; Thu, 5 Jan 2012 10:29:14 -0800 (PST) Received: from BLU0-P1-EAS79 ([65.55.116.73]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 10:29:14 -0800 X-Originating-IP: [74.92.226.89] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> <4F05DDD9.3090305@jesup.org> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <4F05DDD9.3090305@jesup.org> Date: Thu, 5 Jan 2012 10:30:14 -0800 To: Randell Jesup MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 05 Jan 2012 18:29:14.0255 (UTC) FILETIME=[ED0FE1F0:01CCCBD7] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 18:29:15 -0000 Comments below. On Jan 5, 2012, at 9:29, "Randell Jesup" wrote: > "and user will know the implications " >=20 > Right. ;-) [BA] Yeah I'm not even sure that people on this list would grasp *all* the s= ecurity implications based on UI no matter how descriptive it was. > And those sorts of things and exception-mechanisms are a real problem for m= ost users, UI-wise. Users don't generally understand the issues or what the= y're agreeing to, no matter how scary we make the warnings. It helps some= , but often confuses as many users as it helps. This is reinforced every ti= me I play remote-IT-person over the phone with my stepmother. [BA] Heh. WebRTC is more complex than today's security scenarios, and if it i= s necessary to understand device permissions, SRTP vs. RTP, authenticated ve= rsus non-authenticated key mgmt, MITM opportunities, etc. how many of *us* w= ould grasp it instantly? > As for SRTP costs: >=20 > The SRTP cost for the client is low enough not to be an issue (measurable,= but within reason on any expected hardware. [BA] Agreed.= From wwwrun@ietfa.amsl.com Thu Jan 5 11:38:39 2012 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 7ADF321F888A; Thu, 5 Jan 2012 11:38:39 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120105193839.7ADF321F888A@ietfa.amsl.com> Date: Thu, 5 Jan 2012 11:38:39 -0800 (PST) Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG Interim Meeting January 31 and February 1, 2012 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: rtcweb@ietf.org 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 Jan 2012 19:38:39 -0000 The RTCWEB working group will be holding an interim meeting for a full day on January 31st and the first morning of February 1st, 2012, in Mountain View, CA at the Google campus. Further details on dial-in numbers and other facilities will be announced on the rtcweb list. The afternoon of February 1st will be a public meeting of the W3C WEBRTC working group, which members of the RTCWEB working group may also be interested to attend; it will be located at the same venue. From abu_hurayrah@hidayahonline.org Thu Jan 5 11:57:42 2012 Return-Path: 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 742D921F885D for ; Thu, 5 Jan 2012 11:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 P2ABV2kojxjc for ; Thu, 5 Jan 2012 11:57:42 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 063D321F885B for ; Thu, 5 Jan 2012 11:57:42 -0800 (PST) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id BF8B965299C for ; Thu, 5 Jan 2012 14:57:40 -0500 (EST) Message-ID: <4F0600B0.5020307@hidayahonline.org> Date: Thu, 05 Jan 2012 14:57:36 -0500 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20120105193839.7ADF321F888A@ietfa.amsl.com> In-Reply-To: <20120105193839.7ADF321F888A@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB WG Interim Meeting January 31 and February 1, 2012 X-BeenThere: rtcweb@ietf.org 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 Jan 2012 19:57:42 -0000 On 01/05/2012 02:38 PM, IESG Secretary wrote: > The RTCWEB working group will be holding an interim meeting for a > full day on January 31st and the first morning of February 1st, 2012, > in Mountain View, CA at the Google campus. > > Further details on dial-in numbers and other facilities will be announced > on the rtcweb list. > > The afternoon of February 1st will be a public meeting of the W3C > WEBRTC working group, which members of the RTCWEB working group may > also be interested to attend; it will be located at the same venue. This is my first participation on this list, but as an interested party, aside from the dial-in numbers and "other facilities", will there be any measures to record the meeting and then publish it afterward, e.g., either in audio or video format? From ted.ietf@gmail.com Thu Jan 5 12:03:10 2012 Return-Path: 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 951FE21F8779 for ; Thu, 5 Jan 2012 12:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HRMWGraJZKJK for ; Thu, 5 Jan 2012 12:03:10 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 085DD21F86E1 for ; Thu, 5 Jan 2012 12:03:09 -0800 (PST) Received: by yhjj72 with SMTP id j72so363509yhj.31 for ; Thu, 05 Jan 2012 12:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=25viWOAdIdvtdJT40/1Onk0Ew8jZVS1h9ID9xON6XgE=; b=P36AOjIVCPokVarx8xTU0Jlg57lQShkkmHtNtKneeD7k2wzH8VgA457GB6MLZ1yOSx tB+/FswnEjX8VKR8INj08Qwop9hUP+124k+yYLFG2da569nOpybRZ8EHkMd476lvUJkD LsKdHZvqOKgqR5RMUWzvVmuWXgTxw5Z0xMdEQ= MIME-Version: 1.0 Received: by 10.236.128.242 with SMTP id f78mr3920125yhi.7.1325793789673; Thu, 05 Jan 2012 12:03:09 -0800 (PST) Received: by 10.236.155.132 with HTTP; Thu, 5 Jan 2012 12:03:09 -0800 (PST) In-Reply-To: <4F0600B0.5020307@hidayahonline.org> References: <20120105193839.7ADF321F888A@ietfa.amsl.com> <4F0600B0.5020307@hidayahonline.org> Date: Thu, 5 Jan 2012 12:03:09 -0800 Message-ID: From: Ted Hardie To: Basil Mohamed Gohar Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB WG Interim Meeting January 31 and February 1, 2012 X-BeenThere: rtcweb@ietf.org 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 Jan 2012 20:03:10 -0000 Hi Basil, All IETF meetings have minutes, and we have already had two minute takers volunteer (thanks Mary and Stephan!). More are needed, but minutes will be taken and those will be published. We can probably also arrange a recording of the audio as heard by the call-in participants (we have done that for previous ad-hoc and interim meetings.), but the details will depend somewhat on whether we are using Webex or an audio bridge. Please stay tuned for those details. regards, Ted On Thu, Jan 5, 2012 at 11:57 AM, Basil Mohamed Gohar wrote: > On 01/05/2012 02:38 PM, IESG Secretary wrote: >> The RTCWEB working group will be holding an interim meeting for a >> full day on January 31st and the first morning of February 1st, 2012, >> in Mountain View, CA at the Google campus. >> >> Further details on dial-in numbers and other facilities will be announced >> on the rtcweb list. >> >> The afternoon of February 1st will be a public meeting of the W3C >> WEBRTC working group, which members of the RTCWEB working group may >> also be interested to attend; it will be located at the same venue. > This is my first participation on this list, but as an interested party, > aside from the dial-in numbers and "other facilities", will there be any > measures to record the meeting and then publish it afterward, e.g., > either in audio or video format? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From abu_hurayrah@hidayahonline.org Thu Jan 5 12:31:29 2012 Return-Path: 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 D205921F8894 for ; Thu, 5 Jan 2012 12:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 GwyYD+xSVzyg for ; Thu, 5 Jan 2012 12:31:28 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08721F888D for ; Thu, 5 Jan 2012 12:31:28 -0800 (PST) Received: from [10.10.40.98] (rrcs-98-103-138-67.central.biz.rr.com [98.103.138.67]) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 47A0B6529C6 for ; Thu, 5 Jan 2012 15:31:27 -0500 (EST) Message-ID: <4F06089B.7000301@hidayahonline.org> Date: Thu, 05 Jan 2012 15:31:23 -0500 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <20120105193839.7ADF321F888A@ietfa.amsl.com> <4F0600B0.5020307@hidayahonline.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=5AF4B362 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB WG Interim Meeting January 31 and February 1, 2012 X-BeenThere: rtcweb@ietf.org 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 Jan 2012 20:31:29 -0000 Ted, Thanks for the info. I would suggest just using something as simple as a Zoom H2n, which you can just set in the middle of the conference room. Of course, if participants will be talking via the phone system as well, then maybe piping that in would be a problem. Ensuring the best quality will also ensure the best experience for those that want to listen later, and benefit the archival process. I know these are just technical details and you have to go with whatever works best, but I strongly advocate multimedia archival of these meetings. On 01/05/2012 03:03 PM, Ted Hardie wrote: > Hi Basil, > > All IETF meetings have minutes, and we have already had two minute > takers volunteer (thanks Mary and Stephan!). More are needed, but > minutes will be taken and those will be published. We can probably > also arrange a recording of the audio as heard by the call-in > participants (we have done that for previous ad-hoc and interim > meetings.), but the details will depend somewhat on whether we are > using Webex or an audio bridge. > Please stay tuned for those details. > > regards, > > Ted > > > > On Thu, Jan 5, 2012 at 11:57 AM, Basil Mohamed Gohar > wrote: >> On 01/05/2012 02:38 PM, IESG Secretary wrote: >>> The RTCWEB working group will be holding an interim meeting for a >>> full day on January 31st and the first morning of February 1st, 2012, >>> in Mountain View, CA at the Google campus. >>> >>> Further details on dial-in numbers and other facilities will be announced >>> on the rtcweb list. >>> >>> The afternoon of February 1st will be a public meeting of the W3C >>> WEBRTC working group, which members of the RTCWEB working group may >>> also be interested to attend; it will be located at the same venue. >> This is my first participation on this list, but as an interested party, >> aside from the dial-in numbers and "other facilities", will there be any >> measures to record the meeting and then publish it afterward, e.g., >> either in audio or video format? >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Thu Jan 5 12:35:00 2012 Return-Path: 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 CAEF121F8870 for ; Thu, 5 Jan 2012 12:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_16=0.6] 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 QPZdqZEd6cm2 for ; Thu, 5 Jan 2012 12:35:00 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id D7A5421F85D0 for ; Thu, 5 Jan 2012 12:34:58 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id C83DD754A8A3; Thu, 5 Jan 2012 20:34:56 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 5 Jan 2012 08:54:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , , , <4F01A790.4060704@alvestrand.no>, <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , To: Bernard Aboba X-Mailer: Apple Mail (2.1251.1) Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 20:35:00 -0000 4 jan 2012 kl. 01:28 skrev Bernard Aboba: >=20 > Ted Hardie said:=20 >=20 > > I'm a little lost. In a gateway implemented in a back-to-back user > > agent, won't you end up with the same illusion? > >=20 > > The case I think you're talking about is this: > >=20 > > UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 > >=20 > > Do you expect that the gateway would be refuse to use SRTP on one = side > > if it intended not to use it on the other?=20 >=20 >=20 > [BA] If the SBC needed to enable communication with a legacy endpoint, = then it > might want to negotiate security compatible with that endpoint.=20 >=20 > Today there are PSTN gateways that support SRTP with SDES, but interop = is=20 > frequently an issue (I've had to debug interop issues countless = times), so=20 > I've often had to advise customers to turn SRTP off until an issue was = resolved.=20 Interoperability with SRTP has been an issue at several SIPits. But we = do see a change, we see huge improvements in the number of successful interoperability = tests. =46rom the summary of the latest SIPit: "** SRTP All implementations supported SDES for SRTP key exchange. Good interop with many different combinations of endpoints. Some calls were left up for an extended period so that sequence number = wrapping and roc increments were tested. Once the roc had changed the = call was put on hold and resumed with success. In this situation new RTP = streams with different SSRCs were created and the sequence number/roc = combination re-generated thus proving that support for multiple SRTP = contexts exists. Debate surrounding how to signal 'best-effort crypto' continues. Some = implementations choose to advertise RTP/AVP with a=3Dcrypto attributes = and then go crypto if answer also has them and non-crypto if they do = not. RTP/SAVP is used to signal the desire for mandatory crypto. Another = approach observed was to repeat the same media line twice, once for = crypto and once for non-crypto and rely on the receiving end to only = accept one of them and port reject the other. In this case both m-lines = had the same port number and payload number descriptions so if a = receiving end accepted both then the originator would have no clue as to = whether it was receiving crypto or non-crypto traffic." https://www.sipit.net/SIPit29_summary The first time I personally tested SRTP at SIpit we couldn't get any = calls through across vendor boundaries... We will have to bring Webrtc to SIPit for testing :-) /O= From bernard_aboba@hotmail.com Thu Jan 5 12:58:51 2012 Return-Path: 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 7418221F8892 for ; Thu, 5 Jan 2012 12:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.824 X-Spam-Level: X-Spam-Status: No, score=-100.824 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=1.396, 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 7h+Lzj0peTCE for ; Thu, 5 Jan 2012 12:58:46 -0800 (PST) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2D621F888F for ; Thu, 5 Jan 2012 12:58:46 -0800 (PST) Received: from BLU0-P3-EAS115 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 12:58:45 -0800 X-Originating-IP: [74.92.226.89] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Thu, 5 Jan 2012 12:59:45 -0800 To: "Olle E. Johansson" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 05 Jan 2012 20:58:45.0742 (UTC) FILETIME=[D07C28E0:01CCCBEC] Cc: "randell-ietf@jesup.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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 Jan 2012 20:58:51 -0000 Good summary of the current status and issues (e.g. ROC and signaling). And= yes, the situation is improving w/SDES, so I guess we'll have to pick somet= hing else in RTCWEB in order to keep it interesting :( On Jan 5, 2012, at 12:34, "Olle E. Johansson" wrote: >=20 > 4 jan 2012 kl. 01:28 skrev Bernard Aboba: >=20 >>=20 >> Ted Hardie said:=20 >>=20 >>> I'm a little lost. In a gateway implemented in a back-to-back user >>> agent, won't you end up with the same illusion? >>>=20 >>> The case I think you're talking about is this: >>>=20 >>> UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2 >>>=20 >>> Do you expect that the gateway would be refuse to use SRTP on one side >>> if it intended not to use it on the other?=20 >>=20 >>=20 >> [BA] If the SBC needed to enable communication with a legacy endpoint, th= en it >> might want to negotiate security compatible with that endpoint.=20 >>=20 >> Today there are PSTN gateways that support SRTP with SDES, but interop is= =20 >> frequently an issue (I've had to debug interop issues countless times), s= o=20 >> I've often had to advise customers to turn SRTP off until an issue was re= solved.=20 >=20 > Interoperability with SRTP has been an issue at several SIPits. But we do s= ee a change, > we see huge improvements in the number of successful interoperability test= s. >=20 > =46rom the summary of the latest SIPit: >=20 > "** SRTP >=20 > All implementations supported SDES for SRTP key exchange. >=20 > Good interop with many different combinations of endpoints. >=20 > Some calls were left up for an extended period so that sequence number wra= pping and roc increments were tested. Once the roc had changed the call was p= ut on hold and resumed with success. In this situation new RTP streams with d= ifferent SSRCs were created and the sequence number/roc combination re-gener= ated thus proving that support for multiple SRTP contexts exists. >=20 > Debate surrounding how to signal 'best-effort crypto' continues. Some impl= ementations choose to advertise RTP/AVP with a=3Dcrypto attributes and then g= o crypto if answer also has them and non-crypto if they do not. RTP/SAVP is u= sed to signal the desire for mandatory crypto. Another approach observed was= to repeat the same media line twice, once for crypto and once for non-crypt= o and rely on the receiving end to only accept one of them and port reject t= he other. In this case both m-lines had the same port number and payload num= ber descriptions so if a receiving end accepted both then the originator wou= ld have no clue as to whether it was receiving crypto or non-crypto traffic.= " >=20 > https://www.sipit.net/SIPit29_summary >=20 > The first time I personally tested SRTP at SIpit we couldn't get any calls= through across vendor boundaries... >=20 > We will have to bring Webrtc to SIPit for testing :-) >=20 > /O From kpfleming@digium.com Thu Jan 5 13:26:56 2012 Return-Path: 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 AEF0321F88AF for ; Thu, 5 Jan 2012 13:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 FzS1zHTyTYgi for ; Thu, 5 Jan 2012 13:26:55 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4CD21F889D for ; Thu, 5 Jan 2012 13:26:55 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Riupq-0000ga-Pv for rtcweb@ietf.org; Thu, 05 Jan 2012 15:26:54 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C6B27D8004 for ; Thu, 5 Jan 2012 15:26:54 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k5n4Os0Se4L for ; Thu, 5 Jan 2012 15:26:54 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 5374CD8002 for ; Thu, 5 Jan 2012 15:26:54 -0600 (CST) Message-ID: <4F06159D.8040700@digium.com> Date: Thu, 05 Jan 2012 15:26:53 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20120105193839.7ADF321F888A@ietfa.amsl.com> In-Reply-To: <20120105193839.7ADF321F888A@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWEB WG Interim Meeting January 31 and February 1, 2012 X-BeenThere: rtcweb@ietf.org 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 Jan 2012 21:26:56 -0000 On 01/05/2012 01:38 PM, IESG Secretary wrote: > The RTCWEB working group will be holding an interim meeting for a > full day on January 31st and the first morning of February 1st, 2012, > in Mountain View, CA at the Google campus. The 'first morning'? Does February 1st have multiple mornings in leap years? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From harald@alvestrand.no Thu Jan 5 20:06:43 2012 Return-Path: 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 EE02311E8079 for ; Thu, 5 Jan 2012 20:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 52iS1zokhRNN for ; Thu, 5 Jan 2012 20:06:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C19E111E8095 for ; Thu, 5 Jan 2012 20:06:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0B0D39E106 for ; Fri, 6 Jan 2012 05:06:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JXbiXiStjgQ for ; Fri, 6 Jan 2012 05:06:34 +0100 (CET) Received: from [192.168.12.107] (unknown [46.249.236.98]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9DB6639E082 for ; Fri, 6 Jan 2012 05:06:34 +0100 (CET) Message-ID: <4F067349.8000104@alvestrand.no> Date: Fri, 06 Jan 2012 05:06:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20120105193839.7ADF321F888A@ietfa.amsl.com> <4F06159D.8040700@digium.com> In-Reply-To: <4F06159D.8040700@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Second morning (Re: RTCWEB WG Interim Meeting January 31 and February 1, 2012) X-BeenThere: rtcweb@ietf.org 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: Fri, 06 Jan 2012 04:06:44 -0000 On 01/05/2012 10:26 PM, Kevin P. Fleming wrote: > On 01/05/2012 01:38 PM, IESG Secretary wrote: >> The RTCWEB working group will be holding an interim meeting for a >> full day on January 31st and the first morning of February 1st, 2012, >> in Mountain View, CA at the Google campus. > > The 'first morning'? Does February 1st have multiple mornings in leap > years? > It's the period between first and second breakfast. The period between second breakfast and elevenses would be the second morning. http://en.wikipedia.org/wiki/Second_breakfast http://en.wikipedia.org/wiki/Elevenses I'm impressed with the implied completeness of Ted's catering arrangements ;-) From stefan.lk.hakansson@ericsson.com Sat Jan 7 05:43:13 2012 Return-Path: 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 B25B121F854B for ; Sat, 7 Jan 2012 05:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 umxIvRRZBXlp for ; Sat, 7 Jan 2012 05:43:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33621F854A for ; Sat, 7 Jan 2012 05:43:11 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-4d-4f084bee35e6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.E2.23425.EEB480F4; Sat, 7 Jan 2012 14:43:10 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Sat, 7 Jan 2012 14:43:09 +0100 Message-ID: <4F084BED.3010001@ericsson.com> Date: Sat, 7 Jan 2012 14:43:09 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: ekr@rtfm.com, rtcweb@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Sat, 07 Jan 2012 13:43:13 -0000 Hi Ekr, reading http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1 in an effort to catch up, I noted that there is now an appendix called "A Proposed Security Architecture". It looks like a good start for this really important topic. I have a few questions though, and I will start with one: It is stated (in section A.3.2) that "API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). Combined with secure authentication of the communicating peer, this allows a user to be sure that the calling site is not accessing or modifying their conversion." I wonder if you could elaborate a bit more on this? It is a bit unclear to me. Is the idea that when requesting access to microphones and cameras there should be a way to stop the application from doing anything else than ... with the data generated? And in that case, anything else than what? Surely the application must be allowed to route it to a video element (for a self view)? And surely it must be allowed to attach it to a PeerConnection (otherwise there will be no communication happening)? (Sorry if I should know - i did not attend the Tapei meeting and perhaps this was already discussed and clarified) --Stefan From ekr@rtfm.com Sat Jan 7 06:47:54 2012 Return-Path: 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 E98B921F855E for ; Sat, 7 Jan 2012 06:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 cvmVfv-coZqe for ; Sat, 7 Jan 2012 06:47:54 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5258921F855B for ; Sat, 7 Jan 2012 06:47:54 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so1954813vbb.31 for ; Sat, 07 Jan 2012 06:47:53 -0800 (PST) Received: by 10.52.178.70 with SMTP id cw6mr4847750vdc.6.1325947672099; Sat, 07 Jan 2012 06:47:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Sat, 7 Jan 2012 06:47:11 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: <4F084BED.3010001@ericsson.com> References: <4F084BED.3010001@ericsson.com> From: Eric Rescorla Date: Sat, 7 Jan 2012 06:47:11 -0800 Message-ID: To: Stefan Hakansson LK Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Sat, 07 Jan 2012 14:47:55 -0000 On Sat, Jan 7, 2012 at 5:43 AM, Stefan Hakansson LK wrote: > Hi Ekr, > > reading > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1 > in an effort to catch up, I noted that there is now an appendix called > "A Proposed Security Architecture". It looks like a good start for this > really important topic. > > I have a few questions though, and I will start with one: > > It is stated (in section A.3.2) that > > "API Requirement: The API MUST provide a mechanism for the requesting > JS to relinquish the ability to see or modify the media (e.g., via > MediaStream.record()). Combined with secure authentication of the > communicating peer, this allows a user to be sure that the calling > site is not accessing or modifying their conversion." > > I wonder if you could elaborate a bit more on this? It is a bit unclear > to me. > > Is the idea that when requesting access to microphones and cameras there > should be a way to stop the application from doing anything else than > ... with the data generated? > > And in that case, anything else than what? Surely the application must > be allowed to route it to a video element (for a self view)? And surely > it must be allowed to attach it to a PeerConnection (otherwise there > will be no communication happening)? > > > (Sorry if I should know - i did not attend the Tapei meeting and perhaps > this was already discussed and clarified) No need to be sorry. I suspect I glossed over this in my talk anyway... There are a bunch of pieces of functionality that might allow the JS to recover/modify the data even if it's end-to-end encrypted with keys not known to the JS. For instance, it might use mediaStream.record() to save it somewhere, or send it to a canvas which it is able to modify or save. There are settings where these features might be useful, but also settings where they're undesirable. So it should be possible for a calling service to offer a "really secure mode" where they promise not to mess with your data and the user can verify that directly through the browser. Does that make sense? -Ekr From stefan.lk.hakansson@ericsson.com Sun Jan 8 09:48:48 2012 Return-Path: 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 A0B5721F854C for ; Sun, 8 Jan 2012 09:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TnL8T1xHH9OX for ; Sun, 8 Jan 2012 09:48:48 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A19E621F854B for ; Sun, 8 Jan 2012 09:48:47 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-a4-4f09d6fd12d1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 02.51.23425.DF6D90F4; Sun, 8 Jan 2012 18:48:46 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Sun, 8 Jan 2012 18:48:45 +0100 Message-ID: <4F09D6FC.7040801@ericsson.com> Date: Sun, 8 Jan 2012 18:48:44 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Eric Rescorla References: <4F084BED.3010001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Sun, 08 Jan 2012 17:48:48 -0000 On 01/07/2012 03:47 PM, Eric Rescorla wrote: > On Sat, Jan 7, 2012 at 5:43 AM, Stefan Hakansson LK > wrote: >> Hi Ekr, >> >> reading >> http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/?include_text=1 >> in an effort to catch up, I noted that there is now an appendix called >> "A Proposed Security Architecture". It looks like a good start for this >> really important topic. >> >> I have a few questions though, and I will start with one: >> >> It is stated (in section A.3.2) that >> >> "API Requirement: The API MUST provide a mechanism for the requesting >> JS to relinquish the ability to see or modify the media (e.g., via >> MediaStream.record()). Combined with secure authentication of the >> communicating peer, this allows a user to be sure that the calling >> site is not accessing or modifying their conversion." >> >> I wonder if you could elaborate a bit more on this? It is a bit unclear >> to me. >> >> Is the idea that when requesting access to microphones and cameras there >> should be a way to stop the application from doing anything else than >> ... with the data generated? >> >> And in that case, anything else than what? Surely the application must >> be allowed to route it to a video element (for a self view)? And surely >> it must be allowed to attach it to a PeerConnection (otherwise there >> will be no communication happening)? >> >> >> (Sorry if I should know - i did not attend the Tapei meeting and perhaps >> this was already discussed and clarified) > > No need to be sorry. I suspect I glossed over this in my talk anyway... > > There are a bunch of pieces of functionality that might allow the JS > to recover/modify the data even if it's end-to-end encrypted with > keys not known to the JS. For instance, it might use mediaStream.record() > to save it somewhere, or send it to a canvas which it is able to > modify or save. There are settings where these features might > be useful, but also settings where they're undesirable. So it > should be possible for a calling service to offer a "really secure mode" > where they promise not to mess with your data and the user > can verify that directly through the browser. > > Does that make sense? I started to think in terms of APIs, and of course with the current set of proposed APIs as starting point. The MediaStream would have to go (as it can be copied, recorded, attached to another PeerConnection or to a canvas etc), so I started to think about a special version of PeerConnection which would use mic/cam input directly. So you would as app developer setup a special PeerConnection and in addition tell it what audio/video elements to use for local (self) view and remote view. But that still would not be enough since the app can access the media data via the Media elements, look at http://www.w3.org/TR/webaudio/#MediaElementAudioSourceNode-section for example. So we are looking for a new API that allows the application to basically ask for secure audio and/or video communication, and to have some saying about the rendering (e.g. location and size of video windows), but not much more. The rest is handled under the hood. It is also important that the other end can not emulate a "really secure endpoint" by use of PeerConnection - because then the app at the other end would have access to all data. As you indicate it would not be sufficient to have an API, because then the app could anyway use the more flexible APIs (getUserMedia, MediaStream, PeerConnection, audio/video elements) without the user knowing. There would also need to be some info (in the browser chrome, and when asking for user consent?) that the "secure communication", and no other tools, is used. This might be a challenge, how should you present this? It must be easy to distinguish from the mic/cam being used with getUserMedia. Then there are assembled cases; say you want to a push-to-talk service using this secure API, but (when pushing another button) do some voice based input (http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#solution). In this case both the "secure communication" and the voice based input would both need access to the mic, how do you present this to the user in an understandable way (both when asking for consent, and in the chrome during use)? Perhaps we should focus at the more flexible APIs in the first phase? Stefan > > -Ekr From prvs=347b7590c=tterriberry@mozilla.com Sun Jan 8 10:25:39 2012 Return-Path: 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 34DE021F856E for ; Sun, 8 Jan 2012 10:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 AQ6lArnSrKmg for ; Sun, 8 Jan 2012 10:25:38 -0800 (PST) Received: from mxip1i.isis.unc.edu (mxip1i.isis.unc.edu [152.2.0.74]) by ietfa.amsl.com (Postfix) with ESMTP id D5D8A21F8472 for ; Sun, 8 Jan 2012 10:25:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcNAIfeCU+sGgRS/2dsb2JhbABDnA2PSIF1gXIBAQQBOEABBQsLEg8WDwkDAgECATcOEwEHAod2tQuMEQSIOZIOE40J X-IronPort-AV: E=Sophos;i="4.71,475,1320642000"; d="scan'208";a="307475585" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip1o.isis.unc.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jan 2012 13:25:32 -0500 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 71.114.12.189 Received: from [192.168.11.4] (pool-71-114-12-189.washdc.dsl-w.verizon.net [71.114.12.189]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id q08IPTtv020141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 8 Jan 2012 13:25:31 -0500 (EST) Message-ID: <4F09DF99.5070907@mozilla.com> Date: Sun, 08 Jan 2012 10:25:29 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> In-Reply-To: <4F09D6FC.7040801@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Sun, 08 Jan 2012 18:25:39 -0000 > So we are looking for a new API that allows the application to basically > ask for secure audio and/or video communication, and to have some saying > about the rendering (e.g. location and size of video windows), but not > much more. The rest is handled under the hood. It is also important that I think the expectation is that this would use the same "tainting" mechanism used by to prevent access to the raw media from cross-domain resources. So you could use the normal getUserMedia, etc., APIs, but if you tried to use an API that accesses the raw sample data (as opposed to just piping the data into an HTMLMediaElement or a PeerConnection), it would throw a security exception. From stefan.lk.hakansson@ericsson.com Mon Jan 9 05:03:41 2012 Return-Path: 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 13E9321F873E for ; Mon, 9 Jan 2012 05:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 HjT35YiUzGRL for ; Mon, 9 Jan 2012 05:03:40 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0431C21F8747 for ; Mon, 9 Jan 2012 05:03:39 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-e6-4f0ae5aad4fc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.3C.09514.AA5EA0F4; Mon, 9 Jan 2012 14:03:39 +0100 (CET) Received: from [150.132.141.86] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 9 Jan 2012 14:03:38 +0100 Message-ID: <4F0AE5A9.7040307@ericsson.com> Date: Mon, 9 Jan 2012 14:03:37 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> In-Reply-To: <4F09DF99.5070907@mozilla.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Mon, 09 Jan 2012 13:03:41 -0000 On 01/08/2012 07:25 PM, Timothy B. Terriberry wrote: >> So we are looking for a new API that allows the application to basically >> ask for secure audio and/or video communication, and to have some saying >> about the rendering (e.g. location and size of video windows), but not >> much more. The rest is handled under the hood. It is also important that > > I think the expectation is that this would use the same "tainting" > mechanism used by to prevent access to the raw media from > cross-domain resources. So you could use the normal getUserMedia, etc., > APIs, but if you tried to use an API that accesses the raw sample data > (as opposed to just piping the data into an HTMLMediaElement or a > PeerConnection), it would throw a security exception. Sounds like a more elegant solution! Basically (to check that I understand correctly) * getUserMedia would be used to ask for a "protected MediaStream" * the user can easily understand (browser chrome?) that data generated by mic/cam is protected * in the browser generating, it would be allowed to use in audio/video elements and in _one_ PeerConnection (and that PeerConnection _must_ use SRTP) * in the browser receiving it would be allowed to use in audio/video elements only Any use trying to access the data (including using the audio element as source) would throw security exceptions. I guess there are still a few things to sort out, like how to convey this info about the MediaStream to the other end. Stefan > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Jan 9 06:46:24 2012 Return-Path: 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 D9F1321F87A3 for ; Mon, 9 Jan 2012 06:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 qGLeeIMI-M+v for ; Mon, 9 Jan 2012 06:46:20 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 693DC21F85A1 for ; Mon, 9 Jan 2012 06:46:20 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q09El11D012711; Mon, 9 Jan 2012 09:47:01 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 09:46:17 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 20:17:08 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Mon, 9 Jan 2012 20:17:08 +0530 From: "Ravindran, Parthasarathi" To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAEEoCAACFIAIAAA4cAgAAemYCAABaMgIAAcFRAgABk3YCABfK9sA== Date: Mon, 9 Jan 2012 14:47:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC5A0A@inba-mail01.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01DC3C8A@inba-mail01.sonusnet.com> <4F05DDD9.3090305@jesup.org> In-Reply-To: <4F05DDD9.3090305@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jan 2012 14:47:08.0916 (UTC) FILETIME=[90318340:01CCCEDD] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Mon, 09 Jan 2012 14:46:25 -0000 Randell, IIUC, the flexibility vs manageability of the browser is the point of the d= iscussion. Providing SRTP and RTP provides the flexibility for some deploym= ent but it is possible that novice user may be mislead by those configurati= on. ISTM, the question is whether advanced users should not be provided wit= h the browser option as some of the user may get confused and leads to secu= rity issues. IMO, SRTP vs RTP has to be combination of user and website (Ja= vaScript) choice rather than browser choice. I would be interested in hear= ing more opinion from others before we decide "SRTP mandatory-to-use" in We= bRTC. Please read inline. Thanks=20 Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Thursday, January 05, 2012 10:59 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] SRTP not mandatory-to-use > >On 1/5/2012 2:17 AM, Ravindran, Parthasarathi wrote: >> Randell, >> >> I agree that SRTP has to be mandated-to-implement for the reasons >which you have mentioned and also agree that SRTP fallback should not be >accepted by default to avoid bid-down attack. >> >> The only possible solution for RTP media in WebRTC is to provide the >user configuration in the browser (WebRTC client) to allow the trust >website to create RTP media based session. In this model, (browser) user >provides the consent to pass RTP media and user will know the >implications. In case untrusted website asks for RTP session through >JavaScript, those request will be declined. Hope it is inline with >trusted model as user is responsible for RTP session and not JavaScript >or web-server. >> >> RTP mechanism shall be used in the trusted site& network like >intranet, Enterprise application. The need of RTP session is to reduce >WebRTC-GW cost in performing SRTP-RTP. > >"and user will know the implications " > >Right. ;-) > >> I understand that it adds up complication in browser implementation as >browser has to consider both SRTP& RTP based on the configuration. It >is more like pop-up is blocked in browser by default in the browser >except for personal banking website based on user configuration. > > >And those sorts of things and exception-mechanisms are a real problem >for most users, UI-wise. Users don't generally understand the issues or >what they're agreeing to, no matter how scary we make the warnings. >It helps some, but often confuses as many users as it helps. This is >reinforced every time I play remote-IT-person over the phone with my >stepmother. > > I'm with you that some of the user will not know the security impl= ications while adding the site for allowing RTP when website instructs to a= dd its site even though browser provides the security warning. "Ok" button = will be clicked without any reading :-) My point is that it is possible to = misguide those users by Dr.Evil website even though SRTP is used. Say, thos= e users allow RTP plugin in the browser or the user will not check whether = validity of webrtc identity. >As for SRTP costs: > >The SRTP cost for the client is low enough not to be an issue >(measurable, but within reason on any expected hardware). > Agreed >The SRTP cost on a server hosting a large number of connections (and >mostly just routing them) may be significant to a service provider -- >for example, games where 'broadcast' announcements to large numbers of >connected users have to be encrypted for each connection, or a hangout- >like conference where streams are sent to a central location and resent >to a large number of other members (especially in the without-mixing >case). > >In these cases, the server has to encode and/or decode a medium to large >number of streams, but isn't doing heavy processing of the decoded >media, so SRTP cost is a much larger factor. > >Similar aspects apply to WebRTC gateways, at least run on commodity >hardware - media data isn't being processed, just streams forwarded with >decryption/encryption (and ICE, which should be in the noise). > >So, an argument can be made (from a performance of the server/gateway >point-of-view) that there's some justification for plain RTP, at least >in a few use cases. However, even in those there are often privacy >issues - for example, in a Hangout-like app allowing video to be passed >around without encryption is a privacy risk in general, and users aren't >well set up to evaluate the risks (and even more importantly, the >difference in risk in different situations). > The argument here is that WebRTC allows only SRTP by default until= otherwise users configures to allow RTP for the specific URL (website) and= JavaScript API of the same website request for RTP. I agree with you that = user or JavaScript *MUST NOT* use RTP for Hangout-like app. It does not mea= n that all WebRTC application MUST use SRTP. Some of the application based = on the network deployment may use RTP. > >So, even though there are cost optimizations to pure RTP for servers, >they don't (to me) justify allowing plain RTP in webrtc in general.=20 It is debatable. Let us see others opinion here. =20 The >added risk to the user of snooping (which is hard to explain to the >user) is significant; and what is the payoff? Mostly it's slightly >reduced gateway/server costs (since I don't think we can eliminate a >webrtc->legacy gateway due to the consent requirement). If we could >eliminate that, then you'd also get a bonus of lower delay in interop >(or much lower in some cases). Since I don't see that happening, the >benefits are relatively low and the risk to users (and possible UI >confusion) is higher. > > > >> >> My point is that WebRTC client should be flexible for different >deployment rather than considering every URL is untrusted. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Randell Jesup >>> Sent: Thursday, January 05, 2012 10:16 AM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] SRTP not mandatory-to-use >>> >>> On 1/4/2012 10:25 PM, Roman Shpount wrote: >>>> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba >>>> > >wrote: >>>> >>>> [BA] An alternative is to force an initial offer preferring >>>> RTP/SAVP(F). >>>> That way, if both endpoints support SRTP and the offered key >>> management >>>> scheme, it is guaranteed to be negotiated. Only if the >preferred >>>> option is >>>> not mutually supported could an alternative be selected. >>>> >>>> >>>> I would actually prefer a situation where a deliberate decision by >>>> application developer is required to allow RTP. By default, SRTP >>>> only connection should be accepted with no option to bid down (ie >>>> offer with >>>> RTP/SAVP(F) only and no null codec). If developer specifies that >>>> non-secure connections are allowed, only then RTP/AVP should be >>>> present in the offer or accepted in the answer (with crypto >>>> attributes or some other way to specify that AVPS is also >>>> supported). This way there no "accidental" RTP connections. >>> As Eric R. would probably tell you, you not only have to worry about >>> bid-down attacks (and they're important), but also the "threat model" >>> for rtcweb is that we don't trust: >>> a) the JS application >>> b) the service provider/website >>> to maintain security and privacy for our conversation. The JS >>> application may be malicious or may have been subverted without >>> knowledge of the provider, or the provider may have been compromised >>> (by an attacker or by legal force) even if they're not actively evil. >>> >>> If you mandate SRTP (and use DTLS-SRTP), then the application and the >>> website never have access to the keys, and you have end-to-end >>> security (modulo gateways). If you combine that with the identity >>> mechanisms >> >from ekr's draft/presentation at Taipei, and you have verified, no >> >MITM, >>> end-to-end encryption. (Without identity info, we have no way to >>> detect a MITM attack, especially if brokered by the service >>> provider.) Side >>> note: SDES generally has the same problem; the JS app and service >>> provider/website have access to the keys. (With some pain we might >>> be able to encrypt the SDES keys themselves, but I'm not sure that's >>> practical.) >>> >>> The "interop with legacy needs no SRTP or optional SRTP" argument >>> fails if we have to go through a gateway to get to legacy equipment >anyways. >>> And though I've tried hard to find a practical way around it, the >>> 'consent' requirements handled by using ICE/etc end up requiring us >>> to use a gateway. If you're using a gateway to talk to legacy devices >>> and/or PSTN gateways, you can include SRTP in the gateway for the >>> webrtc side. >>> >>> >>> -- >>> Randell Jesup >>> randell-ietf@jesup.org >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > >-- >Randell Jesup >randell-ietf@jesup.org > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Jan 9 07:47:04 2012 Return-Path: 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 C334B21F8838 for ; Mon, 9 Jan 2012 07:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] 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 KZPaanaboSAg for ; Mon, 9 Jan 2012 07:47:00 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A062D21F8832 for ; Mon, 9 Jan 2012 07:47:00 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RkHR5-0002Hu-8x for rtcweb@ietf.org; Mon, 09 Jan 2012 09:46:59 -0600 Message-ID: <4F0B0BD3.4070109@jesup.org> Date: Mon, 09 Jan 2012 10:46:27 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> In-Reply-To: <4F0AE5A9.7040307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Mon, 09 Jan 2012 15:47:04 -0000 On 1/9/2012 8:03 AM, Stefan Hakansson LK wrote: > On 01/08/2012 07:25 PM, Timothy B. Terriberry wrote: >>> So we are looking for a new API that allows the application to basically >>> ask for secure audio and/or video communication, and to have some saying >>> about the rendering (e.g. location and size of video windows), but not >>> much more. The rest is handled under the hood. It is also important that >> >> I think the expectation is that this would use the same "tainting" >> mechanism used by to prevent access to the raw media from >> cross-domain resources. So you could use the normal getUserMedia, etc., >> APIs, but if you tried to use an API that accesses the raw sample data >> (as opposed to just piping the data into an HTMLMediaElement or a >> PeerConnection), it would throw a security exception. Correct - I can't find the reference (perhaps it was a comment made at last July's IETF), but I believe Tim is referring to a suggestion made about tainting. This was discussed in a slightly different context around 8/17/2011 - for example, a message from Rich Tibbett included this: This section of the WHATWG spec summarizes the concept of tainting an object via the origin-clean flag, applied to elements with content coming from a different origin: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#security-with-canvas-elements > Sounds like a more elegant solution! Basically (to check that I > understand correctly) > > * getUserMedia would be used to ask for a "protected MediaStream" > * the user can easily understand (browser chrome?) that data generated > by mic/cam is protected > * in the browser generating, it would be allowed to use in audio/video > elements and in _one_ PeerConnection (and that PeerConnection _must_ use > SRTP) > * in the browser receiving it would be allowed to use in audio/video > elements only > > Any use trying to access the data (including using the audio element as > source) would throw security exceptions. I suggest starting by going back in the archives to that period; there was considerable discussion of the issue. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Tue Jan 10 00:22:26 2012 Return-Path: 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 4124921F85A8 for ; Tue, 10 Jan 2012 00:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Rvnltn026bSK for ; Tue, 10 Jan 2012 00:22:25 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA0721F850B for ; Tue, 10 Jan 2012 00:22:18 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-7e-4f0bf538e4ca Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0C.41.09514.835FB0F4; Tue, 10 Jan 2012 09:22:16 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 Jan 2012 09:22:14 +0100 Message-ID: <4F0BF535.7010600@ericsson.com> Date: Tue, 10 Jan 2012 09:22:13 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> In-Reply-To: <4F0B0BD3.4070109@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 08:22:26 -0000 On 01/09/2012 04:46 PM, Randell Jesup wrote: .... >> * getUserMedia would be used to ask for a "protected MediaStream" >> * the user can easily understand (browser chrome?) that data generated >> by mic/cam is protected >> * in the browser generating, it would be allowed to use in audio/video >> elements and in _one_ PeerConnection (and that PeerConnection _must_ use >> SRTP) >> * in the browser receiving it would be allowed to use in audio/video >> elements only >> >> Any use trying to access the data (including using the audio element as >> source) would throw security exceptions. > > I suggest starting by going back in the archives to that period; there > was considerable discussion of the issue. Thanks for the tip, funny how things fade away from memory.... I did read up, but it seems that discussion did not really end up at a conclusion. And it was mostly discussed for the local context, never how to ensure that the data of a stream on the other end of a PeerConnection can not be accessed. > From ted.ietf@gmail.com Tue Jan 10 08:25:05 2012 Return-Path: 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 9C04A21F85E0 for ; Tue, 10 Jan 2012 08:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 cudH8aUQitLN for ; Tue, 10 Jan 2012 08:25:05 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B26EF21F8705 for ; Tue, 10 Jan 2012 08:24:58 -0800 (PST) Received: by ghbg18 with SMTP id g18so2530438ghb.31 for ; Tue, 10 Jan 2012 08:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=58tcu0ERb0U4DtaG9QRfdZ+2NEWINyFLJS4LAvgIaw0=; b=JJQ4jsDKbwQROxJ1iF4mqiYJasKjTPzPzY1teR+nQRS+V5cNbcrqQuhpoa07HClWgU Rqg5LStWFbnwG5uUzSELKzkVo690ujxgoOf8O/zJKubMFAvY+zVZ5DVKqHLCi22ZyDPU gBZrRYuOAvo6SPwodrce/h4clAgWp8RUuZXOo= MIME-Version: 1.0 Received: by 10.101.4.39 with SMTP id g39mr8779886ani.47.1326212698357; Tue, 10 Jan 2012 08:24:58 -0800 (PST) Received: by 10.236.116.165 with HTTP; Tue, 10 Jan 2012 08:24:58 -0800 (PST) Date: Tue, 10 Jan 2012 08:24:58 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Are you coming to the interim? X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 16:25:05 -0000 If you have not already told me that you are coming to the interim, I would appreciate you dropping me a quick note saying that you are, so that I can make sure that there is enough food etc. This is just a count, not a formal registration, so don't feel bad if you have to later change your mind; I'd rather have more food than less. Ted From bernard_aboba@hotmail.com Tue Jan 10 10:14:06 2012 Return-Path: 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 E180B21F86A5 for ; Tue, 10 Jan 2012 10:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 0vMjrkClDitY for ; Tue, 10 Jan 2012 10:14:06 -0800 (PST) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5192F21F861F for ; Tue, 10 Jan 2012 10:14:06 -0800 (PST) Received: from BLU152-W64 ([65.55.116.74]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:14:05 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f4ddce61-30a1-4869-a034-52517254c8b4_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: , Date: Tue, 10 Jan 2012 10:14:05 -0800 Importance: Normal In-Reply-To: <4F0BF535.7010600@ericsson.com> References: <4F084BED.3010001@ericsson.com>, , <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com>,<4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org>,<4F0BF535.7010600@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:14:05.0947 (UTC) FILETIME=[A3BBD4B0:01CCCFC3] Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 18:14:07 -0000 --_f4ddce61-30a1-4869-a034-52517254c8b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I did read up=2C but it seems that discussion did not really end up at a= =20 > conclusion. And it was mostly discussed for the local context=2C never ho= w=20 > to ensure that the data of a stream on the other end of a PeerConnection= =20 > can not be accessed. [BA] It seems to me that media security should not necessarily imply the ab= sence of recording capabilities.=20 There are scenarios (e.g. web conferences) where the presentations are rout= inely recorded today=2C and there are products that support both media secu= rity and recording.=20 For example=2C SIPREC does not assume that recording is forbidden if SRTP i= s used.=20 =20 = --_f4ddce61-30a1-4869-a034-52517254c8b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B I did read up=2C but it seems that discussion did not reall= y end up at a
>=3B conclusion. And it was mostly discussed for the lo= cal context=2C never how
>=3B to ensure that the data of a stream on = the other end of a PeerConnection
>=3B can not be accessed.

[B= A] It seems to me that media security should not necessarily imply the abse= nce of recording capabilities.

There are scenarios (e.g. web confer= ences) where the presentations are routinely recorded today=2C and there ar= e products that support both media security and recording.

For exam= ple=2C SIPREC does not assume that recording is forbidden if SRTP is used. =

 =3B
= --_f4ddce61-30a1-4869-a034-52517254c8b4_-- From ekr@rtfm.com Tue Jan 10 10:17:48 2012 Return-Path: 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 57CF221F87FC for ; Tue, 10 Jan 2012 10:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Q7RxhZYZ4uHD for ; Tue, 10 Jan 2012 10:17:47 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACADE21F87CF for ; Tue, 10 Jan 2012 10:17:47 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so4050773vbb.31 for ; Tue, 10 Jan 2012 10:17:43 -0800 (PST) Received: by 10.52.29.75 with SMTP id i11mr9916556vdh.23.1326219463098; Tue, 10 Jan 2012 10:17:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Tue, 10 Jan 2012 10:17:02 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> <4F0BF535.7010600@ericsson.com> From: Eric Rescorla Date: Tue, 10 Jan 2012 10:17:02 -0800 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 18:17:48 -0000 On Tue, Jan 10, 2012 at 10:14 AM, Bernard Aboba wrote: > >> I did read up, but it seems that discussion did not really end up at a >> conclusion. And it was mostly discussed for the local context, never how >> to ensure that the data of a stream on the other end of a PeerConnection >> can not be accessed. > > [BA] It seems to me that media security should not necessarily imply the > absence of recording capabilities. > > There are scenarios (e.g. web conferences) where the presentations are > routinely recorded today, and there are products that support both media > security and recording. > > For example, SIPREC does not assume that recording is forbidden if SRTP is > used. Yes, I agree with this. The requirement I am trying to get at is that the site needs to be able to relinquish the ability to record and the user needs to be able to know when that has happened. -Ekr From spencer@wonderhamster.org Tue Jan 10 13:24:48 2012 Return-Path: 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 CEEF121F85A1 for ; Tue, 10 Jan 2012 13:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 yYUejXaSdAAt for ; Tue, 10 Jan 2012 13:24:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 50BAF21F8598 for ; Tue, 10 Jan 2012 13:24:48 -0800 (PST) Received: from [10.0.0.232] (user.216.126.222.zhong-ren.net [222.126.216.9]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MC4Ay-1RtUcr2LOC-009Ge4; Tue, 10 Jan 2012 16:24:46 -0500 Message-ID: <4F0CAC8C.8010203@wonderhamster.org> Date: Tue, 10 Jan 2012 15:24:28 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alan Johnston References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ylt7ToIlqDaxNt3fhFaduQuNmlgZJjeLNJRTkpjoNtU K7iph6/ZP3u2IDbAw4wGGcWPSrZ6iGVB3FdcvPVmVeVqaBjaFB OrRKXRipOoh5gcH87ENQy0cZKfLvUeEXBaxjhbpCTiFAdFHKax CVO2LD+TlzO60dXgskTcRf8CC0l5iuoBCKuztAkA4HiL9auyuV gMLKHRHP4KDIHvSgsSJK5F/NtmbGJKObLH/IW3bqHE7v+EzT3x VOyQxdVP0cEQKqg3OmeY3NP2sdgE8bnV+a06L5hrcPFuNCpJ3h s5IM6+62i1aSe2/tb/uR1kpcMS7RqLjTBTH/YSHaNtdtnnlZ/q sE1wG4PMAiSVkk2VRo5I3AON66j1uTlJxN0QtIha4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 21:24:48 -0000 On 1/5/2012 11:08 AM, Alan Johnston wrote: > On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings wrote: >> >> On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: >> >>> >>> This argument about debugging keeps coming up, and although I am not persuaded by this argument, it is not a completely unreasonable request. However, I don't think this needs to be controllable from JS. One could easily imagine a plain-RTP option being available from a developer options dialog or console, for use by developers in debugging specific problems with their service. >>> _______________________________________________ >> >> I think the best solution for the debugging issue is to allow SRTP to negotiate a NULL cipher in special cases such as Justin described above. This keeps what you are debugging as close as possible to the version when debugging is turned off. I like Justin's idea of having to enable this in the browser and not having it under JS control. >> >> Cullen (in my individual contributor role) > > > This seems like the right way to do this. > > - Alan - And to me. So, just to ask the next question ... if we require the use of SRTP and allow NULL ciphers (for debugging and whatnot), are there any remaining problems with requiring the use of SRTP? Thanks, Spencer From randell-ietf@jesup.org Tue Jan 10 13:50:21 2012 Return-Path: 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 3523D21F8607 for ; Tue, 10 Jan 2012 13:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] 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 SVmAwQeOYHvB for ; Tue, 10 Jan 2012 13:50:20 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A9E7D21F85BE for ; Tue, 10 Jan 2012 13:50:20 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RkjaF-0002ka-Sl for rtcweb@ietf.org; Tue, 10 Jan 2012 15:50:20 -0600 Message-ID: <4F0CB27B.1060008@jesup.org> Date: Tue, 10 Jan 2012 16:49:47 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> <4F0BF535.7010600@ericsson.com> In-Reply-To: <4F0BF535.7010600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Tue, 10 Jan 2012 21:50:21 -0000 On 1/10/2012 3:22 AM, Stefan Hakansson LK wrote: > On 01/09/2012 04:46 PM, Randell Jesup wrote: > .... >>> Any use trying to access the data (including using the audio element as >>> source) would throw security exceptions. >> >> I suggest starting by going back in the archives to that period; there >> was considerable discussion of the issue. > Thanks for the tip, funny how things fade away from memory.... > > I did read up, but it seems that discussion did not really end up at a > conclusion. And it was mostly discussed for the local context, never how > to ensure that the data of a stream on the other end of a PeerConnection > can not be accessed. I was talking to roc (Robert O'Callahan) last night, and he believes using cross-origin-type controls can be used to basically block the JS from getting access to the decrypted/decoded media streams. (This already exists for blocking JS access to cross-origin images.) So, no need to use tainting per-se. There certainly remains the issue of when and how the JS would get access to the streams, and without it they wouldn't be able to use some of the audio "processed streams" stuff we're working on. And if the user has to give permission for access, does this permission stick? (This is overall related to the whole "does this app/website have permission to access the camera & mic" issue.) A strawman proposal might be a "secure connection" checkbox on the getUserMedia() popup which defaults to secure. That may not be an optimum UI, however. -- Randell Jesup randell-ietf@jesup.org From pravindran@sonusnet.com Tue Jan 10 17:52:43 2012 Return-Path: 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 1E2D911E80C2 for ; Tue, 10 Jan 2012 17:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 JhhIl6HLTOyc for ; Tue, 10 Jan 2012 17:52:42 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6643C11E80BD for ; Tue, 10 Jan 2012 17:52:42 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0B1rKEw023816; Tue, 10 Jan 2012 20:53:20 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 20:52:36 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 07:23:29 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Wed, 11 Jan 2012 07:23:29 +0530 From: "Ravindran, Parthasarathi" To: Spencer Dawkins , Alan Johnston , Bernard Aboba , Cullen Jennings Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//A= Date: Wed, 11 Jan 2012 01:53:28 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DCE799@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> In-Reply-To: <4F0CAC8C.8010203@wonderhamster.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 01:53:29.0560 (UTC) FILETIME=[D0ED6580:01CCD003] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 01:52:43 -0000 Hi all, In case the proposal is to use browser configuration for debugging, it is a= lso possible to allow the configuration for sending RTP with user consent f= or a specific URL (website) and debugging shall use the same infrastructure= . I have indicated in the another mail thread that=20 1) SRTP session is the default in WebRTC (default API value & No configurat= ion) 2) SRTP session is created if JavaScript (JS) API requested for RTP and no = configuration in browser for a specific URL 3) SRTP session is created if configuration in browser allows for a URL but= JS API does not. 4) RTP session is created if configuration in browser allows for a URL and = JS API request for RTP session. The above proposal is inline with current security trust model wherein webs= erver is not trusted and user consent is assured for RTP session. This conf= iguration falls under the same category of configuration exception for plug= -in, pop-up blocker, JavaScript execution, cookies. This proposal provides = flexibility in some of the deployment wherein double encryption shall be av= oided or security is assured by non-WebRTC mechanism. The more details are = provided in http://www.ietf.org/mail-archive/web/rtcweb/current/msg03108.ht= ml. The point to be noted is that security key management mechanism is not part= of the proposal. Let us discuss it separately whether single key managemen= t is sufficient (SRTP-DTLS) or multiple key management like ZRTP, SRTP-SDES= , SRTP-DTLS is required for WebRTC.=20 Please let me know your opinion on this. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Spencer Dawkins >Sent: Wednesday, January 11, 2012 2:54 AM >To: Alan Johnston >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] SRTP not mandatory-to-use > >On 1/5/2012 11:08 AM, Alan Johnston wrote: >> On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings >wrote: >>> >>> On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: >>> >>>> >>>> This argument about debugging keeps coming up, and although I am not >persuaded by this argument, it is not a completely unreasonable request. >However, I don't think this needs to be controllable from JS. One could >easily imagine a plain-RTP option being available from a developer >options dialog or console, for use by developers in debugging specific >problems with their service. >>>> _______________________________________________ >>> >>> I think the best solution for the debugging issue is to allow SRTP to >negotiate a NULL cipher in special cases such as Justin described above. >This keeps what you are debugging as close as possible to the version >when debugging is turned off. I like Justin's idea of having to enable >this in the browser and not having it under JS control. >>> >>> Cullen (in my individual contributor role) >> >> >> This seems like the right way to do this. >> >> - Alan - > >And to me. > >So, just to ask the next question ... if we require the use of SRTP and >allow NULL ciphers (for debugging and whatnot), are there any remaining >problems with requiring the use of SRTP? > >Thanks, > >Spencer >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Tue Jan 10 23:22:32 2012 Return-Path: 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 030FB21F8847 for ; Tue, 10 Jan 2012 23:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 EYiPbB2zRyA8 for ; Tue, 10 Jan 2012 23:22:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1DB21F87FE for ; Tue, 10 Jan 2012 23:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4490; q=dns/txt; s=iport; t=1326266551; x=1327476151; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IWwL8tcd4LtwYJ40BdR2E/bbdqWyC0Q+HENIbRfd5cg=; b=W9oIDTJ3U079Q9+flJL8IAWoAQ9ls/i5m4zGSrJPE/YPKp84a5JAq9Vr Rc8RXQIZ661RnBbXUefPomCgJNd18XDxLK20qI/ImotDcOEcjkEYeZSwG XvAN0kGebNyVCfJ2ULsFuRgopWYdJC09yS57J09Ut7JFD3UQjgGqFR2eV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE44DU+rRDoH/2dsb2JhbABCrFyBBYFyAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgCBAEKCAgBEgeHYJhNAZ4YizpjBIg4l0yHSg X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; d="scan'208";a="24817086" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Jan 2012 07:22:31 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0B7LrxD019545; Wed, 11 Jan 2012 07:22:30 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:52:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 12:52:15 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DCE799@inba-mail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIA== References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org><4F035DD5.3050305@jesup.org><4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com><4F0CAC8C.8010203@wonderhamster.org> <387F9047F55E8C42850AD6B3A7A03C 6C01DCE7 99@inba-mail02.sonusnet.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Ravindran, Parthasarathi" , "Spencer Dawkins" , "Alan Johnston" , "Bernard Aboba" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 11 Jan 2012 07:22:18.0411 (UTC) FILETIME=[C03D27B0:01CCD031] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 07:22:32 -0000 Partha, |it is also possible to allow the configuration for sending=20 |RTP with user consent for a specific URL (website) The problem with it is that the need to do SRTP not only depends on what you are accessing but also how and from where you are accessing it. Even if you are accessing a trusted website, you many still want to do SRTP if you are accessing it from a public hotspot or Internet cafe. I think it is a tradeoff b/w simplifying WebRTC user experience vs the cost of connecting users to endpoints that don't do SRTP. My vote is for the for former. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran, Parthasarathi |Sent: Wednesday, January 11, 2012 7:23 AM |To: Spencer Dawkins; Alan Johnston; Bernard Aboba; Cullen Jennings (fluffy) |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] SRTP not mandatory-to-use | |Hi all, | |In case the proposal is to use browser configuration for debugging, it is also possible to allow the |configuration for sending RTP with user consent for a specific URL (website) and debugging shall use |the same infrastructure. I have indicated in the another mail thread that | |1) SRTP session is the default in WebRTC (default API value & No configuration) |2) SRTP session is created if JavaScript (JS) API requested for RTP and no configuration in browser |for a specific URL |3) SRTP session is created if configuration in browser allows for a URL but JS API does not. |4) RTP session is created if configuration in browser allows for a URL and JS API request for RTP |session. | |The above proposal is inline with current security trust model wherein webserver is not trusted and |user consent is assured for RTP session. This configuration falls under the same category of |configuration exception for plug-in, pop-up blocker, JavaScript execution, cookies. This proposal |provides flexibility in some of the deployment wherein double encryption shall be avoided or security |is assured by non-WebRTC mechanism. The more details are provided in http://www.ietf.org/mail- |archive/web/rtcweb/current/msg03108.html. | |The point to be noted is that security key management mechanism is not part of the proposal. Let us |discuss it separately whether single key management is sufficient (SRTP-DTLS) or multiple key |management like ZRTP, SRTP-SDES, SRTP-DTLS is required for WebRTC. | |Please let me know your opinion on this. | |Thanks |Partha | |>-----Original Message----- |>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf |>Of Spencer Dawkins |>Sent: Wednesday, January 11, 2012 2:54 AM |>To: Alan Johnston |>Cc: rtcweb@ietf.org |>Subject: Re: [rtcweb] SRTP not mandatory-to-use |> |>On 1/5/2012 11:08 AM, Alan Johnston wrote: |>> On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings |>wrote: |>>> |>>> On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: |>>> |>>>> |>>>> This argument about debugging keeps coming up, and although I am not |>persuaded by this argument, it is not a completely unreasonable request. |>However, I don't think this needs to be controllable from JS. One could |>easily imagine a plain-RTP option being available from a developer |>options dialog or console, for use by developers in debugging specific |>problems with their service. |>>>> _______________________________________________ |>>> |>>> I think the best solution for the debugging issue is to allow SRTP to |>negotiate a NULL cipher in special cases such as Justin described above. |>This keeps what you are debugging as close as possible to the version |>when debugging is turned off. I like Justin's idea of having to enable |>this in the browser and not having it under JS control. |>>> |>>> Cullen (in my individual contributor role) |>> |>> |>> This seems like the right way to do this. |>> |>> - Alan - |> |>And to me. |> |>So, just to ask the next question ... if we require the use of SRTP and |>allow NULL ciphers (for debugging and whatnot), are there any remaining |>problems with requiring the use of SRTP? |> |>Thanks, |> |>Spencer |>_______________________________________________ |>rtcweb mailing list |>rtcweb@ietf.org |>https://www.ietf.org/mailman/listinfo/rtcweb |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Wed Jan 11 00:39:11 2012 Return-Path: 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 33E3F21F86E4 for ; Wed, 11 Jan 2012 00:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ycu9dcSdu-nX for ; Wed, 11 Jan 2012 00:39:10 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 448AB21F86E1 for ; Wed, 11 Jan 2012 00:39:10 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0B8dnrZ028306; Wed, 11 Jan 2012 03:39:49 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 03:39:05 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 14:09:57 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Wed, 11 Jan 2012 14:09:57 +0530 From: "Ravindran, Parthasarathi" To: "Muthu Arul Mozhi Perumal (mperumal)" , Spencer Dawkins , Alan Johnston , Bernard Aboba , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw Date: Wed, 11 Jan 2012 08:39:56 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org><4F035DD5.3050305@jesup.org><4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com><4F0CAC8C.8010203@wonderhamster.org> <387F9047F55E8C42850AD6B3A7A03C6C01DCE7 99@inba-mail02.sonusnet.com> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 08:39:57.0872 (UTC) FILETIME=[997E7B00:01CCD03C] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 08:39:11 -0000 Hi Muthu, I agree with you that it is not website trust but also network has to be co= nsidered. Please look at this requirement like accessing company intranet s= ervice (email, document) from public hotspot or Internet caf=E9. Your useca= se wherein the deployment will consider security like VPN wherein the (webR= TC) application has no need to perform the double encryption. In case acces= sing company (Enterprise) e-mail in a specific hotspot/public internet care= is unsecure, then accessing company WebRTC application is also unsecure. I= f not, it is perfectly fine to access RTP WebRTC application as the securit= y is ensured in some other layer of the network.=20 >From WebRTC perspective, the standard should not mandate to use as WebRTC i= s one of the application in the system. Thanks Partha >-----Original Message----- >From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Sent: Wednesday, January 11, 2012 12:52 PM >To: Ravindran, Parthasarathi; Spencer Dawkins; Alan Johnston; Bernard >Aboba; Cullen Jennings (fluffy) >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] SRTP not mandatory-to-use > >Partha, > >|it is also possible to allow the configuration for sending RTP with >|user consent for a specific URL (website) > >The problem with it is that the need to do SRTP not only depends on what >you are accessing but also how and from where you are accessing it. Even >if you are accessing a trusted website, you many still want to do SRTP >if you are accessing it from a public hotspot or Internet cafe. > >I think it is a tradeoff b/w simplifying WebRTC user experience vs the >cost of connecting users to endpoints that don't do SRTP. My vote is for >the for former. > >Muthu > >|-----Original Message----- >|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of Ravindran, Parthasarathi >|Sent: Wednesday, January 11, 2012 7:23 AM >|To: Spencer Dawkins; Alan Johnston; Bernard Aboba; Cullen Jennings >(fluffy) >|Cc: rtcweb@ietf.org >|Subject: Re: [rtcweb] SRTP not mandatory-to-use >| >|Hi all, >| >|In case the proposal is to use browser configuration for debugging, it >is also possible to allow the >|configuration for sending RTP with user consent for a specific URL >(website) and debugging shall use >|the same infrastructure. I have indicated in the another mail thread >that >| >|1) SRTP session is the default in WebRTC (default API value & No >configuration) >|2) SRTP session is created if JavaScript (JS) API requested for RTP and >no configuration in browser >|for a specific URL >|3) SRTP session is created if configuration in browser allows for a URL >but JS API does not. >|4) RTP session is created if configuration in browser allows for a URL >and JS API request for RTP >|session. >| >|The above proposal is inline with current security trust model wherein >webserver is not trusted and >|user consent is assured for RTP session. This configuration falls under >the same category of >|configuration exception for plug-in, pop-up blocker, JavaScript >execution, cookies. This proposal >|provides flexibility in some of the deployment wherein double >encryption shall be avoided or security >|is assured by non-WebRTC mechanism. The more details are provided in >http://www.ietf.org/mail- >|archive/web/rtcweb/current/msg03108.html. >| >|The point to be noted is that security key management mechanism is not >part of the proposal. Let us >|discuss it separately whether single key management is sufficient >(SRTP-DTLS) or multiple key >|management like ZRTP, SRTP-SDES, SRTP-DTLS is required for WebRTC. >| >|Please let me know your opinion on this. >| >|Thanks >|Partha >| >|>-----Original Message----- >|>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf >|>Of Spencer Dawkins >|>Sent: Wednesday, January 11, 2012 2:54 AM >|>To: Alan Johnston >|>Cc: rtcweb@ietf.org >|>Subject: Re: [rtcweb] SRTP not mandatory-to-use >|> >|>On 1/5/2012 11:08 AM, Alan Johnston wrote: >|>> On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings >|>wrote: >|>>> >|>>> On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote: >|>>> >|>>>> >|>>>> This argument about debugging keeps coming up, and although I am >not >|>persuaded by this argument, it is not a completely unreasonable >request. >|>However, I don't think this needs to be controllable from JS. One >could >|>easily imagine a plain-RTP option being available from a developer >|>options dialog or console, for use by developers in debugging specific >|>problems with their service. >|>>>> _______________________________________________ >|>>> >|>>> I think the best solution for the debugging issue is to allow SRTP >to >|>negotiate a NULL cipher in special cases such as Justin described >above. >|>This keeps what you are debugging as close as possible to the version >|>when debugging is turned off. I like Justin's idea of having to enable >|>this in the browser and not having it under JS control. >|>>> >|>>> Cullen (in my individual contributor role) >|>> >|>> >|>> This seems like the right way to do this. >|>> >|>> - Alan - >|> >|>And to me. >|> >|>So, just to ask the next question ... if we require the use of SRTP >and >|>allow NULL ciphers (for debugging and whatnot), are there any >remaining >|>problems with requiring the use of SRTP? >|> >|>Thanks, >|> >|>Spencer >|>_______________________________________________ >|>rtcweb mailing list >|>rtcweb@ietf.org >|>https://www.ietf.org/mailman/listinfo/rtcweb >|_______________________________________________ >|rtcweb mailing list >|rtcweb@ietf.org >|https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Jan 11 00:54:23 2012 Return-Path: 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 5AD8E21F84E1 for ; Wed, 11 Jan 2012 00:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 4CHeoosMelZA for ; Wed, 11 Jan 2012 00:54:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAE5E21F84D0 for ; Wed, 11 Jan 2012 00:54:22 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so388130vcb.31 for ; Wed, 11 Jan 2012 00:54:22 -0800 (PST) Received: by 10.220.106.207 with SMTP id y15mr13273322vco.69.1326272062180; Wed, 11 Jan 2012 00:54:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.73 with HTTP; Wed, 11 Jan 2012 00:54:01 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 11 Jan 2012 09:54:01 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 08:54:23 -0000 2012/1/11 Ravindran, Parthasarathi : > I agree with you that it is not website trust but also network has to be = considered. Please look at this requirement like accessing company intranet= service (email, document) from public hotspot or Internet caf=C3=A9. Your = usecase wherein the deployment will consider security like VPN wherein the = (webRTC) application has no need to perform the double encryption. In case = accessing company (Enterprise) e-mail in a specific hotspot/public internet= care is unsecure, then accessing company WebRTC application is also unsecu= re. If not, it is perfectly fine to access RTP WebRTC application as the se= curity is ensured in some other layer of the network. It seems that there is no evolution at all in this issue, same arguments as two months ago. AFAIR the main question/problem is: who does decide when to use SRTP or just plain RTP? does such a suggestion come from the web page itself? If so, the user (the human user) can be deceived: "Press the 'Accept unsecure communication' button and you will win a car = !!!" The double encryption is not a problem at all. The application (the browser) performs SRTP encryption (no problem here!) and the TCP/IP stack in the computer or in the router performs network encryption. Which is the problem??? There is no problem at all. All of this just seems a poor argument in favour of plain RTP to interoperate with legacy and non secure RTP implementations (and this is the fail of lazy SIP vendors, don't bring that to WebRTC please). Regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Wed Jan 11 02:21:56 2012 Return-Path: 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 8051021F8858 for ; Wed, 11 Jan 2012 02:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 OD5dFZZw3teV for ; Wed, 11 Jan 2012 02:21:55 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E01E21F884C for ; Wed, 11 Jan 2012 02:21:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2693C39E23A; Wed, 11 Jan 2012 11:21:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnN5ESQF7wV4; Wed, 11 Jan 2012 11:21:53 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E400239E03A; Wed, 11 Jan 2012 11:21:52 +0100 (CET) Message-ID: <4F0D62C0.7060006@alvestrand.no> Date: Wed, 11 Jan 2012 11:21:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------080404040703010600040207" Cc: "public-webrtc@w3.org" Subject: [rtcweb] New I-D: draft-alvestrand-rtcweb-msid-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "rtcweb@ietf.org" 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: Wed, 11 Jan 2012 10:21:56 -0000 This is a multi-part message in MIME format. --------------080404040703010600040207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have created an internet-draft to cover a minor disconnect between specs: How to signal that an RTP SSRC belongs to a given WebRTC MediaStream. I hope this is uncontroversial; I basically wrote down what I've seen go by in email, and filled in with some formalities around it. Chairs: I request time on the agenda at the interim meeting to discuss this draft, verify that it's uncontroversial, and decide on further disposition of it. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-msid-00.txt Date: Wed, 11 Jan 2012 02:19:27 -0800 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: harald@alvestrand.no A new version of I-D, draft-alvestrand-rtcweb-msid-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-msid Revision: 00 Title: Signalling Media Stream ID in the Session Description Protocol Creation date: 2012-01-11 WG ID: Individual Submission Number of pages: 7 Abstract: This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of"media stream" /"media stream track" is carried using SDP signalling. This document should be discussed in the RTCWEB WG list, rtcweb@ietf.org. The IETF Secretariat --------------080404040703010600040207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have created an internet-draft to cover a minor disconnect between specs: How to signal that an RTP SSRC belongs to a given WebRTC MediaStream.

I hope this is uncontroversial; I basically wrote down what I've seen go by in email, and filled in with some formalities around it.

Chairs: I request time on the agenda at the interim meeting to discuss this draft, verify that it's uncontroversial, and decide on further disposition of it.

             Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-00.txt
Date: Wed, 11 Jan 2012 02:19:27 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 00
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-11
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media stream
   track&quot; is carried using SDP signalling.

   This document should be discussed in the RTCWEB WG list,
   rtcweb@ietf.org.


                                                                                  


The IETF Secretariat
--------------080404040703010600040207-- From pravindran@sonusnet.com Wed Jan 11 02:56:01 2012 Return-Path: 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 B476221F882E for ; Wed, 11 Jan 2012 02:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 KBp8fCSvcbez for ; Wed, 11 Jan 2012 02:56:00 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E0A6121F84A0 for ; Wed, 11 Jan 2012 02:55:59 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0BAucgM020100; Wed, 11 Jan 2012 05:56:38 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 05:55:54 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 16:26:47 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 11 Jan 2012 16:26:47 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw//+vH4CAAHXqEA== Date: Wed, 11 Jan 2012 10:56:45 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 10:56:47.0485 (UTC) FILETIME=[B6CE02D0:01CCD04F] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 10:56:01 -0000 SGkgSW5ha2ksDQoNCk15IHByb3Bvc2FsIGlzIG5vdCB0byB0cnVzdCB0aGUgd2Vic2l0ZSBidXQg dGhlIHVzZXIgZGVjaWRlcyBiYXNlZCANCm9uIGJyb3dzZXIgY29uZmlndXJhdGlvbi4gUGxlYXNl IHNlZSB0aGUgZGlmZmVyZW50IGNvbWJpbmF0aW9uIGluDQp0aGUgZWFybGllciBtYWlsIHdoZXJl aW4gdGhlcmUgaXMgbm8gY29tcHJvbWlzZSBvbiB0aGUgc2VjdXJpdHkgDQp0cnVzdCBtb2RlbC4N Cg0KSHVtYW4gdXNlciB3aG8gIlByZXNzIHRoZSAnQWNjZXB0IHVuc2VjdXJlIGNvbW11bmljYXRp b24nIGJ1dHRvbiANCmFuZCB5b3Ugd2lsbCB3aW4gYSBjYXIgISEhIiB3aWxsIGFsbG93IFJUUCBw bHVnLWluIHRvIGluc3RhbGwgb3IgDQpjb25maWd1cmUgYnJvd3NlciB0byB3aW4gdGhlIGNhci4g SXQgaXMgYXMgZ29vZCBhcyBzZW5kaW5nIHRoZSANCmFpciB0aWNrZXQgbW9uZXkgdG8gdW5rbm93 biBjb3VudHJ5IGtpbmcgYmFzZWQgb24gc3BhbSBtYWlsIGluIA0Kc2VjdXJlZCAoaHR0cHMpIGUt bWFpbCBhY2Nlc3MgdXNlciBmb3IgZ2V0dGluZyBsdW1wIHN1bSBtb25leSANCmZyb20gS2luZyAo c3BhbW1lcikuIA0KDQpBbHNvLCBwbGVhc2Ugbm90ZSB0aGF0IFNSVFAtRFRMUyBkb2VzIG5vdCBw cmV2ZW50IFdlYlJUQyBzZXJ2ZXINCmZyb20gYWNjZXNzaW5nIHRoZSBzZWN1cmVkIFdlYlJUQyBt ZWRpYSAoZGF0YSkgYnV0IGhlbHBzIHVzZXIgdG8gDQppZGVudGlmeSB0aGF0IHRoZSBtZWRpYSBp cyBub3QgZW5kLXRvLWVuZC4gTXkgc3RhdGVtZW50IGlzIGJhc2VkIA0Kb24gbXkgdW5kZXJzdGFu ZGluZyBvZiBXZWJSVEMgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlDQoNClBhcnRoYShCcm93c2VyICsg IEpTKSAtLS0tLS0tLS0tV2ViUlRDc2VydmVyLS0tLS1Ccm93c2VyKyBKUyAoSW5ha2kpDQogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAtLS0tKFNSVFArRFRMUyktLS0tLVdlYlJUQyBNZWRpYSBzZXJ2ZXItLS0o U1JUUCtEVExTKSAtLS0tLSANCg0KSW4gdGhlIGFib3ZlIHRvcG9sb2d5LCB3ZWJzZXJ2ZXIgb3du cyBXZWJSVEMgbWVkaWEgc2VydmVyIGFzIHdlbGwuIA0KV2ViIG1lZGlhIHNlcnZlciB0ZXJtaW5h dGVzICYgb3JpZ2luYXRlcyB0aGUgbWVkaWEuIFRoZSBpZGVudGl0eSBpcyANCnRoZSBkaWZmZXJl bnRpYXRpbmcgZmFjdG9yLiBGb3IgZXhhbXBsZSwgaWYgSSBzZWUgdGhlIGJyb3dzZXIgd2luZG93 DQp3aXRoIGlkZW50aXR5IGliY0BnbWFpbC5jb20gaW5zdGVhZCBvZiBpYmNAYWxpYXgubmV0LCB0 aGVuIEkgaGF2ZSB0byANCnVuZGVyc3RhbmQgdGhhdCBicm93c2VyIGlzIG5vdCBlbmQtdG8tZW5k IGJlY2F1c2Ugb2YgaWRlbnRpdHkuDQoNCk15IGN1cnJlbnQgYXJndW1lbnQgaGFzIG5vdGhpbmcg dG8gZG8gd2l0aCBQU1ROIGludGVyb3AuIEFGQUlLLCANClNSVFAtRFRMUyBzdGFuZGFyZGl6YXRp b24gaW4gV2ViUlRDIGlzIGdvb2QgZm9yIFNCQyA6LSkuIA0KDQpUaGFua3MNClBhcnRoYQ0KDQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFtt YWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTEsIDIwMTIg MjoyNCBQTQ0KPlRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCj5DYzogTXV0aHUgQXJ1bCBN b3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IFNwZW5jZXIgRGF3a2luczsgQWxhbiBKb2huc3RvbjsN Cj5CZXJuYXJkIEFib2JhOyBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IHJ0Y3dlYkBpZXRmLm9y Zw0KPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBTUlRQIG5vdCBtYW5kYXRvcnktdG8tdXNlDQo+DQo+ MjAxMi8xLzExIFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5j b20+Og0KPj4gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IGlzIG5vdCB3ZWJzaXRlIHRydXN0IGJ1 dCBhbHNvIG5ldHdvcmsgaGFzIHRvDQo+YmUgY29uc2lkZXJlZC4gUGxlYXNlIGxvb2sgYXQgdGhp cyByZXF1aXJlbWVudCBsaWtlIGFjY2Vzc2luZyBjb21wYW55DQo+aW50cmFuZXQgc2VydmljZSAo ZW1haWwsIGRvY3VtZW50KSBmcm9tIHB1YmxpYyBob3RzcG90IG9yIEludGVybmV0IGNhZsOpLg0K PllvdXIgdXNlY2FzZSB3aGVyZWluIHRoZSBkZXBsb3ltZW50IHdpbGwgY29uc2lkZXIgc2VjdXJp dHkgbGlrZSBWUE4NCj53aGVyZWluIHRoZSAod2ViUlRDKSBhcHBsaWNhdGlvbiBoYXMgbm8gbmVl ZCB0byBwZXJmb3JtIHRoZSBkb3VibGUNCj5lbmNyeXB0aW9uLiBJbiBjYXNlIGFjY2Vzc2luZyBj b21wYW55IChFbnRlcnByaXNlKSBlLW1haWwgaW4gYSBzcGVjaWZpYw0KPmhvdHNwb3QvcHVibGlj IGludGVybmV0IGNhcmUgaXMgdW5zZWN1cmUsIHRoZW4gYWNjZXNzaW5nIGNvbXBhbnkgV2ViUlRD DQo+YXBwbGljYXRpb24gaXMgYWxzbyB1bnNlY3VyZS4gSWYgbm90LCBpdCBpcyBwZXJmZWN0bHkg ZmluZSB0byBhY2Nlc3MgUlRQDQo+V2ViUlRDIGFwcGxpY2F0aW9uIGFzIHRoZSBzZWN1cml0eSBp cyBlbnN1cmVkIGluIHNvbWUgb3RoZXIgbGF5ZXIgb2YgdGhlDQo+bmV0d29yay4NCj4NCj4NCj5J dCBzZWVtcyB0aGF0IHRoZXJlIGlzIG5vIGV2b2x1dGlvbiBhdCBhbGwgaW4gdGhpcyBpc3N1ZSwg c2FtZSBhcmd1bWVudHMNCj5hcyB0d28gbW9udGhzIGFnby4NCj4NCj5BRkFJUiB0aGUgbWFpbiBx dWVzdGlvbi9wcm9ibGVtIGlzOiB3aG8gZG9lcyBkZWNpZGUgd2hlbiB0byB1c2UgU1JUUCBvcg0K Pmp1c3QgcGxhaW4gUlRQPyBkb2VzIHN1Y2ggYSBzdWdnZXN0aW9uIGNvbWUgZnJvbSB0aGUgd2Vi IHBhZ2UgaXRzZWxmPyBJZg0KPnNvLCB0aGUgdXNlciAodGhlIGh1bWFuIHVzZXIpIGNhbiBiZSBk ZWNlaXZlZDoNCj4NCj4gICJQcmVzcyB0aGUgJ0FjY2VwdCB1bnNlY3VyZSBjb21tdW5pY2F0aW9u JyBidXR0b24gYW5kIHlvdSB3aWxsIHdpbiBhDQo+Y2FyICEhISINCj4NCj5UaGUgZG91YmxlIGVu Y3J5cHRpb24gaXMgbm90IGEgcHJvYmxlbSBhdCBhbGwuIFRoZSBhcHBsaWNhdGlvbiAodGhlDQo+ YnJvd3NlcikgcGVyZm9ybXMgU1JUUCBlbmNyeXB0aW9uIChubyBwcm9ibGVtIGhlcmUhKSBhbmQg dGhlIFRDUC9JUA0KPnN0YWNrIGluIHRoZSBjb21wdXRlciBvciBpbiB0aGUgcm91dGVyIHBlcmZv cm1zIG5ldHdvcmsgZW5jcnlwdGlvbi4NCj5XaGljaCBpcyB0aGUgcHJvYmxlbT8/PyBUaGVyZSBp cyBubyBwcm9ibGVtIGF0IGFsbC4gQWxsIG9mIHRoaXMganVzdA0KPnNlZW1zIGEgcG9vciBhcmd1 bWVudCBpbiBmYXZvdXIgb2YgcGxhaW4gUlRQIHRvIGludGVyb3BlcmF0ZSB3aXRoIGxlZ2FjeQ0K PmFuZCBub24gc2VjdXJlIFJUUCBpbXBsZW1lbnRhdGlvbnMgKGFuZCB0aGlzIGlzIHRoZSBmYWls IG9mIGxhenkgU0lQDQo+dmVuZG9ycywgZG9uJ3QgYnJpbmcgdGhhdCB0byBXZWJSVEMgcGxlYXNl KS4NCj4NCj4NCj5SZWdhcmRzLg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNA YWxpYXgubmV0Pg0K From ibc@aliax.net Wed Jan 11 03:08:16 2012 Return-Path: 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 7824D21F86DE for ; Wed, 11 Jan 2012 03:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 yOTvXW5xREVa for ; Wed, 11 Jan 2012 03:08:15 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE2EC21F8675 for ; Wed, 11 Jan 2012 03:08:15 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so461100vbb.31 for ; Wed, 11 Jan 2012 03:08:15 -0800 (PST) Received: by 10.52.26.8 with SMTP id h8mr5541622vdg.122.1326280095119; Wed, 11 Jan 2012 03:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.73 with HTTP; Wed, 11 Jan 2012 03:07:54 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 11 Jan 2012 12:07:54 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 11:08:16 -0000 2012/1/11 Ravindran, Parthasarathi : > Human user who "Press the 'Accept unsecure communication' button > and you will win a car !!!" will allow RTP plug-in to install or > configure browser to win the car. It is as good as sending the > air ticket money to unknown country king based on spam mail in > secured (https) e-mail access user for getting lump sum money > from King (spammer). Right. My question is: why to allow that? wasn't a primary aim of WebRTC to avoid such a risk? > Also, please note that SRTP-DTLS does not prevent WebRTC server > from accessing the secured WebRTC media (data) but helps user to > identify that the media is not end-to-end. My statement is based > on my understanding of WebRTC security architecture > > Partha(Browser + =C2=A0JS) ----------WebRTCserver-----Browser+ JS (Inaki) > =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| > =C2=A0 =C2=A0 =C2=A0 ----(SRTP+DTLS)-----WebRTC Media server---(SRTP+DTLS= ) ----- > > In the above topology, webserver owns WebRTC media server as well. > Web media server terminates & originates the media. The identity is > the differentiating factor. For example, if I see the browser window > with identity ibc@gmail.com instead of ibc@aliax.net, then I have to > understand that browser is not end-to-end because of identity. Well, I expect that the typicall picture will not include the "WebRTC Media Server" (it could however). > My current argument has nothing to do with PSTN interop. AFAIK, > SRTP-DTLS standardization in WebRTC is good for SBC :-). Ok, but I'm not talking about that. I'm just wondering why the human user should be able to "trust" a website asking permission for untrusted/insecure plain RTP. This is not about having a media server or not. Example: I'm in an airport with open WiFi. If I establish a plain RTP communication anyone in that network can inspect it. Why to allow that? I repeat my main argument against allowing plain RTP: The double encryption is not a problem at all. The application (the browser) performs SRTP encryption (no problem here!) and the TCP/IP stack in the computer or in the router performs network encryption. Which is the problem??? There is no problem at all. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Jan 11 05:39:20 2012 Return-Path: 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 DA17C21F87B9 for ; Wed, 11 Jan 2012 05:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 8K4ujz+KP0TU for ; Wed, 11 Jan 2012 05:39:20 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D1BCB21F861F for ; Wed, 11 Jan 2012 05:39:19 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0BDduMF028302; Wed, 11 Jan 2012 08:39:56 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 08:39:12 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 19:10:05 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Wed, 11 Jan 2012 19:10:04 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw//+vH4CAAHXqEP//r34AgAB980A= Date: Wed, 11 Jan 2012 13:40:04 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 13:40:05.0236 (UTC) FILETIME=[86B82B40:01CCD066] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 13:39:21 -0000 SGkgSW5ha2ksDQoNCkkgdGhpbmsgdGhhdCB3ZSBhcmUgaW4gdGhlIHNhbWUgcGFnZSBvZiBub3Qg dXNpbmcgcGxhaW4gUlRQIGluDQphaXJwb3J0IHdpdGggV2lGaS4gSXQgaXMgdGhlIG1haW4gcmVh c29uIGZvciBhc2tpbmcgU1JUUCBhcyBhIA0KZGVmYXVsdCBtZWRpYSBwcm90b2NvbC4gQWxzbywg dGhlIHB1YmxpYyBpbnRlcm5ldCBhcHBsaWNhdGlvbiBsaWtlDQpHb29nbGUgaGFuZ291dCBzaG91 bGQgYmUgYmFzZWQgb24gU1JUUC4gU28sIE1vc3Qgb2YgdGhlIFdlYlJUQw0KYXBwbGljYXRpb24g d2lsbCBiYXNlZCBvbiBTUlRQIGJ1dCBzb21lIG9mIHRoZSBXZWJSVEMgYXBwbGljYXRpb24NCnBy ZWZlcnMgdG8gUlRQIChpbnRyYW5ldCBzaXRlKSB3aGljaCBNVVNUIE5PVCBiZSByZXN0cmljdGVk IGJ5IA0KSUVURiBzdGFuZGFyZC4NCg0KVGhlIGRvdWJsZSBlbmNyeXB0aW9uIGF2b2lkYW5jZSBp cyB0aGUgbWF0dGVyIG9mIG9wdGltaXphdGlvbiBpbiANCm5ldHdvcmsgZGVzaWduIGFzIGRvdWJs ZSBlbmNyeXB0aW9uIGluIGVuZHBvaW50IGNhbGxzIGZvciBkb3VibGUgDQpkZWNyeXB0aW9uIGlu IHRoZSBuZXR3b3JrIGZvciBzb21lIG9mIHRoZSBzZXJ2aWNlcy4gSSBhZ3JlZSB0aGF0IA0KaXQg bWF5IG5vdCBiZSBwcm9ibGVtIGluIHNvbWUgb2YgdGhlIG5ldHdvcmsgYmVjYXVzZSBvZg0KdGhl IG5ldHdvcmsgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IG9yIG5ldHdvcmsgZW50aXR5IGlzIG5vdCBp bnZvbHZlZCANCihicm93c2VyLWJyb3dzZXIgc2NlbmFyaW8pIGJ1dCB3ZSBjYW4ndCBnZW5lcmFs aXplIHRoaXMuIEluIGNhc2UgaXQgaXMgDQpwb3NzaWJsZSwgRG91YmxlIGVuY3J5cHRpb24gaGFz IHRvIGJlIGF2b2lkZWQgYW5kIElFVEYgaGFzIHRvIA0KcmVjb21tZW5kIGFjY29yZGluZ2x5LiAN Cg0KUGxlYXNlIHJlYWQgaW5saW5lIGZvciBtb3JlIGNvbW1lbnRzLg0KDQpUaGFua3MNClBhcnRo YQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3Rp bGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTEs IDIwMTIgNDozOCBQTQ0KPlRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkNCj5DYzogTXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IFNwZW5jZXIgRGF3a2luczsgQWxhbiBKb2hu c3RvbjsNCj5CZXJuYXJkIEFib2JhOyBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IHJ0Y3dlYkBp ZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBTUlRQIG5vdCBtYW5kYXRvcnktdG8tdXNl DQo+DQo+MjAxMi8xLzExIFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251 c25ldC5jb20+Og0KPj4gSHVtYW4gdXNlciB3aG8gIlByZXNzIHRoZSAnQWNjZXB0IHVuc2VjdXJl IGNvbW11bmljYXRpb24nIGJ1dHRvbiBhbmQNCj4+IHlvdSB3aWxsIHdpbiBhIGNhciAhISEiIHdp bGwgYWxsb3cgUlRQIHBsdWctaW4gdG8gaW5zdGFsbCBvciBjb25maWd1cmUNCj4+IGJyb3dzZXIg dG8gd2luIHRoZSBjYXIuIEl0IGlzIGFzIGdvb2QgYXMgc2VuZGluZyB0aGUgYWlyIHRpY2tldCBt b25leQ0KPj4gdG8gdW5rbm93biBjb3VudHJ5IGtpbmcgYmFzZWQgb24gc3BhbSBtYWlsIGluIHNl Y3VyZWQgKGh0dHBzKSBlLW1haWwNCj4+IGFjY2VzcyB1c2VyIGZvciBnZXR0aW5nIGx1bXAgc3Vt IG1vbmV5IGZyb20gS2luZyAoc3BhbW1lcikuDQo+DQo+UmlnaHQuIE15IHF1ZXN0aW9uIGlzOiB3 aHkgdG8gYWxsb3cgdGhhdD8gd2Fzbid0IGEgcHJpbWFyeSBhaW0gb2YgV2ViUlRDDQo+dG8gYXZv aWQgc3VjaCBhIHJpc2s/DQo+DQo8cGFydGhhPiBJIGd1ZXNzIHRoYXQgbXkgcG9pbnQgZG9lcyBu b3QgY29tZSBvdXQgd2VsbC4gSSdtIHNheWluZyB0aGF0DQp1c2VyIHdobyBhY2NlcHQgdW5zZWN1 cmUgY29tbXVuaWNhdGlvbiBmb3IgYSBjYXIgd2lsbCBhbGxvdyBSVFAgcGx1Zy1pbg0KdG8gYmUg YWRkZWQgaW4gdGhlIGJyb3dzZXIgd2hlcmVpbiBzZWN1cml0eSB3aWxsIGJlIGNvbXByb21pc2Vk IGFueXdheQ0KYW5kIG5vdCByZWxhdGVkIHRvIFdlYlJUQy4gPC9wYXJ0aGE+DQoNCj4NCj4+IEFs c28sIHBsZWFzZSBub3RlIHRoYXQgU1JUUC1EVExTIGRvZXMgbm90IHByZXZlbnQgV2ViUlRDIHNl cnZlciBmcm9tDQo+PiBhY2Nlc3NpbmcgdGhlIHNlY3VyZWQgV2ViUlRDIG1lZGlhIChkYXRhKSBi dXQgaGVscHMgdXNlciB0byBpZGVudGlmeQ0KPj4gdGhhdCB0aGUgbWVkaWEgaXMgbm90IGVuZC10 by1lbmQuIE15IHN0YXRlbWVudCBpcyBiYXNlZCBvbiBteQ0KPj4gdW5kZXJzdGFuZGluZyBvZiBX ZWJSVEMgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlDQo+Pg0KPj4gUGFydGhhKEJyb3dzZXIgKyDCoEpT KSAtLS0tLS0tLS0tV2ViUlRDc2VydmVyLS0tLS1Ccm93c2VyKyBKUyAoSW5ha2kpDQo+PiDCoCDC oCDCoHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8DQo+PiDCoCDCoCDCoCAtLS0tKFNS VFArRFRMUyktLS0tLVdlYlJUQyBNZWRpYSBzZXJ2ZXItLS0oU1JUUCtEVExTKSAtLS0tLQ0KPj4N Cj4+IEluIHRoZSBhYm92ZSB0b3BvbG9neSwgd2Vic2VydmVyIG93bnMgV2ViUlRDIG1lZGlhIHNl cnZlciBhcyB3ZWxsLg0KPj4gV2ViIG1lZGlhIHNlcnZlciB0ZXJtaW5hdGVzICYgb3JpZ2luYXRl cyB0aGUgbWVkaWEuIFRoZSBpZGVudGl0eSBpcw0KPj4gdGhlIGRpZmZlcmVudGlhdGluZyBmYWN0 b3IuIEZvciBleGFtcGxlLCBpZiBJIHNlZSB0aGUgYnJvd3NlciB3aW5kb3cNCj4+IHdpdGggaWRl bnRpdHkgaWJjQGdtYWlsLmNvbSBpbnN0ZWFkIG9mIGliY0BhbGlheC5uZXQsIHRoZW4gSSBoYXZl IHRvDQo+PiB1bmRlcnN0YW5kIHRoYXQgYnJvd3NlciBpcyBub3QgZW5kLXRvLWVuZCBiZWNhdXNl IG9mIGlkZW50aXR5Lg0KPg0KPldlbGwsIEkgZXhwZWN0IHRoYXQgdGhlIHR5cGljYWxsIHBpY3R1 cmUgd2lsbCBub3QgaW5jbHVkZSB0aGUgIldlYlJUQw0KPk1lZGlhIFNlcnZlciIgKGl0IGNvdWxk IGhvd2V2ZXIpLg0KPg0KPg0KPj4gTXkgY3VycmVudCBhcmd1bWVudCBoYXMgbm90aGluZyB0byBk byB3aXRoIFBTVE4gaW50ZXJvcC4gQUZBSUssDQo+PiBTUlRQLURUTFMgc3RhbmRhcmRpemF0aW9u IGluIFdlYlJUQyBpcyBnb29kIGZvciBTQkMgOi0pLg0KPg0KPk9rLCBidXQgSSdtIG5vdCB0YWxr aW5nIGFib3V0IHRoYXQuIEknbSBqdXN0IHdvbmRlcmluZyB3aHkgdGhlIGh1bWFuDQo+dXNlciBz aG91bGQgYmUgYWJsZSB0byAidHJ1c3QiIGEgd2Vic2l0ZSBhc2tpbmcgcGVybWlzc2lvbiBmb3IN Cj51bnRydXN0ZWQvaW5zZWN1cmUgcGxhaW4gUlRQLiBUaGlzIGlzIG5vdCBhYm91dCBoYXZpbmcg YSBtZWRpYSBzZXJ2ZXIgb3INCj5ub3QuDQo+DQo+RXhhbXBsZTogSSdtIGluIGFuIGFpcnBvcnQg d2l0aCBvcGVuIFdpRmkuIElmIEkgZXN0YWJsaXNoIGEgcGxhaW4gUlRQDQo+Y29tbXVuaWNhdGlv biBhbnlvbmUgaW4gdGhhdCBuZXR3b3JrIGNhbiBpbnNwZWN0IGl0LiBXaHkgdG8gYWxsb3cgdGhh dD8NCg0KPHBhcnRoYT4gQWdyZWVkLiBQdWJsaWMgaW50ZXJuZXQgV2ViUlRDIGFwcGxpY2F0aW9u IGhhcyB0byBiZSBiYXNlZCBvbg0KU1JUUCA8L3BhcnRoYT4NCg0KPg0KPkkgcmVwZWF0IG15IG1h aW4gYXJndW1lbnQgYWdhaW5zdCBhbGxvd2luZyBwbGFpbiBSVFA6DQo+DQo+VGhlIGRvdWJsZSBl bmNyeXB0aW9uIGlzIG5vdCBhIHByb2JsZW0gYXQgYWxsLiBUaGUgYXBwbGljYXRpb24gKHRoZQ0K PmJyb3dzZXIpIHBlcmZvcm1zIFNSVFAgZW5jcnlwdGlvbiAobm8gcHJvYmxlbSBoZXJlISkgYW5k IHRoZSBUQ1AvSVANCj5zdGFjayBpbiB0aGUgY29tcHV0ZXIgb3IgaW4gdGhlIHJvdXRlciBwZXJm b3JtcyBuZXR3b3JrIGVuY3J5cHRpb24uDQo+V2hpY2ggaXMgdGhlIHByb2JsZW0/Pz8gVGhlcmUg aXMgbm8gcHJvYmxlbSBhdCBhbGwuDQo+DQo+LS0NCj5Jw7Fha2kgQmF6IENhc3RpbGxvDQo+PGli Y0BhbGlheC5uZXQ+DQo= From juberti@google.com Wed Jan 11 11:52:38 2012 Return-Path: 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 9BF6D21F8528 for ; Wed, 11 Jan 2012 11:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 ecUvp7KnIZ2G for ; Wed, 11 Jan 2012 11:52:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82CE821F8517 for ; Wed, 11 Jan 2012 11:52:37 -0800 (PST) Received: by ggnr5 with SMTP id r5so662726ggn.31 for ; Wed, 11 Jan 2012 11:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=rZwxSpC1Lo02Zezu3k0EXptyvyUKU0D//zWk96v/BRo=; b=oLekkxRmHbfqsvOugqOSqtJBp9tbIpYMbYbI5JQZH0Q5JRgIPhJfw1s8tAt4OVVoau wlavF5bjwdzsyRPBklwCtHIYCCWBhmEmlhx52PN4XLOwP7wWAzCx+mTvE0mS7qaKcTGM 2OejHUC080x3Dlzt4fTlejiL7NPDhXkgWcSWQ= Received: by 10.50.189.199 with SMTP id gk7mr7971832igc.30.1326311556540; Wed, 11 Jan 2012 11:52:36 -0800 (PST) Received: by 10.50.189.199 with SMTP id gk7mr7971818igc.30.1326311556426; Wed, 11 Jan 2012 11:52:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.196.93 with HTTP; Wed, 11 Jan 2012 11:52:15 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> From: Justin Uberti Date: Wed, 11 Jan 2012 14:52:15 -0500 Message-ID: To: "Ravindran, Parthasarathi" X-System-Of-Record: true Content-Type: multipart/alternative; boundary=14dae9340b392ead6204b645f941 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 19:52:38 -0000 --14dae9340b392ead6204b645f941 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To reply to the OP: The consensus that I see having emerged from this discussion is that SRTP should be mandatory to use, with a provision for NULL ciphers for debugging. This provision is only exposed through developer settings, and can never be invoked from the web app; for all practical purposes, applications will have to use SRTP As for the key management mechanism, SDES and DTLS will be supported; while DTLS is preferred, there are few DTLS-SRTP implementations in existence at this time. As far as I know, this is what the major WebRTC implementations are planning to do. On Wed, Jan 11, 2012 at 8:40 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Inaki, > > I think that we are in the same page of not using plain RTP in > airport with WiFi. It is the main reason for asking SRTP as a > default media protocol. Also, the public internet application like > Google hangout should be based on SRTP. So, Most of the WebRTC > application will based on SRTP but some of the WebRTC application > prefers to RTP (intranet site) which MUST NOT be restricted by > IETF standard. > > The double encryption avoidance is the matter of optimization in > network design as double encryption in endpoint calls for double > decryption in the network for some of the services. I agree that > it may not be problem in some of the network because of > the network resource availability or network entity is not involved > (browser-browser scenario) but we can't generalize this. In case it is > possible, Double encryption has to be avoided and IETF has to > recommend accordingly. > > Please read inline for more comments. > > Thanks > Partha > > >-----Original Message----- > >From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > >Sent: Wednesday, January 11, 2012 4:38 PM > >To: Ravindran, Parthasarathi > >Cc: Muthu Arul Mozhi Perumal (mperumal); Spencer Dawkins; Alan Johnston; > >Bernard Aboba; Cullen Jennings (fluffy); rtcweb@ietf.org > >Subject: Re: [rtcweb] SRTP not mandatory-to-use > > > >2012/1/11 Ravindran, Parthasarathi : > >> Human user who "Press the 'Accept unsecure communication' button and > >> you will win a car !!!" will allow RTP plug-in to install or configure > >> browser to win the car. It is as good as sending the air ticket money > >> to unknown country king based on spam mail in secured (https) e-mail > >> access user for getting lump sum money from King (spammer). > > > >Right. My question is: why to allow that? wasn't a primary aim of WebRTC > >to avoid such a risk? > > > I guess that my point does not come out well. I'm saying that > user who accept unsecure communication for a car will allow RTP plug-in > to be added in the browser wherein security will be compromised anyway > and not related to WebRTC. > > > > >> Also, please note that SRTP-DTLS does not prevent WebRTC server from > >> accessing the secured WebRTC media (data) but helps user to identify > >> that the media is not end-to-end. My statement is based on my > >> understanding of WebRTC security architecture > >> > >> Partha(Browser + JS) ----------WebRTCserver-----Browser+ JS (Inaki) > >> | | > >> ----(SRTP+DTLS)-----WebRTC Media server---(SRTP+DTLS) ----- > >> > >> In the above topology, webserver owns WebRTC media server as well. > >> Web media server terminates & originates the media. The identity is > >> the differentiating factor. For example, if I see the browser window > >> with identity ibc@gmail.com instead of ibc@aliax.net, then I have to > >> understand that browser is not end-to-end because of identity. > > > >Well, I expect that the typicall picture will not include the "WebRTC > >Media Server" (it could however). > > > > > >> My current argument has nothing to do with PSTN interop. AFAIK, > >> SRTP-DTLS standardization in WebRTC is good for SBC :-). > > > >Ok, but I'm not talking about that. I'm just wondering why the human > >user should be able to "trust" a website asking permission for > >untrusted/insecure plain RTP. This is not about having a media server or > >not. > > > >Example: I'm in an airport with open WiFi. If I establish a plain RTP > >communication anyone in that network can inspect it. Why to allow that? > > Agreed. Public internet WebRTC application has to be based on > SRTP > > > > >I repeat my main argument against allowing plain RTP: > > > >The double encryption is not a problem at all. The application (the > >browser) performs SRTP encryption (no problem here!) and the TCP/IP > >stack in the computer or in the router performs network encryption. > >Which is the problem??? There is no problem at all. > > > >-- > >I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae9340b392ead6204b645f941 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To reply to the OP: The consensus that I see having emerged from this discu= ssion is that SRTP should be mandatory to use, with a provision for NULL ci= phers for debugging. This provision is only exposed through developer setti= ngs, and can never be invoked from the web app; for all practical purposes,= applications will have to use SRTP

As for the key management mechanism, SDES and DTLS will be s= upported; while DTLS is preferred, there are few DTLS-SRTP implementations = in existence at this time.

As far as I know, this is wha= t the major WebRTC implementations are planning to do.

On Wed, Jan 11, 2012 at 8:40 AM, Ravindran, = Parthasarathi <pravindran@sonusnet.com> wrote:
Hi Inaki,

I think that we are in the same page of not using plain RTP in
airport with WiFi. It is the main reason for asking SRTP as a
default media protocol. Also, the public internet application like
Google hangout should be based on SRTP. So, Most of the WebRTC
application will based on SRTP but some of the WebRTC application
prefers to RTP (intranet site) which MUST NOT be restricted by
IETF standard.

The double encryption avoidance is the matter of optimization in
network design as double encryption in endpoint calls for double
decryption in the network for some of the services. I agree that
it may not be problem in some of the network because of
the network resource availability or network entity is not involved
(browser-browser scenario) but we can't generalize this. In case it is<= br> possible, Double encryption has to be avoided and IETF has to
recommend accordingly.

Please read inline for more comments.

Thanks
Partha

>-----Original Message-----
>From: I=C3=B1aki Baz Castillo [mailto:= ibc@aliax.net]
>Sent: Wednesday, January 11, 2012 4:38 PM
>To: Ravindran, Parthasarathi
>Cc: Muthu Arul Mozhi Perumal (mperumal); Spencer Dawkins; Alan Johnston= ;
>Bernard Aboba; Cullen Jennings (fluffy); rtcweb@ietf.org
>Subject: Re: [rtcweb] SRTP not mandatory-to-use
>
>2012/1/11 Ravindran, Parthasarathi <pravindran@sonusnet.com>:
>> Human user who "Press the 'Accept unsecure communication&= #39; button and
>> you will win a car !!!" will allow RTP plug-in to install or = configure
>> browser to win the car. It is as good as sending the air ticket mo= ney
>> to unknown country king based on spam mail in secured (https) e-ma= il
>> access user for getting lump sum money from King (spammer).
>
>Right. My question is: why to allow that? wasn't a primary aim of W= ebRTC
>to avoid such a risk?
>
<partha> I guess that my point does not come out well. I'm = saying that
user who accept unsecure communication for a car will allow RTP plug-in
to be added in the browser wherein security will be compromised anyway
and not related to WebRTC. </partha>

>
>> Also, please note that SRTP-DTLS does not prevent WebRTC server fr= om
>> accessing the secured WebRTC media (data) but helps user to identi= fy
>> that the media is not end-to-end. My statement is based on my
>> understanding of WebRTC security architecture
>>
>> Partha(Browser + =C2=A0JS) ----------WebRTCserver-----Browser+ JS = (Inaki)
>> =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>> =C2=A0 =C2=A0 =C2=A0 ----(SRTP+DTLS)-----WebRTC Media server---(SR= TP+DTLS) -----
>>
>> In the above topology, webserver owns WebRTC media server as well.=
>> Web media server terminates & originates the media. The identi= ty is
>> the differentiating factor. For example, if I see the browser wind= ow
>> with identity ibc@gmail.com i= nstead of ibc@aliax.net, then I have t= o
>> understand that browser is not end-to-end because of identity.
>
>Well, I expect that the typicall picture will not include the "Web= RTC
>Media Server" (it could however).
>
>
>> My current argument has nothing to do with PSTN interop. AFAIK, >> SRTP-DTLS standardization in WebRTC is good for SBC :-).
>
>Ok, but I'm not talking about that. I'm just wondering why the = human
>user should be able to "trust" a website asking permission fo= r
>untrusted/insecure plain RTP. This is not about having a media server o= r
>not.
>
>Example: I'm in an airport with open WiFi. If I establish a plain R= TP
>communication anyone in that network can inspect it. Why to allow that?=

<partha> Agreed. Public internet WebRTC application has to be b= ased on
SRTP </partha>

>
>I repeat my main argument against allowing plain RTP:
>
>The double encryption is not a problem at all. The application (the
>browser) performs SRTP encryption (no problem here!) and the TCP/IP
>stack in the computer or in the router performs network encryption.
>Which is the problem??? There is no problem at all.
>
>--
>I=C3=B1aki Baz Castillo
><ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--14dae9340b392ead6204b645f941-- From bernard_aboba@hotmail.com Wed Jan 11 12:00:34 2012 Return-Path: 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 A09E71F0C7F for ; Wed, 11 Jan 2012 12:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.327, 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 hvn34Ocq66LY for ; Wed, 11 Jan 2012 12:00:34 -0800 (PST) Received: from blu0-omc1-s27.blu0.hotmail.com (blu0-omc1-s27.blu0.hotmail.com [65.55.116.38]) by ietfa.amsl.com (Postfix) with ESMTP id 696601F0C58 for ; Wed, 11 Jan 2012 12:00:31 -0800 (PST) Received: from BLU152-W13 ([65.55.116.8]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:00:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_832a0b33-4ce5-4bf0-95e8-5218b27d9158_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Wed, 11 Jan 2012 12:00:30 -0800 Importance: Normal In-Reply-To: References: , , , <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org>, , <4F035DD5.3050305@jesup.org>, , , , , , , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.co m>,, <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 20:00:31.0231 (UTC) FILETIME=[AC1298F0:01CCD09B] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 20:00:34 -0000 --_832a0b33-4ce5-4bf0-95e8-5218b27d9158_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some questions: What keying mechanism(s) MUST be implemented? SDES? DTLS/SRTP? both? Is the implication that both SDES and DTLS/SRTP MUST be offered?=20 Is the preference for DTLS/SRTP implied=2C or explicit (RFC 5939)?=20 As for the NULL cipher=2C the discussion so far has been in the context of = DTLS/SRTP. If DTLS/SRTP is not chosen (e.g. SDES is negotiated in offer/an= swer)=2C then what? From: juberti@google.com Date: Wed=2C 11 Jan 2012 14:52:15 -0500 To: pravindran@sonusnet.com CC: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use To reply to the OP: The consensus that I see having emerged from this discu= ssion is that SRTP should be mandatory to use=2C with a provision for NULL = ciphers for debugging. This provision is only exposed through developer set= tings=2C and can never be invoked from the web app=3B for all practical pur= poses=2C applications will have to use SRTP As for the key management mechanism=2C SDES and DTLS will be supported=3B w= hile DTLS is preferred=2C there are few DTLS-SRTP implementations in existe= nce at this time. As far as I know=2C this is what the major WebRTC implementations are plann= ing to do. an/listinfo/rtcweb = --_832a0b33-4ce5-4bf0-95e8-5218b27d9158_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Some questions:

What keying mechanism(s) MUST be implemented? = =3B SDES? =3B DTLS/SRTP? =3B both?

Is the implication that b= oth SDES and DTLS/SRTP MUST be offered?

Is the preference for DTLS/= SRTP implied=2C or explicit (RFC 5939)?

As for the NULL cipher=2C t= he discussion so far has been in the context of DTLS/SRTP. =3B If DTLS/= SRTP is not chosen (e.g. SDES is negotiated in offer/answer)=2C then what?<= br>
F= rom: juberti@google.com
Date: Wed=2C 11 Jan 2012 14:52:15 -0500
To: p= ravindran@sonusnet.com
CC: rtcweb@ietf.org
Subject: Re: [rtcweb] SRTP= not mandatory-to-use

To reply to the OP: The consensus that I see h= aving emerged from this discussion is that SRTP should be mandatory to use= =2C with a provision for NULL ciphers for debugging. This provision is only= exposed through developer settings=2C and can never be invoked from the we= b app=3B for all practical purposes=2C applications will have to use SRTP
As for the key management mechanism=2C SDES and DTLS will be= supported=3B while DTLS is preferred=2C there are few DTLS-SRTP implementa= tions in existence at this time.

As far as I know=2C thi= s is what the major WebRTC implementations are planning to do.
an/listinfo/rtcweb
= --_832a0b33-4ce5-4bf0-95e8-5218b27d9158_-- From randell-ietf@jesup.org Wed Jan 11 13:20:52 2012 Return-Path: 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 52BD611E80B3 for ; Wed, 11 Jan 2012 13:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] 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 KB9rOOoTBboK for ; Wed, 11 Jan 2012 13:20:51 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C924A11E8074 for ; Wed, 11 Jan 2012 13:20:51 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rl5bC-0006Az-C5 for rtcweb@ietf.org; Wed, 11 Jan 2012 15:20:46 -0600 Message-ID: <4F0DFD0B.2000009@jesup.org> Date: Wed, 11 Jan 2012 16:20:11 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 21:20:52 -0000 On 1/11/2012 2:52 PM, Justin Uberti wrote: > To reply to the OP: The consensus that I see having emerged from this > discussion is that SRTP should be mandatory to use, with a provision for > NULL ciphers for debugging. This provision is only exposed through > developer settings, and can never be invoked from the web app; for all > practical purposes, applications will have to use SRTP > > As for the key management mechanism, SDES and DTLS will be supported; > while DTLS is preferred, there are few DTLS-SRTP implementations in > existence at this time. I'd like to explore the possibility of making sure there's a workable DTLS-SRTP implementation openly available, and locking WebRTC down to that only. I should note that while libsrtp 1.4.2 (last official release) doesn't have DTLS-SRTP support, there are DTLS-SRTP support functions and test code in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via a modified OpenSSL. So, I'm not sure the barrier is huge given DTLS support already. The reason (as I've mentioned at times) is that SDES means we expose the media to the JS app and to the website, neither of which we've agreed to trust. All the discussion of blocking access to decrypted media from the JS app is moot if it has the keys. If we use SDES, we're effectively trusting the JS app (and website) to a very large extent. (Not to turn on the camera/mic, but with the contents of all conversations.) It also means bid-down to SDES is trivial. I'm not sure what this would mean to identity validation via BrowserID or others (ekr?); that might survive this, but it means media could be decrypted in realtime or later if anyone has copies of the packets and can get the key from the app/website. -- Randell Jesup randell-ietf@jesup.org From ekr@rtfm.com Wed Jan 11 13:42:28 2012 Return-Path: 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 5068C11E80B3 for ; Wed, 11 Jan 2012 13:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 D4JpTFWyj-0Y for ; Wed, 11 Jan 2012 13:42:27 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9756A11E8074 for ; Wed, 11 Jan 2012 13:42:27 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so992156vbb.31 for ; Wed, 11 Jan 2012 13:42:27 -0800 (PST) Received: by 10.52.29.75 with SMTP id i11mr591441vdh.23.1326318147076; Wed, 11 Jan 2012 13:42:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Wed, 11 Jan 2012 13:41:46 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F0DFD0B.2000009@jesup.org> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> From: Eric Rescorla Date: Wed, 11 Jan 2012 13:41:46 -0800 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 21:42:28 -0000 On Wed, Jan 11, 2012 at 1:20 PM, Randell Jesup wro= te: > On 1/11/2012 2:52 PM, Justin Uberti wrote: >> >> To reply to the OP: The consensus that I see having emerged from this >> discussion is that SRTP should be mandatory to use, with a provision for >> NULL ciphers for debugging. This provision is only exposed through >> developer settings, and can never be invoked from the web app; for all >> practical purposes, applications will have to use SRTP >> >> As for the key management mechanism, SDES and DTLS will be supported; >> while DTLS is preferred, there are few DTLS-SRTP implementations in >> existence at this time. > > > > I'd like to explore the possibility of making sure there's a workable > DTLS-SRTP implementation openly available, and locking WebRTC down to tha= t > only. > > I should note that while libsrtp 1.4.2 (last official release) doesn't ha= ve > DTLS-SRTP support, there are DTLS-SRTP support functions and test code in > the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP v= ia > a modified OpenSSL. =A0So, I'm not sure the barrier is huge given DTLS su= pport > already. The situation is actually rather better than this: 1. OpenSSL 1.0.1 (currently in beta) has all the TLS-side support needed fo= r DTLS-SRTP. 2. The new entry points in libsrtp, while helpful are just helper functions. If you're willing to embed a bit of knowledge about key construction into the application, you should be able to use libsrtp 1.4.2. (though I suspect you actually don't want to. libjingle, for instance, recommends use of = the libsrtp CVS version). 3. As you say, resip and recon have support for DTLS-SRTP, though you likely won't need it for WebRTC anyway, since that support is largely SIP-specific. So in terms of having a working implementation, the issue is primarily integration into your WebRTC stack > The reason (as I've mentioned at times) is that SDES means we expose the > media to the JS app and to the website, neither of which we've agreed to > trust. =A0All the discussion of blocking access to decrypted media from t= he JS > app is moot if it has the keys. I agree that this is a real concern. > If we use SDES, we're effectively trusting the JS app (and website) to a > very large extent. =A0(Not to turn on the camera/mic, but with the conten= ts of > all conversations.) =A0It also means bid-down to SDES is trivial. =A0I'm = not > sure what this would mean to identity validation via BrowserID or others > (ekr?); that might survive this, but it means media could be decrypted in > realtime or later if anyone has copies of the packets and can get the key > from the app/website. I believe that a properly constructed identity scheme a la the one I outlin= ed in my draft (advertisement: I've been working on a prototype, so more detai= ls coming soon) will resist bid-down attacks, but I don't really see any merit for doing anything other than browser-browser key establishment for WebRTC. FWIW, my take on the broader question is that the key issue is how we wish to interop with legacy SIP/PSTN-type stuff. If we want it to be possible to interop without media gatewaying, then the large amount of non-SRTP gear means that as a practical matter one must support RTP. SDES is almost an afterthought in this scenario, in that it would allow you to interop wit= h SRTP with some unknown but probably relatively small fraction of the installed base. If you don't care about interop without media gatewaying, then there is no reason to do anything other than SRTP and I would argue no need to do anything other than DTLS, because there's no backward-compatibility issue. -Ekr From bernard_aboba@hotmail.com Wed Jan 11 13:46:28 2012 Return-Path: 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 899CC21F8566 for ; Wed, 11 Jan 2012 13:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=0.311, 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 CNSvJp9Fo9i7 for ; Wed, 11 Jan 2012 13:46:27 -0800 (PST) Received: from blu0-omc4-s27.blu0.hotmail.com (blu0-omc4-s27.blu0.hotmail.com [65.55.111.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1180221F865D for ; Wed, 11 Jan 2012 13:46:25 -0800 (PST) Received: from BLU152-W52 ([65.55.111.136]) by blu0-omc4-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 13:46:26 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b494d475-17fd-421e-8d47-e5bae6a403f1_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 11 Jan 2012 13:46:25 -0800 Importance: Normal In-Reply-To: <4F0DFD0B.2000009@jesup.org> References: , , , , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 21:46:26.0056 (UTC) FILETIME=[77D7F080:01CCD0AA] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 21:46:28 -0000 --_b494d475-17fd-421e-8d47-e5bae6a403f1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Randall said: > The reason (as I've mentioned at times) is that SDES means we expose the= =20 > media to the JS app and to the website=2C neither of which we've agreed t= o=20 > trust. All the discussion of blocking access to decrypted media from=20 > the JS app is moot if it has the keys. >=20 > If we use SDES=2C we're effectively trusting the JS app (and website) to = a=20 > very large extent. (Not to turn on the camera/mic=2C but with the=20 > contents of all conversations.) It also means bid-down to SDES is=20 > trivial. I'm not sure what this would mean to identity validation via=20 > BrowserID or others (ekr?)=3B that might survive this=2C but it means med= ia=20 > could be decrypted in realtime or later if anyone has copies of the=20 > packets and can get the key from the app/website. [BA] While I agree with your assessment of the security implications of not supporting end-to-end key management=2C I'm concerned about the practicalit= y of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0.=20 The SIPIt reports note progress on SDES implementation=2C but DTLS/SRTP not so much=2C and integrating DTLS/SRTP within RTCWEB would require more work beyond what is available in SIP DTLS/SRTP implementations today.=20 As a result=2C I am more inclined toward Justin's proposal for RTCWEB v1.0 (assuming that the questions are answered).=20 My view is that Justin's approach will maximize the potential for initial RTCWEB implementations to interoperate=2C whereas a mandate for DTLS/SRTP with no SDES support is very likely to result in initial interoperability p= roblems which could fester for a long time. IMHO=2C an interoperable RTCWEB v1.0 should be our highest priority=2C even if it doesn't have all the features = we would want for v2.0 and beyond. This also goes for some of the more advanced features described in the RTP draft=2C by the way. Perfect is the enemy of the good.=20 >From the description in the Security draft=2C it is not clear to me whether= the RTCWEB DTLS/SRTP proposal will necessarily interoperate with SIP=20 implementations of DTLS/SRTP. While the proposals have elements in common (e.g. DTLS/SRTP itself=2C fingerprinting=2C etc.) SIP DTLS/SRTP implementations cannot be expected to implement BrowserId=2C and=20 RTCWEB DTLS/SRTP implementations may not support RFC 4474.=20 = --_b494d475-17fd-421e-8d47-e5bae6a403f1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Randall said:

>=3B The reason (as I've mentioned at times) is that= SDES means we expose the
>=3B media to the JS app and to the we= bsite=2C neither of which we've agreed to
>=3B trust. All the discus= sion of blocking access to decrypted media from
>=3B the JS app is mo= ot if it has the keys.
>=3B
>=3B If we use SDES=2C we're effecti= vely trusting the JS app (and website) to a
>=3B very large extent. = (Not to turn on the camera/mic=2C but with the
>=3B contents of all c= onversations.) It also means bid-down to SDES is
>=3B trivial. I'm = not sure what this would mean to identity validation via
>=3B Browser= ID or others (ekr?)=3B that might survive this=2C but it means media
&g= t=3B could be decrypted in realtime or later if anyone has copies of the >=3B packets and can get the key from the app/website.

[BA] Whil= e I agree with your assessment of the security implications of not
suppo= rting end-to-end key management=2C I'm concerned about the practicality
= of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0.
The SIP= It reports note progress on SDES implementation=2C but DTLS/SRTP
not so = much=2C and integrating DTLS/SRTP within RTCWEB would require more
work = beyond what is available in SIP DTLS/SRTP implementations today.
As a r= esult=2C I am more inclined toward Justin's proposal for RTCWEB v1.0
(as= suming that the questions are answered).

My view is that Justin's a= pproach will maximize the potential for initial
RTCWEB implementations t= o interoperate=2C whereas a mandate for DTLS/SRTP
with no SDES support i= s very likely to result in initial interoperability problems
which could= fester for a long time. =3B IMHO=2C an interoperable RTCWEB v1.0
sh= ould be our highest priority=2C even if it doesn't have all the features we=
would want for v2.0 and beyond. =3B This also goes for some of the = more
advanced features described in the RTP draft=2C by the way. =3B= Perfect is
the enemy of the good.

From the description in the S= ecurity draft=2C it is not clear to me whether the
RTCWEB DTLS/SRTP prop= osal will necessarily interoperate with SIP
implementations of DTLS/SRT= P.  =3B While the proposals have elements
in common (e.g. DTLS/SRTP = itself=2C fingerprinting=2C etc.) SIP DTLS/SRTP
implementations cannot b= e expected to implement BrowserId=2C and
RTCWEB DTLS/SRTP implementatio= ns may not support RFC 4474.
= --_b494d475-17fd-421e-8d47-e5bae6a403f1_-- From bernard_aboba@hotmail.com Wed Jan 11 13:56:43 2012 Return-Path: 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 55E9C1F0C3E for ; Wed, 11 Jan 2012 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.297, 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 5JLcbAw+PZ6u for ; Wed, 11 Jan 2012 13:56:42 -0800 (PST) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A01F0C38 for ; Wed, 11 Jan 2012 13:56:42 -0800 (PST) Received: from BLU152-W47 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 13:56:42 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ce96f09c-fd6f-4398-9235-3574aca9e2a0_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Wed, 11 Jan 2012 13:56:41 -0800 Importance: Normal In-Reply-To: References: , , , , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 21:56:42.0190 (UTC) FILETIME=[E71686E0:01CCD0AB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 21:56:43 -0000 --_ce96f09c-fd6f-4398-9235-3574aca9e2a0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable EKR said: > FWIW=2C my take on the broader question is that the key issue is how we w= ish > to interop with legacy SIP/PSTN-type stuff. If we want it to be possible = to > interop without media gatewaying=2C then the large amount of non-SRTP gea= r > means that as a practical matter one must support RTP. SDES is almost > an afterthought in this scenario=2C in that it would allow you to interop= with > SRTP with some unknown but probably relatively small fraction of the > installed base. [BA] Quite a few PSTN gateways support SRTP/SDES=2C including very inexpens= ive ones (e.g. $<100).=20 As was mentioned=2C there has been considerable movement on SRTP/SDES imple= mentation recently as the SIPIt reports show.=20 So I don't think that a desire to support legacy interop necessarily implie= s a requirement for RTP support. I would say that DTLS/SRTP support is an issue though. Prospects for suppo= rt of SIP DTLS/SRTP within PSTN gateways are not good=2C let alone an RTCWEB variant. =20 > If you don't care about interop without media gatewaying=2C then there is= no > reason to do anything other than SRTP and I would argue no need to do > anything other than DTLS=2C because there's no backward-compatibility > issue. [BA] As noted above=2C I don't think that legacy interop implies support fo= r RTP other than for debugging.=20 However=2C I would agree that legacy interop does imply the need to impleme= nt (and offer) SDES=2C albeit perhaps as a fallback (e.g. if DTLS/SRTP is supported=2C this will always b= e negotiated). =20 = --_ce96f09c-fd6f-4398-9235-3574aca9e2a0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
EKR said:

>=3B FWIW=2C my take on the broader question is tha= t the key issue is how we wish
>=3B to interop with legacy SIP/PSTN-ty= pe stuff. If we want it to be possible to
>=3B interop without media g= atewaying=2C then the large amount of non-SRTP gear
>=3B means that as= a practical matter one must support RTP. SDES is almost
>=3B an after= thought in this scenario=2C in that it would allow you to interop with
&= gt=3B SRTP with some unknown but probably relatively small fraction of the<= br>>=3B installed base.

[BA] Quite a few PSTN gateways support SRT= P/SDES=2C including very inexpensive ones (e.g. $<=3B100).
As was men= tioned=2C there has been considerable movement on SRTP/SDES implementation = recently as the SIPIt reports show.
So I don't think that a desire to s= upport legacy interop necessarily implies a requirement for RTP support.
I would say that DTLS/SRTP support is an issue though. =3B Prospec= ts for support of SIP DTLS/SRTP within PSTN gateways
are not good=2C let= alone an RTCWEB variant. =3B

>=3B If you don't care about in= terop without media gatewaying=2C then there is no
>=3B reason to do a= nything other than SRTP and I would argue no need to do
>=3B anything = other than DTLS=2C because there's no backward-compatibility
>=3B issu= e.

[BA] As noted above=2C I don't think that legacy interop implies = support for RTP other than for debugging.
However=2C I would agree that= legacy interop does imply the need to implement (and offer) SDES=2C albeit=
perhaps as a fallback (e.g. if DTLS/SRTP is supported=2C this will alwa= ys be negotiated). =3B
= --_ce96f09c-fd6f-4398-9235-3574aca9e2a0_-- From ekr@rtfm.com Wed Jan 11 14:05:27 2012 Return-Path: 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 3053221F8674 for ; Wed, 11 Jan 2012 14:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 XopNwHCI3WOi for ; Wed, 11 Jan 2012 14:05:26 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3321F8642 for ; Wed, 11 Jan 2012 14:05:26 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1037102vcb.31 for ; Wed, 11 Jan 2012 14:05:26 -0800 (PST) Received: by 10.52.94.208 with SMTP id de16mr648398vdb.6.1326319526086; Wed, 11 Jan 2012 14:05:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Wed, 11 Jan 2012 14:04:45 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> From: Eric Rescorla Date: Wed, 11 Jan 2012 14:04:45 -0800 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 22:05:27 -0000 On Wed, Jan 11, 2012 at 1:56 PM, Bernard Aboba wrote: > EKR said: > >> FWIW, my take on the broader question is that the key issue is how we wi= sh >> to interop with legacy SIP/PSTN-type stuff. If we want it to be possible >> to >> interop without media gatewaying, then the large amount of non-SRTP gear >> means that as a practical matter one must support RTP. SDES is almost >> an afterthought in this scenario, in that it would allow you to interop >> with >> SRTP with some unknown but probably relatively small fraction of the >> installed base. > > [BA] Quite a few PSTN gateways support SRTP/SDES, including very inexpens= ive > ones (e.g. $<100). > As was mentioned, there has been considerable movement on SRTP/SDES > implementation recently as the SIPIt reports show. > So I don't think that a desire to support legacy interop necessarily impl= ies > a requirement for RTP support. > > I would say that DTLS/SRTP support is an issue though.=A0 Prospects for > support of SIP DTLS/SRTP within PSTN gateways > are not good, let alone an RTCWEB variant. OK. I'm not sufficiently informed on the level of support for SDES in the gateway environment. If it's that popular, then great; we can replace "RTP" in my statement above with SRTP/SDES. Best, -Ekr From roman@telurix.com Wed Jan 11 14:50:17 2012 Return-Path: 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 ABB2D21F8587 for ; Wed, 11 Jan 2012 14:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qxPcjvoApexB for ; Wed, 11 Jan 2012 14:50:17 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2A21F857F for ; Wed, 11 Jan 2012 14:50:16 -0800 (PST) Received: by iaae16 with SMTP id e16so1560318iaa.31 for ; Wed, 11 Jan 2012 14:50:16 -0800 (PST) Received: by 10.50.180.233 with SMTP id dr9mr8734001igc.11.1326322216638; Wed, 11 Jan 2012 14:50:16 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id py9sm5126323igc.2.2012.01.11.14.50.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 14:50:15 -0800 (PST) Received: by dajz8 with SMTP id z8so941723daj.31 for ; Wed, 11 Jan 2012 14:50:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.115.195 with SMTP id jq3mr3100925pbb.34.1326322214059; Wed, 11 Jan 2012 14:50:14 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 11 Jan 2012 14:50:13 -0800 (PST) In-Reply-To: <4F0DFD0B.2000009@jesup.org> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> Date: Wed, 11 Jan 2012 17:50:13 -0500 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=047d7b15a3896d3f0904b6487434 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 22:50:17 -0000 --047d7b15a3896d3f0904b6487434 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup wrote: > > I'd like to explore the possibility of making sure there's a workable > DTLS-SRTP implementation openly available, and locking WebRTC down to that > only. > > I should note that while libsrtp 1.4.2 (last official release) doesn't > have DTLS-SRTP support, there are DTLS-SRTP support functions and test code > in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP > via a modified OpenSSL. So, I'm not sure the barrier is huge given DTLS > support already. > > Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP? The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support). As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this? Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made. How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation? _____________ Roman Shpount --047d7b15a3896d3f0904b6487434 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <= span dir=3D"ltr"><randell-ietf= @jesup.org> wrote:

I'd like to explore the possibility of making sure there's a workab= le DTLS-SRTP implementation openly available, and locking WebRTC down to th= at only.

I should note that while libsrtp 1.4.2 (last official release) doesn't = have DTLS-SRTP support, there are DTLS-SRTP support functions and test code= in the project's CVS since ~2006, and resiprocate/recon supports DTLS-= SRTP via a modified OpenSSL. =A0So, I'm not sure the barrier is huge gi= ven DTLS support already.


Can you name a single soft-phone, hard-phone, SBC= , or gateway that currently supports DTLS-SRTP?

The reason I am ask= ing is libsrtp, despite being widely used, is extremely buggy (last officia= l release for instance crashes with GPF), and does not even provide full DE= S-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody pr= ovide an indication on how widely they are used? I know that OpenSSL suppor= ted DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be inter= esting to hear from SBC implementers before decision is made.

How ma= ny additional round trips does DTLS require for connection setup? Are we pl= anning to support certificate validation?
_____________
Roman Shpount
--047d7b15a3896d3f0904b6487434-- From randell-ietf@jesup.org Wed Jan 11 14:51:45 2012 Return-Path: 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 E0A6721F8593 for ; Wed, 11 Jan 2012 14:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] 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 GI2J-ugWPewV for ; Wed, 11 Jan 2012 14:51:45 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBFB21F8592 for ; Wed, 11 Jan 2012 14:51:45 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rl71E-0002pn-ST for rtcweb@ietf.org; Wed, 11 Jan 2012 16:51:45 -0600 Message-ID: <4F0E125D.8000605@jesup.org> Date: Wed, 11 Jan 2012 17:51:09 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 22:51:46 -0000 On 1/11/2012 4:41 PM, Eric Rescorla wrote: > On Wed, Jan 11, 2012 at 1:20 PM, Randell Jesup wrote: >> I'd like to explore the possibility of making sure there's a workable >> DTLS-SRTP implementation openly available, and locking WebRTC down to that >> only. >> >> I should note that while libsrtp 1.4.2 (last official release) doesn't have >> DTLS-SRTP support, there are DTLS-SRTP support functions and test code in >> the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via >> a modified OpenSSL. So, I'm not sure the barrier is huge given DTLS support >> already. > > The situation is actually rather better than this: > > 1. OpenSSL 1.0.1 (currently in beta) has all the TLS-side support needed for > DTLS-SRTP. > 2. The new entry points in libsrtp, while helpful are just helper > functions. If you're willing to embed a bit of knowledge about key > construction > into the application, you should be able to use libsrtp 1.4.2. > (though I suspect > you actually don't want to. libjingle, for instance, recommends use of the > libsrtp CVS version). > 3. As you say, resip and recon have support for DTLS-SRTP, though you > likely won't > need it for WebRTC anyway, since that support is largely SIP-specific. > > So in terms of having a working implementation, the issue is primarily > integration into your WebRTC stack Great, all this sounds good. > FWIW, my take on the broader question is that the key issue is how we wish > to interop with legacy SIP/PSTN-type stuff. If we want it to be possible to > interop without media gatewaying, then the large amount of non-SRTP gear > means that as a practical matter one must support RTP. SDES is almost > an afterthought in this scenario, in that it would allow you to interop with > SRTP with some unknown but probably relatively small fraction of the > installed base. > > If you don't care about interop without media gatewaying, then there is no > reason to do anything other than SRTP and I would argue no need to do > anything other than DTLS, because there's no backward-compatibility > issue. I agree, and since I believe the answer is "no interop without a media gateway" (I've tried to figure a safe way, no luck unless you relax the requirements for consent and the like), then I come down on SRTP-mandatory, DTLS-SRTP strongly preferred to be mandatory unless there's an implementation roadblock. -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Wed Jan 11 15:03:31 2012 Return-Path: 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 ED24721F86E1 for ; Wed, 11 Jan 2012 15:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 JphxYgdYZfQX for ; Wed, 11 Jan 2012 15:03:31 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8C21F86D0 for ; Wed, 11 Jan 2012 15:03:31 -0800 (PST) Received: by iaae16 with SMTP id e16so1578918iaa.31 for ; Wed, 11 Jan 2012 15:03:31 -0800 (PST) Received: by 10.50.191.200 with SMTP id ha8mr956436igc.27.1326323010951; Wed, 11 Jan 2012 15:03:30 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id he16sm10122556ibb.9.2012.01.11.15.03.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 15:03:29 -0800 (PST) Received: by pbdd12 with SMTP id d12so1026096pbd.31 for ; Wed, 11 Jan 2012 15:03:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr3031461pbv.85.1326323008561; Wed, 11 Jan 2012 15:03:28 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 11 Jan 2012 15:03:28 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4F052B03.8090101@jesup.org> Date: Wed, 11 Jan 2012 18:03:28 -0500 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec54693e7c8634304b648a309 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:03:32 -0000 --bcaec54693e7c8634304b648a309 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 5, 2012 at 10:19 AM, Bernard Aboba wrote: > > [BA] That seems like a precipitous conclusion, given that we haven't even > come up with a set of requirements and evaluated existing protocols against > them. On the other hand, the security draft contains "modified" versions of > existing schemes (thrown in without WG consensus), so it's not like that is > defensible either. > > This is my point exactly. We mandate the use of certain protocols (DTLS-SRTP) without listing the application requirements. DTLS will come with a lot of code baggage and additional round-trip during code setup. It will not provide end-to-end security or identity validation (at least without something else added into a mix). _____________ Roman Shpount --bcaec54693e7c8634304b648a309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 5, 2012 at 10:19 A= M, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

[BA] That seems like a precipitous conclusion, given that we haven't ev= en come up with a set of requirements and evaluated existing protocols agai= nst them. On the other hand, the security draft contains "modified&quo= t; versions of existing schemes (thrown in without WG consensus), so it'= ;s not like that is defensible either.


This is my point exactly. We mandate the use of c= ertain protocols (DTLS-SRTP) without listing the application requirements. = DTLS will come with a lot of code baggage and additional round-trip during = code setup. It will not provide end-to-end security or identity validation = (at least without something else added into a mix).
_____________
Roman Shpount

--bcaec54693e7c8634304b648a309-- From bernard_aboba@hotmail.com Wed Jan 11 15:07:57 2012 Return-Path: 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 4F9E021F86E1 for ; Wed, 11 Jan 2012 15:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.284, 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 8kM837gTkywq for ; Wed, 11 Jan 2012 15:07:56 -0800 (PST) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by ietfa.amsl.com (Postfix) with ESMTP id 554C421F863C for ; Wed, 11 Jan 2012 15:07:55 -0800 (PST) Received: from BLU152-W62 ([65.55.116.7]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 15:07:54 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ae02beed-4598-4a98-b1d3-6e5047b1c382_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 11 Jan 2012 15:07:54 -0800 Importance: Normal In-Reply-To: References: , , , , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jan 2012 23:07:54.0857 (UTC) FILETIME=[D9CBC590:01CCD0B5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:07:57 -0000 --_ae02beed-4598-4a98-b1d3-6e5047b1c382_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Romain said: "Can you name a single soft-phone=2C hard-phone=2C SBC=2C or gateway that c= urrently supports DTLS-SRTP? " [BA] Yes=2C I can name a single implementation shipping in commercial produ= cts :) However=2C for ZRTP=2C I believe there are multiple (independent?) = implementations. =20 Romain also said: "The reason I am asking is libsrtp=2C despite being widely used=2C is extre= mely buggy (last official release for instance crashes with GPF)=2C and doe= s not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 supp= ort). As far as DTLS (non-SRTP) implementations are concerned=2C can anybody prov= ide an indication on how widely they are used? I know that OpenSSL supporte= d DTLS for a while=2C but what commonly used software is using this?" [BA] DTLS is not supported within Windows 7 or Windows Phone 7.5. Overall= =2C I would say that DTLS is not widely used at the moment=2C though I do t= hink it's fair to say that interest is increasing.=20 Finally=2C Romain said: "Also=2C what would be the impact of adding DTLS to SBC? It would be intere= sting to hear from SBC implementers before decision is made. How many additional round trips does DTLS require for connection setup? Are= we planning to support certificate validation?" [BA] By "certificate validation" do you mean PKI support? Or are we talkin= g about something along the lines of what is in SIP DTLS/SRTP or the RTCWEB= security draft Appendix (e.g. support for self-signed certs and fingerprin= t validation)?=20 = --_ae02beed-4598-4a98-b1d3-6e5047b1c382_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Romain said:

"Can you na= me a single soft-phone=2C hard-phone=2C SBC=2C or gateway that currently su= pports DTLS-SRTP? "

[BA] Yes=2C I can name a single implementation s= hipping in commercial products :) =3B However=2C for ZRTP=2C I believe = there are multiple (independent?) implementations. =3B

Romain a= lso said:

"The reason I am asking is libsrtp=2C despite being widely= used=2C is extremely buggy (last official release for instance crashes wit= h GPF)=2C and does not even provide full DES-SRTP implementation (no F8_128= _HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned=2C can anybody = provide an indication on how widely they are used? I know that OpenSSL supp= orted DTLS for a while=2C but what commonly used software is using this?"
[BA] DTLS is not supported within Windows 7 or Windows Phone 7.5.&nbs= p=3B Overall=2C I would say that DTLS is not widely used at the moment=2C t= hough I do think it's fair to say that interest is increasing.

Finally=2C Romain said:

"Also=2C what would be the impact of adding = DTLS to SBC? It would be interesting to hear from SBC implementers before d= ecision is made.

How many additional round trips does DTLS require f= or connection setup? Are we planning to support certificate validation?"
[BA] By "certificate validation" do you mean PKI support? =3B Or a= re we talking about something along the lines of what is in SIP DTLS/SRTP o= r the RTCWEB security draft Appendix (e.g. support for self-signed certs an= d fingerprint validation)?
= --_ae02beed-4598-4a98-b1d3-6e5047b1c382_-- From roman@telurix.com Wed Jan 11 15:10:40 2012 Return-Path: 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 7486421F8707 for ; Wed, 11 Jan 2012 15:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Rs501uknugW2 for ; Wed, 11 Jan 2012 15:10:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3421F86F4 for ; Wed, 11 Jan 2012 15:10:23 -0800 (PST) Received: by iaae16 with SMTP id e16so1586093iaa.31 for ; Wed, 11 Jan 2012 15:10:11 -0800 (PST) Received: by 10.42.153.6 with SMTP id k6mr1038371icw.30.1326323411885; Wed, 11 Jan 2012 15:10:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id rc7sm11412476igb.0.2012.01.11.15.10.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 15:10:11 -0800 (PST) Received: by pbdd12 with SMTP id d12so1029694pbd.31 for ; Wed, 11 Jan 2012 15:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr3070258pbv.85.1326323408419; Wed, 11 Jan 2012 15:10:08 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 11 Jan 2012 15:10:08 -0800 (PST) In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> Date: Wed, 11 Jan 2012 18:10:08 -0500 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec54693e79dbc4f04b648bba2 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:10:40 -0000 --bcaec54693e79dbc4f04b648bba2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 11, 2012 at 6:07 PM, Bernard Aboba wrote: > [BA] By "certificate validation" do you mean PKI support? Or are we > talking about something along the lines of what is in SIP DTLS/SRTP or the > RTCWEB security draft Appendix (e.g. support for self-signed certs and > fingerprint validation)? > Yes, what I am talking about is any type of remote identity validation and/or remote fingerprint validation. _____________ Roman Shpount --bcaec54693e79dbc4f04b648bba2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 11, 2012 at 6:= 07 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
[BA] By "certificate validation" do you mean PKI suppor= t?=A0 Or are we talking about something along the lines of what is in SIP D= TLS/SRTP or the RTCWEB security draft Appendix (e.g. support for self-signe= d certs and fingerprint validation)?

Yes, what I am talking about is any type of remote i= dentity validation and/or remote fingerprint validation.
_____________Roman Shpount

--bcaec54693e79dbc4f04b648bba2-- From juberti@google.com Wed Jan 11 15:14:29 2012 Return-Path: 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 8B7A921F8707 for ; Wed, 11 Jan 2012 15:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 FSzNWMjfpGcZ for ; Wed, 11 Jan 2012 15:14:28 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9000021F858F for ; Wed, 11 Jan 2012 15:14:28 -0800 (PST) Received: by obcuz6 with SMTP id uz6so1843028obc.31 for ; Wed, 11 Jan 2012 15:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=nylYbd/4cNzgNz24cen/3n6CkjD2oYoVALhOPzCgaHQ=; b=IlrkbaP2nUra7ZClXSgB7FfU/4htLTXb5hgLybb2Xrxbe2pFpzL7qVYzQHE/tIqkFH B5ctNCCfi0kj076ERv3vNXCNgekcwW80uHNzbgpZAaqJTvmzDpj/mXTg6rFTjqqRTuQi dI4KHNXriuv7CEGEnsYAGLf4LPZzZmuTc+UTM= Received: by 10.50.104.163 with SMTP id gf3mr4869064igb.26.1326323668063; Wed, 11 Jan 2012 15:14:28 -0800 (PST) Received: by 10.50.104.163 with SMTP id gf3mr4868990igb.26.1326323666279; Wed, 11 Jan 2012 15:14:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.196.93 with HTTP; Wed, 11 Jan 2012 15:14:04 -0800 (PST) In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> From: Justin Uberti Date: Wed, 11 Jan 2012 18:14:04 -0500 Message-ID: To: Bernard Aboba X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f2343dffc5b9e04b648ca63 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:14:29 -0000 --e89a8f2343dffc5b9e04b648ca63 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2012 at 4:46 PM, Bernard Aboba wrote: > Randall said: > > > The reason (as I've mentioned at times) is that SDES means we expose the > > media to the JS app and to the website, neither of which we've agreed to > > trust. All the discussion of blocking access to decrypted media from > > the JS app is moot if it has the keys. > > > > If we use SDES, we're effectively trusting the JS app (and website) to a > > very large extent. (Not to turn on the camera/mic, but with the > > contents of all conversations.) It also means bid-down to SDES is > > trivial. I'm not sure what this would mean to identity validation via > > BrowserID or others (ekr?); that might survive this, but it means media > > could be decrypted in realtime or later if anyone has copies of the > > packets and can get the key from the app/website. > > [BA] While I agree with your assessment of the security implications of not > supporting end-to-end key management, I'm concerned about the practicality > of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0. > The SIPIt reports note progress on SDES implementation, but DTLS/SRTP > not so much, and integrating DTLS/SRTP within RTCWEB would require more > work beyond what is available in SIP DTLS/SRTP implementations today. > As a result, I am more inclined toward Justin's proposal for RTCWEB v1.0 > (assuming that the questions are answered). > > My view is that Justin's approach will maximize the potential for initial > RTCWEB implementations to interoperate, whereas a mandate for DTLS/SRTP > with no SDES support is very likely to result in initial interoperability > problems > which could fester for a long time. IMHO, an interoperable RTCWEB v1.0 > should be our highest priority, even if it doesn't have all the features we > would want for v2.0 and beyond. This also goes for some of the more > advanced features described in the RTP draft, by the way. Perfect is > the enemy of the good. > This is exactly my thinking. We are working very hard at getting DTLS/SRTP up and running, but I am all too familiar with betting the farm on something that is all-new. > > From the description in the Security draft, it is not clear to me whether > the > RTCWEB DTLS/SRTP proposal will necessarily interoperate with SIP > implementations of DTLS/SRTP. While the proposals have elements > in common (e.g. DTLS/SRTP itself, fingerprinting, etc.) SIP DTLS/SRTP > implementations cannot be expected to implement BrowserId, and > RTCWEB DTLS/SRTP implementations may not support RFC 4474. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f2343dffc5b9e04b648ca63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 11, 2012 at 4:46 PM, Bernard= Aboba <b= ernard_aboba@hotmail.com> wrote:
Randall said:

> The reason (as I've mentioned at times) is th= at SDES means we expose the
> media to = the JS app and to the website, neither of which we've agreed to
> trust. All the discussion of blocking access to decrypted media from =
> the JS app is moot if it has the keys.
>
> If we use = SDES, we're effectively trusting the JS app (and website) to a
> very large extent. (Not to turn on the camera/mic, but with the
&= gt; contents of all conversations.) It also means bid-down to SDES is
= > trivial. I'm not sure what this would mean to identity validation= via
> BrowserID or others (ekr?); that might survive this, but it means medi= a
> could be decrypted in realtime or later if anyone has copies of = the
> packets and can get the key from the app/website.

[BA] While I agree with your assessment of the security implications of not=
supporting end-to-end key management, I'm concerned about the pract= icality
of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0. =
The SIPIt reports note progress on SDES implementation, but DTLS/SRTP
no= t so much, and integrating DTLS/SRTP within RTCWEB would require more
wo= rk beyond what is available in SIP DTLS/SRTP implementations today.
As a result, I am more inclined toward Justin's proposal for RTCWEB v1.= 0
(assuming that the questions are answered).

My view is that Ju= stin's approach will maximize the potential for initial
RTCWEB imple= mentations to interoperate, whereas a mandate for DTLS/SRTP
with no SDES support is very likely to result in initial interoperability p= roblems
which could fester for a long time.=C2=A0 IMHO, an interoperable= RTCWEB v1.0
should be our highest priority, even if it doesn't have= all the features we
would want for v2.0 and beyond.=C2=A0 This also goes for some of the moreadvanced features described in the RTP draft, by the way.=C2=A0 Perfect i= s
the enemy of the good.

This is exactly my thinking. We are working very hard at gettin= g DTLS/SRTP up and running, but I am all too familiar with betting the farm= on something that is all-new.
=C2=A0

From the description in the Security draft, = it is not clear to me whether the
RTCWEB DTLS/SRTP proposal will necessa= rily interoperate with SIP
implementations of DTLS/SRTP. =C2=A0 While t= he proposals have elements
in common (e.g. DTLS/SRTP itself, fingerprinting, etc.) SIP DTLS/SRTP
im= plementations cannot be expected to implement BrowserId, and
RTCWEB DTL= S/SRTP implementations may not support RFC 4474.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--e89a8f2343dffc5b9e04b648ca63-- From juberti@google.com Wed Jan 11 15:18:15 2012 Return-Path: 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 E177F11E8074 for ; Wed, 11 Jan 2012 15:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Rog6Ox61dbfp for ; Wed, 11 Jan 2012 15:18:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33BFF11E8071 for ; Wed, 11 Jan 2012 15:18:15 -0800 (PST) Received: by iaae16 with SMTP id e16so1594963iaa.31 for ; Wed, 11 Jan 2012 15:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=B/scdTHusfQgRRHr7Py1eMdUJgTfOfCMX+xgNhpdA6k=; b=SubiORjtsBxXud6rUqGJWTNAal2N9rJnriIw1qDC1yTfM6UEEuQoLTPOzEzJtvGmQm efA/jjRwF28cHih1y0PmLwtppS+Hy4oZJLlkeh1nugAqJdZ6wjQmVCctftt6w0MCs4WR gwMB9g6mnaXQMfd13VtuAjEq4cJ/FEFXHYJ6Q= Received: by 10.50.135.1 with SMTP id po1mr998482igb.26.1326323894913; Wed, 11 Jan 2012 15:18:14 -0800 (PST) Received: by 10.50.135.1 with SMTP id po1mr998469igb.26.1326323894810; Wed, 11 Jan 2012 15:18:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.196.93 with HTTP; Wed, 11 Jan 2012 15:17:52 -0800 (PST) In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> From: Justin Uberti Date: Wed, 11 Jan 2012 18:17:52 -0500 Message-ID: To: Roman Shpount X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f6432c29b78d004b648d899 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:18:16 -0000 --e89a8f6432c29b78d004b648d899 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount wrote: > On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup wrote: > >> >> I'd like to explore the possibility of making sure there's a workable >> DTLS-SRTP implementation openly available, and locking WebRTC down to that >> only. >> >> I should note that while libsrtp 1.4.2 (last official release) doesn't >> have DTLS-SRTP support, there are DTLS-SRTP support functions and test code >> in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP >> via a modified OpenSSL. So, I'm not sure the barrier is huge given DTLS >> support already. >> >> > Can you name a single soft-phone, hard-phone, SBC, or gateway that > currently supports DTLS-SRTP? > > The reason I am asking is libsrtp, despite being widely used, is extremely > buggy (last official release for instance crashes with GPF), and does not > even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support). > > As far as DTLS (non-SRTP) implementations are concerned, can anybody > provide an indication on how widely they are used? I know that OpenSSL > supported DTLS for a while, but what commonly used software is using this? > > Also, what would be the impact of adding DTLS to SBC? It would be > interesting to hear from SBC implementers before decision is made. > > How many additional round trips does DTLS require for connection setup? > Are we planning to support certificate validation? > When used with JSEP, DTLS should not require any additional roundtrips for connection setup, since DTLS can be brought up as part of transport establishment. In fact, connection setup should occur faster than when using SDES, since the keys can be negotiated before the answer arrives. This prevents clipping of the answerer's media from occurring. --e89a8f6432c29b78d004b648d899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 11, 2012 at 5:50 PM, Roman S= hpount <roman@tel= urix.com> wrote:
On Wed, Jan 11, 2012 at 4:20 P= M, Randell Jesup <randell-ietf@jesup.org> wrote:

I'd like to explore the possibility of making sure there's a workab= le DTLS-SRTP implementation openly available, and locking WebRTC down to th= at only.

I should note that while libsrtp 1.4.2 (last official release) doesn't = have DTLS-SRTP support, there are DTLS-SRTP support functions and test code= in the project's CVS since ~2006, and resiprocate/recon supports DTLS-= SRTP via a modified OpenSSL. =C2=A0So, I'm not sure the barrier is huge= given DTLS support already.


Can you name a single soft-phone, hard-phon= e, SBC, or gateway that currently supports DTLS-SRTP?

The reason I = am asking is libsrtp, despite being widely used, is extremely buggy (last o= fficial release for instance crashes with GPF), and does not even provide f= ull DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody pr= ovide an indication on how widely they are used? I know that OpenSSL suppor= ted DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be inter= esting to hear from SBC implementers before decision is made.

How ma= ny additional round trips does DTLS require for connection setup? Are we pl= anning to support certificate validation?

When used with JSEP, DTLS shou= ld not require any additional roundtrips for connection setup, since DTLS c= an be brought up as part of transport establishment. In fact, connection se= tup should occur faster than when using SDES, since the keys can be negotia= ted before the answer arrives. This prevents clipping of the answerer's= media from occurring.
--e89a8f6432c29b78d004b648d899-- From roman@telurix.com Wed Jan 11 15:20:47 2012 Return-Path: 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 2A82321F8531 for ; Wed, 11 Jan 2012 15:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 vQkQf1bZ6bQh for ; Wed, 11 Jan 2012 15:20:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7247321F851A for ; Wed, 11 Jan 2012 15:20:46 -0800 (PST) Received: by ggnr5 with SMTP id r5so785436ggn.31 for ; Wed, 11 Jan 2012 15:20:46 -0800 (PST) Received: by 10.50.10.225 with SMTP id l1mr1096729igb.9.1326324045555; Wed, 11 Jan 2012 15:20:45 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id uc6sm5243166igb.4.2012.01.11.15.20.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jan 2012 15:20:44 -0800 (PST) Received: by pbdd12 with SMTP id d12so1035313pbd.31 for ; Wed, 11 Jan 2012 15:20:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.122.225 with SMTP id lv1mr3178714pbb.68.1326324043593; Wed, 11 Jan 2012 15:20:43 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 11 Jan 2012 15:20:43 -0800 (PST) In-Reply-To: References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> Date: Wed, 11 Jan 2012 18:20:43 -0500 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8f64650b79ba9804b648e110 Cc: "rtcweb@ietf.org\"" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:20:47 -0000 --e89a8f64650b79ba9804b648e110 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 11, 2012 at 2:52 PM, Justin Uberti wrote: > To reply to the OP: The consensus that I see having emerged from this > discussion is that SRTP should be mandatory to use, with a provision for > NULL ciphers for debugging. This provision is only exposed through > developer settings, and can never be invoked from the web app; for all > practical purposes, applications will have to use SRTP > > I would still argue (even though I am obviously a minority here), that plain RTP should be supported and this support should be accessible via JS API with no web server configuration changes. The reasons are (apart from debugging that will be addressed by NULL cypher), are overall symmetry with HTTP vs HTTPS. As I have mentioned before, there are environments where completely unsecured communication applications should be delivered, such as some countries, army, prisons and such. I understand that you want to disregard these people but they are internet users as well. Please keep in mind that I am not arguing for a back-door to intercept secure communications (against IETF policy) or to provide a way for secure communication to fall back to unsecured. All I am looking for is an ability to provide unsecured service if I, as a service provider, decide to do so. _____________ Roman Shpount --e89a8f64650b79ba9804b648e110 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 11, 2012 at 2:52 P= M, Justin Uberti <juberti@google.com> wrote:
On Wed, Jan 11, 2012 at 6:17 P= M, Justin Uberti <juberti@google.com> wrote:

Should we provide some sort of best practice documen= t on DTLS-SRTP implementation? Should we mandate a minimal set of DTLS feat= ures that should be supported to enable WebRTC interop?
_____________ Roman Shpount


--e89a8fb2091208dc0b04b648e898-- From ekr@rtfm.com Wed Jan 11 15:25:57 2012 Return-Path: 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 3A83A21F854A for ; Wed, 11 Jan 2012 15:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 Byzz23BK0yL5 for ; Wed, 11 Jan 2012 15:25:56 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB10F21F8543 for ; Wed, 11 Jan 2012 15:25:56 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so1060267vbb.31 for ; Wed, 11 Jan 2012 15:25:56 -0800 (PST) Received: by 10.52.29.228 with SMTP id n4mr656586vdh.57.1326324356208; Wed, 11 Jan 2012 15:25:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Wed, 11 Jan 2012 15:25:14 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> From: Eric Rescorla Date: Wed, 11 Jan 2012 15:25:14 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Wed, 11 Jan 2012 23:25:57 -0000 On Wed, Jan 11, 2012 at 3:22 PM, Roman Shpount wrote: > > On Wed, Jan 11, 2012 at 6:17 PM, Justin Uberti wrote: >> >> When used with JSEP, DTLS should not require any additional roundtrips for >> connection setup, since DTLS can be brought up as part of transport >> establishment. In fact, connection setup should occur faster than when using >> SDES, since the keys can be negotiated before the answer arrives. This >> prevents clipping of the answerer's media from occurring. > > > Should we provide some sort of best practice document on DTLS-SRTP > implementation? Should we mandate a minimal set of DTLS features that should > be supported to enable WebRTC interop? The requirements in RFC 5246 (DTLS inherits these) and 3711 should be sufficient to ensure interop. If they're not, I don't see a problem with adding some more. -Ekr From pravindran@sonusnet.com Wed Jan 11 16:09:35 2012 Return-Path: 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 F196D11E808D for ; Wed, 11 Jan 2012 16:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PL8L-1hiR64G for ; Wed, 11 Jan 2012 16:09:33 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2282421F84F0 for ; Wed, 11 Jan 2012 16:09:33 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0C0ACcM019337; Wed, 11 Jan 2012 19:10:12 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 19:09:27 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 05:40:21 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 05:40:20 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw//+vH4CAAHXqEP//r34AgAB980CAABSNgIAAoZsg Date: Thu, 12 Jan 2012 00:10:18 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD05E7@inba-mail02.sonusnet.com> References: <4F01A790.4060704@alvestrand.no> <4F02A061.60905@jesup.org> <4F035DD5.3050305@jesup.org> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD05E7inbamail02sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 00:10:21.0006 (UTC) FILETIME=[92ACBEE0:01CCD0BE] Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 00:09:35 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD05E7inbamail02sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluICYgYWxsLA0KDQpBcyBwZXIgbXkgb2ZmbGluZSBkaXNjdXNzaW9uIGluIElFVEYtODIs IGxvdCBvZiBmb2xrcyBoYXMgdHJvdWJsZSBpbiBmb2xsb3dpbmcgcnRjd2ViIGFsaWFzIGJlY2F1 c2Ugb2YgdGhlIG1hc3NpdmUgZS1tYWlsIHBlciBkYXkuIEkgd2lzaCB0aGUgY29uc2Vuc3VzIG9m IOKAnFNSVFAgaXMgbWFuZGF0b3J5IHRvIHVzZSBvciBtYW5kYXRvcnkgdG8gaW1wbGVtZW504oCd IGhhcyB0byBiZSBwb3N0cG9uZWQgYXQgbGVhc3QgZm9yIGludGVyaW0gUlRDV2ViIGZhY2UtdG8t ZmFjZSBtZWV0aW5nIG9uIDFzdCBGZWIuDQoNCkkgc2VlIGxvdCBvZiBlLW1haWwgY2hhaW4gYWJv dXQga2V5IG1hbmFnZW1lbnQgaW4gdGhlIGFsaWFzLiBJ4oCZbGwgcmVwbHkgaW4gb25lIG9mIHRo ZW0gZm9yIGtleSBtYW5hZ2VtZW50Lg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBKdXN0aW4g VWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVh cnkgMTIsIDIwMTIgMToyMiBBTQ0KVG86IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0KQ2M6IEnD sWFraSBCYXogQ2FzdGlsbG87IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJd IFNSVFAgbm90IG1hbmRhdG9yeS10by11c2UNCg0KVG8gcmVwbHkgdG8gdGhlIE9QOiBUaGUgY29u c2Vuc3VzIHRoYXQgSSBzZWUgaGF2aW5nIGVtZXJnZWQgZnJvbSB0aGlzIGRpc2N1c3Npb24gaXMg dGhhdCBTUlRQIHNob3VsZCBiZSBtYW5kYXRvcnkgdG8gdXNlLCB3aXRoIGEgcHJvdmlzaW9uIGZv ciBOVUxMIGNpcGhlcnMgZm9yIGRlYnVnZ2luZy4gVGhpcyBwcm92aXNpb24gaXMgb25seSBleHBv c2VkIHRocm91Z2ggZGV2ZWxvcGVyIHNldHRpbmdzLCBhbmQgY2FuIG5ldmVyIGJlIGludm9rZWQg ZnJvbSB0aGUgd2ViIGFwcDsgZm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZXMsIGFwcGxpY2F0aW9u cyB3aWxsIGhhdmUgdG8gdXNlIFNSVFANCg0KQXMgZm9yIHRoZSBrZXkgbWFuYWdlbWVudCBtZWNo YW5pc20sIFNERVMgYW5kIERUTFMgd2lsbCBiZSBzdXBwb3J0ZWQ7IHdoaWxlIERUTFMgaXMgcHJl ZmVycmVkLCB0aGVyZSBhcmUgZmV3IERUTFMtU1JUUCBpbXBsZW1lbnRhdGlvbnMgaW4gZXhpc3Rl bmNlIGF0IHRoaXMgdGltZS4NCg0KQXMgZmFyIGFzIEkga25vdywgdGhpcyBpcyB3aGF0IHRoZSBt YWpvciBXZWJSVEMgaW1wbGVtZW50YXRpb25zIGFyZSBwbGFubmluZyB0byBkby4NCk9uIFdlZCwg SmFuIDExLCAyMDEyIGF0IDg6NDAgQU0sIFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmlu ZHJhbkBzb251c25ldC5jb208bWFpbHRvOnByYXZpbmRyYW5Ac29udXNuZXQuY29tPj4gd3JvdGU6 DQpIaSBJbmFraSwNCg0KSSB0aGluayB0aGF0IHdlIGFyZSBpbiB0aGUgc2FtZSBwYWdlIG9mIG5v dCB1c2luZyBwbGFpbiBSVFAgaW4NCmFpcnBvcnQgd2l0aCBXaUZpLiBJdCBpcyB0aGUgbWFpbiBy ZWFzb24gZm9yIGFza2luZyBTUlRQIGFzIGENCmRlZmF1bHQgbWVkaWEgcHJvdG9jb2wuIEFsc28s IHRoZSBwdWJsaWMgaW50ZXJuZXQgYXBwbGljYXRpb24gbGlrZQ0KR29vZ2xlIGhhbmdvdXQgc2hv dWxkIGJlIGJhc2VkIG9uIFNSVFAuIFNvLCBNb3N0IG9mIHRoZSBXZWJSVEMNCmFwcGxpY2F0aW9u IHdpbGwgYmFzZWQgb24gU1JUUCBidXQgc29tZSBvZiB0aGUgV2ViUlRDIGFwcGxpY2F0aW9uDQpw cmVmZXJzIHRvIFJUUCAoaW50cmFuZXQgc2l0ZSkgd2hpY2ggTVVTVCBOT1QgYmUgcmVzdHJpY3Rl ZCBieQ0KSUVURiBzdGFuZGFyZC4NCg0KVGhlIGRvdWJsZSBlbmNyeXB0aW9uIGF2b2lkYW5jZSBp cyB0aGUgbWF0dGVyIG9mIG9wdGltaXphdGlvbiBpbg0KbmV0d29yayBkZXNpZ24gYXMgZG91Ymxl IGVuY3J5cHRpb24gaW4gZW5kcG9pbnQgY2FsbHMgZm9yIGRvdWJsZQ0KZGVjcnlwdGlvbiBpbiB0 aGUgbmV0d29yayBmb3Igc29tZSBvZiB0aGUgc2VydmljZXMuIEkgYWdyZWUgdGhhdA0KaXQgbWF5 IG5vdCBiZSBwcm9ibGVtIGluIHNvbWUgb2YgdGhlIG5ldHdvcmsgYmVjYXVzZSBvZg0KdGhlIG5l dHdvcmsgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IG9yIG5ldHdvcmsgZW50aXR5IGlzIG5vdCBpbnZv bHZlZA0KKGJyb3dzZXItYnJvd3NlciBzY2VuYXJpbykgYnV0IHdlIGNhbid0IGdlbmVyYWxpemUg dGhpcy4gSW4gY2FzZSBpdCBpcw0KcG9zc2libGUsIERvdWJsZSBlbmNyeXB0aW9uIGhhcyB0byBi ZSBhdm9pZGVkIGFuZCBJRVRGIGhhcyB0bw0KcmVjb21tZW5kIGFjY29yZGluZ2x5Lg0KDQpQbGVh c2UgcmVhZCBpbmxpbmUgZm9yIG1vcmUgY29tbWVudHMuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21h aWx0bzppYmNAYWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pl0NCj5TZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMTEsIDIwMTIgNDozOCBQTQ0KPlRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0 aGkNCj5DYzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk7IFNwZW5jZXIgRGF3 a2luczsgQWxhbiBKb2huc3RvbjsNCj5CZXJuYXJkIEFib2JhOyBDdWxsZW4gSmVubmluZ3MgKGZs dWZmeSk7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KPlN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBTUlRQIG5vdCBtYW5kYXRvcnktdG8tdXNlDQo+DQo+MjAxMi8xLzExIFJh dmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5jb208bWFpbHRvOnBy YXZpbmRyYW5Ac29udXNuZXQuY29tPj46DQo+PiBIdW1hbiB1c2VyIHdobyAiUHJlc3MgdGhlICdB Y2NlcHQgdW5zZWN1cmUgY29tbXVuaWNhdGlvbicgYnV0dG9uIGFuZA0KPj4geW91IHdpbGwgd2lu IGEgY2FyICEhISIgd2lsbCBhbGxvdyBSVFAgcGx1Zy1pbiB0byBpbnN0YWxsIG9yIGNvbmZpZ3Vy ZQ0KPj4gYnJvd3NlciB0byB3aW4gdGhlIGNhci4gSXQgaXMgYXMgZ29vZCBhcyBzZW5kaW5nIHRo ZSBhaXIgdGlja2V0IG1vbmV5DQo+PiB0byB1bmtub3duIGNvdW50cnkga2luZyBiYXNlZCBvbiBz cGFtIG1haWwgaW4gc2VjdXJlZCAoaHR0cHMpIGUtbWFpbA0KPj4gYWNjZXNzIHVzZXIgZm9yIGdl dHRpbmcgbHVtcCBzdW0gbW9uZXkgZnJvbSBLaW5nIChzcGFtbWVyKS4NCj4NCj5SaWdodC4gTXkg cXVlc3Rpb24gaXM6IHdoeSB0byBhbGxvdyB0aGF0PyB3YXNuJ3QgYSBwcmltYXJ5IGFpbSBvZiBX ZWJSVEMNCj50byBhdm9pZCBzdWNoIGEgcmlzaz8NCj4NCjxwYXJ0aGE+IEkgZ3Vlc3MgdGhhdCBt eSBwb2ludCBkb2VzIG5vdCBjb21lIG91dCB3ZWxsLiBJJ20gc2F5aW5nIHRoYXQNCnVzZXIgd2hv IGFjY2VwdCB1bnNlY3VyZSBjb21tdW5pY2F0aW9uIGZvciBhIGNhciB3aWxsIGFsbG93IFJUUCBw bHVnLWluDQp0byBiZSBhZGRlZCBpbiB0aGUgYnJvd3NlciB3aGVyZWluIHNlY3VyaXR5IHdpbGwg YmUgY29tcHJvbWlzZWQgYW55d2F5DQphbmQgbm90IHJlbGF0ZWQgdG8gV2ViUlRDLiA8L3BhcnRo YT4NCg0KPg0KPj4gQWxzbywgcGxlYXNlIG5vdGUgdGhhdCBTUlRQLURUTFMgZG9lcyBub3QgcHJl dmVudCBXZWJSVEMgc2VydmVyIGZyb20NCj4+IGFjY2Vzc2luZyB0aGUgc2VjdXJlZCBXZWJSVEMg bWVkaWEgKGRhdGEpIGJ1dCBoZWxwcyB1c2VyIHRvIGlkZW50aWZ5DQo+PiB0aGF0IHRoZSBtZWRp YSBpcyBub3QgZW5kLXRvLWVuZC4gTXkgc3RhdGVtZW50IGlzIGJhc2VkIG9uIG15DQo+PiB1bmRl cnN0YW5kaW5nIG9mIFdlYlJUQyBzZWN1cml0eSBhcmNoaXRlY3R1cmUNCj4+DQo+PiBQYXJ0aGEo QnJvd3NlciArICBKUykgLS0tLS0tLS0tLVdlYlJUQ3NlcnZlci0tLS0tQnJvd3NlcisgSlMgKElu YWtpKQ0KPj4gICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgIC0tLS0oU1JUUCtEVExTKS0tLS0tV2ViUlRDIE1l ZGlhIHNlcnZlci0tLShTUlRQK0RUTFMpIC0tLS0tDQo+Pg0KPj4gSW4gdGhlIGFib3ZlIHRvcG9s b2d5LCB3ZWJzZXJ2ZXIgb3ducyBXZWJSVEMgbWVkaWEgc2VydmVyIGFzIHdlbGwuDQo+PiBXZWIg bWVkaWEgc2VydmVyIHRlcm1pbmF0ZXMgJiBvcmlnaW5hdGVzIHRoZSBtZWRpYS4gVGhlIGlkZW50 aXR5IGlzDQo+PiB0aGUgZGlmZmVyZW50aWF0aW5nIGZhY3Rvci4gRm9yIGV4YW1wbGUsIGlmIEkg c2VlIHRoZSBicm93c2VyIHdpbmRvdw0KPj4gd2l0aCBpZGVudGl0eSBpYmNAZ21haWwuY29tPG1h aWx0bzppYmNAZ21haWwuY29tPiBpbnN0ZWFkIG9mIGliY0BhbGlheC5uZXQ8bWFpbHRvOmliY0Bh bGlheC5uZXQ+LCB0aGVuIEkgaGF2ZSB0bw0KPj4gdW5kZXJzdGFuZCB0aGF0IGJyb3dzZXIgaXMg bm90IGVuZC10by1lbmQgYmVjYXVzZSBvZiBpZGVudGl0eS4NCj4NCj5XZWxsLCBJIGV4cGVjdCB0 aGF0IHRoZSB0eXBpY2FsbCBwaWN0dXJlIHdpbGwgbm90IGluY2x1ZGUgdGhlICJXZWJSVEMNCj5N ZWRpYSBTZXJ2ZXIiIChpdCBjb3VsZCBob3dldmVyKS4NCj4NCj4NCj4+IE15IGN1cnJlbnQgYXJn dW1lbnQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBQU1ROIGludGVyb3AuIEFGQUlLLA0KPj4gU1JU UC1EVExTIHN0YW5kYXJkaXphdGlvbiBpbiBXZWJSVEMgaXMgZ29vZCBmb3IgU0JDIDotKS4NCj4N Cj5PaywgYnV0IEknbSBub3QgdGFsa2luZyBhYm91dCB0aGF0LiBJJ20ganVzdCB3b25kZXJpbmcg d2h5IHRoZSBodW1hbg0KPnVzZXIgc2hvdWxkIGJlIGFibGUgdG8gInRydXN0IiBhIHdlYnNpdGUg YXNraW5nIHBlcm1pc3Npb24gZm9yDQo+dW50cnVzdGVkL2luc2VjdXJlIHBsYWluIFJUUC4gVGhp cyBpcyBub3QgYWJvdXQgaGF2aW5nIGEgbWVkaWEgc2VydmVyIG9yDQo+bm90Lg0KPg0KPkV4YW1w bGU6IEknbSBpbiBhbiBhaXJwb3J0IHdpdGggb3BlbiBXaUZpLiBJZiBJIGVzdGFibGlzaCBhIHBs YWluIFJUUA0KPmNvbW11bmljYXRpb24gYW55b25lIGluIHRoYXQgbmV0d29yayBjYW4gaW5zcGVj dCBpdC4gV2h5IHRvIGFsbG93IHRoYXQ/DQo8cGFydGhhPiBBZ3JlZWQuIFB1YmxpYyBpbnRlcm5l dCBXZWJSVEMgYXBwbGljYXRpb24gaGFzIHRvIGJlIGJhc2VkIG9uDQpTUlRQIDwvcGFydGhhPg0K DQo+DQo+SSByZXBlYXQgbXkgbWFpbiBhcmd1bWVudCBhZ2FpbnN0IGFsbG93aW5nIHBsYWluIFJU UDoNCj4NCj5UaGUgZG91YmxlIGVuY3J5cHRpb24gaXMgbm90IGEgcHJvYmxlbSBhdCBhbGwuIFRo ZSBhcHBsaWNhdGlvbiAodGhlDQo+YnJvd3NlcikgcGVyZm9ybXMgU1JUUCBlbmNyeXB0aW9uIChu byBwcm9ibGVtIGhlcmUhKSBhbmQgdGhlIFRDUC9JUA0KPnN0YWNrIGluIHRoZSBjb21wdXRlciBv ciBpbiB0aGUgcm91dGVyIHBlcmZvcm1zIG5ldHdvcmsgZW5jcnlwdGlvbi4NCj5XaGljaCBpcyB0 aGUgcHJvYmxlbT8/PyBUaGVyZSBpcyBubyBwcm9ibGVtIGF0IGFsbC4NCj4NCj4tLQ0KPknDsWFr aSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldDxtYWlsdG86aWJjQGFsaWF4Lm5ldD4+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1h aWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD05E7inbamail02sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkp1c3RpbiAmYW1wOyBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBwZXIgbXkgb2ZmbGluZSBkaXNjdXNz aW9uIGluIElFVEYtODIsIGxvdCBvZiBmb2xrcyBoYXMgdHJvdWJsZSBpbiBmb2xsb3dpbmcgcnRj d2ViIGFsaWFzIGJlY2F1c2Ugb2YgdGhlIG1hc3NpdmUgZS1tYWlsIHBlciBkYXkuIEkgd2lzaCB0 aGUgY29uc2Vuc3VzIG9mIOKAnFNSVFANCiBpcyBtYW5kYXRvcnkgdG8gdXNlIG9yIG1hbmRhdG9y eSB0byBpbXBsZW1lbnTigJ0gaGFzIHRvIGJlIHBvc3Rwb25lZCBhdCBsZWFzdCBmb3IgaW50ZXJp bSBSVENXZWIgZmFjZS10by1mYWNlIG1lZXRpbmcgb24gMTxzdXA+c3Q8L3N1cD4gRmViLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBzZWUgbG90IG9mIGUtbWFpbCBjaGFpbiBhYm91dCBrZXkgbWFuYWdlbWVudCBpbiB0 aGUgYWxpYXMuIEnigJlsbCByZXBseSBpbiBvbmUgb2YgdGhlbSBmb3Iga2V5IG1hbmFnZW1lbnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkg W21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IEphbnVhcnkgMTIsIDIwMTIgMToyMiBBTTxicj4NCjxiPlRvOjwvYj4gUmF2aW5kcmFuLCBQYXJ0 aGFzYXJhdGhpPGJyPg0KPGI+Q2M6PC9iPiBJw7Fha2kgQmF6IENhc3RpbGxvOyBydGN3ZWJAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFNSVFAgbm90IG1hbmRhdG9y eS10by11c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U byByZXBseSB0byB0aGUgT1A6IFRoZSBjb25zZW5zdXMgdGhhdCBJIHNlZSBoYXZpbmcgZW1lcmdl ZCBmcm9tIHRoaXMgZGlzY3Vzc2lvbiBpcyB0aGF0IFNSVFAgc2hvdWxkIGJlIG1hbmRhdG9yeSB0 byB1c2UsIHdpdGggYSBwcm92aXNpb24gZm9yIE5VTEwgY2lwaGVycyBmb3IgZGVidWdnaW5nLiBU aGlzIHByb3Zpc2lvbiBpcyBvbmx5IGV4cG9zZWQgdGhyb3VnaCBkZXZlbG9wZXIgc2V0dGluZ3Ms IGFuZCBjYW4NCiBuZXZlciBiZSBpbnZva2VkIGZyb20gdGhlIHdlYiBhcHA7IGZvciBhbGwgcHJh Y3RpY2FsIHB1cnBvc2VzLCBhcHBsaWNhdGlvbnMgd2lsbCBoYXZlIHRvIHVzZSBTUlRQPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBmb3IgdGhlIGtleSBt YW5hZ2VtZW50IG1lY2hhbmlzbSwgU0RFUyBhbmQgRFRMUyB3aWxsIGJlIHN1cHBvcnRlZDsgd2hp bGUgRFRMUyBpcyBwcmVmZXJyZWQsIHRoZXJlIGFyZSBmZXcgRFRMUy1TUlRQIGltcGxlbWVudGF0 aW9ucyBpbiBleGlzdGVuY2UgYXQgdGhpcyB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BcyBmYXIg YXMgSSBrbm93LCB0aGlzIGlzIHdoYXQgdGhlIG1ham9yIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMg YXJlIHBsYW5uaW5nIHRvIGRvLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFdlZCwgSmFuIDExLCAyMDEyIGF0IDg6NDAgQU0sIFJhdmluZHJhbiwgUGFydGhh c2FyYXRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZpbmRyYW5Ac29udXNuZXQuY29tIj5wcmF2 aW5kcmFuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgSW5ha2ksPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IHdlIGFyZSBp biB0aGUgc2FtZSBwYWdlIG9mIG5vdCB1c2luZyBwbGFpbiBSVFAgaW48YnI+DQphaXJwb3J0IHdp dGggV2lGaS4gSXQgaXMgdGhlIG1haW4gcmVhc29uIGZvciBhc2tpbmcgU1JUUCBhcyBhPGJyPg0K ZGVmYXVsdCBtZWRpYSBwcm90b2NvbC4gQWxzbywgdGhlIHB1YmxpYyBpbnRlcm5ldCBhcHBsaWNh dGlvbiBsaWtlPGJyPg0KR29vZ2xlIGhhbmdvdXQgc2hvdWxkIGJlIGJhc2VkIG9uIFNSVFAuIFNv LCBNb3N0IG9mIHRoZSBXZWJSVEM8YnI+DQphcHBsaWNhdGlvbiB3aWxsIGJhc2VkIG9uIFNSVFAg YnV0IHNvbWUgb2YgdGhlIFdlYlJUQyBhcHBsaWNhdGlvbjxicj4NCnByZWZlcnMgdG8gUlRQIChp bnRyYW5ldCBzaXRlKSB3aGljaCBNVVNUIE5PVCBiZSByZXN0cmljdGVkIGJ5PGJyPg0KSUVURiBz dGFuZGFyZC48YnI+DQo8YnI+DQpUaGUgZG91YmxlIGVuY3J5cHRpb24gYXZvaWRhbmNlIGlzIHRo ZSBtYXR0ZXIgb2Ygb3B0aW1pemF0aW9uIGluPGJyPg0KbmV0d29yayBkZXNpZ24gYXMgZG91Ymxl IGVuY3J5cHRpb24gaW4gZW5kcG9pbnQgY2FsbHMgZm9yIGRvdWJsZTxicj4NCmRlY3J5cHRpb24g aW4gdGhlIG5ldHdvcmsgZm9yIHNvbWUgb2YgdGhlIHNlcnZpY2VzLiBJIGFncmVlIHRoYXQ8YnI+ DQppdCBtYXkgbm90IGJlIHByb2JsZW0gaW4gc29tZSBvZiB0aGUgbmV0d29yayBiZWNhdXNlIG9m PGJyPg0KdGhlIG5ldHdvcmsgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IG9yIG5ldHdvcmsgZW50aXR5 IGlzIG5vdCBpbnZvbHZlZDxicj4NCihicm93c2VyLWJyb3dzZXIgc2NlbmFyaW8pIGJ1dCB3ZSBj YW4ndCBnZW5lcmFsaXplIHRoaXMuIEluIGNhc2UgaXQgaXM8YnI+DQpwb3NzaWJsZSwgRG91Ymxl IGVuY3J5cHRpb24gaGFzIHRvIGJlIGF2b2lkZWQgYW5kIElFVEYgaGFzIHRvPGJyPg0KcmVjb21t ZW5kIGFjY29yZGluZ2x5Ljxicj4NCjxicj4NClBsZWFzZSByZWFkIGlubGluZSBmb3IgbW9yZSBj b21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQpUaGFua3M8YnI+DQpQYXJ0aGE8YnI+DQo8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzppYmNAYWxpYXgubmV0Ij5pYmNAYWxpYXgubmV0PC9hPl08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMTEsIDIwMTIgNDozOCBQTTxicj4NCiZndDtUbzogUmF2aW5kcmFuLCBQYXJ0aGFz YXJhdGhpPGJyPg0KJmd0O0NjOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTsg U3BlbmNlciBEYXdraW5zOyBBbGFuIEpvaG5zdG9uOzxicj4NCiZndDtCZXJuYXJkIEFib2JhOyBD dWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7U3ViamVjdDogUmU6IFtydGN3ZWJdIFNSVFAg bm90IG1hbmRhdG9yeS10by11c2U8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7MjAxMi8xLzExIFJhdmluZHJhbiwgUGFydGhh c2FyYXRoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZpbmRyYW5Ac29udXNuZXQuY29tIj5wcmF2 aW5kcmFuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7IEh1bWFuIHVzZXIgd2hv ICZxdW90O1ByZXNzIHRoZSAnQWNjZXB0IHVuc2VjdXJlIGNvbW11bmljYXRpb24nIGJ1dHRvbiBh bmQ8YnI+DQomZ3Q7Jmd0OyB5b3Ugd2lsbCB3aW4gYSBjYXIgISEhJnF1b3Q7IHdpbGwgYWxsb3cg UlRQIHBsdWctaW4gdG8gaW5zdGFsbCBvciBjb25maWd1cmU8YnI+DQomZ3Q7Jmd0OyBicm93c2Vy IHRvIHdpbiB0aGUgY2FyLiBJdCBpcyBhcyBnb29kIGFzIHNlbmRpbmcgdGhlIGFpciB0aWNrZXQg bW9uZXk8YnI+DQomZ3Q7Jmd0OyB0byB1bmtub3duIGNvdW50cnkga2luZyBiYXNlZCBvbiBzcGFt IG1haWwgaW4gc2VjdXJlZCAoaHR0cHMpIGUtbWFpbDxicj4NCiZndDsmZ3Q7IGFjY2VzcyB1c2Vy IGZvciBnZXR0aW5nIGx1bXAgc3VtIG1vbmV5IGZyb20gS2luZyAoc3BhbW1lcikuPGJyPg0KJmd0 Ozxicj4NCiZndDtSaWdodC4gTXkgcXVlc3Rpb24gaXM6IHdoeSB0byBhbGxvdyB0aGF0PyB3YXNu J3QgYSBwcmltYXJ5IGFpbSBvZiBXZWJSVEM8YnI+DQomZ3Q7dG8gYXZvaWQgc3VjaCBhIHJpc2s/ PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bHQ7cGFydGhhJmd0OyBJIGd1ZXNzIHRoYXQgbXkgcG9pbnQgZG9lcyBub3QgY29tZSBvdXQgd2Vs bC4gSSdtIHNheWluZyB0aGF0PGJyPg0KdXNlciB3aG8gYWNjZXB0IHVuc2VjdXJlIGNvbW11bmlj YXRpb24gZm9yIGEgY2FyIHdpbGwgYWxsb3cgUlRQIHBsdWctaW48YnI+DQp0byBiZSBhZGRlZCBp biB0aGUgYnJvd3NlciB3aGVyZWluIHNlY3VyaXR5IHdpbGwgYmUgY29tcHJvbWlzZWQgYW55d2F5 PGJyPg0KYW5kIG5vdCByZWxhdGVkIHRvIFdlYlJUQy4gJmx0Oy9wYXJ0aGEmZ3Q7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgQWxzbywgcGxlYXNlIG5vdGUgdGhhdCBT UlRQLURUTFMgZG9lcyBub3QgcHJldmVudCBXZWJSVEMgc2VydmVyIGZyb208YnI+DQomZ3Q7Jmd0 OyBhY2Nlc3NpbmcgdGhlIHNlY3VyZWQgV2ViUlRDIG1lZGlhIChkYXRhKSBidXQgaGVscHMgdXNl ciB0byBpZGVudGlmeTxicj4NCiZndDsmZ3Q7IHRoYXQgdGhlIG1lZGlhIGlzIG5vdCBlbmQtdG8t ZW5kLiBNeSBzdGF0ZW1lbnQgaXMgYmFzZWQgb24gbXk8YnI+DQomZ3Q7Jmd0OyB1bmRlcnN0YW5k aW5nIG9mIFdlYlJUQyBzZWN1cml0eSBhcmNoaXRlY3R1cmU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IFBhcnRoYShCcm93c2VyICYjNDM7ICZuYnNwO0pTKSAtLS0tLS0tLS0tV2ViUlRDc2Vy dmVyLS0tLS1Ccm93c2VyJiM0MzsgSlMgKEluYWtpKTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZndDsmZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tLS0oU1JUUCYjNDM7RFRMUyktLS0tLVdlYlJUQyBNZWRp YSBzZXJ2ZXItLS0oU1JUUCYjNDM7RFRMUykgLS0tLS08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IEluIHRoZSBhYm92ZSB0b3BvbG9neSwgd2Vic2VydmVyIG93bnMgV2ViUlRDIG1lZGlhIHNl cnZlciBhcyB3ZWxsLjxicj4NCiZndDsmZ3Q7IFdlYiBtZWRpYSBzZXJ2ZXIgdGVybWluYXRlcyAm YW1wOyBvcmlnaW5hdGVzIHRoZSBtZWRpYS4gVGhlIGlkZW50aXR5IGlzPGJyPg0KJmd0OyZndDsg dGhlIGRpZmZlcmVudGlhdGluZyBmYWN0b3IuIEZvciBleGFtcGxlLCBpZiBJIHNlZSB0aGUgYnJv d3NlciB3aW5kb3c8YnI+DQomZ3Q7Jmd0OyB3aXRoIGlkZW50aXR5IDxhIGhyZWY9Im1haWx0bzpp YmNAZ21haWwuY29tIj5pYmNAZ21haWwuY29tPC9hPiBpbnN0ZWFkIG9mIDxhIGhyZWY9Im1haWx0 bzppYmNAYWxpYXgubmV0Ij4NCmliY0BhbGlheC5uZXQ8L2E+LCB0aGVuIEkgaGF2ZSB0bzxicj4N CiZndDsmZ3Q7IHVuZGVyc3RhbmQgdGhhdCBicm93c2VyIGlzIG5vdCBlbmQtdG8tZW5kIGJlY2F1 c2Ugb2YgaWRlbnRpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDtXZWxsLCBJIGV4cGVjdCB0aGF0IHRo ZSB0eXBpY2FsbCBwaWN0dXJlIHdpbGwgbm90IGluY2x1ZGUgdGhlICZxdW90O1dlYlJUQzxicj4N CiZndDtNZWRpYSBTZXJ2ZXImcXVvdDsgKGl0IGNvdWxkIGhvd2V2ZXIpLjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZndDsgTXkgY3VycmVudCBhcmd1bWVudCBoYXMgbm90aGluZyB0byBk byB3aXRoIFBTVE4gaW50ZXJvcC4gQUZBSUssPGJyPg0KJmd0OyZndDsgU1JUUC1EVExTIHN0YW5k YXJkaXphdGlvbiBpbiBXZWJSVEMgaXMgZ29vZCBmb3IgU0JDIDotKS48YnI+DQomZ3Q7PGJyPg0K Jmd0O09rLCBidXQgSSdtIG5vdCB0YWxraW5nIGFib3V0IHRoYXQuIEknbSBqdXN0IHdvbmRlcmlu ZyB3aHkgdGhlIGh1bWFuPGJyPg0KJmd0O3VzZXIgc2hvdWxkIGJlIGFibGUgdG8gJnF1b3Q7dHJ1 c3QmcXVvdDsgYSB3ZWJzaXRlIGFza2luZyBwZXJtaXNzaW9uIGZvcjxicj4NCiZndDt1bnRydXN0 ZWQvaW5zZWN1cmUgcGxhaW4gUlRQLiBUaGlzIGlzIG5vdCBhYm91dCBoYXZpbmcgYSBtZWRpYSBz ZXJ2ZXIgb3I8YnI+DQomZ3Q7bm90Ljxicj4NCiZndDs8YnI+DQomZ3Q7RXhhbXBsZTogSSdtIGlu IGFuIGFpcnBvcnQgd2l0aCBvcGVuIFdpRmkuIElmIEkgZXN0YWJsaXNoIGEgcGxhaW4gUlRQPGJy Pg0KJmd0O2NvbW11bmljYXRpb24gYW55b25lIGluIHRoYXQgbmV0d29yayBjYW4gaW5zcGVjdCBp dC4gV2h5IHRvIGFsbG93IHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZsdDtwYXJ0aGEmZ3Q7IEFncmVlZC4gUHVibGljIGludGVybmV0IFdlYlJUQyBh cHBsaWNhdGlvbiBoYXMgdG8gYmUgYmFzZWQgb248YnI+DQpTUlRQICZsdDsvcGFydGhhJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQom Z3Q7PGJyPg0KJmd0O0kgcmVwZWF0IG15IG1haW4gYXJndW1lbnQgYWdhaW5zdCBhbGxvd2luZyBw bGFpbiBSVFA6PGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgZG91YmxlIGVuY3J5cHRpb24gaXMgbm90 IGEgcHJvYmxlbSBhdCBhbGwuIFRoZSBhcHBsaWNhdGlvbiAodGhlPGJyPg0KJmd0O2Jyb3dzZXIp IHBlcmZvcm1zIFNSVFAgZW5jcnlwdGlvbiAobm8gcHJvYmxlbSBoZXJlISkgYW5kIHRoZSBUQ1Av SVA8YnI+DQomZ3Q7c3RhY2sgaW4gdGhlIGNvbXB1dGVyIG9yIGluIHRoZSByb3V0ZXIgcGVyZm9y bXMgbmV0d29yayBlbmNyeXB0aW9uLjxicj4NCiZndDtXaGljaCBpcyB0aGUgcHJvYmxlbT8/PyBU aGVyZSBpcyBubyBwcm9ibGVtIGF0IGFsbC48YnI+DQomZ3Q7PGJyPg0KJmd0Oy0tPGJyPg0KJmd0 O0nDsWFraSBCYXogQ2FzdGlsbG88YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzppYmNAYWxp YXgubmV0Ij5pYmNAYWxpYXgubmV0PC9hPiZndDs8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD05E7inbamail02sonus_-- From pravindran@sonusnet.com Wed Jan 11 17:13:37 2012 Return-Path: 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 B61EC11E808D for ; Wed, 11 Jan 2012 17:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2sv7S4Ob7l9n for ; Wed, 11 Jan 2012 17:13:36 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4B711E8074 for ; Wed, 11 Jan 2012 17:13:36 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0C1EIHI028502; Wed, 11 Jan 2012 20:14:18 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 20:05:02 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 06:35:56 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 06:35:55 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti Thread-Topic: JSEP draft query [was RE: [rtcweb] SRTP not mandatory-to-use] Thread-Index: AQHM0MZVMFBIgjy5SEWGFT5o4RsLlg== Date: Thu, 12 Jan 2012 01:05:54 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD0610@inba-mail02.sonusnet.com> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0610inbamail02sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 01:05:56.0230 (UTC) FILETIME=[569F8A60:01CCD0C6] Cc: "rtcweb@ietf.org" Subject: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use] X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 01:13:37 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0610inbamail02sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpTb3JyeSwgIEkgaGF2ZSB0cm91YmxlIGluIGFjY2Vzc2luZyBKU0VQIGRy YWZ0IGF0IElFVEYgUlRDV2ViIHNpdGUgKGh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9ydGN3ZWIv KSBhbmQgZ29vZ2xpbmcgZG9lcyBub3QgeWllbGQgYW55IGRyYWZ0LiBDb3VsZCB5b3UgcGxlYXNl IGZvcndhcmQgbWUgSlNFUCBkcmFmdCB0byBzZWUgaG93IERUTFMga2V5cyBhcmUgbmVnb3RpYXRl ZCBpbiBKU0VQIHByb3Bvc2FsIGV2ZW4gIGJlZm9yZSB0aGUgYW5zd2VyIGlzIHJlY2VpdmVkIGZy b20gdGhlIHJlbW90ZSBXZWJSVEMgY2xpZW50Lg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBy dGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTIsIDIw MTIgNDo0OCBBTQ0KVG86IFJvbWFuIFNocG91bnQNCkNjOiBSYW5kZWxsIEplc3VwOyBydGN3ZWJA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBTUlRQIG5vdCBtYW5kYXRvcnktdG8tdXNl DQoNCg0KT24gV2VkLCBKYW4gMTEsIDIwMTIgYXQgNTo1MCBQTSwgUm9tYW4gU2hwb3VudCA8cm9t YW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpPbiBXZWQs IEphbiAxMSwgMjAxMiBhdCA0OjIwIFBNLCBSYW5kZWxsIEplc3VwIDxyYW5kZWxsLWlldGZAamVz dXAub3JnPG1haWx0bzpyYW5kZWxsLWlldGZAamVzdXAub3JnPj4gd3JvdGU6DQoNCkknZCBsaWtl IHRvIGV4cGxvcmUgdGhlIHBvc3NpYmlsaXR5IG9mIG1ha2luZyBzdXJlIHRoZXJlJ3MgYSB3b3Jr YWJsZSBEVExTLVNSVFAgaW1wbGVtZW50YXRpb24gb3Blbmx5IGF2YWlsYWJsZSwgYW5kIGxvY2tp bmcgV2ViUlRDIGRvd24gdG8gdGhhdCBvbmx5Lg0KDQpJIHNob3VsZCBub3RlIHRoYXQgd2hpbGUg bGlic3J0cCAxLjQuMiAobGFzdCBvZmZpY2lhbCByZWxlYXNlKSBkb2Vzbid0IGhhdmUgRFRMUy1T UlRQIHN1cHBvcnQsIHRoZXJlIGFyZSBEVExTLVNSVFAgc3VwcG9ydCBmdW5jdGlvbnMgYW5kIHRl c3QgY29kZSBpbiB0aGUgcHJvamVjdCdzIENWUyBzaW5jZSB+MjAwNiwgYW5kIHJlc2lwcm9jYXRl L3JlY29uIHN1cHBvcnRzIERUTFMtU1JUUCB2aWEgYSBtb2RpZmllZCBPcGVuU1NMLiAgU28sIEkn bSBub3Qgc3VyZSB0aGUgYmFycmllciBpcyBodWdlIGdpdmVuIERUTFMgc3VwcG9ydCBhbHJlYWR5 Lg0KDQpDYW4geW91IG5hbWUgYSBzaW5nbGUgc29mdC1waG9uZSwgaGFyZC1waG9uZSwgU0JDLCBv ciBnYXRld2F5IHRoYXQgY3VycmVudGx5IHN1cHBvcnRzIERUTFMtU1JUUD8NCg0KVGhlIHJlYXNv biBJIGFtIGFza2luZyBpcyBsaWJzcnRwLCBkZXNwaXRlIGJlaW5nIHdpZGVseSB1c2VkLCBpcyBl eHRyZW1lbHkgYnVnZ3kgKGxhc3Qgb2ZmaWNpYWwgcmVsZWFzZSBmb3IgaW5zdGFuY2UgY3Jhc2hl cyB3aXRoIEdQRiksIGFuZCBkb2VzIG5vdCBldmVuIHByb3ZpZGUgZnVsbCBERVMtU1JUUCBpbXBs ZW1lbnRhdGlvbiAobm8gRjhfMTI4X0hNQUNfU0hBMV84IHN1cHBvcnQpLg0KDQpBcyBmYXIgYXMg RFRMUyAobm9uLVNSVFApIGltcGxlbWVudGF0aW9ucyBhcmUgY29uY2VybmVkLCBjYW4gYW55Ym9k eSBwcm92aWRlIGFuIGluZGljYXRpb24gb24gaG93IHdpZGVseSB0aGV5IGFyZSB1c2VkPyBJIGtu b3cgdGhhdCBPcGVuU1NMIHN1cHBvcnRlZCBEVExTIGZvciBhIHdoaWxlLCBidXQgd2hhdCBjb21t b25seSB1c2VkIHNvZnR3YXJlIGlzIHVzaW5nIHRoaXM/DQoNCkFsc28sIHdoYXQgd291bGQgYmUg dGhlIGltcGFjdCBvZiBhZGRpbmcgRFRMUyB0byBTQkM/IEl0IHdvdWxkIGJlIGludGVyZXN0aW5n IHRvIGhlYXIgZnJvbSBTQkMgaW1wbGVtZW50ZXJzIGJlZm9yZSBkZWNpc2lvbiBpcyBtYWRlLg0K DQpIb3cgbWFueSBhZGRpdGlvbmFsIHJvdW5kIHRyaXBzIGRvZXMgRFRMUyByZXF1aXJlIGZvciBj b25uZWN0aW9uIHNldHVwPyBBcmUgd2UgcGxhbm5pbmcgdG8gc3VwcG9ydCBjZXJ0aWZpY2F0ZSB2 YWxpZGF0aW9uPw0KDQpXaGVuIHVzZWQgd2l0aCBKU0VQLCBEVExTIHNob3VsZCBub3QgcmVxdWly ZSBhbnkgYWRkaXRpb25hbCByb3VuZHRyaXBzIGZvciBjb25uZWN0aW9uIHNldHVwLCBzaW5jZSBE VExTIGNhbiBiZSBicm91Z2h0IHVwIGFzIHBhcnQgb2YgdHJhbnNwb3J0IGVzdGFibGlzaG1lbnQu IEluIGZhY3QsIGNvbm5lY3Rpb24gc2V0dXAgc2hvdWxkIG9jY3VyIGZhc3RlciB0aGFuIHdoZW4g dXNpbmcgU0RFUywgc2luY2UgdGhlIGtleXMgY2FuIGJlIG5lZ290aWF0ZWQgYmVmb3JlIHRoZSBh bnN3ZXIgYXJyaXZlcy4gVGhpcyBwcmV2ZW50cyBjbGlwcGluZyBvZiB0aGUgYW5zd2VyZXIncyBt ZWRpYSBmcm9tIG9jY3VycmluZy4NCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0610inbamail02sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5LCZuYnNwOyBJIGhhdmUgdHJvdWJsZSBpbiBh Y2Nlc3NpbmcgSlNFUCBkcmFmdCBhdCBJRVRGIFJUQ1dlYiBzaXRlICg8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvd2cvcnRjd2ViLyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3J0Y3dl Yi88L2E+KSBhbmQgZ29vZ2xpbmcNCiBkb2VzIG5vdCB5aWVsZCBhbnkgZHJhZnQuIENvdWxkIHlv dSBwbGVhc2UgZm9yd2FyZCBtZSBKU0VQIGRyYWZ0IHRvIHNlZSBob3cgRFRMUyBrZXlzIGFyZSBu ZWdvdGlhdGVkIGluIEpTRVAgcHJvcG9zYWwgZXZlbiAmbmJzcDtiZWZvcmUgdGhlIGFuc3dlciBp cyByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgV2ViUlRDIGNsaWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXJ0aGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFVi ZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxMiwgMjAxMiA0OjQ4IEFN PGJyPg0KPGI+VG86PC9iPiBSb21hbiBTaHBvdW50PGJyPg0KPGI+Q2M6PC9iPiBSYW5kZWxsIEpl c3VwOyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFNS VFAgbm90IG1hbmRhdG9yeS10by11c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDExLCAyMDEy IGF0IDU6NTAgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gMTEsIDIwMTIg YXQgNDoyMCBQTSwgUmFuZGVsbCBKZXN1cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmRlbGwtaWV0 ZkBqZXN1cC5vcmciIHRhcmdldD0iX2JsYW5rIj5yYW5kZWxsLWlldGZAamVzdXAub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkknZCBsaWtl IHRvIGV4cGxvcmUgdGhlIHBvc3NpYmlsaXR5IG9mIG1ha2luZyBzdXJlIHRoZXJlJ3MgYSB3b3Jr YWJsZSBEVExTLVNSVFAgaW1wbGVtZW50YXRpb24gb3Blbmx5IGF2YWlsYWJsZSwgYW5kIGxvY2tp bmcgV2ViUlRDIGRvd24gdG8gdGhhdCBvbmx5Ljxicj4NCjxicj4NCkkgc2hvdWxkIG5vdGUgdGhh dCB3aGlsZSBsaWJzcnRwIDEuNC4yIChsYXN0IG9mZmljaWFsIHJlbGVhc2UpIGRvZXNuJ3QgaGF2 ZSBEVExTLVNSVFAgc3VwcG9ydCwgdGhlcmUgYXJlIERUTFMtU1JUUCBzdXBwb3J0IGZ1bmN0aW9u cyBhbmQgdGVzdCBjb2RlIGluIHRoZSBwcm9qZWN0J3MgQ1ZTIHNpbmNlIH4yMDA2LCBhbmQgcmVz aXByb2NhdGUvcmVjb24gc3VwcG9ydHMgRFRMUy1TUlRQIHZpYSBhIG1vZGlmaWVkIE9wZW5TU0wu ICZuYnNwO1NvLCBJJ20gbm90DQogc3VyZSB0aGUgYmFycmllciBpcyBodWdlIGdpdmVuIERUTFMg c3VwcG9ydCBhbHJlYWR5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQ2FuIHlvdSBuYW1lIGEgc2luZ2xlIHNv ZnQtcGhvbmUsIGhhcmQtcGhvbmUsIFNCQywgb3IgZ2F0ZXdheSB0aGF0IGN1cnJlbnRseSBzdXBw b3J0cyBEVExTLVNSVFA/DQo8YnI+DQo8YnI+DQpUaGUgcmVhc29uIEkgYW0gYXNraW5nIGlzIGxp YnNydHAsIGRlc3BpdGUgYmVpbmcgd2lkZWx5IHVzZWQsIGlzIGV4dHJlbWVseSBidWdneSAobGFz dCBvZmZpY2lhbCByZWxlYXNlIGZvciBpbnN0YW5jZSBjcmFzaGVzIHdpdGggR1BGKSwgYW5kIGRv ZXMgbm90IGV2ZW4gcHJvdmlkZSBmdWxsIERFUy1TUlRQIGltcGxlbWVudGF0aW9uIChubyBGOF8x MjhfSE1BQ19TSEExXzggc3VwcG9ydCkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIERUTFMgKG5vbi1T UlRQKSBpbXBsZW1lbnRhdGlvbnMgYXJlIGNvbmNlcm5lZCwgY2FuIGFueWJvZHkgcHJvdmlkZSBh biBpbmRpY2F0aW9uIG9uIGhvdyB3aWRlbHkgdGhleSBhcmUgdXNlZD8gSSBrbm93IHRoYXQgT3Bl blNTTCBzdXBwb3J0ZWQgRFRMUyBmb3IgYSB3aGlsZSwgYnV0IHdoYXQgY29tbW9ubHkgdXNlZCBz b2Z0d2FyZSBpcyB1c2luZyB0aGlzPzxicj4NCjxicj4NCkFsc28sIHdoYXQgd291bGQgYmUgdGhl IGltcGFjdCBvZiBhZGRpbmcgRFRMUyB0byBTQkM/IEl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRv IGhlYXIgZnJvbSBTQkMgaW1wbGVtZW50ZXJzIGJlZm9yZSBkZWNpc2lvbiBpcyBtYWRlLjxicj4N Cjxicj4NCkhvdyBtYW55IGFkZGl0aW9uYWwgcm91bmQgdHJpcHMgZG9lcyBEVExTIHJlcXVpcmUg Zm9yIGNvbm5lY3Rpb24gc2V0dXA/IEFyZSB3ZSBwbGFubmluZyB0byBzdXBwb3J0IGNlcnRpZmlj YXRlIHZhbGlkYXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiB1c2VkIHdpdGggSlNFUCwgRFRMUyBzaG91bGQgbm90 IHJlcXVpcmUgYW55IGFkZGl0aW9uYWwgcm91bmR0cmlwcyBmb3IgY29ubmVjdGlvbiBzZXR1cCwg c2luY2UgRFRMUyBjYW4gYmUgYnJvdWdodCB1cCBhcyBwYXJ0IG9mIHRyYW5zcG9ydCBlc3RhYmxp c2htZW50LiBJbiBmYWN0LCBjb25uZWN0aW9uIHNldHVwIHNob3VsZCBvY2N1ciBmYXN0ZXIgdGhh biB3aGVuIHVzaW5nIFNERVMsIHNpbmNlIHRoZQ0KIGtleXMgY2FuIGJlIG5lZ290aWF0ZWQgYmVm b3JlIHRoZSBhbnN3ZXIgYXJyaXZlcy4gVGhpcyBwcmV2ZW50cyBjbGlwcGluZyBvZiB0aGUgYW5z d2VyZXIncyBtZWRpYSBmcm9tIG9jY3VycmluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0610inbamail02sonus_-- From fluffy@cisco.com Wed Jan 11 19:49:35 2012 Return-Path: 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 4C2BA11E8085 for ; Wed, 11 Jan 2012 19:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.944 X-Spam-Level: X-Spam-Status: No, score=-105.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KRnpA5HIKMVL for ; Wed, 11 Jan 2012 19:49:34 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2E311E8081 for ; Wed, 11 Jan 2012 19:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5765; q=dns/txt; s=iport; t=1326340174; x=1327549774; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HS73Xla3/IA4Ii9MN2mGzpt9ExTrlTsJvh2DkiSiNrc=; b=Ut5edqRoTt3cBvzVVHnYkhqTeK0yGJbnKgzqAf3NNtIgm39RaOZP6jM+ m6W6cARG1G+tmd1k6LimQyNw+pg7nO1nE6JkizayMCGrKlZ+W++/PTB5B QbcKTNumEDWevENYe78PZ2sy25yell3bxfsequNiS7AmPueugVT+18qjl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADVXDk+rRDoI/2dsb2JhbAA5Ca0LgQWBcgEBAQMBAQEBDwEnLgYLBQsLGC4nMAYTIodYCJlNAZ4rBIhhglljBIg6jFKFUY0L X-IronPort-AV: E=Sophos;i="4.71,495,1320624000"; d="scan'208";a="23263603" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 12 Jan 2012 03:49:34 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0C3nXDH027442; Thu, 12 Jan 2012 03:49:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 11 Jan 2012 20:49:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.o rg> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 03:49:35 -0000 Inline answer with my Cisco hat on .... I've mostly given up mention = this because I sent it to RAI lists too many times before but ... On Jan 11, 2012, at 3:50 PM, Roman Shpount wrote: >=20 > Can you name a single soft-phone, hard-phone, SBC, or gateway that = currently supports DTLS-SRTP?=20 Yes, Yes, Yes, and Yes respectively. For example, pretty much all the = Cisco high end tele presence stuff with includes endpoints, conference = bridges, protocol conversion devices etc supports it. The bulk of the = platforms that are newer than 5 years old from Cisco support DTLS-SRTP. = It interoperates with other vendors. We don't go to SIPIT because with = this sort of stuff as it does not seem to be the best way to test it. We = find that many of the vendors to test with at SIPIT are just getting = going and are still trying to get their spiral loops to work. Don't get = me wrong - I love SIPIT and strongly support it, but it's not the place = to test everything. I've been told a lot of IMS systems can do MiKEY = though I don't recall seeing a test of that at SIPIT. Different folks, = different places.=20 >=20 > The reason I am asking is libsrtp, despite being widely used, is = extremely buggy (last official release for instance crashes with GPF), = and does not even provide full DES-SRTP implementation (no = F8_128_HMAC_SHA1_8 support). I have no idea how much our internal version have diverged from the = version you are using but the libSRTP is being used for a huge number of = calls by enterprises, movements, and military systems. There's not a lot = of bugs reported. I'm certainly not claiming there are bugs in any given = piece of software but you can look at release notes of cisco products = and see this is pretty stable. I realize this does not help much but = DTLS-SRTP is not real complicated if you already have a good TLS stack = and crypto engine - regardless of the quality of any given = implementation, it should not be hard to make a good one.=20 >=20 > As far as DTLS (non-SRTP) implementations are concerned, can anybody = provide an indication on how widely they are used? I know that OpenSSL = supported DTLS for a while, but what commonly used software is using = this? I note most the good deployed SSL VPN in the world are DTLS . Check out = the market share of SSL VPN to traditional IPSec. DTLS is widely used. = Heck, at the next IETF, just check out the amount of DTLS traffic coming = from IETF participants.=20 >=20 > Also, what would be the impact of adding DTLS to SBC? It would be = interesting to hear from SBC implementers before decision is made. I've been on the design and implementation team for multiple SBCs - I = was even a co-founder of an SBC company. But it's really easy to figure = out - you don't need to know much about SBC - it more or less the same = as it would be for any UA. =20 Lets say you have nice SBC that will do 10,000 concurrent sessions. = These are not cheap. If you are doing RTP on one side and DTLS-SRTP on = the other side of each call. Lets just use a pessimistic estimate of = average call duration of 3 minutes. So this device is doing 10000 / 3 / = 60 =3D 55 session setups per second. The expensive part of this is the = RSA private key operation. A single core on the crappy computer I am = sending this email from does about 850 rsa1024 private key operations on = a single core. Try out your machine with "openssl speed rsa1024". It = roughly equivalent to two private key ops - So a big SBC needs 110 per = second under pessimistic assumption and a small CPU can do 850. As you = can imagine, an SBC like that is using some pretty beefy processors - = they impact of the DTLS is often hard to measure it is so little. The = amount of processing you need to process the all the SIP for a single = call greatly exceeds the amount of processing to set up the DTLS = connection. DTLS also requires much less per connection state than SIP = although SBC are typically more constrained by CPU than memory.=20 >=20 > How many additional round trips does DTLS require for connection = setup? A drop in the bucket compared to ICE :-) It depends on how you assume = the ICE ends up going and if you do early media or not. There are many = ways to overlap lots of this processing to minimize impact so it a = slightly hard question to answer but if you draw some call flows with = ICE, you will probably agree with my sort of flip "drop in the bucket" = answer.=20 > Are we planning to support certificate validation? Uh, don't think I am following you here - it's just a dummy X.509 record = to carry the public keys. There's no CA to validate it at.=20 > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb Thought I sound like I might be arguing for DTLS-SRTP to be the only = thing - I'm not sure what I think. I want to see what the whole security = systems looks like. If the weakest link is weak, well no point in making = other links super strong. Clearly the UI needs the ability of = indicating in a secure way if the call is secure or not and the identity = of who is at the other end of secure part. I can imagine Browser to = Browser perhaps always being secure, I agree secure should be preferred = to insecure where both are possible, but have a hard time imagining that = we won't wish we had RTP for Browser to Legacy.=20 Part of me believes that not having the option of using RTP in fallback = legacy cases would be about equally insane to not supporting IPv4 and = only doing v6. Sorry for all the nots.=20 From harald@alvestrand.no Thu Jan 12 01:15:41 2012 Return-Path: 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 D482421F84F2 for ; Thu, 12 Jan 2012 01:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 W95HBPUnqOvX for ; Thu, 12 Jan 2012 01:15:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 37BC621F84B5 for ; Thu, 12 Jan 2012 01:15:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E6EDC39E08A for ; Thu, 12 Jan 2012 10:15:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZmzG1sLmAZa for ; Thu, 12 Jan 2012 10:15:39 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1556C39E048 for ; Thu, 12 Jan 2012 10:15:39 +0100 (CET) Message-ID: <4F0EA4BA.5040809@alvestrand.no> Date: Thu, 12 Jan 2012 10:15:38 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org>, In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 09:15:41 -0000 Just forking the thread because real information may be good to have.... what's the status of libsrtp maintenance at the moment? Who does it, and is it adequately provisioned? It seems like a key component of so many implementations, so it would be good for the community if it's properly looked after. Harald From harald@alvestrand.no Thu Jan 12 01:19:22 2012 Return-Path: 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 1437521F854D for ; Thu, 12 Jan 2012 01:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 WzexOnCII91I for ; Thu, 12 Jan 2012 01:19:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D5C4621F84B4 for ; Thu, 12 Jan 2012 01:19:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 22D4A39E08A; Thu, 12 Jan 2012 10:19:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgRtIEzNgOsw; Thu, 12 Jan 2012 10:19:19 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1BAF539E048; Thu, 12 Jan 2012 10:19:19 +0100 (CET) Message-ID: <4F0EA596.1040009@alvestrand.no> Date: Thu, 12 Jan 2012 10:19:18 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01DD0610@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DD0610@inba-mail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------040906050602000904040409" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use] X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 09:19:22 -0000 This is a multi-part message in MIME format. --------------040906050602000904040409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/12/2012 02:05 AM, Ravindran, Parthasarathi wrote: > > Hi Justin, > > Sorry, I have trouble in accessing JSEP draft at IETF RTCWeb site > (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any > draft. Could you please forward me JSEP draft to see how DTLS keys are > negotiated in JSEP proposal even before the answer is received from > the remote WebRTC client. > A copy of the JSEP proposal is archived in the W3C WebRTC archives: http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0002.html It has not yet been submitted as an internet-draft; indeed, one of the things we have to decide is whether it should be an internet-draft or a part of the W3C API spec. > > Thanks > > Partha > > *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Thursday, January 12, 2012 4:48 AM > *To:* Roman Shpount > *Cc:* Randell Jesup; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SRTP not mandatory-to-use > > On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount > wrote: > > On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup > wrote: > > I'd like to explore the possibility of making sure there's a > workable DTLS-SRTP implementation openly available, and locking > WebRTC down to that only. > > I should note that while libsrtp 1.4.2 (last official release) > doesn't have DTLS-SRTP support, there are DTLS-SRTP support > functions and test code in the project's CVS since ~2006, and > resiprocate/recon supports DTLS-SRTP via a modified OpenSSL. So, > I'm not sure the barrier is huge given DTLS support already. > > > Can you name a single soft-phone, hard-phone, SBC, or gateway that > currently supports DTLS-SRTP? > > The reason I am asking is libsrtp, despite being widely used, is > extremely buggy (last official release for instance crashes with GPF), > and does not even provide full DES-SRTP implementation (no > F8_128_HMAC_SHA1_8 support). > > As far as DTLS (non-SRTP) implementations are concerned, can anybody > provide an indication on how widely they are used? I know that OpenSSL > supported DTLS for a while, but what commonly used software is using this? > > Also, what would be the impact of adding DTLS to SBC? It would be > interesting to hear from SBC implementers before decision is made. > > How many additional round trips does DTLS require for connection > setup? Are we planning to support certificate validation? > > When used with JSEP, DTLS should not require any additional roundtrips > for connection setup, since DTLS can be brought up as part of > transport establishment. In fact, connection setup should occur faster > than when using SDES, since the keys can be negotiated before the > answer arrives. This prevents clipping of the answerer's media from > occurring. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040906050602000904040409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/12/2012 02:05 AM, Ravindran, Parthasarathi wrote:

Hi Justin,

 

Sorry,  I have trouble in accessing JSEP draft at IETF RTCWeb site (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any draft. Could you please forward me JSEP draft to see how DTLS keys are negotiated in JSEP proposal even  before the answer is received from the remote WebRTC client.


A copy of the JSEP proposal is archived in the W3C WebRTC archives:

http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0002.html

It has not yet been submitted as an internet-draft; indeed, one of the things we have to decide is whether it should be an internet-draft or a part of the W3C API spec.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, January 12, 2012 4:48 AM
To: Roman Shpount
Cc: Randell Jesup; rtcweb@ietf.org
Subject: Re: [rtcweb] SRTP not mandatory-to-use

 

 

On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount <roman@telurix.com> wrote:

On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <randell-ietf@jesup.org> wrote:

 

I'd like to explore the possibility of making sure there's a workable DTLS-SRTP implementation openly available, and locking WebRTC down to that only.

I should note that while libsrtp 1.4.2 (last official release) doesn't have DTLS-SRTP support, there are DTLS-SRTP support functions and test code in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS support already.


Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP?

The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation?

 

When used with JSEP, DTLS should not require any additional roundtrips for connection setup, since DTLS can be brought up as part of transport establishment. In fact, connection setup should occur faster than when using SDES, since the keys can be negotiated before the answer arrives. This prevents clipping of the answerer's media from occurring.


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------040906050602000904040409-- From oej@edvina.net Thu Jan 12 02:06:03 2012 Return-Path: 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 CCE4521F84E4 for ; Thu, 12 Jan 2012 02:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] 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 WMc4eXrR4VaP for ; Thu, 12 Jan 2012 02:06:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2966121F84E1 for ; Thu, 12 Jan 2012 02:06:02 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D897D754A8A2; Thu, 12 Jan 2012 10:05:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Thu, 12 Jan 2012 11:05:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A996A85-7CE8-4768-B1AE-168F33145135@edvina.net> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.o rg> To: Justin Uberti X-Mailer: Apple Mail (2.1251.1) Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP DTLS - SIPit X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 10:06:03 -0000 12 jan 2012 kl. 00:14 skrev Justin Uberti: > The SIPIt reports note progress on SDES implementation, but DTLS/SRTP > not so much, and integrating DTLS/SRTP within RTCWEB would require = more > work beyond what is available in SIP DTLS/SRTP implementations today.=20= > As a result, I am more inclined toward Justin's proposal for RTCWEB = v1.0 > (assuming that the questions are answered).=20 When asking implementers at SIPit I have gotten a lot of people pointing = to not ready implementations in GnutTLS and OpenSSL (still in beta). = Talking with an OpenSSL developer a few days ago, I was clearly informed = that OpenSSL DTLS support is ready for implementation, no reason to = wait. Another reason I heard mostly from hardware device vendors was that the = chips vendors lack support of DTLS. I think it's mostly a question of lack of customer demand. If people = realize that the encryption keys are more or less distributed without = control with SDES, this will not be accepted. A secure IP-telephony = project in germany went for ZRTP because they could not accept SDES and = hardware phone vendors did not want to fix DTLS even if they was offered = orders of a quantity of phones... With all the implementations listed in this thread I think we can have = successful tests of DTLS-srtp at the next SIPit event. Remember that we = had very few participants at SIPit in Monaco, so using that report as = statistical evidence is propably not a good thing. /O= From pravindran@sonusnet.com Thu Jan 12 02:10:24 2012 Return-Path: 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 68CCA21F8484 for ; Thu, 12 Jan 2012 02:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 oHZbsCaw4YQP for ; Thu, 12 Jan 2012 02:10:20 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DE4F421F849A for ; Thu, 12 Jan 2012 02:10:19 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0CAAwI2021166; Thu, 12 Jan 2012 05:10:58 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 05:10:11 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 15:41:04 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 15:41:03 +0530 From: "Ravindran, Parthasarathi" To: Harald Alvestrand Thread-Topic: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use] Thread-Index: AQHM0Qtop3QL/AICg0GqE+1tD2qfKpYIfzqw Date: Thu, 12 Jan 2012 10:11:03 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD0757@inba-mail02.sonusnet.com> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6C01DD0610@inba-mail02.sonusnet.com> <4F0EA596.1040009@alvestrand.no> In-Reply-To: <4F0EA596.1040009@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0757inbamail02sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 10:11:04.0487 (UTC) FILETIME=[7E437B70:01CCD112] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use] X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 10:10:24 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0757inbamail02sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFyYWxkLA0KDQpUaGFua3MgZm9yIHRoZSBsaW5rLiAgRnJvbSBKU0VQIHByb3Bvc2FsIHNl Y3Rpb24sIEkgdW5kZXJzdGFuZCB0aGF0IEppbmdsZSBoYXMgZGlmZmVyZW50IHNpZ25hbGluZyBt ZWNoYW5pc20gdGhhbiBTSVAgYW5kIHRoZSBleGFjdCB0ZXh0IGlzIGFzIGZvbGxvd3M6DQoNCuKA nEluIHByb3RvY29scyB0aGF0IGRlY291cGxlIHNlc3Npb24gZGVzY3JpcHRpb25zIGZyb20gdHJh bnNwb3J0LCBzdWNoIGFzIEppbmdsZSwgdGhlIHRyYW5zcG9ydCBpbmZvcm1hdGlvbiBjYW4gYmUg c2VudCBzZXBhcmF0ZWx5OyBpbiBwcm90b2NvbHMgdGhhdCBkb24ndCwgc3VjaCBhcyBTSVAsIHRo ZSBpbmZvcm1hdGlvbiBjYW4gYmUgZWFzaWx5IGFnZ3JlZ2F0ZWQgYW5kIHJlY29tYmluZWQuIFNl bmRpbmcgdHJhbnNwb3J0IGluZm9ybWF0aW9uIHNlcGFyYXRlbHkgY2FuIGFsbG93IGZvciBmYXN0 ZXIgSUNFIGFuZCBEVExTIHN0YXJ0dXAsIHNpbmNlIHRoZSBuZWNlc3Nhcnkgcm91bmR0cmlwcyBj YW4gb2NjdXIgd2hpbGUgd2FpdGluZyBmb3IgdGhlIHJlbW90ZSBzaWRlIHRvIGFjY2VwdCB0aGUg c2Vzc2lvbi7igJ0NCg0KSeKAmWxsIGdvIHRocm91Z2ggdGhpcyBtZWNoYW5pc20gaW4gZGV0YWls IGFuZCBwcm92aWRlIGZ1cnRoZXIgY29tbWVudHMuDQoNClRoYW5rcw0KUGFydGhhDQoNCkZyb206 IEhhcmFsZCBBbHZlc3RyYW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAxMiwgMjAxMiAyOjQ5IFBNDQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFz YXJhdGhpDQpDYzogSnVzdGluIFViZXJ0aTsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3J0Y3dlYl0gSlNFUCBkcmFmdCBxdWVyeSBbd2FzIFJFOiBTUlRQIG5vdCBtYW5kYXRvcnktdG8t dXNlXQ0KDQpPbiAwMS8xMi8yMDEyIDAyOjA1IEFNLCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkg d3JvdGU6DQpIaSBKdXN0aW4sDQoNClNvcnJ5LCAgSSBoYXZlIHRyb3VibGUgaW4gYWNjZXNzaW5n IEpTRVAgZHJhZnQgYXQgSUVURiBSVENXZWIgc2l0ZSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3dn L3J0Y3dlYi8pIGFuZCBnb29nbGluZyBkb2VzIG5vdCB5aWVsZCBhbnkgZHJhZnQuIENvdWxkIHlv dSBwbGVhc2UgZm9yd2FyZCBtZSBKU0VQIGRyYWZ0IHRvIHNlZSBob3cgRFRMUyBrZXlzIGFyZSBu ZWdvdGlhdGVkIGluIEpTRVAgcHJvcG9zYWwgZXZlbiAgYmVmb3JlIHRoZSBhbnN3ZXIgaXMgcmVj ZWl2ZWQgZnJvbSB0aGUgcmVtb3RlIFdlYlJUQyBjbGllbnQuDQoNCkEgY29weSBvZiB0aGUgSlNF UCBwcm9wb3NhbCBpcyBhcmNoaXZlZCBpbiB0aGUgVzNDIFdlYlJUQyBhcmNoaXZlczoNCg0KaHR0 cDovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLXdlYnJ0Yy8yMDEySmFuLzAw MDIuaHRtbA0KDQpJdCBoYXMgbm90IHlldCBiZWVuIHN1Ym1pdHRlZCBhcyBhbiBpbnRlcm5ldC1k cmFmdDsgaW5kZWVkLCBvbmUgb2YgdGhlIHRoaW5ncyB3ZSBoYXZlIHRvIGRlY2lkZSBpcyB3aGV0 aGVyIGl0IHNob3VsZCBiZSBhbiBpbnRlcm5ldC1kcmFmdCBvciBhIHBhcnQgb2YgdGhlIFczQyBB UEkgc3BlYy4NCg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBUaHVyc2RheSwg SmFudWFyeSAxMiwgMjAxMiA0OjQ4IEFNDQpUbzogUm9tYW4gU2hwb3VudA0KQ2M6IFJhbmRlbGwg SmVzdXA7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtydGN3ZWJdIFNSVFAgbm90IG1hbmRhdG9yeS10by11c2UNCg0KDQpPbiBXZWQsIEphbiAx MSwgMjAxMiBhdCA1OjUwIFBNLCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWls dG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCk9uIFdlZCwgSmFuIDExLCAyMDEyIGF0IDQ6 MjAgUE0sIFJhbmRlbGwgSmVzdXAgPHJhbmRlbGwtaWV0ZkBqZXN1cC5vcmc8bWFpbHRvOnJhbmRl bGwtaWV0ZkBqZXN1cC5vcmc+PiB3cm90ZToNCg0KSSdkIGxpa2UgdG8gZXhwbG9yZSB0aGUgcG9z c2liaWxpdHkgb2YgbWFraW5nIHN1cmUgdGhlcmUncyBhIHdvcmthYmxlIERUTFMtU1JUUCBpbXBs ZW1lbnRhdGlvbiBvcGVubHkgYXZhaWxhYmxlLCBhbmQgbG9ja2luZyBXZWJSVEMgZG93biB0byB0 aGF0IG9ubHkuDQoNCkkgc2hvdWxkIG5vdGUgdGhhdCB3aGlsZSBsaWJzcnRwIDEuNC4yIChsYXN0 IG9mZmljaWFsIHJlbGVhc2UpIGRvZXNuJ3QgaGF2ZSBEVExTLVNSVFAgc3VwcG9ydCwgdGhlcmUg YXJlIERUTFMtU1JUUCBzdXBwb3J0IGZ1bmN0aW9ucyBhbmQgdGVzdCBjb2RlIGluIHRoZSBwcm9q ZWN0J3MgQ1ZTIHNpbmNlIH4yMDA2LCBhbmQgcmVzaXByb2NhdGUvcmVjb24gc3VwcG9ydHMgRFRM Uy1TUlRQIHZpYSBhIG1vZGlmaWVkIE9wZW5TU0wuICBTbywgSSdtIG5vdCBzdXJlIHRoZSBiYXJy aWVyIGlzIGh1Z2UgZ2l2ZW4gRFRMUyBzdXBwb3J0IGFscmVhZHkuDQoNCkNhbiB5b3UgbmFtZSBh IHNpbmdsZSBzb2Z0LXBob25lLCBoYXJkLXBob25lLCBTQkMsIG9yIGdhdGV3YXkgdGhhdCBjdXJy ZW50bHkgc3VwcG9ydHMgRFRMUy1TUlRQPw0KDQpUaGUgcmVhc29uIEkgYW0gYXNraW5nIGlzIGxp YnNydHAsIGRlc3BpdGUgYmVpbmcgd2lkZWx5IHVzZWQsIGlzIGV4dHJlbWVseSBidWdneSAobGFz dCBvZmZpY2lhbCByZWxlYXNlIGZvciBpbnN0YW5jZSBjcmFzaGVzIHdpdGggR1BGKSwgYW5kIGRv ZXMgbm90IGV2ZW4gcHJvdmlkZSBmdWxsIERFUy1TUlRQIGltcGxlbWVudGF0aW9uIChubyBGOF8x MjhfSE1BQ19TSEExXzggc3VwcG9ydCkuDQoNCkFzIGZhciBhcyBEVExTIChub24tU1JUUCkgaW1w bGVtZW50YXRpb25zIGFyZSBjb25jZXJuZWQsIGNhbiBhbnlib2R5IHByb3ZpZGUgYW4gaW5kaWNh dGlvbiBvbiBob3cgd2lkZWx5IHRoZXkgYXJlIHVzZWQ/IEkga25vdyB0aGF0IE9wZW5TU0wgc3Vw cG9ydGVkIERUTFMgZm9yIGEgd2hpbGUsIGJ1dCB3aGF0IGNvbW1vbmx5IHVzZWQgc29mdHdhcmUg aXMgdXNpbmcgdGhpcz8NCg0KQWxzbywgd2hhdCB3b3VsZCBiZSB0aGUgaW1wYWN0IG9mIGFkZGlu ZyBEVExTIHRvIFNCQz8gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBmcm9tIFNCQyBp bXBsZW1lbnRlcnMgYmVmb3JlIGRlY2lzaW9uIGlzIG1hZGUuDQoNCkhvdyBtYW55IGFkZGl0aW9u YWwgcm91bmQgdHJpcHMgZG9lcyBEVExTIHJlcXVpcmUgZm9yIGNvbm5lY3Rpb24gc2V0dXA/IEFy ZSB3ZSBwbGFubmluZyB0byBzdXBwb3J0IGNlcnRpZmljYXRlIHZhbGlkYXRpb24/DQoNCldoZW4g dXNlZCB3aXRoIEpTRVAsIERUTFMgc2hvdWxkIG5vdCByZXF1aXJlIGFueSBhZGRpdGlvbmFsIHJv dW5kdHJpcHMgZm9yIGNvbm5lY3Rpb24gc2V0dXAsIHNpbmNlIERUTFMgY2FuIGJlIGJyb3VnaHQg dXAgYXMgcGFydCBvZiB0cmFuc3BvcnQgZXN0YWJsaXNobWVudC4gSW4gZmFjdCwgY29ubmVjdGlv biBzZXR1cCBzaG91bGQgb2NjdXIgZmFzdGVyIHRoYW4gd2hlbiB1c2luZyBTREVTLCBzaW5jZSB0 aGUga2V5cyBjYW4gYmUgbmVnb3RpYXRlZCBiZWZvcmUgdGhlIGFuc3dlciBhcnJpdmVzLiBUaGlz IHByZXZlbnRzIGNsaXBwaW5nIG9mIHRoZSBhbnN3ZXJlcidzIG1lZGlhIGZyb20gb2NjdXJyaW5n Lg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCg0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQoNCg== --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0757inbamail02sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpIEhhcmFsZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGxpbmsuICZuYnNwO0Zyb20g SlNFUCBwcm9wb3NhbCBzZWN0aW9uLCBJIHVuZGVyc3RhbmQgdGhhdCBKaW5nbGUgaGFzIGRpZmZl cmVudCBzaWduYWxpbmcgbWVjaGFuaXNtIHRoYW4gU0lQIGFuZCB0aGUgZXhhY3QgdGV4dCBpcyBh cyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcSW4gcHJvdG9jb2xzIHRoYXQgZGVjb3VwbGUgc2Vzc2lv biBkZXNjcmlwdGlvbnMgZnJvbSB0cmFuc3BvcnQsIHN1Y2ggYXMgSmluZ2xlLCB0aGUgdHJhbnNw b3J0IGluZm9ybWF0aW9uIGNhbiBiZSBzZW50IHNlcGFyYXRlbHk7IGluIHByb3RvY29scyB0aGF0 IGRvbid0LA0KIHN1Y2ggYXMgU0lQLCB0aGUgaW5mb3JtYXRpb24gY2FuIGJlIGVhc2lseSBhZ2dy ZWdhdGVkIGFuZCByZWNvbWJpbmVkLiBTZW5kaW5nIHRyYW5zcG9ydCBpbmZvcm1hdGlvbiBzZXBh cmF0ZWx5IGNhbiBhbGxvdyBmb3IgZmFzdGVyIElDRSBhbmQgRFRMUyBzdGFydHVwLCBzaW5jZSB0 aGUgbmVjZXNzYXJ5IHJvdW5kdHJpcHMgY2FuIG9jY3VyIHdoaWxlIHdhaXRpbmcgZm9yIHRoZSBy ZW1vdGUgc2lkZSB0byBhY2NlcHQgdGhlIHNlc3Npb24u4oCdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J4oCZbGwgZ28g dGhyb3VnaCB0aGlzIG1lY2hhbmlzbSBpbiBkZXRhaWwgYW5kIHByb3ZpZGUgZnVydGhlciBjb21t ZW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBh cnRoYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzpoYXJh bGRAYWx2ZXN0cmFuZC5ub10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAx MiwgMjAxMiAyOjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGk8 YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVydGk7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSlNFUCBkcmFmdCBxdWVyeSBbd2FzIFJFOiBTUlRQIG5v dCBtYW5kYXRvcnktdG8tdXNlXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDAxLzEyLzIwMTIgMDI6MDUgQU0sIFJhdmluZHJhbiwgUGFydGhhc2FyYXRo aSB3cm90ZTogPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgSnVzdGluLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Tb3JyeSwmbmJzcDsgSSBoYXZlIHRyb3VibGUgaW4gYWNjZXNzaW5nIEpT RVAgZHJhZnQgYXQgSUVURiBSVENXZWIgc2l0ZSAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYu b3JnL3dnL3J0Y3dlYi8iPmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9ydGN3ZWIvPC9hPikgYW5k IGdvb2dsaW5nIGRvZXMgbm90DQogeWllbGQgYW55IGRyYWZ0LiBDb3VsZCB5b3UgcGxlYXNlIGZv cndhcmQgbWUgSlNFUCBkcmFmdCB0byBzZWUgaG93IERUTFMga2V5cyBhcmUgbmVnb3RpYXRlZCBp biBKU0VQIHByb3Bvc2FsIGV2ZW4gJm5ic3A7YmVmb3JlIHRoZSBhbnN3ZXIgaXMgcmVjZWl2ZWQg ZnJvbSB0aGUgcmVtb3RlIFdlYlJUQyBjbGllbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQSBjb3B5IG9mIHRoZSBKU0VQIHByb3Bvc2FsIGlzIGFy Y2hpdmVkIGluIHRoZSBXM0MgV2ViUlRDIGFyY2hpdmVzOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0 dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy13ZWJydGMvMjAxMkphbi8w MDAyLmh0bWwiPmh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy13ZWJy dGMvMjAxMkphbi8wMDAyLmh0bWw8L2E+PGJyPg0KPGJyPg0KSXQgaGFzIG5vdCB5ZXQgYmVlbiBz dWJtaXR0ZWQgYXMgYW4gaW50ZXJuZXQtZHJhZnQ7IGluZGVlZCwgb25lIG9mIHRoZSB0aGluZ3Mg d2UgaGF2ZSB0byBkZWNpZGUgaXMgd2hldGhlciBpdCBzaG91bGQgYmUgYW4gaW50ZXJuZXQtZHJh ZnQgb3IgYSBwYXJ0IG9mIHRoZSBXM0MgQVBJIHNwZWMuPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5QYXJ0aGE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0 LWNvbG9yIC1tb3otdXNlLXRleHQtY29sb3INCiAgICAgICAgICBibHVlIj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6LW1vei11c2UtdGV4dC1jb2xvcg0K ICAgICAgICAgICAgICAtbW96LXVzZS10ZXh0LWNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgSmFudWFyeSAxMiwgMjAxMiA0OjQ4IEFNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBTaHBvdW50 PGJyPg0KPGI+Q2M6PC9iPiBSYW5kZWxsIEplc3VwOyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRj d2ViXSBTUlRQIG5vdCBtYW5kYXRvcnktdG8tdXNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAx MSwgMjAxMiBhdCA1OjUwIFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9t YW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDEx LCAyMDEyIGF0IDQ6MjAgUE0sIFJhbmRlbGwgSmVzdXAgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5k ZWxsLWlldGZAamVzdXAub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmFuZGVsbC1pZXRmQGplc3VwLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItY29sb3I6LW1v ei11c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yDQogICAgICAgICAgICAgICAgICAt bW96LXVzZS10ZXh0LWNvbG9yIHJnYigyMDQsIDIwNCwgMjA0KSI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdkIGxpa2UgdG8gZXhwbG9yZSB0 aGUgcG9zc2liaWxpdHkgb2YgbWFraW5nIHN1cmUgdGhlcmUncyBhIHdvcmthYmxlIERUTFMtU1JU UCBpbXBsZW1lbnRhdGlvbiBvcGVubHkgYXZhaWxhYmxlLCBhbmQgbG9ja2luZyBXZWJSVEMgZG93 biB0byB0aGF0IG9ubHkuPGJyPg0KPGJyPg0KSSBzaG91bGQgbm90ZSB0aGF0IHdoaWxlIGxpYnNy dHAgMS40LjIgKGxhc3Qgb2ZmaWNpYWwgcmVsZWFzZSkgZG9lc24ndCBoYXZlIERUTFMtU1JUUCBz dXBwb3J0LCB0aGVyZSBhcmUgRFRMUy1TUlRQIHN1cHBvcnQgZnVuY3Rpb25zIGFuZCB0ZXN0IGNv ZGUgaW4gdGhlIHByb2plY3QncyBDVlMgc2luY2UgfjIwMDYsIGFuZCByZXNpcHJvY2F0ZS9yZWNv biBzdXBwb3J0cyBEVExTLVNSVFAgdmlhIGEgbW9kaWZpZWQgT3BlblNTTC4gJm5ic3A7U28sIEkn bSBub3QNCiBzdXJlIHRoZSBiYXJyaWVyIGlzIGh1Z2UgZ2l2ZW4gRFRMUyBzdXBwb3J0IGFscmVh ZHkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpDYW4geW91IG5hbWUgYSBzaW5nbGUgc29mdC1waG9uZSwgaGFy ZC1waG9uZSwgU0JDLCBvciBnYXRld2F5IHRoYXQgY3VycmVudGx5IHN1cHBvcnRzIERUTFMtU1JU UD8NCjxicj4NCjxicj4NClRoZSByZWFzb24gSSBhbSBhc2tpbmcgaXMgbGlic3J0cCwgZGVzcGl0 ZSBiZWluZyB3aWRlbHkgdXNlZCwgaXMgZXh0cmVtZWx5IGJ1Z2d5IChsYXN0IG9mZmljaWFsIHJl bGVhc2UgZm9yIGluc3RhbmNlIGNyYXNoZXMgd2l0aCBHUEYpLCBhbmQgZG9lcyBub3QgZXZlbiBw cm92aWRlIGZ1bGwgREVTLVNSVFAgaW1wbGVtZW50YXRpb24gKG5vIEY4XzEyOF9ITUFDX1NIQTFf OCBzdXBwb3J0KS48YnI+DQo8YnI+DQpBcyBmYXIgYXMgRFRMUyAobm9uLVNSVFApIGltcGxlbWVu dGF0aW9ucyBhcmUgY29uY2VybmVkLCBjYW4gYW55Ym9keSBwcm92aWRlIGFuIGluZGljYXRpb24g b24gaG93IHdpZGVseSB0aGV5IGFyZSB1c2VkPyBJIGtub3cgdGhhdCBPcGVuU1NMIHN1cHBvcnRl ZCBEVExTIGZvciBhIHdoaWxlLCBidXQgd2hhdCBjb21tb25seSB1c2VkIHNvZnR3YXJlIGlzIHVz aW5nIHRoaXM/PGJyPg0KPGJyPg0KQWxzbywgd2hhdCB3b3VsZCBiZSB0aGUgaW1wYWN0IG9mIGFk ZGluZyBEVExTIHRvIFNCQz8gSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gaGVhciBmcm9tIFNC QyBpbXBsZW1lbnRlcnMgYmVmb3JlIGRlY2lzaW9uIGlzIG1hZGUuPGJyPg0KPGJyPg0KSG93IG1h bnkgYWRkaXRpb25hbCByb3VuZCB0cmlwcyBkb2VzIERUTFMgcmVxdWlyZSBmb3IgY29ubmVjdGlv biBzZXR1cD8gQXJlIHdlIHBsYW5uaW5nIHRvIHN1cHBvcnQgY2VydGlmaWNhdGUgdmFsaWRhdGlv bj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGVuIHVzZWQgd2l0aCBKU0VQLCBEVExTIHNob3VsZCBub3QgcmVxdWlyZSBhbnkg YWRkaXRpb25hbCByb3VuZHRyaXBzIGZvciBjb25uZWN0aW9uIHNldHVwLCBzaW5jZSBEVExTIGNh biBiZSBicm91Z2h0IHVwIGFzIHBhcnQgb2YgdHJhbnNwb3J0IGVzdGFibGlzaG1lbnQuIEluIGZh Y3QsIGNvbm5lY3Rpb24gc2V0dXAgc2hvdWxkIG9jY3VyIGZhc3RlciB0aGFuIHdoZW4gdXNpbmcg U0RFUywgc2luY2UgdGhlDQoga2V5cyBjYW4gYmUgbmVnb3RpYXRlZCBiZWZvcmUgdGhlIGFuc3dl ciBhcnJpdmVzLiBUaGlzIHByZXZlbnRzIGNsaXBwaW5nIG9mIHRoZSBhbnN3ZXJlcidzIG1lZGlh IGZyb20gb2NjdXJyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_387F9047F55E8C42850AD6B3A7A03C6C01DD0757inbamail02sonus_-- From pravindran@sonusnet.com Thu Jan 12 03:03:04 2012 Return-Path: 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 BE4CA21F85A5 for ; Thu, 12 Jan 2012 03:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 lUDrR4aTOjOK for ; Thu, 12 Jan 2012 03:03:03 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 99E2121F8594 for ; Thu, 12 Jan 2012 03:03:03 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0CB3jWi023040; Thu, 12 Jan 2012 06:03:45 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 06:03:00 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 16:33:54 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 16:33:53 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings , Roman Shpount Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw//+vH4CAAHXqEP//r34AgAB980CAABSNgIAAGJKAgAAZKICAAFOigIAA0kPQ Date: Thu, 12 Jan 2012 11:03:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD0794@inba-mail02.sonusnet.com> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.o rg> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 11:03:54.0335 (UTC) FILETIME=[DFA3E6F0:01CCD119] Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 11:03:04 -0000 Cullen, Nice to see the last few statements from legacy perspective. Clearly the UI needs the ability of indicating in a secure way if th= e call is secure or not and the identity of who is at the other end of secu= re part. I can imagine Browser to Browser perhaps always being secure, I ag= ree secure should be preferred to insecure where both are possible, but hav= e a hard time imagining that we won't wish we had RTP for Browser to Legacy= .=20 Part of me believes that not having the option of using RTP in fallback leg= acy cases would be about equally insane to not supporting IPv4 and only doi= ng v6. Sorry for all the nots. I look for configuration in browser for RTP traffic to get the user consent= while sending/receiving the media. =20 Apart from this, SRTP-DTLS is the only proposed standard RFC in IETF for cu= rrent WebRTC security trust model. SRTP-SDES breaks the model by trusting J= S app and ZRTP is the informational draft. I agree with you that implementi= ng SRTP-DTLS in middle box like SBC is possible if standard and market ado= pts. So, I'll prefer to have SRTP-DTLS as long as there is no alternative s= tandard proposal or new proposal exists. =20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Cullen Jennings >Sent: Thursday, January 12, 2012 9:20 AM >To: Roman Shpount >Cc: Randell Jesup; rtcweb@ietf.org >Subject: Re: [rtcweb] SRTP not mandatory-to-use > > >Inline answer with my Cisco hat on .... I've mostly given up mention >this because I sent it to RAI lists too many times before but ... > >On Jan 11, 2012, at 3:50 PM, Roman Shpount wrote: >> >> Can you name a single soft-phone, hard-phone, SBC, or gateway that >currently supports DTLS-SRTP? > >Yes, Yes, Yes, and Yes respectively. For example, pretty much all the >Cisco high end tele presence stuff with includes endpoints, conference >bridges, protocol conversion devices etc supports it. The bulk of the >platforms that are newer than 5 years old from Cisco support DTLS-SRTP. >It interoperates with other vendors. We don't go to SIPIT because with >this sort of stuff as it does not seem to be the best way to test it. We >find that many of the vendors to test with at SIPIT are just getting >going and are still trying to get their spiral loops to work. Don't get >me wrong - I love SIPIT and strongly support it, but it's not the place >to test everything. I've been told a lot of IMS systems can do MiKEY >though I don't recall seeing a test of that at SIPIT. Different folks, >different places. > >> >> The reason I am asking is libsrtp, despite being widely used, is >extremely buggy (last official release for instance crashes with GPF), >and does not even provide full DES-SRTP implementation (no >F8_128_HMAC_SHA1_8 support). > >I have no idea how much our internal version have diverged from the >version you are using but the libSRTP is being used for a huge number of >calls by enterprises, movements, and military systems. There's not a lot >of bugs reported. I'm certainly not claiming there are bugs in any given >piece of software but you can look at release notes of cisco products >and see this is pretty stable. I realize this does not help much but >DTLS-SRTP is not real complicated if you already have a good TLS stack >and crypto engine - regardless of the quality of any given >implementation, it should not be hard to make a good one. > >> >> As far as DTLS (non-SRTP) implementations are concerned, can anybody >provide an indication on how widely they are used? I know that OpenSSL >supported DTLS for a while, but what commonly used software is using >this? > >I note most the good deployed SSL VPN in the world are DTLS . Check out >the market share of SSL VPN to traditional IPSec. DTLS is widely used. >Heck, at the next IETF, just check out the amount of DTLS traffic coming >from IETF participants. > >> >> Also, what would be the impact of adding DTLS to SBC? It would be >interesting to hear from SBC implementers before decision is made. > >I've been on the design and implementation team for multiple SBCs - I >was even a co-founder of an SBC company. But it's really easy to figure >out - you don't need to know much about SBC - it more or less the same >as it would be for any UA. > >Lets say you have nice SBC that will do 10,000 concurrent sessions. >These are not cheap. If you are doing RTP on one side and DTLS-SRTP on >the other side of each call. Lets just use a pessimistic estimate of >average call duration of 3 minutes. So this device is doing 10000 / 3 / >60 =3D 55 session setups per second. The expensive part of this is the RSA >private key operation. A single core on the crappy computer I am sending >this email from does about 850 rsa1024 private key operations on a >single core. Try out your machine with "openssl speed rsa1024". It >roughly equivalent to two private key ops - So a big SBC needs 110 per >second under pessimistic assumption and a small CPU can do 850. As you >can imagine, an SBC like that is using some pretty beefy processors - >they impact of the DTLS is often hard to measure it is so little. The >amount of processing you need to process the all the SIP for a single >call greatly exceeds the amount of processing to set up the DTLS >connection. D TLS also requires much less per connection state than SIP >although SBC are typically more constrained by CPU than memory. > > >> >> How many additional round trips does DTLS require for connection >setup? > >A drop in the bucket compared to ICE :-) It depends on how you assume >the ICE ends up going and if you do early media or not. There are many >ways to overlap lots of this processing to minimize impact so it a >slightly hard question to answer but if you draw some call flows with >ICE, you will probably agree with my sort of flip "drop in the bucket" >answer. > >> Are we planning to support certificate validation? > >Uh, don't think I am following you here - it's just a dummy X.509 record >to carry the public keys. There's no CA to validate it at. > >> _____________ >> Roman Shpount >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > >Thought I sound like I might be arguing for DTLS-SRTP to be the only >thing - I'm not sure what I think. I want to see what the whole security >systems looks like. If the weakest link is weak, well no point in making >other links super strong. Clearly the UI needs the ability of >indicating in a secure way if the call is secure or not and the identity >of who is at the other end of secure part. I can imagine Browser to >Browser perhaps always being secure, I agree secure should be preferred >to insecure where both are possible, but have a hard time imagining that >we won't wish we had RTP for Browser to Legacy. > >Part of me believes that not having the option of using RTP in fallback >legacy cases would be about equally insane to not supporting IPv4 and >only doing v6. Sorry for all the nots. > > > > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Jan 12 03:56:07 2012 Return-Path: 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 079D421F8527 for ; Thu, 12 Jan 2012 03:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 Fowjyk9BiOVw for ; Thu, 12 Jan 2012 03:56:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F148421F850B for ; Thu, 12 Jan 2012 03:56:05 -0800 (PST) Received: by iaae16 with SMTP id e16so2624696iaa.31 for ; Thu, 12 Jan 2012 03:56:05 -0800 (PST) Received: by 10.50.77.226 with SMTP id v2mr3803846igw.7.1326369364354; Thu, 12 Jan 2012 03:56:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id bj3sm334059igb.4.2012.01.12.03.56.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 03:56:03 -0800 (PST) Received: by pbbb2 with SMTP id b2so370232pbb.31 for ; Thu, 12 Jan 2012 03:56:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.115.195 with SMTP id jq3mr7762359pbb.34.1326369361676; Thu, 12 Jan 2012 03:56:01 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 12 Jan 2012 03:56:01 -0800 (PST) In-Reply-To: <4F0EA4BA.5040809@alvestrand.no> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0EA4BA.5040809@alvestrand.no> Date: Thu, 12 Jan 2012 06:56:01 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b15a389a4c97804b6536e02 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 11:56:07 -0000 --047d7b15a389a4c97804b6536e02 Content-Type: text/plain; charset=ISO-8859-1 Just as a side not SRTP-SDES is a fairly simple feature to implement. All you need as AES CM, SHA1 HMAC, F8, and a replay database. This is a few thousand lines of code (or a lot less if you have good crypto library, such as OpenSSH, GnuTLS, or Intel IPP, handy). libsrtp comes with its own crypto library (which is considerably worse maintenance state wise and performance wise then OpenSSH or GnuTLS). It also implements extensive self-checks as a part of library initialization, which are strictly speaking not necessary. For some reason libsrtp implements two replay libraries (one for RTP and another for RTCP) even though they suppose to do the same thing. It also implements a number of crypto routines that are not normally used for anything when implementing SRTP. My point is, if all is needed is an implementation of SRTP-SDES, the state of libsrtp is irrelevant since it is easy enough to code around. If SRTP-DTLS is needed, then couple of order of magnitude more code is needed to implement TLS handshake, which will mean using an existing mature DTLS implementation and adding SRTP encoding if necessary. _____________ Roman Shpount On Thu, Jan 12, 2012 at 4:15 AM, Harald Alvestrand wrote: > Just forking the thread because real information may be good to have.... > > what's the status of libsrtp maintenance at the moment? Who does it, and > is it adequately provisioned? > > It seems like a key component of so many implementations, so it would be > good for the community if it's properly looked after. > > Harald > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --047d7b15a389a4c97804b6536e02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just as a side not SRTP-SDES is a fairly simple feature to implement. All y= ou need as AES CM, SHA1=A0 HMAC, F8, and a replay database. This is a few t= housand lines of code (or a lot less if you have good crypto library, such = as OpenSSH, GnuTLS, or Intel IPP, handy).

libsrtp comes with its own crypto library (which is considerably worse = maintenance state wise and performance wise then OpenSSH or GnuTLS). It als= o implements extensive self-checks as a part of library initialization, whi= ch are strictly speaking not necessary. For some reason libsrtp implements = two replay libraries (one for RTP and another for RTCP) even=A0 though they= suppose to do the same thing. It also implements a number of crypto routin= es that are not normally used for anything when implementing SRTP.

My point is, if all is needed is an implementation of SRTP-SDES, the st= ate of libsrtp is irrelevant since it is easy enough to code around. If SRT= P-DTLS is needed, then couple of order of magnitude more code is needed to = implement TLS handshake, which will mean using an existing mature DTLS impl= ementation and adding SRTP encoding if necessary.
_____________
Roman Shpount


On Thu, Jan 12, 2012 at 4:15 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
Just forking the thread because real information may be good to have....
what's the status of libsrtp maintenance at the moment? Who does it, an= d is it adequately provisioned?

It seems like a key component of so many implementations, so it would be go= od for the community if it's properly looked after.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b15a389a4c97804b6536e02-- From ekr@rtfm.com Thu Jan 12 06:37:50 2012 Return-Path: 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 B605D21F85F4 for ; Thu, 12 Jan 2012 06:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 tDmrrNuZ237i for ; Thu, 12 Jan 2012 06:37:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE93221F85F6 for ; Thu, 12 Jan 2012 06:37:45 -0800 (PST) Received: by vbbfc21 with SMTP id fc21so417345vbb.31 for ; Thu, 12 Jan 2012 06:37:45 -0800 (PST) Received: by 10.52.29.75 with SMTP id i11mr1791704vdh.23.1326379065166; Thu, 12 Jan 2012 06:37:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Thu, 12 Jan 2012 06:37:04 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0EA4BA.5040809@alvestrand.no> From: Eric Rescorla Date: Thu, 12 Jan 2012 06:37:04 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 14:37:50 -0000 On Thu, Jan 12, 2012 at 3:56 AM, Roman Shpount wrote: > libsrtp comes with its own crypto library (which is considerably worse > maintenance state wise and performance wise then OpenSSH or GnuTLS). It a= lso > implements extensive self-checks as a part of library initialization, whi= ch > are strictly speaking not necessary. For some reason libsrtp implements t= wo > replay libraries (one for RTP and another for RTCP) even=A0 though they > suppose to do the same thing. It also implements a number of crypto routi= nes > that are not normally used for anything when implementing SRTP. > > My point is, if all is needed is an implementation of SRTP-SDES, the stat= e > of libsrtp is irrelevant since it is easy enough to code around. If > SRTP-DTLS is needed, then couple of order of magnitude more code is neede= d > to implement TLS handshake, which will mean using an existing mature DTLS > implementation and adding SRTP encoding if necessary. DTLS-SRTP was specifically designed so that one could put together a DTLS stack and an SRTP stack with minimal modifications to both (and no necessar= y modifications to the SRTP stack). In the case of OpenSSL and libsrtp, you do the OpenSSL handshake, then use a new interface to export the keys which you then push onto libsrtp using existing interfaces. -Ekr From ekr@rtfm.com Thu Jan 12 06:41:27 2012 Return-Path: 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 2FCBD21F8603 for ; Thu, 12 Jan 2012 06:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 rwqFwYUTv6Z2 for ; Thu, 12 Jan 2012 06:41:26 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62521F8602 for ; Thu, 12 Jan 2012 06:41:26 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1623811vcb.31 for ; Thu, 12 Jan 2012 06:41:26 -0800 (PST) Received: by 10.220.148.196 with SMTP id q4mr2161134vcv.42.1326379286219; Thu, 12 Jan 2012 06:41:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Thu, 12 Jan 2012 06:40:45 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: <1A996A85-7CE8-4768-B1AE-168F33145135@edvina.net> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <1A996A85-7CE8-4768-B1AE-168F33145135@edvina.net> From: Eric Rescorla Date: Thu, 12 Jan 2012 06:40:45 -0800 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP DTLS - SIPit X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 14:41:27 -0000 On Thu, Jan 12, 2012 at 2:05 AM, Olle E. Johansson wrote: > Another reason I heard mostly from hardware device vendors was that the chips vendors lack support of DTLS. Aside from the question here, I'd be interested to talk to vendors who have this concern. The hardware interfaces for DTLS are very similar to those for DTLS. Indeed, if you're just doing asymmetric key acceleration they are identical. So, please feel free to point anyone like this to me and I'll be happy to try to help. -Ekr From hannes.tschofenig@gmx.net Thu Jan 12 07:00:03 2012 Return-Path: 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 4F10421F847A for ; Thu, 12 Jan 2012 07:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 c4oW0PbztJNf for ; Thu, 12 Jan 2012 07:00:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4994321F846E for ; Thu, 12 Jan 2012 07:00:02 -0800 (PST) Received: (qmail invoked by alias); 12 Jan 2012 14:59:59 -0000 Received: from unknown (EHLO [10.255.133.35]) [192.100.123.77] by mail.gmx.net (mp021) with SMTP; 12 Jan 2012 15:59:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IhAswWjMI4FUVRHabuGveNEIhWbUWfkMrMMkZWB eUcgzV5m4rHyCQ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 12 Jan 2012 16:59:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <781D922C-AF85-495D-AA98-20CED76E53C0@gmx.net> References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <1A996A85-7CE8-4768-B1AE-168F33145135@edvina.net> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: randell-ietf@jesup.org, rtcweb@ietf.org Subject: Re: [rtcweb] SRTP DTLS - SIPit X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 15:00:03 -0000 Hi Ekr, Hi Olle,=20 I am also interested to hear why vendors want to put support support for = DTLS into their chip. I would rather assume that they want to have the = SRTP support in hardware and use hardware support for some selected = functions of the key exchange (instead of implementing the entire = protocol).=20 I believe that there is a confusion about DTLS-SRTP from how the design = looked like initionally when the DTLS record layer was used; the design = was later changed to support SRTP and to use DTLS to create the SRTP = security associations.=20 Ciao Hannes On Jan 12, 2012, at 4:40 PM, Eric Rescorla wrote: > On Thu, Jan 12, 2012 at 2:05 AM, Olle E. Johansson = wrote: >> Another reason I heard mostly from hardware device vendors was that = the chips vendors lack support of DTLS. >=20 > Aside from the question here, I'd be interested to talk to vendors who > have this concern. > The hardware interfaces for DTLS are very similar to those for DTLS. > Indeed, if you're > just doing asymmetric key acceleration they are identical. So, please > feel free to > point anyone like this to me and I'll be happy to try to help. >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Jan 12 08:19:03 2012 Return-Path: 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 B37E221F859A for ; Thu, 12 Jan 2012 08:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 7suvu1ec-CSg for ; Thu, 12 Jan 2012 08:19:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C766921F84F1 for ; Thu, 12 Jan 2012 08:19:02 -0800 (PST) Received: by ggnr5 with SMTP id r5so1245507ggn.31 for ; Thu, 12 Jan 2012 08:19:02 -0800 (PST) Received: by 10.50.181.197 with SMTP id dy5mr4780043igc.13.1326385141832; Thu, 12 Jan 2012 08:19:01 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id py9sm9464318igc.2.2012.01.12.08.18.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:18:58 -0800 (PST) Received: by dajz8 with SMTP id z8so1573940daj.31 for ; Thu, 12 Jan 2012 08:18:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.122.225 with SMTP id lv1mr9448328pbb.68.1326385136681; Thu, 12 Jan 2012 08:18:56 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 12 Jan 2012 08:18:56 -0800 (PST) In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0EA4BA.5040809@alvestrand.no> Date: Thu, 12 Jan 2012 11:18:56 -0500 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=e89a8f64650be8414604b6571a70 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 16:19:03 -0000 --e89a8f64650be8414604b6571a70 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 12, 2012 at 9:37 AM, Eric Rescorla wrote: > DTLS-SRTP was specifically designed so that one could put together a DTLS > stack and an SRTP stack with minimal modifications to both (and no > necessary > modifications to the SRTP stack). In the case of OpenSSL and libsrtp, you > do the OpenSSL handshake, then use a new interface to export the keys > which you then push onto libsrtp using existing interfaces. > > My point is if you use OpenSSL crypto functions you can replace libsrtp with a few hundred lines of code. It is almost easier then integrating with libsrtp (and introduce another instance of unoptimized encryption and check sum functions). _____________ Roman Shpount --e89a8f64650be8414604b6571a70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 12, 2012 at 9:37 A= M, Eric Rescorla <ekr@= rtfm.com> wrote:
DTLS-SRTP was specifically designed so that one could put together a DTLS stack and an SRTP stack with minimal modifications to both (and no necessar= y
modifications to the SRTP stack). In the case of OpenSSL and libsrtp, you do the OpenSSL handshake, then use a new interface to export the keys
which you then push onto libsrtp using existing interfaces.

My point is if you use OpenSSL crypto functions you = can replace libsrtp with a few hundred lines of code. It is almost easier t= hen integrating with libsrtp (and introduce another instance of unoptimized= encryption and check sum functions).
_____________
Roman Shpount

--e89a8f64650be8414604b6571a70-- From oscar.ohlsson@ericsson.com Thu Jan 12 13:42:29 2012 Return-Path: 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 0767421F8624 for ; Thu, 12 Jan 2012 13:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 6b3MHqYisbIr for ; Thu, 12 Jan 2012 13:42:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 269B421F8603 for ; Thu, 12 Jan 2012 13:42:27 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-ed-4f0f53bec398 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.FD.09514.EB35F0F4; Thu, 12 Jan 2012 22:42:22 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.39]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 12 Jan 2012 22:42:22 +0100 From: Oscar Ohlsson To: Randell Jesup Date: Thu, 12 Jan 2012 22:42:20 +0100 Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AczQs5vpTXZmEjB2S+60FT04+bQtOwAvsdEQ Message-ID: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> In-Reply-To: <4F0E125D.8000605@jesup.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 21:42:29 -0000 =20 Randall said: > I'd like to explore the possibility of making sure there's a=20 > workable DTLS-SRTP implementation openly available, and=20 > locking WebRTC down to that only. >=20 > If we use SDES, we're effectively trusting the JS app (and=20 > website) to a very large extent. (Not to turn on the=20 > camera/mic, but with the contents of all conversations.) It=20 > also means bid-down to SDES is trivial. I'm not sure what=20 > this would mean to identity validation via BrowserID or=20 > others (ekr?); that might survive this, but it means media=20 > could be decrypted in realtime or later if anyone has copies=20 > of the packets and can get the key from the app/website. As has been pointed out many times before it is not significantly harder to= eavesdrop on a SDES call than a DTLS-SRTP call. When comparing SDES to DTL= S-SRTP the comparison should really be made with plain DTLS-SRTP without ke= y continuity or the new identity mechanism. There are a number of reasons why key continuity doesn't work in a web cont= ext. EKR mention the problem of multiple browsers but there are other issue= s as well (e.g., public key not bound to an id, an increasing amount of pub= lic keys stored over time, anonymous users with one time public keys, etc).= It is therefore unlikely that the user will react if the peer's fingerprin= t is replaced by the web application. The new identity mechanism doesn't help eiter unless it is made mandatory t= o use. In the same way as the web application can downgrade from DTLS-SRTP = to SDES it can downgrade from DTLS-SRTP+identity to plain DTLS-SRTP. I doub= t that the identity mechanism can be made mandatory since: (1) Many web applications do not want to depend on external identity provid= ers (2) Some users do not have any identity provider account (3) Many web applications are already trusted by the user (4) Users may not always want to reveal their identity (5) Working out all the details of the identity mechanism will take time Protecting ourselves against the web application would also require disabli= ng (or at least require user consent for) lots of useful JavaScript functio= nality (e.g. forwarding, manipulation, or recording of streams). The bottom= line is that (except in the case of security aware users) the web applicat= ion will be able to eavesdrop on calls. I know that logging and cross-site scripting has been pointed out as potent= ial vulnerabilities for SDES. These two problems should be properly analyze= d but let's defer that discussion for now.=20 Regards, Oscar Ohlsson= From randell-ietf@jesup.org Thu Jan 12 13:55:33 2012 Return-Path: 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 0950021F865F for ; Thu, 12 Jan 2012 13:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] 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 x2BtnMxe2VBz for ; Thu, 12 Jan 2012 13:55:32 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2EF21F865B for ; Thu, 12 Jan 2012 13:55:32 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RlScN-0007gz-Ux for rtcweb@ietf.org; Thu, 12 Jan 2012 15:55:32 -0600 Message-ID: <4F0F56AE.80306@jesup.org> Date: Thu, 12 Jan 2012 16:54:54 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0EA4BA.5040809@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 21:55:33 -0000 On 1/12/2012 11:18 AM, Roman Shpount wrote: > > On Thu, Jan 12, 2012 at 9:37 AM, Eric Rescorla > wrote: > > DTLS-SRTP was specifically designed so that one could put together a > DTLS > stack and an SRTP stack with minimal modifications to both (and no > necessary > modifications to the SRTP stack). In the case of OpenSSL and > libsrtp, you > do the OpenSSL handshake, then use a new interface to export the keys > which you then push onto libsrtp using existing interfaces. > > My point is if you use OpenSSL crypto functions you can replace libsrtp > with a few hundred lines of code. It is almost easier then integrating > with libsrtp (and introduce another instance of unoptimized encryption > and check sum functions). I'm not tied to libsrtp - though I have commit privileges for it, and made a bunch of improvements and fixes to it back in the 2004-2005 timeframe (SRTCP was broken, remove dependence on long long, etc), since which point (around 2006) it's been very stable outside of a very occasional patch. Last set of changes generally seem to be around a year and half ago by Jonathan Lennox. (A few minor C99 changes this fall). It does the job. Perhaps you can replace it with a few hundred lines of OpenSSL code; I have to say I'd be surprised. But srtp.c is ~2000 lines; I can believe OpenSSL would replace most of the crypto files; you'd still need much of the logic in srtp.c and perhaps the replay code. And realize we're not specifying libsrtp, just SRTP - so your comment that libsrtp can be replaced with OpenSSL plus some code is simply more indication that SRTP implementations are not a blocker. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Thu Jan 12 14:18:04 2012 Return-Path: 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 DAC8D11E80A3 for ; Thu, 12 Jan 2012 14:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 m7Oc+J0k2BRE for ; Thu, 12 Jan 2012 14:18:04 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA4C211E8073 for ; Thu, 12 Jan 2012 14:18:03 -0800 (PST) Received: by ghbg2 with SMTP id g2so677956ghb.31 for ; Thu, 12 Jan 2012 14:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ac7ly69F6n8YhJ1Swq7esSvwcwyomEZr8sjGq+V5B44=; b=ldgJdItAf1jUS13+Y3R65jebDKO/C6w+dxx7oM0J4hBkecuWF46BQchl4PQgkTMFcG 1sxo/AT4HmcD2t+3sPA9OHRJwqUsy40yBaG+DuSgwUSIxO9Qw8e+I8qfH3GKPTM07mIy KdMon4W8QOjwKlMX/mJn84WaOZQ6aU9m20LV0= MIME-Version: 1.0 Received: by 10.236.152.35 with SMTP id c23mr8507281yhk.58.1326406683467; Thu, 12 Jan 2012 14:18:03 -0800 (PST) Received: by 10.236.116.165 with HTTP; Thu, 12 Jan 2012 14:18:03 -0800 (PST) In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> Date: Thu, 12 Jan 2012 14:18:03 -0800 Message-ID: From: Ted Hardie To: Oscar Ohlsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 22:18:05 -0000 On Thu, Jan 12, 2012 at 1:42 PM, Oscar Ohlsson wrote: > > > > There are a number of reasons why key continuity doesn't work in a web co= ntext. EKR mention the problem of multiple browsers but there are other iss= ues as well (e.g., public key not bound to an id, an increasing amount of p= ublic keys stored over time, anonymous users with one time public keys, etc= ). It is therefore unlikely that the user will react if the peer's fingerpr= int is replaced by the web application. > > The new identity mechanism doesn't help eiter unless it is made mandatory= to use. In the same way as the web application can downgrade from DTLS-SRT= P to SDES it can downgrade from DTLS-SRTP+identity to plain DTLS-SRTP. I do= ubt that the identity mechanism can be made mandatory since: > I think this points out something I had assumed, but not be well-stated anywhere: that any identity associations are stored outside the javascript applications. My mental model for that had been the "known_hosts" file you find in .ssh directories in unix systems; I had imagined that a browser or an OS would store the associations. That doesn't give you great guarantees about identity, but it does give you reasonable guarantees about persistence of identity. To put this another way, with this, I think the bid-down attack is really effective only the first time the association is created. There is always the UI problem of how to notify folks when the association cannot be validated by the stored data, but I think that's a separate problem. Had you not assumed that, or are you drawing different conclusions of the result of its availablity? Ted From ekr@rtfm.com Thu Jan 12 14:22:06 2012 Return-Path: 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 7ECA211E80A2 for ; Thu, 12 Jan 2012 14:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 XTgGca4H4T4P for ; Thu, 12 Jan 2012 14:22:06 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D721911E8073 for ; Thu, 12 Jan 2012 14:22:05 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2025834vcb.31 for ; Thu, 12 Jan 2012 14:22:05 -0800 (PST) Received: by 10.220.230.6 with SMTP id jk6mr3124038vcb.62.1326406925309; Thu, 12 Jan 2012 14:22:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Thu, 12 Jan 2012 14:21:24 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> From: Eric Rescorla Date: Thu, 12 Jan 2012 14:21:24 -0800 Message-ID: To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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, 12 Jan 2012 22:22:06 -0000 On Thu, Jan 12, 2012 at 2:18 PM, Ted Hardie wrote: > On Thu, Jan 12, 2012 at 1:42 PM, Oscar Ohlsson > wrote: >> >> >> >> There are a number of reasons why key continuity doesn't work in a web c= ontext. EKR mention the problem of multiple browsers but there are other is= sues as well (e.g., public key not bound to an id, an increasing amount of = public keys stored over time, anonymous users with one time public keys, et= c). It is therefore unlikely that the user will react if the peer's fingerp= rint is replaced by the web application. >> >> The new identity mechanism doesn't help eiter unless it is made mandator= y to use. In the same way as the web application can downgrade from DTLS-SR= TP to SDES it can downgrade from DTLS-SRTP+identity to plain DTLS-SRTP. I d= oubt that the identity mechanism can be made mandatory since: >> > > I think this points out something I had assumed, but not be > well-stated anywhere: =A0that any identity associations are stored > outside the javascript applications. =A0My mental model for that had > been the "known_hosts" file you find in .ssh directories in unix > systems; I had imagined that a browser or an OS would store the > associations. =A0That doesn't give you great guarantees about identity, > but it does give you reasonable guarantees about persistence of > identity. =A0To put this another way, with this, I think the bid-down > attack is really effective only the first time the association is > created. > > There is always the UI problem of how to notify folks when the > association cannot be validated by the stored data, but I think that's > a separate problem. > > Had you not assumed that, or are you drawing different conclusions of > the result of its availablity? More generally, identity assertions should be enforced in the browser or the OS. This is true whether they are key continuity (which, as Oscar says, is not the world's greatest mechanism and is primarily usable by the security conscious) or a 3rd-party identity mechanism of the type that is discussed in my draft. -Ekr From harald@alvestrand.no Fri Jan 13 06:19:51 2012 Return-Path: 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 D2BC021F8617 for ; Fri, 13 Jan 2012 06:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NSxbY2Lsv+lW for ; Fri, 13 Jan 2012 06:19:51 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFDB21F8628 for ; Fri, 13 Jan 2012 06:19:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 190EE39E163; Fri, 13 Jan 2012 15:19:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48pL+96OCcpX; Fri, 13 Jan 2012 15:19:49 +0100 (CET) Received: from [192.168.1.2] (unknown [46.249.236.98]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AEBDC39E04C; Fri, 13 Jan 2012 15:19:49 +0100 (CET) Message-ID: <4F103D86.2040005@alvestrand.no> Date: Fri, 13 Jan 2012 15:19:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Oscar Ohlsson References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Fri, 13 Jan 2012 14:19:51 -0000 On 01/12/2012 10:42 PM, Oscar Ohlsson wrote: > > As has been pointed out many times before it is not significantly harder to eavesdrop on a SDES call than a DTLS-SRTP call. When comparing SDES to DTLS-SRTP the comparison should really be made with plain DTLS-SRTP without key continuity or the new identity mechanism. Sorry, I couldn't parse that. Are you saying that it is harder (but not significantly harder) to eavesdrop on a call with key exchange using SDES than it is to eavesdrop on a call with key exchange using DTLS-SRTP? That didn't compute for me - did something get inverted somewhere? (I don't feel confident enough in the ways of key exchanges that I want to assume that it's a simple inversion - but I think it's strictly harder to eavesdrop on DTLS-SRTP than on SDES; with DTLS-SRTP you have to do a man-in-the-middle on the key exchange + finagling with the confirmation bits sent via the signalling, while in the SDES case, you only need to eavesdrop on the signalling, which is strictly a simpler operation. Not saying that the difference is significant). Harald From oscar.ohlsson@ericsson.com Fri Jan 13 08:09:51 2012 Return-Path: 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 D233221F8606 for ; Fri, 13 Jan 2012 08:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dPnx+tBP3HLG for ; Fri, 13 Jan 2012 08:09:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BAF4821F85E9 for ; Fri, 13 Jan 2012 08:09:48 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-ba-4f10574adf78 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F4.2C.09514.A47501F4; Fri, 13 Jan 2012 17:09:47 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.39]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 13 Jan 2012 17:09:41 +0100 From: Oscar Ohlsson To: Harald Alvestrand Date: Fri, 13 Jan 2012 17:09:39 +0100 Thread-Topic: [rtcweb] SRTP not mandatory-to-use Thread-Index: AczR/mnPm9NVZ1BXTTmjfcwU1V4r/QADk3EQ Message-ID: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> <4F103D86.2040005@alvestrand.no> In-Reply-To: <4F103D86.2040005@alvestrand.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP not mandatory-to-use X-BeenThere: rtcweb@ietf.org 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: Fri, 13 Jan 2012 16:09:52 -0000 Sorry, yes it should be the other way around. I agree that eavesdropping on a DTLS-SDES call is harder and would require = a greater (initial) coding effort. But the difference is not huge as some e= mails seem to suggest. 1. Search for 'a=3Dfingerprint:' in the offer/answer SDP string and replace= what comes after with your own public key fingerprint (a single, staticall= y configured public key would probably do if synching with the TURN server = is hard) 2. Force the media to go through the TURN server by deleting all ICE candid= ates except the relayed one (if deleting is not possible another option is = to replace the candidates with bogus ones) 3. Modify an existing TURN server implementation so that it decrypts and re= -encrypts the DTLS traffic Regards, Oscar Ohlsson=20 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: den 13 januari 2012 15:20 > To: Oscar Ohlsson > Cc: Randell Jesup; rtcweb@ietf.org > Subject: Re: [rtcweb] SRTP not mandatory-to-use >=20 > On 01/12/2012 10:42 PM, Oscar Ohlsson wrote: > > > > As has been pointed out many times before it is not=20 > significantly harder to eavesdrop on a SDES call than a=20 > DTLS-SRTP call. When comparing SDES to DTLS-SRTP the=20 > comparison should really be made with plain DTLS-SRTP without=20 > key continuity or the new identity mechanism. > Sorry, I couldn't parse that. >=20 > Are you saying that it is harder (but not significantly=20 > harder) to eavesdrop on a call with key exchange using SDES=20 > than it is to eavesdrop on a call with key exchange using DTLS-SRTP? > That didn't compute for me - did something get inverted somewhere? >=20 > (I don't feel confident enough in the ways of key exchanges=20 > that I want to assume that it's a simple inversion - but I=20 > think it's strictly harder to eavesdrop on DTLS-SRTP than on=20 > SDES; with DTLS-SRTP you have to do a man-in-the-middle on=20 > the key exchange + finagling with the confirmation bits sent=20 > via the signalling, while in the SDES case, you only need to=20 > eavesdrop on the signalling, which is strictly a simpler=20 > operation. Not saying that the difference is significant). >=20 > Harald >=20 > = From bernard_aboba@hotmail.com Mon Jan 16 08:51:42 2012 Return-Path: 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 35FF721F85AD for ; Mon, 16 Jan 2012 08:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.009 X-Spam-Level: X-Spam-Status: No, score=-101.009 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_50=0.001, 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 UxngXHToDe2t for ; Mon, 16 Jan 2012 08:51:41 -0800 (PST) Received: from blu0-omc1-s14.blu0.hotmail.com (blu0-omc1-s14.blu0.hotmail.com [65.55.116.25]) by ietfa.amsl.com (Postfix) with ESMTP id 675C221F84E2 for ; Mon, 16 Jan 2012 08:51:41 -0800 (PST) Received: from BLU152-W31 ([65.55.116.9]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 08:51:41 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_0536d2e4-a8eb-4434-8c6e-b7f11dfe3606_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Mon, 16 Jan 2012 08:51:40 -0800 Importance: Normal In-Reply-To: References: , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com>, , <4F0CAC8C.8010203@wonderhamster.org>, <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org>, , <4F0E125D.8000605@jesup.org>, , <4F103D86.2040005@alvestrand.no>, MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2012 16:51:41.0012 (UTC) FILETIME=[1ECD2140:01CCD46F] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security analysis of RTCWEB X-BeenThere: rtcweb@ietf.org 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: Mon, 16 Jan 2012 16:51:42 -0000 --_0536d2e4-a8eb-4434-8c6e-b7f11dfe3606_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This discussion illustrates some of the issues that arise in analyzing the = security of SIP-based functionality re-purposed for RTCWEB. If we assume t= hat signaling is not implemented natively=2C then we cannot depend on funct= ionality provided within signalling in our security analysis. This implie= s that the security properties of ICE=2C DTLS/SRTP=2C etc. can be different= in RTCWEB than they would be within SIP. In contrast=2C the security pro= perties of media-only approaches such as ZRTP are the same regardless of th= e signalling approach (e.g. SIP=2C Jingle=2C etc.). =20 Within DTLS/SRTP as used in SIP=2C RFC 4474 is utilized to provide end-to-e= nd integrity of the SDP and address the man-in-the-middle attack you refer = to below. In a scenario where an RTCWEB application needed to interoperat= e with a DTLS/SRTP implementation utilizing SIP=2C presumably RFC 4474 woul= d be supported.=20 However=2C if SIP is not implemented natively=2C then an alternative mechan= ism is needed. As you point out below=2C the identity provider approach de= scribed in the security draft does not address all of the potential attacks= that are handled by RFC 4474 (e.g. ICE mangling). =20 > Sorry=2C yes it should be the other way around. >=20 > I agree that eavesdropping on a DTLS-SRTP call is harder and would requir= e a greater (initial) coding effort. But the difference is not huge as some= emails seem to suggest. >=20 > 1. Search for 'a=3Dfingerprint:' in the offer/answer SDP string and repla= ce what comes after with your own public key fingerprint (a single=2C stati= cally configured public key would probably do if synching with the TURN ser= ver is hard) >=20 > 2. Force the media to go through the TURN server by deleting all ICE cand= idates except the relayed one (if deleting is not possible another option i= s to replace the candidates with bogus ones) >=20 > 3. Modify an existing TURN server implementation so that it decrypts and = re-encrypts the DTLS traffic >=20 > Regards=2C >=20 > Oscar Ohlsson=20 = --_0536d2e4-a8eb-4434-8c6e-b7f11dfe3606_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This discussion illustrates some of the issues that arise in analyzing the = security of SIP-based functionality re-purposed for RTCWEB. =3B If we a= ssume that signaling is not implemented natively=2C then we cannot depend o= n functionality provided within signalling in our security analysis. = =3B =3B This implies that the security properties of ICE=2C DTLS/SRTP= =2C etc. can be different in RTCWEB than they would be within SIP. =3B&= nbsp=3B In contrast=2C the security properties of media-only approaches suc= h as ZRTP are the same regardless of the signalling approach (e.g. SIP=2C J= ingle=2C etc.). =3B

Within DTLS/SRTP as used in SIP=2C RFC 4474= is utilized to provide end-to-end integrity of the SDP and address the man= -in-the-middle attack you refer to below. =3B =3B In a scenario whe= re an RTCWEB application needed to interoperate with a DTLS/SRTP implementa= tion utilizing SIP=2C presumably RFC 4474 would be supported.

Howev= er=2C if SIP is not implemented natively=2C then an alternative mechanism i= s needed. =3B As you point out below=2C the identity provider approach = described in the security draft does not address all of the potential attac= ks that are handled by RFC 4474 (e.g. ICE mangling). =3B

&= gt=3B Sorry=2C yes it should be the other way around.
>=3B
>=3B = I agree that eavesdropping on a DTLS-SRTP call is harder and would require = a greater (initial) coding effort. But the difference is not huge as some e= mails seem to suggest.
>=3B
>=3B 1. Search for 'a=3Dfingerprint:= ' in the offer/answer SDP string and replace what comes after with your own= public key fingerprint (a single=2C statically configured public key would= probably do if synching with the TURN server is hard)
>=3B
>=3B= 2. Force the media to go through the TURN server by deleting all ICE candi= dates except the relayed one (if deleting is not possible another option is= to replace the candidates with bogus ones)
>=3B
>=3B 3. Modify = an existing TURN server implementation so that it decrypts and re-encrypts = the DTLS traffic
>=3B
>=3B Regards=2C
>=3B
>=3B Oscar= Ohlsson

= --_0536d2e4-a8eb-4434-8c6e-b7f11dfe3606_-- From ekr@rtfm.com Mon Jan 16 09:32:11 2012 Return-Path: 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 8C7E921F85B7 for ; Mon, 16 Jan 2012 09:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 2KhCRK9RZmPG for ; Mon, 16 Jan 2012 09:32:10 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2B9721F8605 for ; Mon, 16 Jan 2012 09:32:10 -0800 (PST) Received: by vbmv11 with SMTP id v11so371451vbm.31 for ; Mon, 16 Jan 2012 09:32:10 -0800 (PST) Received: by 10.52.94.208 with SMTP id de16mr6542372vdb.6.1326735130268; Mon, 16 Jan 2012 09:32:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.185.227 with HTTP; Mon, 16 Jan 2012 09:31:29 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> <4F103D86.2040005@alvestrand.no> From: Eric Rescorla Date: Mon, 16 Jan 2012 09:31:29 -0800 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security analysis of RTCWEB X-BeenThere: rtcweb@ietf.org 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: Mon, 16 Jan 2012 17:32:11 -0000 On Mon, Jan 16, 2012 at 8:51 AM, Bernard Aboba wrote: > This discussion illustrates some of the issues that arise in analyzing th= e > security of SIP-based functionality re-purposed for RTCWEB.=A0 If we assu= me > that signaling is not implemented natively, then we cannot depend on > functionality provided within signalling in our security analysis.=A0=A0 = This > implies that the security properties of ICE, DTLS/SRTP, etc. can be > different in RTCWEB than they would be within SIP.=A0=A0 In contrast, the > security properties of media-only approaches such as ZRTP are the same > regardless of the signalling approach (e.g. SIP, Jingle, etc.). > > Within DTLS/SRTP as used in SIP, RFC 4474 is utilized to provide end-to-e= nd > integrity of the SDP and address the man-in-the-middle attack you refer t= o > below.=A0=A0 In a scenario where an RTCWEB application needed to interope= rate > with a DTLS/SRTP implementation utilizing SIP, presumably RFC 4474 would = be > supported. > > However, if SIP is not implemented natively, then an alternative mechanis= m > is needed.=A0 As you point out below, the identity provider approach desc= ribed > in the security draft does not address all of the potential attacks that = are > handled by RFC 4474 (e.g. ICE mangling). I'm not tracking this argument at all: 1. If you have end-to-end integrity for the keying material, then providing end-to-end security for the ICE candidates only offers modest additional value, since all it does is prevent rerouting of the ciphertext. 2. There's no technical reason why the IdP-based approach detailed in Appendix A can't cover the ICE candidates as well. Indeed, it's natural to have it cover as much of the message as possible. However, since we haven't yet settled on the signaling protocol, it's also not possible to settle on the exact inputs to the signature. However, the minimum necessary is the public key of the side. 3. In the RTCWEB setting, since the STUN and TURN servers are likely to be supplied by the signaling site, it's probably not that difficult for = a malicious signaling server to simply provide STUN and TURN responses which reroute the traffic through it without tampering with the ICE candidates at all. E.g., it provides a bogus server-reflexive address, thus forcing ICE to converge on its TURN server. -Ekr >> Sorry, yes it should be the other way around. >> >> I agree that eavesdropping on a DTLS-SRTP call is harder and would requi= re >> a greater (initial) coding effort. But the difference is not huge as som= e >> emails seem to suggest. >> >> 1. Search for 'a=3Dfingerprint:' in the offer/answer SDP string and repl= ace >> what comes after with your own public key fingerprint (a single, statica= lly >> configured public key would probably do if synching with the TURN server= is >> hard) >> >> 2. Force the media to go through the TURN server by deleting all ICE >> candidates except the relayed one (if deleting is not possible another >> option is to replace the candidates with bogus ones) >> >> 3. Modify an existing TURN server implementation so that it decrypts and >> re-encrypts the DTLS traffic >> >> Regards, >> >> Oscar Ohlsson > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From igor.faynberg@alcatel-lucent.com Mon Jan 16 09:51:39 2012 Return-Path: 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 2055221F860D for ; Mon, 16 Jan 2012 09:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0qk22BElUp6Q for ; Mon, 16 Jan 2012 09:51:38 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AD44F21F860B for ; Mon, 16 Jan 2012 09:51:37 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0GHpaTg024866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Jan 2012 11:51:37 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0GHpavP024166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Jan 2012 11:51:36 -0600 Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0GHpamG019965; Mon, 16 Jan 2012 11:51:36 -0600 (CST) Message-ID: <4F1463A8.7010201@alcatel-lucent.com> Date: Mon, 16 Jan 2012 12:51:36 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> <4F103D86.2040005@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Security analysis of RTCWEB X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com 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: Mon, 16 Jan 2012 17:51:39 -0000 Exactly! On 1/16/2012 12:31 PM, Eric Rescorla wrote: > ... > 2. There's no technical reason why the IdP-based approach detailed in > Appendix A can't cover the ICE candidates as well. Indeed, it's natural > to have it cover as much of the message as possible. From bernard_aboba@hotmail.com Mon Jan 16 09:58:04 2012 Return-Path: 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 AFB5621F867E for ; Mon, 16 Jan 2012 09:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.328, 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 3Z+RLXXevbhL for ; Mon, 16 Jan 2012 09:58:04 -0800 (PST) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F221F867D for ; Mon, 16 Jan 2012 09:58:04 -0800 (PST) Received: from BLU152-W6 ([65.55.111.73]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Jan 2012 09:58:04 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b9738b9b-8014-4b4f-a894-5864af9f83c3_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Mon, 16 Jan 2012 09:58:03 -0800 Importance: Normal In-Reply-To: References: , , <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> , <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com>, <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com>, , <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com>, , <4F0DFD0B.2000009@jesup.org> <4F0E125D.8000605@jesup.org> , <4F103D86.2040005@alvestrand.no> , , MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2012 17:58:04.0042 (UTC) FILETIME=[64DF46A0:01CCD478] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security analysis of RTCWEB X-BeenThere: rtcweb@ietf.org 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: Mon, 16 Jan 2012 17:58:04 -0000 --_b9738b9b-8014-4b4f-a894-5864af9f83c3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric said:=20 > 2. There's no technical reason why the IdP-based approach detailed in > Appendix A can't cover the ICE candidates as well. Indeed=2C it's natural > to have it cover as much of the message as possible. However=2C > since we haven't yet settled on the signaling protocol=2C it's also not > possible to settle on the exact inputs to the signature. However=2C the > minimum necessary is the public key of the side. [BA] I agree that it makes sense to cover as much of the message as possible. However=2C I'd also suggest that it is undesirable to tie RTCWE= B key management to particular signaling mechanisms. =20 = --_b9738b9b-8014-4b4f-a894-5864af9f83c3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eric said:

>=3B 2. There's no technical reason why the IdP-b= ased approach detailed in
>=3B Appendix A can't cover the ICE candidat= es as well. Indeed=2C it's natural
>=3B to have it cover as much of th= e message as possible. However=2C
>=3B since we haven't yet settled on= the signaling protocol=2C it's also not
>=3B possible to settle on th= e exact inputs to the signature. However=2C the
>=3B minimum necessary= is the public key of the side.

[BA] I agree that it makes sense to = cover as much of the message as
possible. =3B =3B However=2C I'd= also suggest that it is undesirable to tie RTCWEB
key management to par= ticular signaling mechanisms. =3B
= --_b9738b9b-8014-4b4f-a894-5864af9f83c3_-- From harald@alvestrand.no Tue Jan 17 04:18:21 2012 Return-Path: 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 9A29D21F85E4 for ; Tue, 17 Jan 2012 04:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ZvoJFBVjYMH7 for ; Tue, 17 Jan 2012 04:18:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1421F85DF for ; Tue, 17 Jan 2012 04:18:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4406239E0FD for ; Tue, 17 Jan 2012 13:18:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIUTAd+1TkGt for ; Tue, 17 Jan 2012 13:18:17 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B495139E048 for ; Tue, 17 Jan 2012 13:18:17 +0100 (CET) Message-ID: <4F156709.9030604@alvestrand.no> Date: Tue, 17 Jan 2012 13:18:17 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 12:18:21 -0000 This came up in an off-list discussion, but I think it should be on our open issues list: When a sender mutes a stream, what happens at the receiving end? Either the stream will continue to send data (black/silence), or it doesn't. If it continues, no problem. If it doesn't: Either the recipient knows that the non-data is intentional, or he doesn't. If he doesn't, we need to make sure nothing times out or gets out of whack because of the lack of data. If he knows it's intentional, he has to learn it somehow. Either the information comes over the media path, or over the signalling path. If it's the media path, there needs to be an RTP-level definition of what's sent to indicate it. (RTCP message, comfort noise / video equivalent, other...) If it's the signalling path, there needs to be a defined API to get the information passed up to the JS layer at the sender, and passed down from the JS layer at the recipient. Thoughts from the community? Harald From stefan.lk.hakansson@ericsson.com Tue Jan 17 05:12:51 2012 Return-Path: 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 EEE1421F8578 for ; Tue, 17 Jan 2012 05:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MCgaTzPdV5Nu for ; Tue, 17 Jan 2012 05:12:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2348E21F8554 for ; Tue, 17 Jan 2012 05:12:50 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-0f-4f1573d29879 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.25.23425.2D3751F4; Tue, 17 Jan 2012 14:12:50 +0100 (CET) Received: from [150.132.142.220] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 Jan 2012 14:12:49 +0100 Message-ID: <4F1573D0.9080809@ericsson.com> Date: Tue, 17 Jan 2012 14:12:48 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F156709.9030604@alvestrand.no> In-Reply-To: <4F156709.9030604@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 13:12:52 -0000 On 01/17/2012 01:18 PM, Harald Alvestrand wrote: > This came up in an off-list discussion, but I think it should be on our > open issues list: > > When a sender mutes a stream, what happens at the receiving end? > > Either the stream will continue to send data (black/silence), or it doesn't. > If it continues, no problem. > If it doesn't: > > Either the recipient knows that the non-data is intentional, or he doesn't. > If he doesn't, we need to make sure nothing times out or gets out of > whack because of the lack of data. > If he knows it's intentional, he has to learn it somehow. > > Either the information comes over the media path, or over the signalling > path. > If it's the media path, there needs to be an RTP-level definition of > what's sent to indicate it. (RTCP message, comfort noise / video > equivalent, other...) > If it's the signalling path, there needs to be a defined API to get the > information passed up to the JS layer at the sender, and passed down > from the JS layer at the recipient. > > Thoughts from the community? Off the top of my head: 1. I think we should do this in the media plane (RTP/RTCP) 2. Initially, the browser could interpret the absence of data (RTP and/or RTCP reports) to determine if the other end has stopped sending, and then change the state of the corresponding MediaStreamTrack(s) to "muted". This is more or less the same way as when adding a new MediaStream to PeerConnection: the MediaStream object at the receiving PeerConnection is created immediately with all MediaStreamTracks in muted state, once RTP is coming in the state is changed to not muted. 3. Perhaps special RTP or RTCP packets can be added later to indicate "muted" later - I suspect this will involve other WGs so it might take some time. Stefan > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From wolfgang.beck01@googlemail.com Tue Jan 17 05:38:18 2012 Return-Path: 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 7D9C521F85B8 for ; Tue, 17 Jan 2012 05:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 JOa3jCDBn8X3 for ; Tue, 17 Jan 2012 05:38:17 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9147021F85A0 for ; Tue, 17 Jan 2012 05:38:17 -0800 (PST) Received: by pbbb2 with SMTP id b2so4094250pbb.31 for ; Tue, 17 Jan 2012 05:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NHg02VZHiZXPhrk/bFJqIFwQ0SDS8em6MXyJfArGxjo=; b=AkqS3Pv7EQBhyyfY2amTJ9z2me/DiYR7s7ysqXsJCqs29491P628SPf4b4SIX7XDl7 lGYG04XrxHPyp7ups+jaz2HQe7nP+MGiJ6n7R2ONnmYv7BzxKxDkOGm93hKUMt82xxto LYeHbjvHE+9iN4AGULiPfkIubc3MIi5ats0Rg= MIME-Version: 1.0 Received: by 10.68.74.69 with SMTP id r5mr34885961pbv.118.1326807497368; Tue, 17 Jan 2012 05:38:17 -0800 (PST) Received: by 10.68.197.132 with HTTP; Tue, 17 Jan 2012 05:38:17 -0800 (PST) In-Reply-To: <4F156709.9030604@alvestrand.no> References: <4F156709.9030604@alvestrand.no> Date: Tue, 17 Jan 2012 14:38:17 +0100 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 13:38:18 -0000 On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand wrote: > This came up in an off-list discussion, but I think it should be on our open > issues list: > > When a sender mutes a stream, what happens at the receiving end? > It's the signalling discussion again. If you tunnel SDP through HTTP and some some server-to-server protocol, you just use the SDP mechanism to mute one side. Without server-to-server protocol, you only need an API call to pause sending of RTP packets. How this is signaled to the remote party is up the JS client and server. Moving parts of the SDP functionality to RTP would break compatibility with existing systems. Which was the main argument for sticking with SDP.. Wolfgang Beck From harald@alvestrand.no Tue Jan 17 05:51:55 2012 Return-Path: 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 AD76221F84D2 for ; Tue, 17 Jan 2012 05:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 m6r6CCTXqcXj for ; Tue, 17 Jan 2012 05:51:55 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6421F84CD for ; Tue, 17 Jan 2012 05:51:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5D5C439E08A; Tue, 17 Jan 2012 14:51:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlQa6BK7vbAF; Tue, 17 Jan 2012 14:51:53 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B78FC39E048; Tue, 17 Jan 2012 14:51:53 +0100 (CET) Message-ID: <4F157CF9.3090304@alvestrand.no> Date: Tue, 17 Jan 2012 14:51:53 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Wolfgang Beck References: <4F156709.9030604@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 13:51:55 -0000 On 01/17/2012 02:38 PM, Wolfgang Beck wrote: > On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand wrote: >> This came up in an off-list discussion, but I think it should be on our open >> issues list: >> >> When a sender mutes a stream, what happens at the receiving end? >> > It's the signalling discussion again. > > If you tunnel SDP through HTTP and some some server-to-server > protocol, you just use the SDP mechanism to mute one side. Which SDP mechanism are you recommending? (RFC and section) > Without server-to-server protocol, you only need an API call to pause > sending of RTP packets. How this is signaled to the remote party is up > the JS client and server. > > Moving parts of the SDP functionality to RTP would break compatibility > with existing systems. Which was the main argument for sticking with > SDP.. So your answer is "API, and use an SDP mechanism". Thanks for the clarity! > > Wolfgang Beck > From pravindran@sonusnet.com Tue Jan 17 06:27:57 2012 Return-Path: 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 492C621F86C4 for ; Tue, 17 Jan 2012 06:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 BQfNBppliVcU for ; Tue, 17 Jan 2012 06:27:56 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2921F86D6 for ; Tue, 17 Jan 2012 06:27:56 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0HESYi0021119; Tue, 17 Jan 2012 09:28:34 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 09:27:50 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 19:58:47 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Tue, 17 Jan 2012 19:58:46 +0530 From: "Ravindran, Parthasarathi" To: Harald Alvestrand , Wolfgang Beck Thread-Topic: [rtcweb] Open issue: Signaling muted streams Thread-Index: AQHM1SRRa2WO4urvJEKAirjgvWvN5A== Date: Tue, 17 Jan 2012 14:28:45 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD13D1@inba-mail02.sonusnet.com> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> In-Reply-To: <4F157CF9.3090304@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 14:28:47.0136 (UTC) FILETIME=[52C93A00:01CCD524] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signaling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 14:27:57 -0000 Harald, Hope the point of discussion is "Signaling Hold" and it will be solved by S= DP mechanism (by inactive direction attribute) as you mentioned below. AFAIK, Mute operation normally does not involve any signaling and stop send= ing the media from the endpoint (browser in WebRTC). In case mute operation= is required in WebRTC, ICE shall solve keep-alive mechanism in the media p= ath and mute API is required for stop transmitting the media from the local= browser. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Harald Alvestrand >Sent: Tuesday, January 17, 2012 7:22 PM >To: Wolfgang Beck >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Open issue: Signalling muted streams > >On 01/17/2012 02:38 PM, Wolfgang Beck wrote: >> On Tue, Jan 17, 2012 at 1:18 PM, Harald >Alvestrand wrote: >>> This came up in an off-list discussion, but I think it should be on >>> our open issues list: >>> >>> When a sender mutes a stream, what happens at the receiving end? >>> >> It's the signalling discussion again. >> >> If you tunnel SDP through HTTP and some some server-to-server >> protocol, you just use the SDP mechanism to mute one side. >Which SDP mechanism are you recommending? (RFC and section) >> Without server-to-server protocol, you only need an API call to pause >> sending of RTP packets. How this is signaled to the remote party is up >> the JS client and server. >> >> Moving parts of the SDP functionality to RTP would break compatibility >> with existing systems. Which was the main argument for sticking with >> SDP.. >So your answer is "API, and use an SDP mechanism". Thanks for the >clarity! >> >> Wolfgang Beck >> > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From vsingh.ietf@gmail.com Tue Jan 17 06:44:42 2012 Return-Path: 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 58EBD21F86DF for ; Tue, 17 Jan 2012 06:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 buk9p-FrSrkU for ; Tue, 17 Jan 2012 06:44:41 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47B1621F854E for ; Tue, 17 Jan 2012 06:44:41 -0800 (PST) Received: by werp11 with SMTP id p11so680921wer.31 for ; Tue, 17 Jan 2012 06:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=foBQ+d6zT8o7euThnlULFr3hL93E0U53M1LurHZyzT4=; b=CAy0nnakuZ4QYcx1cRpCLLk3bSIObLBK737R/poLLGr7W6A8p/Wx0AMO1Z0D1672aU sT/fJWbTQcddHS4ix2h228GrDaXxBSWLThBD7va2YLRgHvCiJt0mKW+zn2UEiauP+ySM 05wKFvorLjQA8kPJzbrgjz0blipmclIJF38+Y= Received: by 10.216.133.104 with SMTP id p82mr7319486wei.6.1326811480208; Tue, 17 Jan 2012 06:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.62.147 with HTTP; Tue, 17 Jan 2012 06:44:19 -0800 (PST) In-Reply-To: <4F156709.9030604@alvestrand.no> References: <4F156709.9030604@alvestrand.no> From: Varun Singh Date: Tue, 17 Jan 2012 16:44:19 +0200 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 14:44:42 -0000 Hi, Comments inline. On Tue, Jan 17, 2012 at 14:18, Harald Alvestrand wro= te: > This came up in an off-list discussion, but I think it should be on our o= pen > issues list: > > When a sender mutes a stream, what happens at the receiving end? > > Either the stream will continue to send data (black/silence), or it doesn= 't. > If it continues, no problem. > If it doesn't: > > Either the recipient knows that the non-data is intentional, or he doesn'= t. > If he doesn't, we need to make sure nothing times out or gets out of whac= k > because of the lack of data. > If he knows it's intentional, he has to learn it somehow. > > Either the information comes over the media path, or over the signalling > path. > If it's the media path, there needs to be an RTP-level definition of what= 's > sent to indicate it. (RTCP message, comfort noise / video equivalent, > other...) The sender will send RTCP sender reports to keep the session alive and if t= he "sender's packet count" does not change between two consecutive reports the receiver can guess that the stream is muted. Caveat is that the RTCP report= s are not sent as often as RTP, so a detection based on RTCP SRs will take an RTCP Interval. > If it's the signalling path, there needs to be a defined API to get the > information passed up to the JS layer at the sender, and passed down from > the JS layer at the recipient. > Defining an API may be more appropriate. > Thoughts from the community? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 http://www.netlab.tkk.fi/~varun/ From roman@telurix.com Tue Jan 17 07:17:03 2012 Return-Path: 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 0E6B921F84A0 for ; Tue, 17 Jan 2012 07:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 eqUU+h1QMBiZ for ; Tue, 17 Jan 2012 07:17:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49A0421F849B for ; Tue, 17 Jan 2012 07:17:02 -0800 (PST) Received: by ggnr5 with SMTP id r5so3752751ggn.31 for ; Tue, 17 Jan 2012 07:17:01 -0800 (PST) Received: by 10.50.168.4 with SMTP id zs4mr9389203igb.25.1326813421480; Tue, 17 Jan 2012 07:17:01 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id he16sm78225480ibb.9.2012.01.17.07.16.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 07:17:00 -0800 (PST) Received: by dakf10 with SMTP id f10so1195254dak.31 for ; Tue, 17 Jan 2012 07:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr35386738pbv.85.1326813418719; Tue, 17 Jan 2012 07:16:58 -0800 (PST) Received: by 10.68.44.197 with HTTP; Tue, 17 Jan 2012 07:16:58 -0800 (PST) In-Reply-To: <4F157CF9.3090304@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> Date: Tue, 17 Jan 2012 10:16:58 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec54693e78188a304b6bad2e6 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 15:17:03 -0000 --bcaec54693e78188a304b6bad2e6 Content-Type: text/plain; charset=ISO-8859-1 Can CN packets be used to indicate muted stream on the media plane? _____________ Roman Shpount On Tue, Jan 17, 2012 at 8:51 AM, Harald Alvestrand wrote: > On 01/17/2012 02:38 PM, Wolfgang Beck wrote: > >> On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand> >> wrote: >> >>> This came up in an off-list discussion, but I think it should be on our >>> open >>> issues list: >>> >>> When a sender mutes a stream, what happens at the receiving end? >>> >>> It's the signalling discussion again. >> >> If you tunnel SDP through HTTP and some some server-to-server >> protocol, you just use the SDP mechanism to mute one side. >> > Which SDP mechanism are you recommending? (RFC and section) > > Without server-to-server protocol, you only need an API call to pause >> sending of RTP packets. How this is signaled to the remote party is up >> the JS client and server. >> >> Moving parts of the SDP functionality to RTP would break compatibility >> with existing systems. Which was the main argument for sticking with >> SDP.. >> > So your answer is "API, and use an SDP mechanism". Thanks for the clarity! > > >> Wolfgang Beck >> >> > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec54693e78188a304b6bad2e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can CN packets be used to indicate muted stream on the media plane?
_____________
Roman Shpount


On Tue, Jan 17, 2012 at 8:51 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 01/17/2012 02:38 PM, Wolfgang Beck wrote:
On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand<harald@alvestrand.no> = =A0wrote:
This came up in an off-list discussion, but I think it should be on our ope= n
issues list:

When a sender mutes a stream, what happens at the receiving end?

It's the signalling discussion again.

If you tunnel SDP through HTTP and some some server-to-server
protocol, you just use the SDP mechanism to mute one side.
Which SDP mechanism are you recommending? (RFC and section)

Without server-to-server protocol, you only need an API call to pause
sending of RTP packets. How this is signaled to the remote party is up
the JS client and server.

Moving parts of the SDP functionality to RTP would break compatibility
with existing systems. Which was the main argument for sticking with
SDP..
So your answer is "API, and use an SDP mechanism". Thanks for the= clarity!


Wolfgang Beck


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec54693e78188a304b6bad2e6-- From randell-ietf@jesup.org Tue Jan 17 07:24:05 2012 Return-Path: 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 4C8EC21F8522 for ; Tue, 17 Jan 2012 07:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_20=-0.74] 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 puMWAaWMU3cl for ; Tue, 17 Jan 2012 07:24:04 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A4FFF21F851C for ; Tue, 17 Jan 2012 07:24:04 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RnAtH-0003kb-Pc for rtcweb@ietf.org; Tue, 17 Jan 2012 09:24:03 -0600 Message-ID: <4F159262.8030505@jesup.org> Date: Tue, 17 Jan 2012 10:23:14 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F156709.9030604@alvestrand.no> <4F1573D0.9080809@ericsson.com> In-Reply-To: <4F1573D0.9080809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 15:24:05 -0000 On 1/17/2012 8:12 AM, Stefan Hakansson LK wrote: > On 01/17/2012 01:18 PM, Harald Alvestrand wrote: >> This came up in an off-list discussion, but I think it should be on our >> open issues list: >> >> When a sender mutes a stream, what happens at the receiving end? I'll note that it's critical that muting of audio and video occur immediately, and not require any handshake with the recipient. This can be black/silence, though in practice I've found that black video is disconcerting to recipients - a visual indication of Mute is much better. In the past I've used either a textual message, or more recently a symbol of a camera with a red circle & slash. >> Either the stream will continue to send data (black/silence), or it >> doesn't. >> If it continues, no problem. In interop scenarios, it's always unclear how a receiver will react to stopping of media. Some will end a call after 10-30 seconds of no media (though hopefully RTCP reports would preclude that; they did in my implementations). >> If it doesn't: >> >> Either the recipient knows that the non-data is intentional, or he >> doesn't. >> If he doesn't, we need to make sure nothing times out or gets out of >> whack because of the lack of data. Right. >> If he knows it's intentional, he has to learn it somehow. >> >> Either the information comes over the media path, or over the signalling >> path. >> If it's the media path, there needs to be an RTP-level definition of >> what's sent to indicate it. (RTCP message, comfort noise / video >> equivalent, other...) The original Ojo used a bit in an RTCP APP status message sent when the other side muted (obviously only worked between two of our phones). We resent it several times at increasing delays to avoid packet loss issues, a bit like RFC 2833. * You could define a new RTCP message * You could define a 'status' payload ala DTMF in RTP * You could mandate that media stoppage occurs via CN, and then only if the other side agreed (audio only) * For video you could mandate sending a black IDR periodically (video rough equivalent of comfort noise). Or sending a "Mute" image by IDR periodically. (And of course your could continue to send silent/black/mute-image). There is an advantage in conferencing (and some other) scenarios to recover the bandwidth during mute. >> If it's the signalling path, there needs to be a defined API to get the >> information passed up to the JS layer at the sender, and passed down >> from the JS layer at the recipient. >> >> Thoughts from the community? > > Off the top of my head: > > 1. I think we should do this in the media plane (RTP/RTCP) > 2. Initially, the browser could interpret the absence of data (RTP > and/or RTCP reports) to determine if the other end has stopped sending, > and then change the state of the corresponding MediaStreamTrack(s) to > "muted". This is more or less the same way as when adding a new > MediaStream to PeerConnection: the MediaStream object at the receiving > PeerConnection is created immediately with all MediaStreamTracks in > muted state, once RTP is coming in the state is changed to not muted. Mute->non-mute is easier (though note that 'muted' reception tracks is not the same as 'muted' at the far end, and so shouldn't be used for UI purposes to indicate mute). Non-Mute->mute as described could also be triggered by a network interruption. If the delay is longer, it would be slow at triggering. > 3. Perhaps special RTP or RTCP packets can be added later to indicate > "muted" later - I suspect this will involve other WGs so it might take > some time. See above. I favor silence for audio, and a mute image periodically sent by IDR. If we can agree on signalling mute, I would want it in the media plane. I'm open as to RTCP vs RTP but prefer RTP; RTP is faster and there would be explicit up-front negotiation as to whether the other side supports it (and if not, you just continue to send media as normal silence and a mute image or black, which should reduce bandwidth). -- Randell Jesup randell-ietf@jesup.org From stewe@stewe.org Tue Jan 17 07:26:34 2012 Return-Path: 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 B36E321F8493 for ; Tue, 17 Jan 2012 07:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599] 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 n5CfQtS0eeCo for ; Tue, 17 Jan 2012 07:26:34 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id D9D7321F84CF for ; Tue, 17 Jan 2012 07:26:33 -0800 (PST) Received: from [192.168.1.66] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 14182-1743317 for multiple; Tue, 17 Jan 2012 16:26:32 +0100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 17 Jan 2012 07:26:00 -0800 From: Stephan Wenger To: Harald Alvestrand , "rtcweb@ietf.org" Message-ID: Thread-Topic: [rtcweb] Open issue: Signalling muted streams In-Reply-To: <4F156709.9030604@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 15:26:34 -0000 Hi Harald, On 1.17.2012 04:18 , "Harald Alvestrand" wrote: >[=8A] > >Either the information comes over the media path, or over the signaling >path. This is not necessarily an "either, or" (exclusive or) decision. For example, the ITU video conferencing system Recs since H.320 (and the associated video codecs) include a mechanism that allows for picture-exact video mute (in the form of a Supplementary Enhancement Information (SEI) message inside the video bitstream, and a video unmute in the signaling protocol. =20 Historically, this design choice was motivated by video switching MCUs and video encoders incapable of coding full intra pictures (using intra walk around in inter pictures). However, the ability of sending a mute right in the media path, and thereby synchronized with the bitstream and not subject to delays that may or may not occur on the signaling path, has been shown to be very useful outside these limited scenarios. The case for precise synchronization of an unmute with the media is not quite as strong, but has been made as well. OTOH, media is susceptible to losses, and a lost "mute" can lead to rather embarrassing (or worse) situations. Therefore, I would suggest to add a mute/unmute capability, per media path, to the media plane related "signaling" (for example using the RTP/RTCP related standards you mentioned--I'm not pushing for those SEI messages). If the designer wishes to put the same signaling also on the signaling path, well and good. AFAICT, it's relatively simple to deal with conflicting information over both paths in a receiver implementation. Traditional video conferencing systems have dealt with this for decades. Stephan =20 >If it's the media path, there needs to be an RTP-level definition of >what's sent to indicate it. (RTCP message, comfort noise / video >equivalent, other...) >If it's the signalling path, there needs to be a defined API to get the >information passed up to the JS layer at the sender, and passed down >from the JS layer at the recipient. > >Thoughts from the community? > > Harald > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Jan 17 08:28:21 2012 Return-Path: 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 D16ED21F861F for ; Tue, 17 Jan 2012 08:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.953 X-Spam-Level: X-Spam-Status: No, score=-109.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8, 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 DJXRlnWiw-qA for ; Tue, 17 Jan 2012 08:28:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5F21F8570 for ; Tue, 17 Jan 2012 08:28:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FBFD39E08A; Tue, 17 Jan 2012 17:28:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODXm3k29v+3C; Tue, 17 Jan 2012 17:28:19 +0100 (CET) Received: from [172.16.33.25] (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8FE7739E048; Tue, 17 Jan 2012 17:28:19 +0100 (CET) Message-ID: <4F15A1A3.6000304@alvestrand.no> Date: Tue, 17 Jan 2012 17:28:19 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 16:28:21 -0000 (after a long delay) thank you very much for the input! I've downloaded and compiled the code, but haven't yet found out how to do the typical "hello world" call with the binaries provided. Could you give us a note saying "do this and see the packets flow"? Harald, experimenter On 11/18/2011 02:17 PM, Michael Tüxen wrote: > Dear all, > > I just wanted to let you know that the initial version of the > SCTP user-land stack based on the FreeBSD kernel code for SCTP > is available at > http://sctp.fh-muenster.de/sctp-user-land-stack.html > > It currently support FreeBSD, Linux and Mac OS X. We are > currently working on adding support for Windows, adding > more examples and improving the API. > > Best regards > Michael > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Michael.Tuexen@lurchi.franken.de Tue Jan 17 08:39:19 2012 Return-Path: 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 51F0621F85F8 for ; Tue, 17 Jan 2012 08:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8OkXHWq92Wtd for ; Tue, 17 Jan 2012 08:39:18 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 44E7221F858A for ; Tue, 17 Jan 2012 08:39:18 -0800 (PST) Received: from [212.201.127.167] (unknown [212.201.127.167]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 60E491C0B4611; Tue, 17 Jan 2012 17:39:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4F15A1A3.6000304@alvestrand.no> Date: Tue, 17 Jan 2012 17:39:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <575C34FB-901C-4953-84E0-D10A65D74439@lurchi.franken.de> References: <4F15A1A3.6000304@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 16:39:19 -0000 On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: > (after a long delay) > thank you very much for the input! >=20 > I've downloaded and compiled the code, but haven't yet found out how = to do the typical "hello world" call with the binaries provided. >=20 > Could you give us a note saying "do this and see the packets flow"? Sure. Give me a day or two to put out a new release, which support = Windows and IPv6 and some other options for the testprogram, which will allow a simple = usage for testing. Best regards Michael >=20 > Harald, experimenter >=20 > On 11/18/2011 02:17 PM, Michael T=FCxen wrote: >> Dear all, >>=20 >> I just wanted to let you know that the initial version of the >> SCTP user-land stack based on the FreeBSD kernel code for SCTP >> is available at >> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>=20 >> It currently support FreeBSD, Linux and Mac OS X. We are >> currently working on adding support for Windows, adding >> more examples and improving the API. >>=20 >> Best regards >> Michael >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 From wolfgang.beck01@googlemail.com Tue Jan 17 08:59:45 2012 Return-Path: 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 BF64221F870B for ; Tue, 17 Jan 2012 08:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Yf64w0cdHR+2 for ; Tue, 17 Jan 2012 08:59:45 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB521F870A for ; Tue, 17 Jan 2012 08:59:45 -0800 (PST) Received: by dakf10 with SMTP id f10so1270068dak.31 for ; Tue, 17 Jan 2012 08:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oSYEowgZVDIEtiI1fg9eStv6+zr0DXt6gfu+93T3pXM=; b=oIHpiI8aGBoOLB+4heGXUuUBECBk5DhfxF5rgUYpiIN/bmkaskAaVgWgyg6JReKyjg cztKszFm0OcOWOQDd41Uq5wb/AXgRSheca2kErcu5T7N/6lO8qwcAxv/Z5HGMiNgVsMP vuNG1K8IylEU80LIHf8fp9WlGWKMwFY2h8vrY= MIME-Version: 1.0 Received: by 10.68.115.133 with SMTP id jo5mr35743188pbb.50.1326819584998; Tue, 17 Jan 2012 08:59:44 -0800 (PST) Received: by 10.68.197.132 with HTTP; Tue, 17 Jan 2012 08:59:44 -0800 (PST) In-Reply-To: <4F157CF9.3090304@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> Date: Tue, 17 Jan 2012 17:59:44 +0100 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 16:59:45 -0000 On Tue, Jan 17, 2012 at 2:51 PM, Harald Alvestrand wrote: > Which SDP mechanism are you recommending? (RFC and section) > RfC 3264 section 8.4 recommends a=sendonly, which turned out to be problematic if you need to distinguish between 'I will send RTP but ignore your RTP' and 'I won't send RTP and ignore your RTP'. > So your answer is "API, and use an SDP mechanism". Thanks for the clarity! If we want to go the SDP over ROAP path, yes. If we had an API which was loosely modeled after SDP, we wouldn't need SDP at all. We've discussed that. The only good reason to use SDP is compatibility with existing implementations. Wolfgang Beck From roman@telurix.com Tue Jan 17 09:13:16 2012 Return-Path: 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 868501F0C4A for ; Tue, 17 Jan 2012 09:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] 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 6u89jmiF4s5n for ; Tue, 17 Jan 2012 09:13:16 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F170A1F0C49 for ; Tue, 17 Jan 2012 09:13:15 -0800 (PST) Received: by ggnr5 with SMTP id r5so3863573ggn.31 for ; Tue, 17 Jan 2012 09:13:15 -0800 (PST) Received: by 10.50.95.169 with SMTP id dl9mr18390829igb.12.1326820395195; Tue, 17 Jan 2012 09:13:15 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id x18sm79249069ibi.2.2012.01.17.09.13.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 09:13:14 -0800 (PST) Received: by dakf10 with SMTP id f10so1279752dak.31 for ; Tue, 17 Jan 2012 09:13:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.122.225 with SMTP id lv1mr36162144pbb.68.1326820393255; Tue, 17 Jan 2012 09:13:13 -0800 (PST) Received: by 10.68.44.197 with HTTP; Tue, 17 Jan 2012 09:13:13 -0800 (PST) In-Reply-To: References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> Date: Tue, 17 Jan 2012 12:13:13 -0500 Message-ID: From: Roman Shpount To: Wolfgang Beck Content-Type: multipart/alternative; boundary=e89a8f64650b38811504b6bc727f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 17:13:16 -0000 --e89a8f64650b38811504b6bc727f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 17, 2012 at 11:59 AM, Wolfgang Beck < wolfgang.beck01@googlemail.com> wrote: > RfC 3264 section 8.4 recommends a=sendonly, which turned out to be > problematic if you need to distinguish between 'I will send RTP but > ignore your RTP' and 'I won't send RTP and ignore your RTP'. > > This section was actually a fairly bad decision on behalf of RFC authors. It is worded this way since a=sendonly corresponds to using 0.0.0.0 address in c line, but should almost never be used in normal call flows. For hold you typically use a=inactive. So use a=sendonly if you are planning to send RTP, but don't want to receive any media (reverse mute), a=recvonly if you put a line on mute, but still want to receive RTP, and a=inactive if you put a line on hold and plan to do neither. _____________ Roman Shpount --e89a8f64650b38811504b6bc727f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jan 17, 2012 at 11= :59 AM, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
=
RfC 3264 section 8.4 recommends a=3Dsendonly, which turned out to be
problematic if you need to distinguish between 'I will send RTP but
ignore your RTP' and 'I won't send RTP and ignore your RTP'= .

This section was actually a = fairly bad decision on behalf of RFC authors. It is worded this way since a= =3Dsendonly corresponds to using 0.0.0.0 address in c line, but should almo= st never be used in normal call flows. For hold you typically use a=3Dinact= ive. So use a=3Dsendonly if you are planning to send RTP, but don't wan= t to receive any media (reverse mute), a=3Drecvonly if you put a line on mu= te, but still want to receive RTP, and a=3Dinactive if you put a line on ho= ld and plan to do neither.
_____________
Roman Shpount

--e89a8f64650b38811504b6bc727f-- From randell-ietf@jesup.org Tue Jan 17 09:18:33 2012 Return-Path: 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 D012521F8579 for ; Tue, 17 Jan 2012 09:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] 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 JPoENotvOOeN for ; Tue, 17 Jan 2012 09:18:33 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDE721F85B6 for ; Tue, 17 Jan 2012 09:18:33 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RnCg4-0007At-Oc for rtcweb@ietf.org; Tue, 17 Jan 2012 11:18:32 -0600 Message-ID: <4F15AD38.2030604@jesup.org> Date: Tue, 17 Jan 2012 12:17:44 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 17:18:33 -0000 On 1/17/2012 11:59 AM, Wolfgang Beck wrote: > On Tue, Jan 17, 2012 at 2:51 PM, Harald Alvestrand wrote: >> Which SDP mechanism are you recommending? (RFC and section) >> > RfC 3264 section 8.4 recommends a=sendonly, which turned out to be > problematic if you need to distinguish between 'I will send RTP but > ignore your RTP' and 'I won't send RTP and ignore your RTP'. Please note, because people are often sloppy about this: Mute != Hold They are very closely related, but there are two primary differences: 1) In Mute, you expect to continue to receive *and* play audio and/or video from the other side. In Hold, any incoming media is thrown away. 2) Mute often may affect only audio or only video, though it could affect both/all (this is a UI decision). Hold would affect all streams. Hold is what was being discussed in RFC 3264 8.4, and they suggested re-INVITE with a=sendonly PLUS muting local audio immediately and blocking playback immediately. Hold often implies replacing audio and/or video with some sort of "you're on hold" message (audio and/or video), which also tells the far-end party that they don't have to worry (much) about talking. -- Randell Jesup randell-ietf@jesup.org From igor.faynberg@alcatel-lucent.com Tue Jan 17 09:29:59 2012 Return-Path: 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 7EC1D1F0C49 for ; Tue, 17 Jan 2012 09:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 XGiO6WxWyGuw for ; Tue, 17 Jan 2012 09:29:59 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F0C7C1F0C40 for ; Tue, 17 Jan 2012 09:29:58 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q0HHTuUx028438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Jan 2012 11:29:56 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0HHTucA014507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jan 2012 11:29:56 -0600 Received: from [135.244.33.97] (faynberg.lra.lucent.com [135.244.33.97]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0HHTt1u015575; Tue, 17 Jan 2012 11:29:55 -0600 (CST) Message-ID: <4F15B013.6020907@alcatel-lucent.com> Date: Tue, 17 Jan 2012 12:29:55 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F156709.9030604@alvestrand.no> In-Reply-To: <4F156709.9030604@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com 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: Tue, 17 Jan 2012 17:29:59 -0000 At the first glance, it appears to me that sending "muted data" is wasteful. I don't fully understand why sending nothing would confuse the recipient (or, more important, the recipient's system), but to deal with it I think sending a "muted" bit through signaling is the cleanest solution. Wolfgang's suggestion of using SDP is doable I think. Igor On 1/17/2012 7:18 AM, Harald Alvestrand wrote: > This came up in an off-list discussion, but I think it should be on > our open issues list: > > When a sender mutes a stream, what happens at the receiving end? > > Either the stream will continue to send data (black/silence), or it > doesn't. > If it continues, no problem. > If it doesn't: > > Either the recipient knows that the non-data is intentional, or he > doesn't. > If he doesn't, we need to make sure nothing times out or gets out of > whack because of the lack of data. > If he knows it's intentional, he has to learn it somehow. > > Either the information comes over the media path, or over the > signalling path. > If it's the media path, there needs to be an RTP-level definition of > what's sent to indicate it. (RTCP message, comfort noise / video > equivalent, other...) > If it's the signalling path, there needs to be a defined API to get > the information passed up to the JS layer at the sender, and passed > down from the JS layer at the recipient. > > Thoughts from the community? > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From arosenberg@logitech.com Tue Jan 17 11:28:08 2012 Return-Path: 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 5416821F8535 for ; Tue, 17 Jan 2012 11:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] 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 yg3leYNS735b for ; Tue, 17 Jan 2012 11:28:07 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id ED9FC21F8539 for ; Tue, 17 Jan 2012 11:28:06 -0800 (PST) Received: from mail-vw0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTxXLxjdCt1MMeBB6KjtYrHl3MpvlTONQ@postini.com; Tue, 17 Jan 2012 11:28:07 PST Received: by mail-vw0-f43.google.com with SMTP id fo1so2529266vbb.2 for ; Tue, 17 Jan 2012 11:28:06 -0800 (PST) Received: by 10.52.24.35 with SMTP id r3mr9226670vdf.81.1326828485894; Tue, 17 Jan 2012 11:28:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.32.7 with HTTP; Tue, 17 Jan 2012 11:27:44 -0800 (PST) In-Reply-To: <4F15B013.6020907@alcatel-lucent.com> References: <4F156709.9030604@alvestrand.no> <4F15B013.6020907@alcatel-lucent.com> From: Aron Rosenberg Date: Tue, 17 Jan 2012 11:27:44 -0800 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf307c9b0094616f04b6be543e Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 19:28:08 -0000 --20cf307c9b0094616f04b6be543e Content-Type: text/plain; charset=ISO-8859-1 For "muting" of outbound video, the best real-world interop method that we have found is to just have your encoder constantly reencode the last frame of video prior to the user requesting mute. This method keeps the media going, doesn't trip far-end timeout logic and has the nice side effect that the image quality improves on the frozen frame and it works with any video codec (VP8 doesn't support SEI). Once steady state is hit, the bitrate used while in mute state is practically zero. On the audio side, we do something similar where we degrade/convert the audio signal to CN over one or two 20ms audio frames (so no popping or squeaks occur). After that initial period, CN is passed to the audio codec to keep compressing. This also works with any audio codec. Both methods still allow for signaling if you decide to let the far end know about the mute. On the signaling side, I have seen RTCP based methods and SIP INFO based methods. RTCP is nice because it has a better association with a particular stream. For video, our testing showed that freezing the last image is far better than sending a black/gray/other color frame. Aron Rosenberg Sr. Director, Engineering, LifeSize, a division of Logitech On Tue, Jan 17, 2012 at 9:29 AM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > At the first glance, it appears to me that sending "muted data" is > wasteful. I don't fully understand why sending nothing would confuse the > recipient (or, more important, the recipient's system), but to deal with it > I think sending a "muted" bit through signaling is the cleanest solution. > > Wolfgang's suggestion of using SDP is doable I think. > > Igor > > > On 1/17/2012 7:18 AM, Harald Alvestrand wrote: > >> This came up in an off-list discussion, but I think it should be on our >> open issues list: >> >> When a sender mutes a stream, what happens at the receiving end? >> >> Either the stream will continue to send data (black/silence), or it >> doesn't. >> If it continues, no problem. >> If it doesn't: >> >> Either the recipient knows that the non-data is intentional, or he >> doesn't. >> If he doesn't, we need to make sure nothing times out or gets out of >> whack because of the lack of data. >> If he knows it's intentional, he has to learn it somehow. >> >> Either the information comes over the media path, or over the signalling >> path. >> If it's the media path, there needs to be an RTP-level definition of >> what's sent to indicate it. (RTCP message, comfort noise / video >> equivalent, other...) >> If it's the signalling path, there needs to be a defined API to get the >> information passed up to the JS layer at the sender, and passed down from >> the JS layer at the recipient. >> >> Thoughts from the community? >> >> Harald >> >> >> ______________________________**_________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/**listinfo/rtcweb >> > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --20cf307c9b0094616f04b6be543e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For "muting" of outbound video, the best real-world interop metho= d that we have found is to just have your encoder constantly reencode the l= ast frame of video prior to the user requesting mute. This method keeps the= media going, doesn't trip far-end timeout logic and has the nice side = effect that the image quality improves on the frozen frame and it works wit= h any video codec (VP8 doesn't support SEI). Once steady state is hit, = the bitrate used while in mute state is practically zero.

On the audio side, we do something=A0similar where we degrad= e/convert the audio signal to CN=A0over one or two 20ms audio frames (so no= popping or=A0squeaks occur). After that initial period, CN is passed to th= e audio codec to keep compressing. This also works with any audio codec.

Both methods still allow for signaling if you decide to= let the far end know about the mute. On the signaling side, I have seen RT= CP based methods and SIP INFO based methods. RTCP is nice because it has a = better association with a particular stream.

For video, our testing showed that freezing the last im= age is far better than sending a black/gray/other color frame.

Aron Rosenberg
Sr. Director, Engineering= ,
LifeSize, a division of Logitech




On Tue, Jan 17, 2012 at 9:29 AM, Igor Fa= ynberg <igor.faynberg@alcatel-lucent.com> wrote:
At the first glance, it appears to me that sending "muted data" i= s wasteful. I don't fully understand why sending nothing would confuse = the recipient (or, more important, the recipient's system), but to deal= with it I think sending a "muted" bit through signaling is the c= leanest solution.

Wolfgang's suggestion of using SDP is doable I think.

Igor


On 1/17/2012 7:18 AM, Harald Alvestrand wrote:
This came up in an off-list discussion, but I think it should be on our ope= n issues list:

When a sender mutes a stream, what happens at the receiving end?

Either the stream will continue to send data (black/silence), or it doesn&#= 39;t.
If it continues, no problem.
If it doesn't:

Either the recipient knows that the non-data is intentional, or he doesn= 9;t.
If he doesn't, we need to make sure nothing times out or gets out of wh= ack because of the lack of data.
If he knows it's intentional, he has to learn it somehow.

Either the information comes over the media path, or over the signalling pa= th.
If it's the media path, there needs to be an RTP-level definition of wh= at's sent to indicate it. (RTCP message, comfort noise / video equivale= nt, other...)
If it's the signalling path, there needs to be a defined API to get the= information passed up to the JS layer at the sender, and passed down from = the JS layer at the recipient.

Thoughts from the community?

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--20cf307c9b0094616f04b6be543e-- From vvenkatar@gmail.com Tue Jan 17 14:50:28 2012 Return-Path: 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 5E83321F86C9 for ; Tue, 17 Jan 2012 14:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 D14s5RezmYD0 for ; Tue, 17 Jan 2012 14:50:26 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1445F21F86C7 for ; Tue, 17 Jan 2012 14:50:26 -0800 (PST) Received: by qcsc1 with SMTP id c1so2739476qcs.31 for ; Tue, 17 Jan 2012 14:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cDQhSIkvYYoIFft0qr+PxayvViRBGUNNGahsvVDjjAE=; b=dAmn06/VAvUDxJxllB/r97Gl1F8RllQERHGhvttLNt6WTvohreUU4JgvkHAAymtU1Z ZP2Yy1KYxqSKnF4rrA3uOZnBJzbN69dj+sdFxsTyOQXedV9AG3+2iVuISZMJf9TvP3yG wTlTSZMTPl0u7aF4W4mDJgVfXF+PjRK4YKZAI= MIME-Version: 1.0 Received: by 10.229.77.72 with SMTP id f8mr6954073qck.38.1326840625395; Tue, 17 Jan 2012 14:50:25 -0800 (PST) Received: by 10.229.223.135 with HTTP; Tue, 17 Jan 2012 14:50:25 -0800 (PST) In-Reply-To: <4F157CF9.3090304@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> Date: Tue, 17 Jan 2012 14:50:25 -0800 Message-ID: From: Venkatesh To: Harald Alvestrand Content-Type: multipart/alternative; boundary=00235447142426775f04b6c128fd Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Tue, 17 Jan 2012 22:50:29 -0000 --00235447142426775f04b6c128fd Content-Type: text/plain; charset=ISO-8859-1 Section 8.4 of RFC 3264 talks about SDP usage to indicate streams on hold. Although this is in the context of SIP, the mechanism is probably applicable in this context. Thanks, Venkatesh On Tue, Jan 17, 2012 at 5:51 AM, Harald Alvestrand wrote: > On 01/17/2012 02:38 PM, Wolfgang Beck wrote: > >> On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand> >> wrote: >> >>> This came up in an off-list discussion, but I think it should be on our >>> open >>> issues list: >>> >>> When a sender mutes a stream, what happens at the receiving end? >>> >>> It's the signalling discussion again. >> >> If you tunnel SDP through HTTP and some some server-to-server >> protocol, you just use the SDP mechanism to mute one side. >> > Which SDP mechanism are you recommending? (RFC and section) > > Without server-to-server protocol, you only need an API call to pause >> sending of RTP packets. How this is signaled to the remote party is up >> the JS client and server. >> >> Moving parts of the SDP functionality to RTP would break compatibility >> with existing systems. Which was the main argument for sticking with >> SDP.. >> > So your answer is "API, and use an SDP mechanism". Thanks for the clarity! > > >> Wolfgang Beck >> >> > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --00235447142426775f04b6c128fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Section 8.4 of RFC 3264 talks about SDP usage to indicate streams on hold. = Although this is in the context of SIP, the mechanism is probably applicabl= e in this context.

Thanks,
Venkatesh

On Tue, Jan 17, 2012 at 5:51 AM, Harald Alve= strand <harald@alvestrand.no> wrote:
On 01/17/2012 02:38 PM, Wolfgang Beck wrote:
On Tue, Jan 17, 2012 at 1:18 PM, Harald Alvestrand<harald@alvestrand.no> = =A0wrote:
This came up in an off-list discussion, but I think it should be on our ope= n
issues list:

When a sender mutes a stream, what happens at the receiving end?

It's the signalling discussion again.

If you tunnel SDP through HTTP and some some server-to-server
protocol, you just use the SDP mechanism to mute one side.
Which SDP mechanism are you recommending? (RFC and section)

Without server-to-server protocol, you only need an API call to pause
sending of RTP packets. How this is signaled to the remote party is up
the JS client and server.

Moving parts of the SDP functionality to RTP would break compatibility
with existing systems. Which was the main argument for sticking with
SDP..
So your answer is "API, and use an SDP mechanism". Thanks for the= clarity!


Wolfgang Beck


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--00235447142426775f04b6c128fd-- From harald@alvestrand.no Wed Jan 18 01:07:18 2012 Return-Path: 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 1529B21F876A for ; Wed, 18 Jan 2012 01:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, 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 6phF-7ZW3f2Y for ; Wed, 18 Jan 2012 01:07:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2EF21F8760 for ; Wed, 18 Jan 2012 01:07:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D8F7639E12B; Wed, 18 Jan 2012 10:07:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vA59MCvP9Z1; Wed, 18 Jan 2012 10:07:09 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1F35C39E112; Wed, 18 Jan 2012 10:07:09 +0100 (CET) Message-ID: <4F168BBC.2090305@alvestrand.no> Date: Wed, 18 Jan 2012 10:07:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070707090304090608070907" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 09:07:18 -0000 This is a multi-part message in MIME format. --------------070707090304090608070907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/17/2012 06:13 PM, Roman Shpount wrote: > > > On Tue, Jan 17, 2012 at 11:59 AM, Wolfgang Beck > > wrote: > > RfC 3264 section 8.4 recommends a=sendonly, which turned out to be > problematic if you need to distinguish between 'I will send RTP but > ignore your RTP' and 'I won't send RTP and ignore your RTP'. > > This section was actually a fairly bad decision on behalf of RFC > authors. It is worded this way since a=sendonly corresponds to using > 0.0.0.0 address in c line, but should almost never be used in normal > call flows. For hold you typically use a=inactive. So use a=sendonly > if you are planning to send RTP, but don't want to receive any media > (reverse mute), a=recvonly if you put a line on mute, but still want > to receive RTP, and a=inactive if you put a line on hold and plan to > do neither. An interesting wrinkle is that RFC 3264 section 8.4 seems to assume that the dominant use case of mute is the recipient wanting to not receive media (so it needs to be receiver-initiated), while the most-discussed use case in this group has been a sender turning off his microphone or camera (so it needs to be sender-initiated). Is a=sendonly / a=recvonly / a=inactive manipulation appropriate for both cases? Harald --------------070707090304090608070907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/17/2012 06:13 PM, Roman Shpount wrote:


On Tue, Jan 17, 2012 at 11:59 AM, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
RfC 3264 section 8.4 recommends a=sendonly, which turned out to be
problematic if you need to distinguish between 'I will send RTP but
ignore your RTP' and 'I won't send RTP and ignore your RTP'.

This section was actually a fairly bad decision on behalf of RFC authors. It is worded this way since a=sendonly corresponds to using 0.0.0.0 address in c line, but should almost never be used in normal call flows. For hold you typically use a=inactive. So use a=sendonly if you are planning to send RTP, but don't want to receive any media (reverse mute), a=recvonly if you put a line on mute, but still want to receive RTP, and a=inactive if you put a line on hold and plan to do neither.

An interesting wrinkle is that RFC 3264 section 8.4 seems to assume that the dominant use case of mute is the recipient wanting to not receive media (so it needs to be receiver-initiated), while the most-discussed use case in this group has been a sender turning off his microphone or camera (so it needs to be sender-initiated).

Is a=sendonly / a=recvonly / a=inactive manipulation appropriate for both cases?

               Harald

--------------070707090304090608070907-- From harald@alvestrand.no Wed Jan 18 01:08:53 2012 Return-Path: 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 5187621F8768 for ; Wed, 18 Jan 2012 01:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.163 X-Spam-Level: X-Spam-Status: No, score=-110.163 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, 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 MZ2BtaD58Pa1 for ; Wed, 18 Jan 2012 01:08:52 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7403821F8707 for ; Wed, 18 Jan 2012 01:08:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BCF6639E12B; Wed, 18 Jan 2012 10:08:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5z3sbiMsY-6; Wed, 18 Jan 2012 10:08:51 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1C14239E112; Wed, 18 Jan 2012 10:08:51 +0100 (CET) Message-ID: <4F168C20.9010308@alvestrand.no> Date: Wed, 18 Jan 2012 10:08:48 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080809030709000809090502" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 09:08:53 -0000 This is a multi-part message in MIME format. --------------080809030709000809090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/17/2012 06:13 PM, Roman Shpount wrote: > > > On Tue, Jan 17, 2012 at 11:59 AM, Wolfgang Beck > > wrote: > > RfC 3264 section 8.4 recommends a=sendonly, which turned out to be > problematic if you need to distinguish between 'I will send RTP but > ignore your RTP' and 'I won't send RTP and ignore your RTP'. > > This section was actually a fairly bad decision on behalf of RFC > authors. It is worded this way since a=sendonly corresponds to using > 0.0.0.0 address in c line, but should almost never be used in normal > call flows. For hold you typically use a=inactive. So use a=sendonly > if you are planning to send RTP, but don't want to receive any media > (reverse mute), a=recvonly if you put a line on mute, but still want > to receive RTP, and a=inactive if you put a line on hold and plan to > do neither. Oops.... I suddenly realized: These mechanisms (a=sendonly and so on) are at the RTP session level. They apply to all SSRCs in the RTP session. The mute functions we've been discussing at the API level are at the MediaStreamTrack level. That maps to wanting to mute a single SSRC. How does that affect things? Harald --------------080809030709000809090502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/17/2012 06:13 PM, Roman Shpount wrote:


On Tue, Jan 17, 2012 at 11:59 AM, Wolfgang Beck <wolfgang.beck01@googlemail.com> wrote:
RfC 3264 section 8.4 recommends a=sendonly, which turned out to be
problematic if you need to distinguish between 'I will send RTP but
ignore your RTP' and 'I won't send RTP and ignore your RTP'.

This section was actually a fairly bad decision on behalf of RFC authors. It is worded this way since a=sendonly corresponds to using 0.0.0.0 address in c line, but should almost never be used in normal call flows. For hold you typically use a=inactive. So use a=sendonly if you are planning to send RTP, but don't want to receive any media (reverse mute), a=recvonly if you put a line on mute, but still want to receive RTP, and a=inactive if you put a line on hold and plan to do neither.
Oops.... I suddenly realized:

These mechanisms (a=sendonly and so on) are at the RTP session level. They apply to all SSRCs in the RTP session.

The mute functions we've been discussing at the API level are at the MediaStreamTrack level. That maps to wanting to mute a single SSRC.

How does that affect things?

               Harald

--------------080809030709000809090502-- From stefan.lk.hakansson@ericsson.com Wed Jan 18 06:48:10 2012 Return-Path: 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 D8D4921F86BB for ; Wed, 18 Jan 2012 06:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 8yFiyTlKS+co for ; Wed, 18 Jan 2012 06:48:10 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7421F86B7 for ; Wed, 18 Jan 2012 06:48:09 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-93-4f16dba8d452 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.2F.09514.8ABD61F4; Wed, 18 Jan 2012 15:48:08 +0100 (CET) Received: from [150.132.141.86] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 18 Jan 2012 15:48:07 +0100 Message-ID: <4F16DBA8.9010804@ericsson.com> Date: Wed, 18 Jan 2012 15:48:08 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> <4F0BF535.7010600@ericsson.com> <4F0CB27B.1060008@jesup.org> In-Reply-To: <4F0CB27B.1060008@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 14:48:11 -0000 On 01/10/2012 10:49 PM, Randell Jesup wrote: > On 1/10/2012 3:22 AM, Stefan Hakansson LK wrote: >> On 01/09/2012 04:46 PM, Randell Jesup wrote: >> .... >>>> Any use trying to access the data (including using the audio element as >>>> source) would throw security exceptions. >>> >>> I suggest starting by going back in the archives to that period; there >>> was considerable discussion of the issue. > >> Thanks for the tip, funny how things fade away from memory.... >> >> I did read up, but it seems that discussion did not really end up at a >> conclusion. And it was mostly discussed for the local context, never how >> to ensure that the data of a stream on the other end of a PeerConnection >> can not be accessed. > > I was talking to roc (Robert O'Callahan) last night, and he believes > using cross-origin-type controls can be used to basically block the JS > from getting access to the decrypted/decoded media streams. (This > already exists for blocking JS access to cross-origin images.) So, no > need to use tainting per-se. > > There certainly remains the issue of when and how the JS would get > access to the streams, and without it they wouldn't be able to use some > of the audio "processed streams" stuff we're working on. And if the > user has to give permission for access, does this permission stick? > (This is overall related to the whole "does this app/website have > permission to access the camera& mic" issue.) I think we have a lot to sort out as you indicate above. Matters are also complicated by the fact that (at least that is what I understood) that one likely way to add functionality like VU meter, possibility to adjust levels, panning, etc. could be provided by the use of the Web Audio API (so that the webrtc group does not have to re-invent a lot of stuff). But how do you restrict what can be done once the audio is available to that tool set? Then the same rules must apply on the other end of a PeerConnection, so this limitation in JS access must be carried over in a really secure way (and ideally the sending side should get an ack from the receiving browser that the data can not be accessed). This is also not clear to me how to do. And even if we manage to fix all this, there are other possible security issues, like: * A hacked application uses a canvas to present incoming video and adds fake objects to the scene (I agree, a bit silly) * A hacked application also uses voice based search API (they seem to be going for a lower security bar) to record I'm not saying we should not investigate this; on the contrary I think this is of great interest. It is only that my personal gut feeling is that we should do this in an orderly fashion with a holistic view so that things developed in different groups (we have the Audio WG, the voice search work in WebApps, Web Security, discussions on a Identity WG etc.) fit together - and that this may take some more time than what is available in the current charters, and perhaps should be moved to a phase 2. Or maybe it's just me being overly pessimistic! > > A strawman proposal might be a "secure connection" checkbox on the > getUserMedia() popup which defaults to secure. That may not be an > optimum UI, however. Or the application decides if it asks for secure or not (some applications may not work as intended without access to the data) but most importantly the user is clearly informed when giving consent and through the icon in the browser chrome (solved in some unknown way when in full-screen mode!) whether the access to user data is secure or not. > From ted.ietf@gmail.com Wed Jan 18 09:03:05 2012 Return-Path: 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 6FBB721F874C for ; Wed, 18 Jan 2012 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] 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 j0RyPSYev42L for ; Wed, 18 Jan 2012 09:03:05 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E977D21F876E for ; Wed, 18 Jan 2012 09:03:04 -0800 (PST) Received: by yhnn12 with SMTP id n12so2065113yhn.31 for ; Wed, 18 Jan 2012 09:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=7SLh1sxbDcAclNOP7JxVf4N+nBZoSlPH9/ORw0sD4L0=; b=ju9LCT3ErJRdA6p8oI1tagys50XXO1W23eaql4NvxwKaF83qpzYRp2ZKnMgmxmO6OE b74vtJmL3StSY0UHbahgZ1Y1d+LaChlswhmdh0KiRXrH0fwKvVWRF1FbI4im2RxJFYSN RbbwwqV+ZG9jf+a4LGUtMYHoN12CR7VgBSPxM= MIME-Version: 1.0 Received: by 10.236.121.168 with SMTP id r28mr34003409yhh.51.1326906184453; Wed, 18 Jan 2012 09:03:04 -0800 (PST) Received: by 10.236.180.230 with HTTP; Wed, 18 Jan 2012 09:03:04 -0800 (PST) Date: Wed, 18 Jan 2012 09:03:04 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org, Cullen Jennings , Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] AGENDA for the Interim meeting X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:03:05 -0000 January 31st, 2012 The Interim will be held at the Google campus in Mountain View, CA, in building GWC5. This building does not normally have staffed reception, but there will be someone from 8:00 to 9:00 with badges for everyone who has notified the chairs of their attendance. If you did not send your name in, please go to GWC6, ask for a badge with Ted Hardie as your local host and have the staff contact Ted. If you arrive outside this time but did let the Chairs know you were coming, please IM or email ted.ietf@gmail.com, and so he can come out of the meeting room with your badge. January 31st, 2012 8:00-9:00 Breakfast 9:00-12:00 JSEP 12:30-1:00 ROAP (1) 12:0-1:30 Lunch 1:30-2:30 ROAP (2) 2:30-4:30 Signaling resolution 4:30-5:30 Data Channel 1 5:30-Close Demos of existing systems February 1st, 2012 8:00-9:00 Breakfast 9:00-10:00 Data channel 2 10:00-12:30 Security 12:30-1:30 Lunch Transition to WEBRTC at this point. Reply regards, Cullen, Magnus, Ted From harald@alvestrand.no Wed Jan 18 09:12:46 2012 Return-Path: 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 16E4721F86E0 for ; Wed, 18 Jan 2012 09:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.443 X-Spam-Level: X-Spam-Status: No, score=-110.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 JH8lF0SeKoLF for ; Wed, 18 Jan 2012 09:12:45 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 643FD21F86D0 for ; Wed, 18 Jan 2012 09:12:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFC0639E12F for ; Wed, 18 Jan 2012 18:12:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUnfdvssu+hl for ; Wed, 18 Jan 2012 18:12:43 +0100 (CET) Received: from [172.16.33.99] (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8272D39E112 for ; Wed, 18 Jan 2012 18:12:43 +0100 (CET) Message-ID: <4F16FD8B.6090209@alvestrand.no> Date: Wed, 18 Jan 2012 18:12:43 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Implementation available: WebRTC in Chrome! X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:12:46 -0000 For everyone who's been wanting something to play with: Chromium now has WebRTC! http://www.webrtc.org/blog/webrtcnowavailableinthechromedevchannel Not the latest and greatest spec - but we're working hard to catch up. Please - try it, and tell us what works! Harald From roman@telurix.com Wed Jan 18 09:36:27 2012 Return-Path: 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 E258021F85D4 for ; Wed, 18 Jan 2012 09:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 zgy9i5dnBrb4 for ; Wed, 18 Jan 2012 09:36:27 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9125421F859F for ; Wed, 18 Jan 2012 09:36:22 -0800 (PST) Received: by iaae16 with SMTP id e16so13656196iaa.31 for ; Wed, 18 Jan 2012 09:36:22 -0800 (PST) Received: by 10.42.168.133 with SMTP id w5mr10872519icy.38.1326908182222; Wed, 18 Jan 2012 09:36:22 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id bj3sm37642485igb.4.2012.01.18.09.36.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 09:36:20 -0800 (PST) Received: by dakf10 with SMTP id f10so2149192dak.31 for ; Wed, 18 Jan 2012 09:36:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.131 with SMTP id nc3mr6470235pbc.17.1326908177707; Wed, 18 Jan 2012 09:36:17 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 18 Jan 2012 09:36:17 -0800 (PST) In-Reply-To: <4F16DBA8.9010804@ericsson.com> References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> <4F0BF535.7010600@ericsson.com> <4F0CB27B.1060008@jesup.org> <4F16DBA8.9010804@ericsson.com> Date: Wed, 18 Jan 2012 12:36:17 -0500 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=e89a8ff1c08694f33204b6d0e2e9 Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:36:28 -0000 --e89a8ff1c08694f33204b6d0e2e9 Content-Type: text/plain; charset=ISO-8859-1 How realistic is what you are trying to achieve? If we cannot provide an end-to-end identity verification during the call, and we consider JavaScript application compromised, there is no guarantee that what the end user is communicating with is the actual remote party and not some type of intermediary device which is recording or modifying the media. What we need is some sort of application specific client identity mechanism, that can ensure that ICE candidates and key fingerprints are not tempered with. This borders on creation of a signaling protocol, but if we make PeerConnection take the HTTPS url of the media description signing agent, credentials for this agent, remote party ID, and local party IDs, issue an HTTPS request to sign the media description, and show this information to the user (i.e. you are placing call from local party ID to remote party ID validated by service URL), we will have a media description that can be validated at least in the context of this specific service. When media description is received from the remote party, the same mechanism can be used to validate this description and show information to the user (incoming call from remote party ID to local party ID validated by service URL). I realize these are very rough ideas, but unless we close this hole, all other security measures can be easily circumvented. _____________ Roman Shpount --e89a8ff1c08694f33204b6d0e2e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How realistic is what you are trying to achieve? If we cannot provide an en= d-to-end identity verification during the call, and we consider JavaScript = application compromised, there is no guarantee that what the end user is co= mmunicating with is the actual remote party and not some type of intermedia= ry device which is recording or modifying the media.

What we need is some sort of application specific client identity mecha= nism, that can ensure that ICE candidates and key fingerprints are not temp= ered with. This borders on creation of a signaling protocol, but if we make= PeerConnection take the HTTPS url of the media description signing agent, = credentials for this agent, remote party ID, and local party IDs, issue an = HTTPS request to sign the media description, and show this information to t= he user (i.e. you are placing call from local party ID to remote party ID v= alidated by service URL), we will have a media description that can be vali= dated at least in the context of this specific service. When media descript= ion is received from the remote party, the same mechanism can be used to va= lidate this description and show information to the user (incoming call fro= m remote party ID to local party ID validated by service URL). I realize th= ese are very rough ideas, but unless we close this hole, all other security= measures can be easily circumvented.
_____________
Roman Shpount

--e89a8ff1c08694f33204b6d0e2e9-- From roman@telurix.com Wed Jan 18 09:42:07 2012 Return-Path: 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 EEC9321F8585 for ; Wed, 18 Jan 2012 09:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Y+7UmoOiXgxQ for ; Wed, 18 Jan 2012 09:42:06 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7E17F21F857D for ; Wed, 18 Jan 2012 09:42:06 -0800 (PST) Received: by iaae16 with SMTP id e16so2444718iaa.1 for ; Wed, 18 Jan 2012 09:42:06 -0800 (PST) Received: by 10.42.164.71 with SMTP id f7mr18695101icy.49.1326908526119; Wed, 18 Jan 2012 09:42:06 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id 5sm91233746ibe.8.2012.01.18.09.42.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 09:42:05 -0800 (PST) Received: by dakf10 with SMTP id f10so2152699dak.31 for ; Wed, 18 Jan 2012 09:42:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.230 with SMTP id g6mr45889073pbv.119.1326908523698; Wed, 18 Jan 2012 09:42:03 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 18 Jan 2012 09:42:03 -0800 (PST) In-Reply-To: <4F168BBC.2090305@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168BBC.2090305@alvestrand.no> Date: Wed, 18 Jan 2012 12:42:03 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d041911da345a0304b6d0f777 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:42:07 -0000 --f46d041911da345a0304b6d0f777 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 18, 2012 at 4:07 AM, Harald Alvestrand wrote: > ** > An interesting wrinkle is that RFC 3264 section 8.4 seems to assume that > the dominant use case of mute is the recipient wanting to not receive media > (so it needs to be receiver-initiated), while the most-discussed use case > in this group has been a sender turning off his microphone or camera (so it > needs to be sender-initiated). > > Is a=sendonly / a=recvonly / a=inactive manipulation appropriate for both > cases? > > It is appropriate in all three cases: - Hold with Music: pausing remote media and playing some sort of hold music (or hold signal) to remote party - Mute: muting local audio and stopping camera, but still receiving remote media - Hold: pausing both sent and received media _____________ Roman Shpount --f46d041911da345a0304b6d0f777 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2012 at 4:07 AM, Harald Alvestra= nd <harald@alv= estrand.no> wrote:
=20 =20 =20
An interesting = wrinkle is that RFC 3264 section 8.4 seems to assume that the dominant use case of mute is the recipient wanting to not receive media (so it needs to be receiver-initiated), while the most-discussed use case in this group has been a sender turning off his microphone or camera (so it needs to be sender-initiated).

Is a=3Dsendonly / a=3Drecvonly / a=3Dinactive manipulation appropriate = for both cases?


It is appropriate in all three = cases:
  • Hold with Music: pausing remote media and playing some s= ort of hold music (or hold signal) to remote party
  • Mute: muting loc= al audio and stopping camera, but still receiving remote media
  • Hold: pausing both sent and received media
_____________Roman Shpount


--f46d041911da345a0304b6d0f777-- From ekr@rtfm.com Wed Jan 18 09:44:31 2012 Return-Path: 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 6232C11E80A5 for ; Wed, 18 Jan 2012 09:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 8LWAnQEOE2UQ for ; Wed, 18 Jan 2012 09:44:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C490511E8098 for ; Wed, 18 Jan 2012 09:44:30 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so738867vbb.31 for ; Wed, 18 Jan 2012 09:44:30 -0800 (PST) Received: by 10.52.90.164 with SMTP id bx4mr11117483vdb.128.1326908670186; Wed, 18 Jan 2012 09:44:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Wed, 18 Jan 2012 09:43:49 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <4F084BED.3010001@ericsson.com> <4F09D6FC.7040801@ericsson.com> <4F09DF99.5070907@mozilla.com> <4F0AE5A9.7040307@ericsson.com> <4F0B0BD3.4070109@jesup.org> <4F0BF535.7010600@ericsson.com> <4F0CB27B.1060008@jesup.org> <4F16DBA8.9010804@ericsson.com> From: Eric Rescorla Date: Wed, 18 Jan 2012 09:43:49 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question on sec architecture proposal X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:44:31 -0000 On Wed, Jan 18, 2012 at 9:36 AM, Roman Shpount wrote: > How realistic is what you are trying to achieve? If we cannot provide an > end-to-end identity verification during the call, and we consider JavaScript > application compromised, there is no guarantee that what the end user is > communicating with is the actual remote party and not some type of > intermediary device which is recording or modifying the media. > > What we need is some sort of application specific client identity mechanism, > that can ensure that ICE candidates and key fingerprints are not tempered > with. This borders on creation of a signaling protocol, but if we make > PeerConnection take the HTTPS url of the media description signing agent, > credentials for this agent, remote party ID, and local party IDs, issue an > HTTPS request to sign the media description, and show this information to > the user (i.e. you are placing call from local party ID to remote party ID > validated by service URL), we will have a media description that can be > validated at least in the context of this specific service. When media > description is received from the remote party, the same mechanism can be > used to validate this description and show information to the user (incoming > call from remote party ID to local party ID validated by service URL). I > realize these are very rough ideas, but unless we close this hole, all other > security measures can be easily circumvented. See Section A.3.6 of draft-ietf-rtcweb-security-01 -Ekr From roman@telurix.com Wed Jan 18 09:45:05 2012 Return-Path: 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 22F8D11E8085 for ; Wed, 18 Jan 2012 09:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1] 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 pTIsEgfttzNl for ; Wed, 18 Jan 2012 09:45:04 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id A597C21F857D for ; Wed, 18 Jan 2012 09:45:04 -0800 (PST) Received: by iaae16 with SMTP id e16so2445425iaa.1 for ; Wed, 18 Jan 2012 09:45:04 -0800 (PST) Received: by 10.50.156.138 with SMTP id we10mr20728820igb.10.1326908704162; Wed, 18 Jan 2012 09:45:04 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id yg2sm37922542igb.1.2012.01.18.09.45.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 09:45:03 -0800 (PST) Received: by pbbb2 with SMTP id b2so5127368pbb.31 for ; Wed, 18 Jan 2012 09:45:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.131 with SMTP id nc3mr6528865pbc.17.1326908702430; Wed, 18 Jan 2012 09:45:02 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 18 Jan 2012 09:45:02 -0800 (PST) In-Reply-To: <4F168C20.9010308@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> Date: Wed, 18 Jan 2012 12:45:02 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=e89a8ff1c086db955904b6d10142 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:45:05 -0000 --e89a8ff1c086db955904b6d10142 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 18, 2012 at 4:08 AM, Harald Alvestrand wrote: > ** > Oops.... I suddenly realized: > > These mechanisms (a=sendonly and so on) are at the RTP session level. They > apply to all SSRCs in the RTP session. > > The mute functions we've been discussing at the API level are at the > MediaStreamTrack level. That maps to wanting to mute a single SSRC. > > How does that affect things? > > a=sendonly / a=recvonly / a=inactive attributes are per "m" line in SDP, so each media line (audio, video, etc) can be put on hold or muted separately. P.S. SDP in general does not work with SSRC, it operates with source and destination ports. Technically speaking, SSRC for the same source/destination pair can change during the call. _____________ Roman Shpount --e89a8ff1c086db955904b6d10142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2012 at 4:08 A= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
Oops.... I suddenly realized:
These mechanisms (a=3Dsendonly and so on) are at the RTP session level. They apply to all SSRCs in the RTP session.

The mute functions we've been discussing at the API level are at th= e MediaStreamTrack level. That maps to wanting to mute a single SSRC.

How does that affect things?


a=3Dsendonly / a=3Drecvonly / a= =3Dinactive attributes are per "m" line in SDP, so each media lin= e (audio, video, etc) can be put on hold or muted separately.

P.S. = SDP in general does not work with SSRC, it operates with source and destina= tion ports. Technically speaking, SSRC for the same source/destination pair= can change during the call.
_____________
Roman Shpount

--e89a8ff1c086db955904b6d10142-- From harald@alvestrand.no Wed Jan 18 09:58:24 2012 Return-Path: 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 A0F8621F8585 for ; Wed, 18 Jan 2012 09:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.16 X-Spam-Level: X-Spam-Status: No, score=-110.16 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, 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 xMDBNx0hi8in for ; Wed, 18 Jan 2012 09:58:24 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C75DA21F8571 for ; Wed, 18 Jan 2012 09:58:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 166C539E12F; Wed, 18 Jan 2012 18:58:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEXh2aGAqCWh; Wed, 18 Jan 2012 18:58:22 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6DA9239E112; Wed, 18 Jan 2012 18:58:22 +0100 (CET) Message-ID: <4F17083D.4000307@alvestrand.no> Date: Wed, 18 Jan 2012 18:58:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070301000007060605000206" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 17:58:24 -0000 This is a multi-part message in MIME format. --------------070301000007060605000206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/18/2012 06:45 PM, Roman Shpount wrote: > > On Wed, Jan 18, 2012 at 4:08 AM, Harald Alvestrand > > wrote: > > Oops.... I suddenly realized: > > These mechanisms (a=sendonly and so on) are at the RTP session > level. They apply to all SSRCs in the RTP session. > > The mute functions we've been discussing at the API level are at > the MediaStreamTrack level. That maps to wanting to mute a single > SSRC. > > How does that affect things? > > > a=sendonly / a=recvonly / a=inactive attributes are per "m" line in > SDP, so each media line (audio, video, etc) can be put on hold or > muted separately. I don't think you understood my question. If we have one SDP session, consisting of two RTP sessions (one for audio and one for video), and each RTP session is carrying two tracks (one for participant A and one for participant B), and we want to mute the audio of participant A, but do not want to mute participant B, how should we signal it? > > P.S. SDP in general does not work with SSRC, it operates with source > and destination ports. Technically speaking, SSRC for the same > source/destination pair can change during the call. Yes, that's why RFC 5576 specified the "previous-ssrc" attribute. --------------070301000007060605000206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/18/2012 06:45 PM, Roman Shpount wrote:

On Wed, Jan 18, 2012 at 4:08 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Oops.... I suddenly realized:

These mechanisms (a=sendonly and so on) are at the RTP session level. They apply to all SSRCs in the RTP session.

The mute functions we've been discussing at the API level are at the MediaStreamTrack level. That maps to wanting to mute a single SSRC.

How does that affect things?


a=sendonly / a=recvonly / a=inactive attributes are per "m" line in SDP, so each media line (audio, video, etc) can be put on hold or muted separately.

I don't think you understood my question.

If we have one SDP session, consisting of two RTP sessions (one for audio and one for video), and each RTP session is carrying two tracks (one for participant A and one for participant B), and we want to mute the audio of participant A, but do not want to mute participant B, how should we signal it?


P.S. SDP in general does not work with SSRC, it operates with source and destination ports. Technically speaking, SSRC for the same source/destination pair can change during the call.

Yes, that's why RFC 5576 specified the "previous-ssrc" attribute.


--------------070301000007060605000206-- From roman@telurix.com Wed Jan 18 10:04:12 2012 Return-Path: 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 505F521F869A for ; Wed, 18 Jan 2012 10:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 J2OCrYgHcDe7 for ; Wed, 18 Jan 2012 10:04:11 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id C9F8721F8698 for ; Wed, 18 Jan 2012 10:04:11 -0800 (PST) Received: by iaae16 with SMTP id e16so2450143iaa.1 for ; Wed, 18 Jan 2012 10:04:11 -0800 (PST) Received: by 10.50.186.226 with SMTP id fn2mr23420127igc.25.1326909851227; Wed, 18 Jan 2012 10:04:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id d15sm466964ibf.7.2012.01.18.10.04.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 10:04:10 -0800 (PST) Received: by pbbb2 with SMTP id b2so5141632pbb.31 for ; Wed, 18 Jan 2012 10:04:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.68 with SMTP id r4mr45436914pbv.102.1326909849438; Wed, 18 Jan 2012 10:04:09 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 18 Jan 2012 10:04:09 -0800 (PST) In-Reply-To: <4F17083D.4000307@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> Date: Wed, 18 Jan 2012 13:04:09 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec54696a1398ae904b6d1465f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 18:04:12 -0000 --bcaec54696a1398ae904b6d1465f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 18, 2012 at 12:58 PM, Harald Alvestrand wrote: > ** > > I don't think you understood my question. > > If we have one SDP session, consisting of two RTP sessions (one for audio > and one for video), and each RTP session is carrying two tracks (one for > participant A and one for participant B), and we want to mute the audio of > participant A, but do not want to mute participant B, how should we signal > it? > I am not sure what you mean here. Are you saying that an end point is getting media from two different remote parties on the same IP and port from the same remote IP and port? Is this due to remote mixer or due to multicast? _____________ Roman Shpount --bcaec54696a1398ae904b6d1465f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2012 at 12:58 = PM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20

I don't think you understood my question.

If we have one SDP session, consisting of two RTP sessions (one for audio and one for video), and each RTP session is carrying two tracks (one for participant A and one for participant B), and we want to mute the audio of participant A, but do not want to mute participant B, how should we signal it?
I am not sure what you mean here. Are you saying that an end point is gett= ing media from two different remote parties on the same IP and port from th= e same remote IP and port? Is this due to remote mixer or due to multicast?=
_____________
Roman Shpount

--bcaec54696a1398ae904b6d1465f-- From harald@alvestrand.no Wed Jan 18 10:13:31 2012 Return-Path: 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 58D3421F8713 for ; Wed, 18 Jan 2012 10:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 ntBAedxrKVLb for ; Wed, 18 Jan 2012 10:13:30 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 413D421F870A for ; Wed, 18 Jan 2012 10:13:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F0B8F39E12F; Wed, 18 Jan 2012 19:13:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnmErQY02XHa; Wed, 18 Jan 2012 19:13:24 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 318F539E112; Wed, 18 Jan 2012 19:13:24 +0100 (CET) Message-ID: <4F170BC3.8030006@alvestrand.no> Date: Wed, 18 Jan 2012 19:13:23 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010905010906090108030604" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 18:13:31 -0000 This is a multi-part message in MIME format. --------------010905010906090108030604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/18/2012 07:04 PM, Roman Shpount wrote: > > On Wed, Jan 18, 2012 at 12:58 PM, Harald Alvestrand > > wrote: > > > I don't think you understood my question. > > If we have one SDP session, consisting of two RTP sessions (one > for audio and one for video), and each RTP session is carrying two > tracks (one for participant A and one for participant B), and we > want to mute the audio of participant A, but do not want to mute > participant B, how should we signal it? > > > I am not sure what you mean here. Are you saying that an end point is > getting media from two different remote parties on the same IP and > port from the same remote IP and port? Is this due to remote mixer or > due to multicast? It's a permitted configuration for a PeerConnection. The discussions around the need to minimize the number of separate ICE setups has led it to be a preferred one. Use cases include multiple cameras (section 4.2.9 in the requirements doc) and central-server video conferencing (section 4.2.10). Harald --------------010905010906090108030604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/18/2012 07:04 PM, Roman Shpount wrote:

On Wed, Jan 18, 2012 at 12:58 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

I don't think you understood my question.

If we have one SDP session, consisting of two RTP sessions (one for audio and one for video), and each RTP session is carrying two tracks (one for participant A and one for participant B), and we want to mute the audio of participant A, but do not want to mute participant B, how should we signal it?

I am not sure what you mean here. Are you saying that an end point is getting media from two different remote parties on the same IP and port from the same remote IP and port? Is this due to remote mixer or due to multicast?
It's a permitted configuration for a PeerConnection. The discussions around the need to minimize the number of separate ICE setups has led it to be a preferred one.

Use cases include multiple cameras (section 4.2.9 in the requirements doc) and central-server video conferencing (section 4.2.10).

            Harald

--------------010905010906090108030604-- From roman@telurix.com Wed Jan 18 10:35:50 2012 Return-Path: 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 E423A11E808E for ; Wed, 18 Jan 2012 10:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] 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 kw+p1Jng978w for ; Wed, 18 Jan 2012 10:35:50 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF8511E8087 for ; Wed, 18 Jan 2012 10:35:50 -0800 (PST) Received: by iaae16 with SMTP id e16so2459085iaa.1 for ; Wed, 18 Jan 2012 10:35:50 -0800 (PST) Received: by 10.50.207.72 with SMTP id lu8mr23675757igc.0.1326911749982; Wed, 18 Jan 2012 10:35:49 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id va6sm45850134igc.6.2012.01.18.10.35.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 10:35:49 -0800 (PST) Received: by dakf10 with SMTP id f10so2188996dak.31 for ; Wed, 18 Jan 2012 10:35:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.230 with SMTP id g6mr46237764pbv.119.1326911747366; Wed, 18 Jan 2012 10:35:47 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 18 Jan 2012 10:35:47 -0800 (PST) In-Reply-To: <4F170BC3.8030006@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> Date: Wed, 18 Jan 2012 13:35:47 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d041911da599eea04b6d1b7ac Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 18:35:51 -0000 --f46d041911da599eea04b6d1b7ac Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 18, 2012 at 1:13 PM, Harald Alvestrand wrote: > ** > It's a permitted configuration for a PeerConnection. The discussions > around the need to minimize the number of separate ICE setups has led it to > be a preferred one. > > Use cases include multiple cameras (section 4.2.9 in the requirements doc) > and central-server video conferencing (section 4.2.10). > > I was under the impression that we planned to reuse the same ip/port with multiple m=lines and different ssrc attributes in SDP for this. In this case end point can refuse each line, negotiate codecs, and support direction attributes for each line separately. It is often needed for both of those use cases anyway, since multiple cameras (or video conference participants) can use different codecs, video resolutions and such. Also, in case of central mixing server, you typically signal the mixing server to put the individual participant on hold via some sort of side channel. _____________ Roman Shpount --f46d041911da599eea04b6d1b7ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 18, 2012 at 1:13 P= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
It's a perm= itted configuration for a PeerConnection. The discussions around the need to minimize the number of separate ICE setups has led it to be a preferred one.

Use cases include multiple cameras (section 4.2.9 in the requirements doc) and central-server video conferencing (section 4.2.10).


I was under the impression that= we planned to reuse the same ip/port with multiple m=3Dlines and different= ssrc attributes in SDP for this. In this case end point can refuse each li= ne, negotiate codecs, and support direction attributes for each line separa= tely. It is often needed for both of those use cases anyway, since multiple= cameras (or video conference participants) can use different codecs, video= resolutions and such. Also, in case of central mixing server, you typicall= y signal the mixing server to put the individual participant on hold via so= me sort of side channel.
_____________
Roman Shpount

--f46d041911da599eea04b6d1b7ac-- From ron.even.tlv@gmail.com Wed Jan 18 11:57:14 2012 Return-Path: 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 8C3D71F0C40 for ; Wed, 18 Jan 2012 11:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zrq7C8RswjqJ for ; Wed, 18 Jan 2012 11:57:13 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CADEE1F0C41 for ; Wed, 18 Jan 2012 11:56:51 -0800 (PST) Received: by eeit10 with SMTP id t10so1876574eei.31 for ; Wed, 18 Jan 2012 11:56:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=w5TBvMveULxXyqsrPWnujApJ7tSc+/GDjhFDgQ085zM=; b=gE88+b/ovYyjuON7DXbSLlEMNeErscx7nBlPaoLhxxqD6kGLT5ACh78IXKnfedEFRY WYCwAaYnc965can90yuXZtNi0ZnWdoKeQgC7Qsos6Sb04q3XhJenC6UKI4zJY1VUv95w q5YyUrnoCoMKojW6nNagOoIefgay0iMlXRrxI= Received: by 10.213.26.11 with SMTP id b11mr1305896ebc.40.1326916610938; Wed, 18 Jan 2012 11:56:50 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id s16sm103634216eef.2.2012.01.18.11.56.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 11:56:49 -0800 (PST) From: "Roni Even" To: "'Harald Alvestrand'" , References: <4F156709.9030604@alvestrand.no> In-Reply-To: <4F156709.9030604@alvestrand.no> Date: Wed, 18 Jan 2012 21:53:14 +0200 Message-ID: <4f172401.10610e0a.39b2.ffffa628@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczVEh9oBr7SIj4nRqyKiRRnErfsLgBCDiig Content-Language: en-us Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 19:57:14 -0000 Hi, If the sender stops sending data but keeps the RTP session it will still send RTCP sender reports allowing the receiver to know that it temporary not sending data. If the sender wants to stop the RTP session he should send an RTCP BYE to close the channel. If receiver do not get data, RTCP sender reports or RTCP BYE he should time out and view the RTP session as closed Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Tuesday, January 17, 2012 2:18 PM > To: rtcweb@ietf.org > Subject: [rtcweb] Open issue: Signalling muted streams > > This came up in an off-list discussion, but I think it should be on our > open issues list: > > When a sender mutes a stream, what happens at the receiving end? > > Either the stream will continue to send data (black/silence), or it > doesn't. > If it continues, no problem. > If it doesn't: > > Either the recipient knows that the non-data is intentional, or he > doesn't. > If he doesn't, we need to make sure nothing times out or gets out of > whack because of the lack of data. > If he knows it's intentional, he has to learn it somehow. > > Either the information comes over the media path, or over the > signalling path. > If it's the media path, there needs to be an RTP-level definition of > what's sent to indicate it. (RTCP message, comfort noise / video > equivalent, other...) If it's the signalling path, there needs to be a > defined API to get the information passed up to the JS layer at the > sender, and passed down from the JS layer at the recipient. > > Thoughts from the community? > > Harald > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Jan 18 12:04:46 2012 Return-Path: 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 9C16211E80B4 for ; Wed, 18 Jan 2012 12:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, 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 vc8zF-wDI0kG for ; Wed, 18 Jan 2012 12:04:46 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65A691F0C47 for ; Wed, 18 Jan 2012 12:04:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A7E3039E12F; Wed, 18 Jan 2012 21:04:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWihZ54PPwSL; Wed, 18 Jan 2012 21:04:44 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0E75639E112; Wed, 18 Jan 2012 21:04:44 +0100 (CET) Message-ID: <4F1725DB.20403@alvestrand.no> Date: Wed, 18 Jan 2012 21:04:43 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090709030203060704080105" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 20:04:46 -0000 This is a multi-part message in MIME format. --------------090709030203060704080105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/18/2012 07:35 PM, Roman Shpount wrote: > > On Wed, Jan 18, 2012 at 1:13 PM, Harald Alvestrand > > wrote: > > It's a permitted configuration for a PeerConnection. The > discussions around the need to minimize the number of separate ICE > setups has led it to be a preferred one. > > Use cases include multiple cameras (section 4.2.9 in the > requirements doc) and central-server video conferencing (section > 4.2.10). > > > I was under the impression that we planned to reuse the same ip/port > with multiple m=lines and different ssrc attributes in SDP for this. > In this case end point can refuse each line, negotiate codecs, and > support direction attributes for each line separately. It is often > needed for both of those use cases anyway, since multiple cameras (or > video conference participants) can use different codecs, video > resolutions and such. That wasn't my impression. The ultimate goal of the "reuse" discussions, as I see it, is to send all the audio and all the video over a single IP/port pair. If we can't get reuse, we'll revert to doing one RTP session for all the audio and one RTP session for all the video. > Also, in case of central mixing server, you typically signal the > mixing server to put the individual participant on hold via some sort > of side channel. And how does the mixing server tell the end-user that a channel has been put on hold? > _____________ > Roman Shpount > --------------090709030203060704080105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/18/2012 07:35 PM, Roman Shpount wrote:

On Wed, Jan 18, 2012 at 1:13 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
It's a permitted configuration for a PeerConnection. The discussions around the need to minimize the number of separate ICE setups has led it to be a preferred one.

Use cases include multiple cameras (section 4.2.9 in the requirements doc) and central-server video conferencing (section 4.2.10).


I was under the impression that we planned to reuse the same ip/port with multiple m=lines and different ssrc attributes in SDP for this. In this case end point can refuse each line, negotiate codecs, and support direction attributes for each line separately. It is often needed for both of those use cases anyway, since multiple cameras (or video conference participants) can use different codecs, video resolutions and such.
That wasn't my impression. The ultimate goal of the "reuse" discussions, as I see it, is to send all the audio and all the video over a single IP/port pair. If we can't get reuse, we'll revert to doing one RTP session for all the audio and one RTP session for all the video.

Also, in case of central mixing server, you typically signal the mixing server to put the individual participant on hold via some sort of side channel.
And how does the mixing server tell the end-user that a channel has been put on hold?

_____________
Roman Shpount


--------------090709030203060704080105-- From csp@csperkins.org Wed Jan 18 14:12:04 2012 Return-Path: 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 73EB311E809C for ; Wed, 18 Jan 2012 14:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 WYFhdvt9y-F8 for ; Wed, 18 Jan 2012 14:12:03 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAB11E807F for ; Wed, 18 Jan 2012 14:12:03 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Rndjd-000277-ca; Wed, 18 Jan 2012 22:12:02 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <4F156709.9030604@alvestrand.no> Date: Wed, 18 Jan 2012 22:11:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCB835D-F42E-4120-85ED-AA4BDEE663D7@csperkins.org> References: <4F156709.9030604@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Wed, 18 Jan 2012 22:12:04 -0000 On 17 Jan 2012, at 12:18, Harald Alvestrand wrote: > This came up in an off-list discussion, but I think it should be on = our open issues list: >=20 > When a sender mutes a stream, what happens at the receiving end? >=20 > Either the stream will continue to send data (black/silence), or it = doesn't. > If it continues, no problem. > If it doesn't: >=20 > Either the recipient knows that the non-data is intentional, or he = doesn't. > If he doesn't, we need to make sure nothing times out or gets out of = whack because of the lack of data. > If he knows it's intentional, he has to learn it somehow. >=20 > Either the information comes over the media path, or over the = signalling path. > If it's the media path, there needs to be an RTP-level definition of = what's sent to indicate it. (RTCP message, comfort noise / video = equivalent, other=85) RTCP SR packets include a "sender's packet count" field. A sender which = stops transmitting RTP data packets will keep sending RTCP packets, and = the receiver can tell from the non-increasing sender packet count that = the sender stopped transmitting, rather than the path losing the = packets. This takes a couple of reports before the receiver is sure, of = course, so can be relatively slow (although using AVPF to send an SR = just after the last video packet, coupled with a reasonably short = reporting interval to get a second SR, should inform the receiver = reasonably quickly, and we'll need a reasonably short reporting interval = to make the congestion control stable most likely). Colin > If it's the signalling path, there needs to be a defined API to get = the information passed up to the JS layer at the sender, and passed down = from the JS layer at the recipient. >=20 > Thoughts from the community? >=20 > Harald >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From christer.holmberg@ericsson.com Wed Jan 18 22:23:09 2012 Return-Path: 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 238DB21F8584 for ; Wed, 18 Jan 2012 22:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.072 X-Spam-Level: X-Spam-Status: No, score=-8.072 tagged_above=-999 required=5 tests=[AWL=1.927, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] 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 I9cxw4ZD3V6d for ; Wed, 18 Jan 2012 22:23:08 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 352EE21F8581 for ; Wed, 18 Jan 2012 22:23:07 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-45-4f17b6ca37de Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.25.09514.AC6B71F4; Thu, 19 Jan 2012 07:23:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 19 Jan 2012 07:23:06 +0100 From: Christer Holmberg To: Harald Alvestrand , Roman Shpount Date: Thu, 19 Jan 2012 07:23:05 +0100 Thread-Topic: [rtcweb] Open issue: Signalling muted streams Thread-Index: AczWHG+UWoMpsWJ9QruyYORjtoVVDAAVcUTA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> In-Reply-To: <4F1725DB.20403@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 06:23:09 -0000 Hi Harald, >> I was under the impression that we planned to reuse the same ip/port wit= h multiple m=3Dlines and=20 >> different ssrc attributes in SDP for this. In this case end point can re= fuse each line, negotiate=20 >> codecs, and support direction attributes for each line separately. It is= often needed for both=20 >> of those use cases anyway, since multiple cameras (or video conference p= articipants) can use=20 >> different codecs, video resolutions and such. > > That wasn't my impression. The ultimate goal of the "reuse" discussions, = as I see it, is to send all=20 > the audio and all the video over a single IP/port pair. If we can't get r= euse, we'll revert to doing=20 > one RTP session for all the audio and one RTP session for all the video. As you know, BUNDLE allows the sending of all the audio and all the video o= ver a single IP/port pair, still using multiple m=3D lines :) I guess the question here is whether a single m=3D line could contain multi= ple media tracks, and you want to be able to control them individualy, in w= hich case you could not use direction attributes etc which affect the whole= m=3D line. Regards, Christer From roman@telurix.com Thu Jan 19 08:05:29 2012 Return-Path: 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 2171721F8698 for ; Thu, 19 Jan 2012 08:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 HYUX87zz0xw2 for ; Thu, 19 Jan 2012 08:05:28 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6886521F8685 for ; Thu, 19 Jan 2012 08:05:28 -0800 (PST) Received: by iaae16 with SMTP id e16so20795iaa.1 for ; Thu, 19 Jan 2012 08:05:27 -0800 (PST) Received: by 10.42.163.200 with SMTP id d8mr22624580icy.41.1326989127775; Thu, 19 Jan 2012 08:05:27 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id cv10sm43104241igc.0.2012.01.19.08.05.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 08:05:25 -0800 (PST) Received: by dakf10 with SMTP id f10so53411dak.31 for ; Thu, 19 Jan 2012 08:05:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr53871158pbv.85.1326989124211; Thu, 19 Jan 2012 08:05:24 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 08:05:23 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 19 Jan 2012 11:05:23 -0500 Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec54693e75e932204b6e3bb3c Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 16:05:29 -0000 --bcaec54693e75e932204b6e3bb3c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > I guess the question here is whether a single m= line could contain > multiple media tracks, and you want to be able to control them individualy, > in which case you could not use direction attributes etc which affect the > whole m= line. > > Using multiple media tracks with a single m line is tricky. For instance it would require dynamically to create and remove windows for each remote video participant. And you are obviously loosing a lot of control over individual participants such as direction attributes or codec settings. Out of curiosity, would current WebRTC implementation even support multiple simultaneous sources over the same m=line for video? _____________ Roman Shpount --bcaec54693e75e932204b6e3bb3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2012 at 1:23 A= M, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I guess the question here is whether a single m=3D line could contain multi= ple media tracks, and you want to be able to control them individualy, in w= hich case you could not use direction attributes etc which affect the whole= m=3D line.


Using multiple media tracks with a single m line= is tricky. For instance it would require dynamically to create and remove = windows for each remote video participant. And you are obviously loosing a = lot of control over individual participants such as direction attributes or= codec settings.

Out of curiosity, would current WebRTC implementation even support mult= iple simultaneous sources over the same m=3Dline for video?
___________= __
Roman Shpount

--bcaec54693e75e932204b6e3bb3c-- From harald@alvestrand.no Thu Jan 19 08:13:36 2012 Return-Path: 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 3536321F868A for ; Thu, 19 Jan 2012 08:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.158 X-Spam-Level: X-Spam-Status: No, score=-110.158 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 H1msNgwCSvBK for ; Thu, 19 Jan 2012 08:13:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 486AA21F8684 for ; Thu, 19 Jan 2012 08:13:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 562BD39E129; Thu, 19 Jan 2012 17:13:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ9dEfnnbMbH; Thu, 19 Jan 2012 17:13:33 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A544C39E106; Thu, 19 Jan 2012 17:13:33 +0100 (CET) Message-ID: <4F18412D.2070706@alvestrand.no> Date: Thu, 19 Jan 2012 17:13:33 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020001030004000301000605" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 16:13:36 -0000 This is a multi-part message in MIME format. --------------020001030004000301000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/19/2012 05:05 PM, Roman Shpount wrote: > > On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg > > wrote: > > > I guess the question here is whether a single m= line could > contain multiple media tracks, and you want to be able to control > them individualy, in which case you could not use direction > attributes etc which affect the whole m= line. > > > Using multiple media tracks with a single m line is tricky. For > instance it would require dynamically to create and remove windows for > each remote video participant. And you are obviously loosing a lot of > control over individual participants such as direction attributes or > codec settings. > > Out of curiosity, would current WebRTC implementation even support > multiple simultaneous sources over the same m=line for video? I can only speak to the one WebRTC implementation I know about (Chrome), and it only supports one video stream in one PeerConnection. But that's a temporary limitation. We intend to support multiple simultaneous sources over the same m= line; in fact we have no intention of ever generating multiple m= lines for video sources - we see no need to. However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about. Harald --------------020001030004000301000605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/19/2012 05:05 PM, Roman Shpount wrote:

On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I guess the question here is whether a single m= line could contain multiple media tracks, and you want to be able to control them individualy, in which case you could not use direction attributes etc which affect the whole m= line.


Using multiple media tracks with a single m line is tricky. For instance it would require dynamically to create and remove windows for each remote video participant. And you are obviously loosing a lot of control over individual participants such as direction attributes or codec settings.

Out of curiosity, would current WebRTC implementation even support multiple simultaneous sources over the same m=line for video?
I can only speak to the one WebRTC implementation I know about (Chrome), and it only supports one video stream in one PeerConnection. But that's a temporary limitation.

We intend to support multiple simultaneous sources over the same m= line; in fact we have no intention of ever generating multiple m= lines for video sources - we see no need to.

However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about.

                  Harald


--------------020001030004000301000605-- From roman@telurix.com Thu Jan 19 08:29:39 2012 Return-Path: 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 6572F21F863C for ; Thu, 19 Jan 2012 08:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NhN47l+y4Asl for ; Thu, 19 Jan 2012 08:29:38 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id C672021F850C for ; Thu, 19 Jan 2012 08:29:38 -0800 (PST) Received: by iaae16 with SMTP id e16so27264iaa.1 for ; Thu, 19 Jan 2012 08:29:38 -0800 (PST) Received: by 10.42.243.198 with SMTP id ln6mr26692179icb.29.1326990578458; Thu, 19 Jan 2012 08:29:38 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id gd2sm3874372igc.1.2012.01.19.08.29.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 08:29:37 -0800 (PST) Received: by pbaa13 with SMTP id a13so177188pba.31 for ; Thu, 19 Jan 2012 08:29:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr54024334pbv.85.1326990576460; Thu, 19 Jan 2012 08:29:36 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 08:29:36 -0800 (PST) In-Reply-To: <4F18412D.2070706@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> <4F18412D.2070706@alvestrand.no> Date: Thu, 19 Jan 2012 11:29:36 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec54693e7ee21b404b6e4118d Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 16:29:39 -0000 --bcaec54693e7ee21b404b6e4118d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 19, 2012 at 11:13 AM, Harald Alvestrand wrote: > ** > We intend to support multiple simultaneous sources over the same m= line; > in fact we have no intention of ever generating multiple m= lines for video > sources - we see no need to. > > However, that requires some work on signaling the association between > media carried on SSRCs and media presented as MediaStreamTracks inside > MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I > mentioned on this list a week ago, is all about. > > I guess if we are changing the way things normally work, we can put together a draft that defines directional attributes as an source level attributes. Something like: a=ssrc:12345 sendonly a=ssrc:12345 recvonly a=ssrc:12345 inactive BTW, have anybody considered the implications of carrying multiple audio or video sources over the same m= line on interop? This would probably require a very non-trivial signaling logic in order to interop with anything that does not support this, since adding a media source in this case will not require a signaling transaction. Because of this, something like an SBC will need to monitor RTP and then issue signaling transactions to add or remove additional m-lines. _____________ Roman Shpount --bcaec54693e7ee21b404b6e4118d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 19, 2012 at 11:13 AM, Harald Alvestrand <<= a href=3D"mailto:harald@alvestrand.no">harald@alvestrand.no> = wrote:
=20 =20 =20
We intend to su= pport multiple simultaneous sources over the same m=3D line; in fact we have no intention of ever generating multiple m=3D lines for video sources - we see no need to.

However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about.

I guess if we are changing the way = things normally work, we can put=20 together a draft that defines directional attributes as an source level=20 attributes.

Something like:
a=3Dssrc:12345 sendonly
a=3Dssrc:12345 recvonly
a=3Dssrc:12345 inactive

BTW, have anybody considered the implication= s of carrying multiple audio or video sources over the same m=3D line on in= terop? This would probably require a very non-trivial signaling logic in or= der to interop with anything that does not support this, since adding a med= ia source in this case will not require a signaling transaction. Because of= this, something like an SBC will need to monitor RTP and then issue signal= ing transactions to add or remove additional m-lines.
_____________
Roman Shpount


--bcaec54693e7ee21b404b6e4118d-- From vvenkatar@gmail.com Thu Jan 19 08:52:17 2012 Return-Path: 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 2C19D21F8642 for ; Thu, 19 Jan 2012 08:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 27uQiSwDR8UM for ; Thu, 19 Jan 2012 08:52:16 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59FEE21F84B6 for ; Thu, 19 Jan 2012 08:52:16 -0800 (PST) Received: by qady23 with SMTP id y23so1337630qad.10 for ; Thu, 19 Jan 2012 08:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JZS+FjX7OMvyUTC7xv7RzUqzNzBk4qv2Rhs+eUKvfqU=; b=rVy+Dh8NPyT1dU+BFCZWukRLo2TB9vYe+PhezHh5sWpvY6J5cgIayHsY4LCm/CLLK1 qjGrBHgsYkCSBolRj6buTZi2BESB7x/jUJgdkrKaC1tknIcROAlXvBZ4ZA6As8eFcYvH 0K8VgB1W834EpgVGkL3d2fB1iO+y4xby8PF4U= MIME-Version: 1.0 Received: by 10.224.198.3 with SMTP id em3mr12897049qab.23.1326991935934; Thu, 19 Jan 2012 08:52:15 -0800 (PST) Received: by 10.229.223.135 with HTTP; Thu, 19 Jan 2012 08:52:15 -0800 (PST) In-Reply-To: <4F18412D.2070706@alvestrand.no> References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> <4F18412D.2070706@alvestrand.no> Date: Thu, 19 Jan 2012 08:52:15 -0800 Message-ID: From: Venkatesh To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf300fb3fdf6120304b6e462a2 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 16:52:17 -0000 --20cf300fb3fdf6120304b6e462a2 Content-Type: text/plain; charset=ISO-8859-1 Harold: If you are going to be signaling the SSRC's in the SDP rather than using multiple m lines, may be, we could extend it to be able to provide directional attributes on a per SSRC basis? Venkatesh On Thu, Jan 19, 2012 at 8:13 AM, Harald Alvestrand wrote: > ** > On 01/19/2012 05:05 PM, Roman Shpount wrote: > > > On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >> I guess the question here is whether a single m= line could contain >> multiple media tracks, and you want to be able to control them individualy, >> in which case you could not use direction attributes etc which affect the >> whole m= line. >> >> > Using multiple media tracks with a single m line is tricky. For instance > it would require dynamically to create and remove windows for each remote > video participant. And you are obviously loosing a lot of control over > individual participants such as direction attributes or codec settings. > > Out of curiosity, would current WebRTC implementation even support > multiple simultaneous sources over the same m=line for video? > > I can only speak to the one WebRTC implementation I know about (Chrome), > and it only supports one video stream in one PeerConnection. But that's a > temporary limitation. > > We intend to support multiple simultaneous sources over the same m= line; > in fact we have no intention of ever generating multiple m= lines for video > sources - we see no need to. > > However, that requires some work on signaling the association between > media carried on SSRCs and media presented as MediaStreamTracks inside > MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I > mentioned on this list a week ago, is all about. > > Harald > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf300fb3fdf6120304b6e462a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Harold:
If you are going to be signaling the SSRC's = in the SDP rather than using multiple m lines, may be,=A0we could extend it= to be able to provide=A0directional attributes on a per SSRC basis?
<= div> =A0
Venkatesh
=A0
On Thu, Jan 19, 2012 at 8:1= 3 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 01/19/2012 05:05 PM, Roman Shpount wrote:

On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I guess the question here is whether a single m=3D line could contain multiple media tracks, and you want to be able to control them individualy, in which case you could not use direction attributes etc which affect the whole m=3D line.


Using multiple media tracks with a single m line is tricky. For instance it would require dynamically to create and remove windows for each remote video participant. And you are obviously loosing a lot of control over individual participants such as direction attributes or codec settings.

Out of curiosity, would current WebRTC implementation even support multiple simultaneous sources over the same m=3Dline for video?
I can only speak to the one WebRTC implementation I know about (Chrome), and it only supports one video stream in one PeerConnection. But that's a temporary limitation.

We intend to support multiple simultaneous sources over the same m=3D line; in fact we have no intention of ever generating multiple m=3D lines for video sources - we see no need to.

However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--20cf300fb3fdf6120304b6e462a2-- From harald@alvestrand.no Thu Jan 19 09:43:35 2012 Return-Path: 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 099D021F86C4 for ; Thu, 19 Jan 2012 09:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 wXykfImqKZAE for ; Thu, 19 Jan 2012 09:43:34 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6D21F86C5 for ; Thu, 19 Jan 2012 09:43:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7188F39E129; Thu, 19 Jan 2012 18:43:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI9n7vq22uKy; Thu, 19 Jan 2012 18:43:24 +0100 (CET) Received: from [172.16.33.99] (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AFBA039E106; Thu, 19 Jan 2012 18:43:24 +0100 (CET) Message-ID: <4F18563C.6000809@alvestrand.no> Date: Thu, 19 Jan 2012 18:43:24 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> <4F18412D.2070706@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090407050307000102020404" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 17:43:35 -0000 This is a multi-part message in MIME format. --------------090407050307000102020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/19/2012 05:29 PM, Roman Shpount wrote: > On Thu, Jan 19, 2012 at 11:13 AM, Harald Alvestrand > > wrote: > > We intend to support multiple simultaneous sources over the same > m= line; in fact we have no intention of ever generating multiple > m= lines for video sources - we see no need to. > > However, that requires some work on signaling the association > between media carried on SSRCs and media presented as > MediaStreamTracks inside MediaStreams at the API; that's what > draft-alvestrand-rtcweb-msid, which I mentioned on this list a > week ago, is all about. > > I guess if we are changing the way things normally work, we can put > together a draft that defines directional attributes as an source > level attributes. > > Something like: > a=ssrc:12345 sendonly > a=ssrc:12345 recvonly > a=ssrc:12345 inactive > > BTW, have anybody considered the implications of carrying multiple > audio or video sources over the same m= line on interop? This would > probably require a very non-trivial signaling logic in order to > interop with anything that does not support this, since adding a media > source in this case will not require a signaling transaction. Because > of this, something like an SBC will need to monitor RTP and then issue > signaling transactions to add or remove additional m-lines. See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this. FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP session. > _____________ > Roman Shpount > > --------------090407050307000102020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/19/2012 05:29 PM, Roman Shpount wrote:
On Thu, Jan 19, 2012 at 11:13 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
We intend to support multiple simultaneous sources over the same m= line; in fact we have no intention of ever generating multiple m= lines for video sources - we see no need to.

However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about.

I guess if we are changing the way things normally work, we can put together a draft that defines directional attributes as an source level attributes.

Something like:
a=ssrc:12345 sendonly
a=ssrc:12345 recvonly
a=ssrc:12345 inactive

BTW, have anybody considered the implications of carrying multiple audio or video sources over the same m= line on interop? This would probably require a very non-trivial signaling logic in order to interop with anything that does not support this, since adding a media source in this case will not require a signaling transaction. Because of this, something like an SBC will need to monitor RTP and then issue signaling transactions to add or remove additional m-lines.
See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this.

FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP session.

_____________
Roman Shpount



--------------090407050307000102020404-- From roman@telurix.com Thu Jan 19 10:08:41 2012 Return-Path: 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 3F78C21F85EE for ; Thu, 19 Jan 2012 10:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 J6vjylRPBuQw for ; Thu, 19 Jan 2012 10:08:40 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id B705821F859A for ; Thu, 19 Jan 2012 10:08:40 -0800 (PST) Received: by iaae16 with SMTP id e16so54572iaa.1 for ; Thu, 19 Jan 2012 10:08:40 -0800 (PST) Received: by 10.42.144.69 with SMTP id a5mr13342363icv.45.1326996520039; Thu, 19 Jan 2012 10:08:40 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id lu10sm227491igc.0.2012.01.19.10.08.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 10:08:39 -0800 (PST) Received: by dakf10 with SMTP id f10so144401dak.31 for ; Thu, 19 Jan 2012 10:08:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.135.4 with SMTP id po4mr4351694pbb.68.1326996517597; Thu, 19 Jan 2012 10:08:37 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 10:08:37 -0800 (PST) Date: Thu, 19 Jan 2012 13:08:37 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b10c9630eb04204b6e57409 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 18:08:41 -0000 --047d7b10c9630eb04204b6e57409 Content-Type: text/plain; charset=ISO-8859-1 Switching to a new topic. On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand wrote: > ** > See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this. > > FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP > session. > Just to clarify -- for interop this would be disabled and the system would fall back to using an m-line per each stream, correct? What are the benefits of doing this vs bundle? _____________ Roman Shpount --047d7b10c9630eb04204b6e57409 Content-Type: text/html; charset=ISO-8859-1 Switching to a new topic.

On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this.

FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP session.

Just to clarify -- for interop this would be disabled and the system would fall back to using an m-line per each stream, correct?

What are the benefits of doing this vs bundle?
_____________
Roman Shpount


--047d7b10c9630eb04204b6e57409-- From harald@alvestrand.no Thu Jan 19 10:13:55 2012 Return-Path: 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 78C2521F85CE for ; Thu, 19 Jan 2012 10:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.156 X-Spam-Level: X-Spam-Status: No, score=-110.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 m2HxfoUXxMDc for ; Thu, 19 Jan 2012 10:13:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 602B421F857A for ; Thu, 19 Jan 2012 10:13:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A6AC39E129; Thu, 19 Jan 2012 19:13:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e2Bnyggqdzl; Thu, 19 Jan 2012 19:13:46 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0366739E106; Thu, 19 Jan 2012 19:13:45 +0100 (CET) Message-ID: <4F185D59.1000609@alvestrand.no> Date: Thu, 19 Jan 2012 19:13:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060006070000010108070005" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 18:13:55 -0000 This is a multi-part message in MIME format. --------------060006070000010108070005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/19/2012 07:08 PM, Roman Shpount wrote: > Switching to a new topic. > > On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand > > wrote: > > See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this. > > FWIW, Google Hangouts works just fine with a large number of SSRCs > per RTP session. > > > Just to clarify -- for interop this would be disabled and the system > would fall back to using an m-line per each stream, correct? So far, the only interop we've been doing from hangouts is with phone gateways, and that link uses intermediate servers. (https://plus.google.com/u/0/104364547339874244431/posts/gKKyJjTpzj8 for the details). > > What are the benefits of doing this vs bundle? We're planning on doing bundle too, in order to reduce our connections from 2 to 1 RTP session per client, but bundle did not exist until recently; the hangouts work started a long time ago. --------------060006070000010108070005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/19/2012 07:08 PM, Roman Shpount wrote:
Switching to a new topic.

On Thu, Jan 19, 2012 at 12:43 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
See draft-westerlund-avtcore-max-ssrc-00 for one discussion of this.

FWIW, Google Hangouts works just fine with a large number of SSRCs per RTP session.

Just to clarify -- for interop this would be disabled and the system would fall back to using an m-line per each stream, correct?
So far, the only interop we've been doing from hangouts is with phone gateways, and that link uses intermediate servers. (https://plus.google.com/u/0/104364547339874244431/posts/gKKyJjTpzj8 for the details).

What are the benefits of doing this vs bundle?
We're planning on doing bundle too, in order to reduce our connections from 2 to 1 RTP session per client, but bundle did not exist until recently; the hangouts work started a long time ago.



--------------060006070000010108070005-- From roman@telurix.com Thu Jan 19 10:23:12 2012 Return-Path: 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 7962221F854A for ; Thu, 19 Jan 2012 10:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 K8IOUyla3FaC for ; Thu, 19 Jan 2012 10:23:11 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id A59F121F8548 for ; Thu, 19 Jan 2012 10:23:10 -0800 (PST) Received: by iaae16 with SMTP id e16so58376iaa.1 for ; Thu, 19 Jan 2012 10:23:10 -0800 (PST) Received: by 10.50.194.199 with SMTP id hy7mr17813714igc.26.1326997390216; Thu, 19 Jan 2012 10:23:10 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id lu10sm281691igc.0.2012.01.19.10.23.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 10:23:09 -0800 (PST) Received: by pbaa13 with SMTP id a13so257568pba.31 for ; Thu, 19 Jan 2012 10:23:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.115.195 with SMTP id jq3mr54941639pbb.34.1326997388396; Thu, 19 Jan 2012 10:23:08 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 10:23:08 -0800 (PST) In-Reply-To: <4F185D59.1000609@alvestrand.no> References: <4F185D59.1000609@alvestrand.no> Date: Thu, 19 Jan 2012 13:23:08 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7b15a389f40a1304b6e5a711 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 18:23:12 -0000 --047d7b15a389f40a1304b6e5a711 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 19, 2012 at 1:13 PM, Harald Alvestrand wrote: > ** > > What are the benefits of doing this vs bundle? > > We're planning on doing bundle too, in order to reduce our connections > from 2 to 1 RTP session per client, but bundle did not exist until > recently; the hangouts work started a long time ago. > So, why won't we just do bundling? This allows for more functionality (different payload types per SSRC, ability to accept/reject each individual SSRC, directional attributes) and still allows to reduce number of ICE setups. Unless there is a strong requirement or benefit of doing just multiple SSRC without any signaling announcements, bundling just seems a better solution. _____________ Roman Shpount --047d7b15a389f40a1304b6e5a711 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2012 at 1:13 P= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
What are the benefits of doing this vs bundle?
We're planning on doing bundle too, in order to reduce our connections from 2 to 1 RTP session per client, but bundle did not exist until recently; the hangouts work started a long time ago.
=20

So, why won't we just do bundling? This allows f= or more functionality (different payload types per SSRC, ability to accept/= reject each individual SSRC, directional attributes) and still allows to re= duce number of ICE setups. Unless there is a strong requirement or benefit = of doing just multiple SSRC without any signaling announcements, bundling j= ust seems a better solution.
_____________
Roman Shpount

--047d7b15a389f40a1304b6e5a711-- From juberti@google.com Thu Jan 19 10:55:30 2012 Return-Path: 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 339D921F86A5 for ; Thu, 19 Jan 2012 10:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, 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 m0MKwgCF9Mci for ; Thu, 19 Jan 2012 10:55:29 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9721F86A3 for ; Thu, 19 Jan 2012 10:55:29 -0800 (PST) Received: by qcsc1 with SMTP id c1so160185qcs.31 for ; Thu, 19 Jan 2012 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=LTDbZpSlcQBO6AyBBu39THgB1HL2kNZPn0ysNJqsClM=; b=ZJR4WQAuDcwcYKWPpN+2h+2cesR3hzsCLf6oHAy2KCxa56tdHtjkIURTYH9b3UdmSB EOQEhqEMC7g53Jrzzgr6XYZhCynr3jtSr6kt/N2WcZoZHtZgfAhV9J3NPLzSHHZnbmf8 IlepqCcXXZS6blYVPVlZVpTTOL37enoxJUmyk= Received: by 10.229.76.11 with SMTP id a11mr11166973qck.71.1326999329058; Thu, 19 Jan 2012 10:55:29 -0800 (PST) Received: by 10.229.76.11 with SMTP id a11mr11166927qck.71.1326999327268; Thu, 19 Jan 2012 10:55:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.133.131 with HTTP; Thu, 19 Jan 2012 10:55:06 -0800 (PST) In-Reply-To: References: <4F185D59.1000609@alvestrand.no> From: Justin Uberti Date: Thu, 19 Jan 2012 13:55:06 -0500 Message-ID: To: Roman Shpount X-System-Of-Record: true Content-Type: multipart/alternative; boundary=00235447034484e1f704b6e61be7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 18:55:30 -0000 --00235447034484e1f704b6e61be7 Content-Type: text/plain; charset=UTF-8 I think there is value in being able to separate the concept of a source from a session. For instance, you may want to set the bandwidth for an overall session, but allow flexibility in how that is distributed between sources. RFC 5576 provides the signaling information necessary to perform SSRC multiplexing; while BUNDLE provides other benefits, we don't need to use it in this case. On Thu, Jan 19, 2012 at 1:23 PM, Roman Shpount wrote: > > On Thu, Jan 19, 2012 at 1:13 PM, Harald Alvestrand wrote: > >> ** >> >> What are the benefits of doing this vs bundle? >> >> We're planning on doing bundle too, in order to reduce our connections >> from 2 to 1 RTP session per client, but bundle did not exist until >> recently; the hangouts work started a long time ago. >> > > So, why won't we just do bundling? This allows for more functionality > (different payload types per SSRC, ability to accept/reject each individual > SSRC, directional attributes) and still allows to reduce number of ICE > setups. Unless there is a strong requirement or benefit of doing just > multiple SSRC without any signaling announcements, bundling just seems a > better solution. > _____________ > Roman Shpount > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --00235447034484e1f704b6e61be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think there is value in being able to separate the concept of a source fr= om a session. For instance, you may want to set the bandwidth for an overal= l session, but allow flexibility in how that is distributed between sources= .

RFC 5576 provides the signaling information necessary to per= form SSRC multiplexing; while BUNDLE provides other benefits, we don't = need to use it in this case.

On Thu, Jan = 19, 2012 at 1:23 PM, Roman Shpount <roman@telurix.com> wrote:

On Thu, Jan 19, 2012 at 1:13 PM, Harald Alvestrand <= harald@alvestrand.no> wrote:
=20 =20 =20
What are the benefits of doing this vs bundle?
We're planning on doing bundle too, in order to reduce our connections from 2 to 1 RTP session per client, but bundle did not exist until recently; the hangouts work started a long time ago.
=20

So, why won't we just do bundling? This al= lows for more functionality (different payload types per SSRC, ability to a= ccept/reject each individual SSRC, directional attributes) and still allows= to reduce number of ICE setups. Unless there is a strong requirement or be= nefit of doing just multiple SSRC without any signaling announcements, bund= ling just seems a better solution.
_____________
Roman Shpou= nt


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--00235447034484e1f704b6e61be7-- From roman@telurix.com Thu Jan 19 11:05:46 2012 Return-Path: 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 2A7F721F8648 for ; Thu, 19 Jan 2012 11:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 jLmUo2EjRlvK for ; Thu, 19 Jan 2012 11:05:45 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9A21F8690 for ; Thu, 19 Jan 2012 11:05:45 -0800 (PST) Received: by iaae16 with SMTP id e16so69923iaa.1 for ; Thu, 19 Jan 2012 11:05:45 -0800 (PST) Received: by 10.50.160.136 with SMTP id xk8mr16618888igb.12.1326999945272; Thu, 19 Jan 2012 11:05:45 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id gf6sm43774523igb.1.2012.01.19.11.05.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 11:05:43 -0800 (PST) Received: by dakf10 with SMTP id f10so182029dak.31 for ; Thu, 19 Jan 2012 11:05:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.11 with SMTP id y11mr55141913pbv.51.1326999942610; Thu, 19 Jan 2012 11:05:42 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 11:05:42 -0800 (PST) In-Reply-To: References: <4F185D59.1000609@alvestrand.no> Date: Thu, 19 Jan 2012 14:05:42 -0500 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b15a4a7323f0904b6e64005 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 19:05:46 -0000 --047d7b15a4a7323f0904b6e64005 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 19, 2012 at 1:55 PM, Justin Uberti wrote: > I think there is value in being able to separate the concept of a source > from a session. For instance, you may want to set the bandwidth for an > overall session, but allow flexibility in how that is distributed between > sources. > > RFC 5576 provides the signaling information necessary to perform SSRC > multiplexing; while BUNDLE provides other benefits, we don't need to use it > in this case. > > The whole reason this came about is that in case of bundling we can put individual participants on hold. In case of SSRC multiplexing, we need to define something new. In general, I am cautious of SSRC multiplexing since it does not require a new signaling interaction when new source is added to removed. An end point declares that it can take up-to 5 sources and it should take any 5 sources that are sent to it. No individual direction control, very rough payload and allowed resolution control. This seems to be completely un-interopable with anything which does not explicitly supports this. With bundling you can map each SSRC to an individual remote ip/port on the SBC and still conduct signaling exchange as normal. SSRC multiplexing does not seem to map to legacy signaling exchange at all and would need to be disabled to work with it. _____________ Roman Shpount --047d7b15a4a7323f0904b6e64005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2012 at 1:55 P= M, Justin Uberti <juberti@google.com> wrote:

The whole reason=A0 this came= about is that in case of bundling we can put individual participants on ho= ld. In case of SSRC multiplexing, we need to define something new.

In general, I am cautious of SSRC multiplexing since it does not require a = new signaling interaction when new source is added to removed. An end point= declares that it can take up-to 5 sources and it should take any 5 sources= that are sent to it. No individual direction control, very rough payload a= nd allowed resolution control. This seems to be completely un-interopable w= ith anything which does not explicitly supports this. With bundling you can= map each SSRC to an individual remote ip/port on the SBC and still conduct= signaling exchange as normal. SSRC multiplexing does not seem to map to le= gacy signaling exchange at all and would need to be disabled to work with i= t.

_____________
Roman Shpount


--047d7b15a4a7323f0904b6e64005-- From bernard_aboba@hotmail.com Thu Jan 19 15:38:23 2012 Return-Path: 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 9C7E321F8552 for ; Thu, 19 Jan 2012 15:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.003 X-Spam-Level: X-Spam-Status: No, score=-102.003 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 L1423HNHuvo4 for ; Thu, 19 Jan 2012 15:38:23 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id 9319321F854E for ; Thu, 19 Jan 2012 15:38:22 -0800 (PST) Received: from BLU152-DS13 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 15:38:22 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Justin Uberti'" References: <4F185D59.1000609@alvestrand.no> In-Reply-To: Date: Thu, 19 Jan 2012 15:38:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A5_01CCD6C0.70A35900" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQFm3LNpYn1B5iudD/EUL/Zq0hZ4iQMKXBeDAlJ6C6EB2eUd+QIJ/UMslpZGR5A= X-OriginalArrivalTime: 19 Jan 2012 23:38:22.0359 (UTC) FILETIME=[6E607270:01CCD703] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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, 19 Jan 2012 23:38:23 -0000 ------=_NextPart_000_02A5_01CCD6C0.70A35900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Roman said: SSRC multiplexing does not seem to map to legacy signaling exchange at all and would need to be disabled to work with it. [BA] To date implementations have tended to assume that an MCU is used. However, for small conferences peer-to-peer interaction is feasible and advantageous. So while I'm not a fan of multiplexing audio/video on the same address/port (it degrades the security assurances provided by ICE), SSRC multiplexing has significant benefits in small conference scenarios. ------=_NextPart_000_02A5_01CCD6C0.70A35900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roman said:

 

SSRC multiplexing = does not seem to map to legacy signaling exchange at all and would need = to be disabled to work with it.

 

[BA] To date implementations have tended to assume that an MCU is = used.  However, for small conferences peer-to-peer interaction is = feasible and advantageous.  So while I'm not a fan of multiplexing = audio/video on the same address/port (it degrades the security = assurances provided by ICE), SSRC multiplexing has significant benefits = in small conference scenarios.

------=_NextPart_000_02A5_01CCD6C0.70A35900-- From roman@telurix.com Thu Jan 19 16:29:17 2012 Return-Path: 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 0897021F86D7 for ; Thu, 19 Jan 2012 16:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 YtbW2fwxE8zU for ; Thu, 19 Jan 2012 16:29:16 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7B21F864C for ; Thu, 19 Jan 2012 16:29:16 -0800 (PST) Received: by iaae16 with SMTP id e16so12900iaa.1 for ; Thu, 19 Jan 2012 16:29:15 -0800 (PST) Received: by 10.50.47.136 with SMTP id d8mr30351048ign.21.1327019355067; Thu, 19 Jan 2012 16:29:15 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id or1sm1714383igc.3.2012.01.19.16.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 16:29:14 -0800 (PST) Received: by dakf10 with SMTP id f10so20604dak.31 for ; Thu, 19 Jan 2012 16:29:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.164 with SMTP id u4mr57352303pbv.85.1327019352593; Thu, 19 Jan 2012 16:29:12 -0800 (PST) Received: by 10.68.44.197 with HTTP; Thu, 19 Jan 2012 16:29:12 -0800 (PST) In-Reply-To: References: <4F185D59.1000609@alvestrand.no> Date: Thu, 19 Jan 2012 19:29:12 -0500 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec54693e71f14c304b6eac593 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 00:29:17 -0000 --bcaec54693e71f14c304b6eac593 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba wrote: > *Roman said:* > > * * > > SSRC multiplexing does not seem to map to legacy signaling exchange at all > and would need to be disabled to work with it.**** > > ** ** > > [BA] To date implementations have tended to assume that an MCU is used. > However, for small conferences peer-to-peer interaction is feasible and > advantageous. So while I'm not a fan of multiplexing audio/video on the > same address/port (it degrades the security assurances provided by ICE), > SSRC multiplexing has significant benefits in small conference scenarios.* > *** > What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundling vs SSRC multiplexing. We can still do peer-to-peer conferencing and use the same IP and port to communicate with each party as long as each peer gets its own signaling exchange. Otherwise there is no way to put each party on hold or to negotiate payloads and codecs independently for each party. _____________ Roman Shpount --bcaec54693e71f14c304b6eac593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 19, 2012 at 6:38 P= M, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
<= div>

Roman said:=

=A0

SSRC multiplexing does not seem to map to l= egacy signaling exchange at all and would need to be disabled to work with = it.

=A0<= /p>

= [BA] To date implementations have tended to assu= me that an MCU is used.=A0 However, for small conferences peer-to-peer inte= raction is feasible and advantageous. =A0So while I'm not a fan of mult= iplexing audio/video on the same address/port (it degrades the security ass= urances provided by ICE), SSRC multiplexing has significant benefits in sma= ll conference scenarios.

What I am arguing is not MCU vs SSRC multipl= exing. I am arguing bundling vs SSRC multiplexing. We can still do peer-to-= peer conferencing and use the same IP and port to communicate with each par= ty as long as each peer gets its own signaling exchange. Otherwise there is= no way to put each party on hold or to negotiate payloads and codecs indep= endently for each party.
_____________
Roman Shpount
--bcaec54693e71f14c304b6eac593-- From harald@alvestrand.no Fri Jan 20 00:16:04 2012 Return-Path: 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 139D121F85BD for ; Fri, 20 Jan 2012 00:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 0Tyx2WrE9VTk for ; Fri, 20 Jan 2012 00:15:59 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82321F861B for ; Fri, 20 Jan 2012 00:15:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 638D839E132; Fri, 20 Jan 2012 09:15:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3E1pWQUOBeE; Fri, 20 Jan 2012 09:15:52 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BAF8E39E0C0; Fri, 20 Jan 2012 09:15:52 +0100 (CET) Message-ID: <4F1922B8.2000005@alvestrand.no> Date: Fri, 20 Jan 2012 09:15:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Venkatesh References: <4F156709.9030604@alvestrand.no> <4F157CF9.3090304@alvestrand.no> <4F168C20.9010308@alvestrand.no> <4F17083D.4000307@alvestrand.no> <4F170BC3.8030006@alvestrand.no> <4F1725DB.20403@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C3D567EE9@ESESSCMS0356.eemea.ericsson.se> <4F18412D.2070706@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000104080607050905070209" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 08:16:04 -0000 This is a multi-part message in MIME format. --------------000104080607050905070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/19/2012 05:52 PM, Venkatesh wrote: > Harold: > If you are going to be signaling the SSRC's in the SDP rather than > using multiple m lines, may be, we could extend it to be able to > provide directional attributes on a per SSRC basis? Since SSRCs are defined to be one-way, "on" or "off" should be enough. > Venkatesh > On Thu, Jan 19, 2012 at 8:13 AM, Harald Alvestrand > > wrote: > > On 01/19/2012 05:05 PM, Roman Shpount wrote: >> >> On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg >> > > wrote: >> >> >> I guess the question here is whether a single m= line could >> contain multiple media tracks, and you want to be able to >> control them individualy, in which case you could not use >> direction attributes etc which affect the whole m= line. >> >> >> Using multiple media tracks with a single m line is tricky. For >> instance it would require dynamically to create and remove >> windows for each remote video participant. And you are obviously >> loosing a lot of control over individual participants such as >> direction attributes or codec settings. >> >> Out of curiosity, would current WebRTC implementation even >> support multiple simultaneous sources over the same m=line for >> video? > I can only speak to the one WebRTC implementation I know about > (Chrome), and it only supports one video stream in one > PeerConnection. But that's a temporary limitation. > > We intend to support multiple simultaneous sources over the same > m= line; in fact we have no intention of ever generating multiple > m= lines for video sources - we see no need to. > > However, that requires some work on signaling the association > between media carried on SSRCs and media presented as > MediaStreamTracks inside MediaStreams at the API; that's what > draft-alvestrand-rtcweb-msid, which I mentioned on this list a > week ago, is all about. > > Harald > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------000104080607050905070209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/19/2012 05:52 PM, Venkatesh wrote:
Harold:
If you are going to be signaling the SSRC's in the SDP rather than using multiple m lines, may be, we could extend it to be able to provide directional attributes on a per SSRC basis?
Since SSRCs are defined to be one-way, "on" or "off" should be enough.
 
Venkatesh
 
On Thu, Jan 19, 2012 at 8:13 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 01/19/2012 05:05 PM, Roman Shpount wrote:

On Thu, Jan 19, 2012 at 1:23 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

I guess the question here is whether a single m= line could contain multiple media tracks, and you want to be able to control them individualy, in which case you could not use direction attributes etc which affect the whole m= line.


Using multiple media tracks with a single m line is tricky. For instance it would require dynamically to create and remove windows for each remote video participant. And you are obviously loosing a lot of control over individual participants such as direction attributes or codec settings.

Out of curiosity, would current WebRTC implementation even support multiple simultaneous sources over the same m=line for video?
I can only speak to the one WebRTC implementation I know about (Chrome), and it only supports one video stream in one PeerConnection. But that's a temporary limitation.

We intend to support multiple simultaneous sources over the same m= line; in fact we have no intention of ever generating multiple m= lines for video sources - we see no need to.

However, that requires some work on signaling the association between media carried on SSRCs and media presented as MediaStreamTracks inside MediaStreams at the API; that's what draft-alvestrand-rtcweb-msid, which I mentioned on this list a week ago, is all about.

                  Harald



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--------------000104080607050905070209-- From harald@alvestrand.no Fri Jan 20 02:03:48 2012 Return-Path: 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 5712521F8578 for ; Fri, 20 Jan 2012 02:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 gNUMdgpCiK-k for ; Fri, 20 Jan 2012 02:03:44 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0702321F855B for ; Fri, 20 Jan 2012 02:03:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2417C39E112; Fri, 20 Jan 2012 11:03:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE+9XKN5Y0vc; Fri, 20 Jan 2012 11:03:39 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2F70839E0C0; Fri, 20 Jan 2012 11:03:39 +0100 (CET) Message-ID: <4F193BFB.1030805@alvestrand.no> Date: Fri, 20 Jan 2012 11:03:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , rtcweb@ietf.org Subject: Re: [rtcweb] AGENDA for the Interim meeting X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 10:03:48 -0000 I wonder if it's possible to drill down on this agenda a bit more... as it stands, we're spending 6 hours on just the question of JSEP and ROAP, with no internal structure, no specific input documents, and no proposal for what the decision should be. Given that all participants will have read the input documents carefully before the meeting, this might not be the optimal use of time. We might structure this differently, as in: Division of labor between JS and browser: ROAP vs JSEP ================================== Input documents: .... Output decisions: One of - Make the browser stateless wrt offer/answer, keep ICE state in browser (JSEP) - Make the browser keep state wrt offer/answer and ICE (ROAP) - We don't have enough information to decide Stuff that is already decided, or where no alternatives exist: - Format for describing states: the SDP format is used in both current proposals. - ICE state maintenance: This will be done in the browser (both proposals, timing, and security) - (more can be added here) Stuff that may be flagged as needing clarification / further work: - Matching between ICE connections and RTP sessions / m-lines in JSEP - (more can be added here) Structure of session: - Principles presentations: 10 minutes per proposal (max) - Q&A on proposal details (clarification, not decision): 1 hour - Break (15 min) - Decision session: - Identifying what factors are important to people - Making a decision - Available slack time, in case debate runs longer: 4 hours. Of course, this depends on having people read the documents beforehand. On 01/18/2012 06:03 PM, Ted Hardie wrote: > January 31st, 2012 > > The Interim will be held at the Google campus in Mountain View, CA, in > building GWC5. This building does not normally have staffed > reception, but there will be someone from 8:00 to 9:00 with badges for > everyone who has notified the chairs of their attendance. If you did > not send your name in, please go to GWC6, ask for a badge with Ted > Hardie as your local host and have the staff contact Ted. If you > arrive outside this time but did let the Chairs know you were coming, > please IM or email ted.ietf@gmail.com, and so he can come out of the > meeting room with your badge. > > January 31st, 2012 > 8:00-9:00 Breakfast > 9:00-12:00 JSEP > 12:30-1:00 ROAP (1) > 12:0-1:30 Lunch > 1:30-2:30 ROAP (2) > 2:30-4:30 Signaling resolution > 4:30-5:30 Data Channel 1 > 5:30-Close Demos of existing systems > > February 1st, 2012 > 8:00-9:00 Breakfast > 9:00-10:00 Data channel 2 > 10:00-12:30 Security > 12:30-1:30 Lunch > > Transition to WEBRTC at this point. > Reply > > > regards, > > Cullen, Magnus, Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From Michael.Tuexen@lurchi.franken.de Fri Jan 20 04:02:35 2012 Return-Path: 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 0705A21F85C0 for ; Fri, 20 Jan 2012 04:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 HpR-B1d5uf7O for ; Fri, 20 Jan 2012 04:02:34 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id A95E621F85C6 for ; Fri, 20 Jan 2012 04:02:33 -0800 (PST) Received: from [192.168.1.103] (p5481D32B.dip.t-dialin.net [84.129.211.43]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 47ACA1C0B4611; Fri, 20 Jan 2012 13:02:31 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4F15A1A3.6000304@alvestrand.no> Date: Fri, 20 Jan 2012 13:02:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F15A1A3.6000304@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 12:02:35 -0000 On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: > (after a long delay) > thank you very much for the input! >=20 > I've downloaded and compiled the code, but haven't yet found out how = to do the typical "hello world" call with the binaries provided. >=20 > Could you give us a note saying "do this and see the packets flow"? Hi Harald, an updated version of the user-land stack is available from http://sctp.fh-muenster.de/sctp-user-land-stack.html It now supports the platforms Windows in addition to FreeBSD, Linux and = Mac OS X. It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation = variants SCTP/UDP/IPv4 and SCTP/UDP/IPv6. In libusrsctp-0.9.0/programs you find examples programs. Please note that you need to run the programs with root privileges, if you want to use native SCTP/IPv4 or SCTP/IPv6. For example, you can run sudo ./discard_server in one shell and sudo ./client 127.0.0.1 9 in another shell. Whatever you type on the console will be sent to the discard server. Wireshark will show the packets. If you want to use UDP encapsulation, you can run ./discard_server 9899 9999 in one shell and ./client 127.0.0.1 9 9999 9899 in another shell. Things are simpler, if you run the stack on two separate machines: ./discard_server on one machine. ./client a.b.c.d 9 9899 9899 on the other. Please note that the demo programs disable the sending of ABORTs in response to out of the blue packets to allow running multiple stacks on the same host. This is done by the line SCTP_BASE_SYSCTL(sctp_blackhole) =3D 2; in the code. (On FreeBSD / Mac OS X kernel versions, you have such a sysctl). I hope this helps. If you have any further questions or issues, please let me know. Best regards Michael >=20 > Harald, experimenter >=20 > On 11/18/2011 02:17 PM, Michael T=FCxen wrote: >> Dear all, >>=20 >> I just wanted to let you know that the initial version of the >> SCTP user-land stack based on the FreeBSD kernel code for SCTP >> is available at >> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>=20 >> It currently support FreeBSD, Linux and Mac OS X. We are >> currently working on adding support for Windows, adding >> more examples and improving the API. >>=20 >> Best regards >> Michael >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 From harald@alvestrand.no Fri Jan 20 04:32:57 2012 Return-Path: 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 A54C421F8517 for ; Fri, 20 Jan 2012 04:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 UXh6ABTLVW9l for ; Fri, 20 Jan 2012 04:32:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4421F8512 for ; Fri, 20 Jan 2012 04:32:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C81FD39E112; Fri, 20 Jan 2012 13:32:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xif10JWJdOrE; Fri, 20 Jan 2012 13:32:53 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 34BB239E0C0; Fri, 20 Jan 2012 13:32:53 +0100 (CET) Message-ID: <4F195EF4.4080504@alvestrand.no> Date: Fri, 20 Jan 2012 13:32:52 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Michael Tuexen References: <4F15A1A3.6000304@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 12:32:57 -0000 Thank you - I now see the (UDP) packets flowing! Harald On 01/20/2012 01:02 PM, Michael Tuexen wrote: > On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: > >> (after a long delay) >> thank you very much for the input! >> >> I've downloaded and compiled the code, but haven't yet found out how to do the typical "hello world" call with the binaries provided. >> >> Could you give us a note saying "do this and see the packets flow"? > Hi Harald, > > an updated version of the user-land stack is available from > http://sctp.fh-muenster.de/sctp-user-land-stack.html > > It now supports the platforms Windows in addition to FreeBSD, Linux and Mac OS X. > It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation variants > SCTP/UDP/IPv4 and SCTP/UDP/IPv6. > > In libusrsctp-0.9.0/programs you find examples programs. > > Please note that you need to run the programs with root privileges, > if you want to use native SCTP/IPv4 or SCTP/IPv6. > > For example, you can run > sudo ./discard_server > in one shell and > sudo ./client 127.0.0.1 9 > in another shell. > Whatever you type on the console will be sent to the discard server. > Wireshark will show the packets. > > If you want to use UDP encapsulation, you can run > ./discard_server 9899 9999 > in one shell and > ./client 127.0.0.1 9 9999 9899 > in another shell. > > Things are simpler, if you run the stack on two separate machines: > ./discard_server > on one machine. > ./client a.b.c.d 9 9899 9899 > on the other. > > Please note that the demo programs disable the sending of ABORTs > in response to out of the blue packets to allow running multiple > stacks on the same host. This is done by the line > SCTP_BASE_SYSCTL(sctp_blackhole) = 2; > in the code. (On FreeBSD / Mac OS X kernel versions, you have such > a sysctl). > > I hope this helps. If you have any further questions or issues, > please let me know. > > Best regards > Michael >> Harald, experimenter >> >> On 11/18/2011 02:17 PM, Michael Tüxen wrote: >>> Dear all, >>> >>> I just wanted to let you know that the initial version of the >>> SCTP user-land stack based on the FreeBSD kernel code for SCTP >>> is available at >>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>> >>> It currently support FreeBSD, Linux and Mac OS X. We are >>> currently working on adding support for Windows, adding >>> more examples and improving the API. >>> >>> Best regards >>> Michael >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> > From magnus.westerlund@ericsson.com Fri Jan 20 05:00:10 2012 Return-Path: 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 2D7B721F852C for ; Fri, 20 Jan 2012 05:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.113 X-Spam-Level: X-Spam-Status: No, score=-109.113 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 skzukLH4a86r for ; Fri, 20 Jan 2012 05:00:09 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 40CD321F852B for ; Fri, 20 Jan 2012 05:00:09 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-01-4f19655855b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.44.09514.855691F4; Fri, 20 Jan 2012 14:00:08 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 Jan 2012 14:00:08 +0100 Message-ID: <4F196555.5050409@ericsson.com> Date: Fri, 20 Jan 2012 14:00:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Roman Shpount References: <4F185D59.1000609@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 13:00:10 -0000 Hi, As individual: Roman, I think you are conflating two aspects in this discussion. The first one is if one uses one or more RTP sessions. The second is the number of SSRC a given end-point is capable or willing to send or receive within the context of a give RTP session. The Bundle proposal is part SDP signaling and secondly the method for how multiple media lines in SDP is related to RTP sessions. There is two proposals on the table. 1. Use multiple media types and thus SDP media lines (due to SDP restriction) in a single RTP session sent over a single lower layer transport session (5-tuple). 2. Enable multiple RTP sessions to be identified and handled when using them over a single lower layer transport session. This requires an additional multiplexing layer on top of UDP. Independently of which choice of the above one selects, within a given RTP session one can have multiple RTP streams, i.e. multiple SSRCs. Yes, choice 1 forces each end-point to have multiple SSRC in that single RTP session if both an audio and a video session is to be supported. Choice 2 could avoid this by having multiple RTP sessions. However, I personally don't want to use that as an argument as there are other reasons why multiple RTP streams (SSRCs) are reaosonable within a given RTP session. The main reasons I have seen so far that is valid in WebRTC context are: 1. End-point has multiple media sources, i.e. several cameras 2. Participating in conferences based on central node receiving each individual sender and distributing the necessary to the receivers. Yes, if one take it to the extreme, in both cases each stream could be mapped to an individual RTP session. However, it appears easier to use the RTP sessions to gather related stream and deal with multiple SSRCs in each session, which RTP was designed to handle. Cheers Magnus On 2012-01-20 01:29, Roman Shpount wrote: > > On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba > > wrote: > > *Roman said:____* > > *__ __* > > SSRC multiplexing does not seem to map to legacy signaling exchange > at all and would need to be disabled to work with it.____ > > __ __ > > [BA] To date implementations have tended to assume that an MCU is > used. However, for small conferences peer-to-peer interaction is > feasible and advantageous. So while I'm not a fan of multiplexing > audio/video on the same address/port (it degrades the security > assurances provided by ICE), SSRC multiplexing has significant > benefits in small conference scenarios.____ > > What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundling > vs SSRC multiplexing. We can still do peer-to-peer conferencing and use > the same IP and port to communicate with each party as long as each peer > gets its own signaling exchange. Otherwise there is no way to put each > party on hold or to negotiate payloads and codecs independently for each > party. > _____________ > Roman Shpount -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Jan 20 05:24:32 2012 Return-Path: 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 F3F3621F8501 for ; Fri, 20 Jan 2012 05:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.487 X-Spam-Level: X-Spam-Status: No, score=-109.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 p6U5vLLisdhT for ; Fri, 20 Jan 2012 05:24:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2552921F84E1 for ; Fri, 20 Jan 2012 05:24:30 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-6e-4f196b0ef2b3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.99.09514.E0B691F4; Fri, 20 Jan 2012 14:24:30 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 Jan 2012 14:24:29 +0100 Message-ID: <4F196B0C.6050207@ericsson.com> Date: Fri, 20 Jan 2012 14:24:28 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Colin Perkins References: <4F156709.9030604@alvestrand.no> <7BCB835D-F42E-4120-85ED-AA4BDEE663D7@csperkins.org> In-Reply-To: <7BCB835D-F42E-4120-85ED-AA4BDEE663D7@csperkins.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open issue: Signalling muted streams X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 13:24:32 -0000 On 2012-01-18 23:11, Colin Perkins wrote: > > RTCP SR packets include a "sender's packet count" field. A sender > which stops transmitting RTP data packets will keep sending RTCP > packets, and the receiver can tell from the non-increasing sender > packet count that the sender stopped transmitting, rather than the > path losing the packets. This takes a couple of reports before the > receiver is sure, of course, so can be relatively slow (although > using AVPF to send an SR just after the last video packet, coupled > with a reasonably short reporting interval to get a second SR, should > inform the receiver reasonably quickly, and we'll need a reasonably > short reporting interval to make the congestion control stable most > likely). > As Indidivual, Fully agree with this as a basic approach to indicating the (temporarily) end of transmission indication. I think this actually are a common problem that hasn't been dealt with in the RTP level yet. In RTSP 2.0 there is a Server to client signaling message for End_of_Stream indication. This tells you that the last RTP packet for this stream is the following RTP sequence number. That way one also avoids the issues with packet retransmission and other transport mechanism from reacting on the lack of packets. >From my perspective I think there are the following categories of solutions. 1. Let the Web APP deal with telling the other end that it happened. (may require API functions) 2. Use the signaling channel between the browser instances to indicate it. 3. Use media plane signaling I think it is also important to remember which use case we are talking about. A. Telling the receiver that the sender stopped sending intentionally B. Have the receiver tell the sender that it doesn't need a particular media stream. For B3, I presented a potential solution in Taipei's AVTEXT meeting https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ That got the interesting feedback that TMMBR=0 (RFC 5104) is used in video conferencing (not fully ok according to normative statements and semantically). There is clearly other cases where signalling plane solutions are argued for. But, in the WebRTC context doing a B1 solution may be the simplest. I think A3 should be pursued because I certain that WebRTC is not the only application that would like an indication that one stopped sending. And that an indication following the media plane so all middleboxes that can access becomes aware of it. But, this is clearly work for AVTCORE or AVTEXT. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From roman@telurix.com Fri Jan 20 10:59:19 2012 Return-Path: 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 2BD2721F8648 for ; Fri, 20 Jan 2012 10:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] 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 Xb9E1WCgXBuK for ; Fri, 20 Jan 2012 10:59:18 -0800 (PST) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id EB41F21F85ED for ; Fri, 20 Jan 2012 10:59:17 -0800 (PST) Received: by iaae16 with SMTP id e16so332581iaa.1 for ; Fri, 20 Jan 2012 10:59:17 -0800 (PST) Received: by 10.50.135.1 with SMTP id po1mr33801277igb.26.1327085957491; Fri, 20 Jan 2012 10:59:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx.google.com with ESMTPS id gh7sm6220779igb.1.2012.01.20.10.59.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 10:59:15 -0800 (PST) Received: by dakf10 with SMTP id f10so653980dak.31 for ; Fri, 20 Jan 2012 10:59:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.68 with SMTP id r4mr63803028pbv.102.1327085953271; Fri, 20 Jan 2012 10:59:13 -0800 (PST) Received: by 10.68.44.197 with HTTP; Fri, 20 Jan 2012 10:59:13 -0800 (PST) In-Reply-To: <4F196555.5050409@ericsson.com> References: <4F185D59.1000609@alvestrand.no> <4F196555.5050409@ericsson.com> Date: Fri, 20 Jan 2012 13:59:13 -0500 Message-ID: From: Roman Shpount To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec54696a1d4c8af04b6fa46e9 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 18:59:19 -0000 --bcaec54696a1d4c8af04b6fa46e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I understand the purpose of using multiple SSRC within the single RTP sessions. My issue with it that without the corresponding media line in SDP, there is no way to changing signaling parameters per SSRC. For instance I am receiving video from 3 cameras from the remote party. With such a setup I cannot signal remote party that I no longer want to receive video from camera number 2. And there are a lot of different things that cannot be done since there is no signaling mechanism associated with each individual source. Individual sources cannot be paused or resumed by the receiver, there is no way to signal that other encoding options are desired. Furthermore, all the proposals that allow multiplexing of several SSRC in RTP state that signaling is optional when new sources are added or removed. This creates some interesting problems when mapping appearance of a new source to the application logic or to UI. Having a signaling exchange with an option to refuse additional source would allow for better applications. What I was thinking is that using a separate m=3D line for each source and using bundling to reduce the number of RTP ports and ICE setups is a better solution for the same problem. It does not change what's going to happen on the RTP side, it would just map it better to signaling (media description). _____________ Roman Shpount On Fri, Jan 20, 2012 at 8:00 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > As individual: > > Roman, I think you are conflating two aspects in this discussion. > > The first one is if one uses one or more RTP sessions. The second is the > number of SSRC a given end-point is capable or willing to send or > receive within the context of a give RTP session. > > The Bundle proposal is part SDP signaling and secondly the method for > how multiple media lines in SDP is related to RTP sessions. There is two > proposals on the table. > > 1. Use multiple media types and thus SDP media lines (due to SDP > restriction) in a single RTP session sent over a single lower layer > transport session (5-tuple). > > 2. Enable multiple RTP sessions to be identified and handled when using > them over a single lower layer transport session. This requires an > additional multiplexing layer on top of UDP. > > Independently of which choice of the above one selects, within a given > RTP session one can have multiple RTP streams, i.e. multiple SSRCs. Yes, > choice 1 forces each end-point to have multiple SSRC in that single RTP > session if both an audio and a video session is to be supported. Choice > 2 could avoid this by having multiple RTP sessions. However, I > personally don't want to use that as an argument as there are other > reasons why multiple RTP streams (SSRCs) are reaosonable within a given > RTP session. > > The main reasons I have seen so far that is valid in WebRTC context are: > 1. End-point has multiple media sources, i.e. several cameras > 2. Participating in conferences based on central node receiving each > individual sender and distributing the necessary to the receivers. > > Yes, if one take it to the extreme, in both cases each stream could be > mapped to an individual RTP session. However, it appears easier to use > the RTP sessions to gather related stream and deal with multiple SSRCs > in each session, which RTP was designed to handle. > > > Cheers > > Magnus > > On 2012-01-20 01:29, Roman Shpount wrote: > > > > On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba > > > wrote: > > > > *Roman said:____* > > > > *__ __* > > > > SSRC multiplexing does not seem to map to legacy signaling exchange > > at all and would need to be disabled to work with it.____ > > > > __ __ > > > > [BA] To date implementations have tended to assume that an MCU is > > used. However, for small conferences peer-to-peer interaction is > > feasible and advantageous. So while I'm not a fan of multiplexing > > audio/video on the same address/port (it degrades the security > > assurances provided by ICE), SSRC multiplexing has significant > > benefits in small conference scenarios.____ > > > > What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundlin= g > > vs SSRC multiplexing. We can still do peer-to-peer conferencing and use > > the same IP and port to communicate with each party as long as each pee= r > > gets its own signaling exchange. Otherwise there is no way to put each > > party on hold or to negotiate payloads and codecs independently for eac= h > > party. > > _____________ > > Roman Shpount > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --bcaec54696a1d4c8af04b6fa46e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I understand the purpose of using multiple SSRC within the single RTP sessi= ons. My issue with it that without the corresponding media line in SDP, the= re is no way to changing signaling parameters per SSRC. For instance I am r= eceiving video from 3 cameras from the remote party. With such a setup I ca= nnot signal remote party that I no longer want to receive video from camera= number 2. And there are a lot of different things that cannot be done sinc= e there is no signaling mechanism associated with each individual source. I= ndividual sources cannot be paused or resumed by the receiver, there is no = way to signal that other encoding options are desired.

Furthermore, all the proposals that allow multiplexing of several SSRC = in RTP state that signaling is optional when new sources are added or remov= ed. This creates some interesting problems when mapping appearance of a new= source to the application logic or to UI. Having a signaling exchange with= an option to refuse additional source would allow for better applications.=

What I was thinking is that using a separate m=3D line for each source = and using bundling to reduce the number of RTP ports and ICE setups is a be= tter solution for the same problem. It does not change what's going to = happen on the RTP side, it would just map it better to signaling (media des= cription).
_____________
Roman Shpount


On Fri, Jan 20, 2012 at 8:00 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

As individual:

Roman, I think you are conflating two aspects in this discussion.

The first one is if one uses one or more RTP sessions. The second is the number of SSRC a given end-point is capable or willing to send or
receive within the context of a give RTP session.

The Bundle proposal is part SDP signaling and secondly the method for
how multiple media lines in SDP is related to RTP sessions. There is two proposals on the table.

1. Use multiple media types and thus SDP media lines (due to SDP
restriction) in a single RTP session sent over a single lower layer
transport session (5-tuple).

2. Enable multiple RTP sessions to be identified and handled when using
them over a single lower layer transport session. This requires an
additional multiplexing layer on top of UDP.

Independently of which choice of the above one selects, within a given
RTP session one can have multiple RTP streams, i.e. multiple SSRCs. Yes, choice 1 forces each end-point to have multiple SSRC in that single RTP
session if both an audio and a video session is to be supported. Choice
2 could avoid this by having multiple RTP sessions. However, I
personally don't want to use that as an argument as there are other
reasons why multiple RTP streams (SSRCs) are reaosonable within a given
RTP session.

The main reasons I have seen so far that is valid in WebRTC context are: 1. End-point has multiple media sources, i.e. several cameras
2. Participating in conferences based on central node receiving each
individual sender and distributing the necessary to the receivers.

Yes, if one take it to the extreme, in both cases each stream could be
mapped to an individual RTP session. However, it appears easier to use
the RTP sessions to gather related stream and deal with multiple SSRCs
in each session, which RTP was designed to handle.


Cheers

Magnus

On 2012-01-20 01= :29, Roman Shpount wrote:
>
> On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba
> <bernard_aboba@h= otmail.com <mailto:bern= ard_aboba@hotmail.com>> wrote:
>
> =A0 =A0 *Roman said:____*
>
> =A0 =A0 *__ __*
>
> =A0 =A0 SSRC multiplexing does not seem to map to legacy signaling exc= hange
> =A0 =A0 at all and would need to be disabled to work with it.___= _
>
> =A0 =A0 __ __
>
> =A0 =A0 [BA] To date implementations have tended to assume that an MCU= is
> =A0 =A0 used. =A0However, for small conferences peer-to-peer interacti= on is
> =A0 =A0 feasible and advantageous. =A0So while I'm not a fan of mu= ltiplexing
> =A0 =A0 audio/video on the same address/port (it degrades the security=
> =A0 =A0 assurances provided by ICE), SSRC multiplexing has significant=
> =A0 =A0 benefits in small conference scenarios.____
>
> What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundli= ng
> vs SSRC multiplexing. We can still do peer-to-peer conferencing and us= e
> the same IP and port to communicate with each party as long as each pe= er
> gets its own signaling exchange. Otherwise there is no way to put each=
> party on hold or to negotiate payloads and codecs independently for ea= ch
> party.
> _____________
> Roman Shpount


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--bcaec54696a1d4c8af04b6fa46e9-- From bernard_aboba@hotmail.com Fri Jan 20 10:59:26 2012 Return-Path: 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 550FF21F8685 for ; Fri, 20 Jan 2012 10:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.096 X-Spam-Level: X-Spam-Status: No, score=-101.096 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_40=-0.185, 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 s9V8L+xtMkPx for ; Fri, 20 Jan 2012 10:59:25 -0800 (PST) Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id BA9AA21F8679 for ; Fri, 20 Jan 2012 10:59:25 -0800 (PST) Received: from BLU152-W26 ([65.55.116.8]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 10:59:25 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_e58356c4-45b6-4ae5-af54-ffce61bb9155_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: Date: Fri, 20 Jan 2012 10:59:25 -0800 Importance: Normal In-Reply-To: <4F193BFB.1030805@alvestrand.no> References: , <4F193BFB.1030805@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jan 2012 18:59:25.0401 (UTC) FILETIME=[A0C91490:01CCD7A5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AGENDA for the Interim meeting X-BeenThere: rtcweb@ietf.org 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: Fri, 20 Jan 2012 18:59:26 -0000 --_e58356c4-45b6-4ae5-af54-ffce61bb9155_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Harald that the agenda seems lopsided=2C and that more structu= re is needed.=20 However=2C even with more structure I'd be concerned about the relative tim= e allocations.=20 While I realize that the impact goes beyond W3C API=2C spending 6 hours on this at an IETF RTCWEB interim seems excessive to me=2C particularly when there are so many open issues that fall clearly on the IETF side of the fence=2C some of which we might even be able to come to consensus on.=20 Perhaps we should more clearly delineate the division of labor between W3C = and IETF on things like ROAP vs. JSEP.=20 = --_e58356c4-45b6-4ae5-af54-ffce61bb9155_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree with Harald that the agenda seems lopsided=2C and that more structu= re is needed.

However=2C even with more structure I'd be concerned = about the relative time allocations.

While I realize that the impac= t goes beyond W3C API=2C spending 6 hours on this at an IETF RTCWEB interim seems excessive to me=2C particularly when there are so many open issues that fall clearly on the IETF side of the fence=2C some of which we might even be able to come to consensus on.

Perhaps we should more clearly delineate the division of labor between = W3C and IETF on things like ROAP vs. JSEP.



= --_e58356c4-45b6-4ae5-af54-ffce61bb9155_-- From harald@alvestrand.no Sat Jan 21 12:28:49 2012 Return-Path: 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 7717721F84A5 for ; Sat, 21 Jan 2012 12:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, 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 Pa0Y1qrj2gWP for ; Sat, 21 Jan 2012 12:28:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DC84821F8493 for ; Sat, 21 Jan 2012 12:28:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 00BA139E070 for ; Sat, 21 Jan 2012 21:28:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN5m4k4jiMeU for ; Sat, 21 Jan 2012 21:28:45 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id ABAAE39E03A for ; Sat, 21 Jan 2012 21:28:45 +0100 (CET) Message-ID: <4F1B1FFD.6000904@alvestrand.no> Date: Sat, 21 Jan 2012 21:28:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F185D59.1000609@alvestrand.no> <4F196555.5050409@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060700040606040901050502" Subject: Re: [rtcweb] Bundling vs sending multiple RTP streams per m=line X-BeenThere: rtcweb@ietf.org 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: Sat, 21 Jan 2012 20:28:49 -0000 This is a multi-part message in MIME format. --------------060700040606040901050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 01/20/2012 07:59 PM, Roman Shpount wrote: > I understand the purpose of using multiple SSRC within the single RTP > sessions. My issue with it that without the corresponding media line > in SDP, there is no way to changing signaling parameters per SSRC. For > instance I am receiving video from 3 cameras from the remote party. > With such a setup I cannot signal remote party that I no longer want > to receive video from camera number 2. And there are a lot of > different things that cannot be done since there is no signaling > mechanism associated with each individual source. Individual sources > cannot be paused or resumed by the receiver, there is no way to signal > that other encoding options are desired. > > Furthermore, all the proposals that allow multiplexing of several SSRC > in RTP state that signaling is optional when new sources are added or > removed. To be precise: draft-alvestrand-rtcweb-msid suggests that if any sources (SSRCs) are mentioned explicitly in the SDP, all should be. I would really appreciate some commentary on that proposal. > This creates some interesting problems when mapping appearance of a > new source to the application logic or to UI. Having a signaling > exchange with an option to refuse additional source would allow for > better applications. > > What I was thinking is that using a separate m= line for each source > and using bundling to reduce the number of RTP ports and ICE setups is > a better solution for the same problem. It does not change what's > going to happen on the RTP side, it would just map it better to > signaling (media description). > _____________ > Roman Shpount > > > On Fri, Jan 20, 2012 at 8:00 AM, Magnus Westerlund > > wrote: > > Hi, > > As individual: > > Roman, I think you are conflating two aspects in this discussion. > > The first one is if one uses one or more RTP sessions. The second > is the > number of SSRC a given end-point is capable or willing to send or > receive within the context of a give RTP session. > > The Bundle proposal is part SDP signaling and secondly the method for > how multiple media lines in SDP is related to RTP sessions. There > is two > proposals on the table. > > 1. Use multiple media types and thus SDP media lines (due to SDP > restriction) in a single RTP session sent over a single lower layer > transport session (5-tuple). > > 2. Enable multiple RTP sessions to be identified and handled when > using > them over a single lower layer transport session. This requires an > additional multiplexing layer on top of UDP. > > Independently of which choice of the above one selects, within a given > RTP session one can have multiple RTP streams, i.e. multiple > SSRCs. Yes, > choice 1 forces each end-point to have multiple SSRC in that > single RTP > session if both an audio and a video session is to be supported. > Choice > 2 could avoid this by having multiple RTP sessions. However, I > personally don't want to use that as an argument as there are other > reasons why multiple RTP streams (SSRCs) are reaosonable within a > given > RTP session. > > The main reasons I have seen so far that is valid in WebRTC > context are: > 1. End-point has multiple media sources, i.e. several cameras > 2. Participating in conferences based on central node receiving each > individual sender and distributing the necessary to the receivers. > > Yes, if one take it to the extreme, in both cases each stream could be > mapped to an individual RTP session. However, it appears easier to use > the RTP sessions to gather related stream and deal with multiple SSRCs > in each session, which RTP was designed to handle. > > > Cheers > > Magnus > > On 2012-01-20 01 :29, Roman Shpount wrote: > > > > On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba > > > >> wrote: > > > > *Roman said:____* > > > > *__ __* > > > > SSRC multiplexing does not seem to map to legacy signaling > exchange > > at all and would need to be disabled to work with it.____ > > > > __ __ > > > > [BA] To date implementations have tended to assume that an > MCU is > > used. However, for small conferences peer-to-peer > interaction is > > feasible and advantageous. So while I'm not a fan of > multiplexing > > audio/video on the same address/port (it degrades the security > > assurances provided by ICE), SSRC multiplexing has significant > > benefits in small conference scenarios.____ > > > > What I am arguing is not MCU vs SSRC multiplexing. I am arguing > bundling > > vs SSRC multiplexing. We can still do peer-to-peer conferencing > and use > > the same IP and port to communicate with each party as long as > each peer > > gets its own signaling exchange. Otherwise there is no way to > put each > > party on hold or to negotiate payloads and codecs independently > for each > > party. > > _____________ > > Roman Shpount > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: > magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060700040606040901050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/20/2012 07:59 PM, Roman Shpount wrote:
I understand the purpose of using multiple SSRC within the single RTP sessions. My issue with it that without the corresponding media line in SDP, there is no way to changing signaling parameters per SSRC. For instance I am receiving video from 3 cameras from the remote party. With such a setup I cannot signal remote party that I no longer want to receive video from camera number 2. And there are a lot of different things that cannot be done since there is no signaling mechanism associated with each individual source. Individual sources cannot be paused or resumed by the receiver, there is no way to signal that other encoding options are desired.

Furthermore, all the proposals that allow multiplexing of several SSRC in RTP state that signaling is optional when new sources are added or removed.
To be precise: draft-alvestrand-rtcweb-msid suggests that if any sources (SSRCs) are mentioned explicitly in the SDP, all should be.

I would really appreciate some commentary on that proposal.
This creates some interesting problems when mapping appearance of a new source to the application logic or to UI. Having a signaling exchange with an option to refuse additional source would allow for better applications.

What I was thinking is that using a separate m= line for each source and using bundling to reduce the number of RTP ports and ICE setups is a better solution for the same problem. It does not change what's going to happen on the RTP side, it would just map it better to signaling (media description).
_____________
Roman Shpount


On Fri, Jan 20, 2012 at 8:00 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

As individual:

Roman, I think you are conflating two aspects in this discussion.

The first one is if one uses one or more RTP sessions. The second is the
number of SSRC a given end-point is capable or willing to send or
receive within the context of a give RTP session.

The Bundle proposal is part SDP signaling and secondly the method for
how multiple media lines in SDP is related to RTP sessions. There is two
proposals on the table.

1. Use multiple media types and thus SDP media lines (due to SDP
restriction) in a single RTP session sent over a single lower layer
transport session (5-tuple).

2. Enable multiple RTP sessions to be identified and handled when using
them over a single lower layer transport session. This requires an
additional multiplexing layer on top of UDP.

Independently of which choice of the above one selects, within a given
RTP session one can have multiple RTP streams, i.e. multiple SSRCs. Yes,
choice 1 forces each end-point to have multiple SSRC in that single RTP
session if both an audio and a video session is to be supported. Choice
2 could avoid this by having multiple RTP sessions. However, I
personally don't want to use that as an argument as there are other
reasons why multiple RTP streams (SSRCs) are reaosonable within a given
RTP session.

The main reasons I have seen so far that is valid in WebRTC context are:
1. End-point has multiple media sources, i.e. several cameras
2. Participating in conferences based on central node receiving each
individual sender and distributing the necessary to the receivers.

Yes, if one take it to the extreme, in both cases each stream could be
mapped to an individual RTP session. However, it appears easier to use
the RTP sessions to gather related stream and deal with multiple SSRCs
in each session, which RTP was designed to handle.


Cheers

Magnus

On 2012-01-20 01:29, Roman Shpount wrote:
>
> On Thu, Jan 19, 2012 at 6:38 PM, Bernard Aboba
> <bernard_aboba@hotmail.com <mailto:bernard_aboba@hotmail.com>> wrote:
>
>     *Roman said:____*
>
>     *__ __*
>
>     SSRC multiplexing does not seem to map to legacy signaling exchange
>     at all and would need to be disabled to work with it.____
>
>     __ __
>
>     [BA] To date implementations have tended to assume that an MCU is
>     used.  However, for small conferences peer-to-peer interaction is
>     feasible and advantageous.  So while I'm not a fan of multiplexing
>     audio/video on the same address/port (it degrades the security
>     assurances provided by ICE), SSRC multiplexing has significant
>     benefits in small conference scenarios.____
>
> What I am arguing is not MCU vs SSRC multiplexing. I am arguing bundling
> vs SSRC multiplexing. We can still do peer-to-peer conferencing and use
> the same IP and port to communicate with each party as long as each peer
> gets its own signaling exchange. Otherwise there is no way to put each
> party on hold or to negotiate payloads and codecs independently for each
> party.
> _____________
> Roman Shpount


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060700040606040901050502-- From internet-drafts@ietf.org Mon Jan 23 17:27:51 2012 Return-Path: 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 2DFC221F8618; Mon, 23 Jan 2012 17:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 vXL-gTAIxGBy; Mon, 23 Jan 2012 17:27:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7926021F8522; Mon, 23 Jan 2012 17:27:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120124012749.6707.33330.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 17:27:49 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-00.txt X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 01:27:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : RTCWEB Security Architecture Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-00.txt Pages : 19 Date : 2012-01-23 The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf- rtcweb-security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-arch-00.txt From ekr@rtfm.com Mon Jan 23 17:37:51 2012 Return-Path: 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 4228E21F862D for ; Mon, 23 Jan 2012 17:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 I2-bgLXSw2Zr for ; Mon, 23 Jan 2012 17:37:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3921F85BB for ; Mon, 23 Jan 2012 17:37:50 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2575211vbb.31 for ; Mon, 23 Jan 2012 17:37:50 -0800 (PST) Received: by 10.52.28.238 with SMTP id e14mr4966909vdh.96.1327369070193; Mon, 23 Jan 2012 17:37:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Mon, 23 Jan 2012 17:37:09 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 23 Jan 2012 17:37:09 -0800 Message-ID: To: rtcweb@ietf.org X-Gm-Message-State: ALoCoQkPwX74C+RxvWg66JRW6bGyCJewQ+Ln+GkI6+z+NcIYAYerJuC9A8AenPYoksQsoxIfsfQ/ Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Security Architecture -00 posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 01:37:51 -0000 As requested by the chairs after Taipei, I have split out the Security Architecture document as its own document and submitted it. The draft is at: http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-00 It is well-known that there are a number of open issues in this document. I believe that most if not all are marked off with OPEN ISSUE, but please feel free to let me know if I have missed some. I will be attempting to cover the major open issues at the Interim next week. -Ekr From ekr@rtfm.com Mon Jan 23 17:38:18 2012 Return-Path: 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 678C121F865C for ; Mon, 23 Jan 2012 17:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 XAakgkWDVPfN for ; Mon, 23 Jan 2012 17:38:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9A21F8650 for ; Mon, 23 Jan 2012 17:38:17 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2600072vcb.31 for ; Mon, 23 Jan 2012 17:38:17 -0800 (PST) Received: by 10.52.20.165 with SMTP id o5mr4986636vde.79.1327369097165; Mon, 23 Jan 2012 17:38:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Mon, 23 Jan 2012 17:37:36 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Mon, 23 Jan 2012 17:37:36 -0800 Message-ID: To: rtcweb@ietf.org X-Gm-Message-State: ALoCoQmSQETmY0cjXT/NneD4OC/pqp6MeaMWk0PXHqjW6zcN2CutJfThXhsXgRy6P1RFMWcW9ZVO Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Generic IdP doc posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 01:38:18 -0000 Since Taipei, I have spent a bunch of time working through the details of how to make generic IdP-based authentication work for WebRTC calls. This was very handwavy in Taipei but I believe I now have solutions that will work for all the major issues (which isn't to say that there isn't much left to improve), but this is still at the individual submission stage. The draft is at: http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00 Comments welcome. I have a prototype implementation of most of the basic concepts (though in JS rather than integrated with the browser), so I hope to have something (though probably something clunky) to demo next week. Best, -Ekr From juberti@google.com Mon Jan 23 21:57:00 2012 Return-Path: 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 032F021F846F for ; Mon, 23 Jan 2012 21:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 wqgickwPUWqz for ; Mon, 23 Jan 2012 21:56:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1626521F8467 for ; Mon, 23 Jan 2012 21:56:58 -0800 (PST) Received: by iagf6 with SMTP id f6so5207627iag.31 for ; Mon, 23 Jan 2012 21:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:x-system-of-record :x-gm-message-state:content-type; bh=5BEZoCS0lk5tvuDdmzVB1PxSL/geKrNVs+hB6gG/jGk=; b=ntFRE41mnSvibAphynieqlbajpbpWAUUrsoef8fTj4D2gcnTpoyTqN74MZHYGD2/gb CP+kHSKh2OrsIu1MEzKdTcJwRwC7FrQyHvkLTe2AlQvASiwnVRwUAyFBcQxkCTFSIjTp mUic+umRc2N+P1zkjXPAp2HHiIYRmdNL4jyyA= Received: by 10.50.34.202 with SMTP id b10mr3091758igj.30.1327384618430; Mon, 23 Jan 2012 21:56:58 -0800 (PST) Received: by 10.50.34.202 with SMTP id b10mr3091746igj.30.1327384618153; Mon, 23 Jan 2012 21:56:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Mon, 23 Jan 2012 21:56:36 -0800 (PST) From: Justin Uberti Date: Tue, 24 Jan 2012 00:56:36 -0500 Message-ID: To: rtcweb@ietf.org, public-webrtc@w3.org X-System-Of-Record: true X-Gm-Message-State: ALoCoQmU7Jm6GMHnMVbrINDbF/Hz9KmdXZ8KT0u130DfSfqVpOCgMruaKfHPE1zGsbpo1H0IJMCvbsZUFT2dU3IGj1iWTgDkNNUL5dVXJ/jdyN8m3MWpTcrA/iQc8am7HqoLOkzj9jFgpCfTeWW3naOOGo9tptXEUA== Content-Type: multipart/alternative; boundary=14dae9340f9da535c404b73fd0c5 Subject: [rtcweb] Initial JSEP draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 05:57:00 -0000 --14dae9340f9da535c404b73fd0c5 Content-Type: text/plain; charset=UTF-8 I've just submitted the -00 version of the JSEP signaling proposal at: http://www.ietf.org/id/draft-uberti-rtcweb-jsep-00.txt I've received a number of comments and questions that I'm still working through, most of them listed in the open issues appendix of the document. I expect to resolve many of them in a forthcoming -01 version, before the interim meeting. --14dae9340f9da535c404b73fd0c5 Content-Type: text/html; charset=UTF-8
I've just submitted the -00 version of the JSEP signaling proposal at:


I've received a number of comments and questions that I'm still working through, most of them listed in the open issues appendix of the document. I expect to resolve many of them in a forthcoming -01 version, before the interim meeting.

--14dae9340f9da535c404b73fd0c5-- From magnus.westerlund@ericsson.com Tue Jan 24 00:37:07 2012 Return-Path: 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 566D221F847E for ; Tue, 24 Jan 2012 00:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.709 X-Spam-Level: X-Spam-Status: No, score=-109.709 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 X-7guBrZiwfi for ; Tue, 24 Jan 2012 00:37:06 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 713C621F846B for ; Tue, 24 Jan 2012 00:37:06 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-9a-4f1e6db16b63 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.DF.27041.1BD6E1F4; Tue, 24 Jan 2012 09:37:05 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 24 Jan 2012 09:37:05 +0100 Message-ID: <4F1E6DB0.3000709@ericsson.com> Date: Tue, 24 Jan 2012 09:37:04 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Questions to consider when analyzing the signaling proposals X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 08:37:07 -0000 WG, At the interim we are attempting to come to some conclusions on the signaling proposals. The WG chairs are aware that parts of the arguments between the proponents will likely be related to API more than the general functionality. We have discussed this with the W3C WEBRTC WG chairs, to enable a constructive session we do need to allow such discussion. But please remember that the formal decision power regarding any questions for the API is in the W3C, this WG can only recommend or formulate requirements on the API for them to consider. It is also important that we don't forget important aspects of the signaling and ensure that it functions correctly. Therefore I have put together this email which contains a number of questions or issues related to signaling that is likely important. The reason for this is to provide food for thought in the evaluation of the proposals by WG participants. I also recommend the proponents to try to answer how their proposals handles the listed questions or issues. There is no particular order among the issues, they are alphabetically numbered to help you keep track of them. I also encourage the WG participants to submit additional items for discussion. If you want to discuss a particular item, please change the subject line so that one keep track of the threads. A) Glare handling: How does the signaling handle situations where both end-points initiate negotiation, updates or re-negotiate at the same time (i.e. messages pass each other in-flight between the peers)? B) Can media clipping occur at the initial media establishment? Can it occur at re-negotiations? Initially this shouldn't happen as long as media configuration is in place prior to ICE promotes any candidate pairs. However, at media re-negotiation this could occur. And when you split the transport setup from media negotiation it becomes an issue again. C) Does the glare handling result in periods where either side is prevented from updating offers? For example is it possible to send a new offer immediately after sending an answer to the peer's Offer? This becomes important as we are likely having declarative media stream information, like the Media Stream ID mapping to SSRCs for each media stream an end-point intends to send. D) Is it possible to provide additional ICE candidate's after the initial offer? What level of complexities does that incur? E) Is it possible to establish transport session which completes ICE processing without negotiating any media, or at least without forcing the user to assign media resource to it (not having to run getUserMedia in the API)? Some versions of WhatWG API did establish a data channel by default, which could be one option but other possibilities do exist. F) How does one support forking, and specifically can one deal with; - F1) Parallel forking? I.e. deal with multiple answers to a given offer and establish multiple flows? - F2) Sequential/Serial Forking? i.e. receive one answer and later get a second answer to the same initial offer and use that to replace the first? G) How does the proposal attempt to improve the time until media is negotiated and can flow between the peers. H) What explicit indication or other hints can the upper layer get from the proposal get that this might be a suitable time to perform a re-negotiation or is it automatically triggered by the browser core? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Tue Jan 24 02:27:27 2012 Return-Path: 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 64DE121F856D for ; Tue, 24 Jan 2012 02:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 RlYA9B8VHzjN for ; Tue, 24 Jan 2012 02:27:26 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B7D3A21F8550 for ; Tue, 24 Jan 2012 02:27:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 29F8839E12B for ; Tue, 24 Jan 2012 11:27:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbCYRipKbmXZ for ; Tue, 24 Jan 2012 11:27:23 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F380039E0FA for ; Tue, 24 Jan 2012 11:27:22 +0100 (CET) Message-ID: <4F1E878A.402@alvestrand.no> Date: Tue, 24 Jan 2012 11:27:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1E6DB0.3000709@ericsson.com> In-Reply-To: <4F1E6DB0.3000709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Glare and when it's relevant (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 10:27:27 -0000 In accordance with the chair's request, I'm starting a new thread on this issue. There will be more. On 01/24/2012 09:37 AM, Magnus Westerlund wrote: > There is no particular order among the issues, they are alphabetically > numbered to help you keep track of them. I also encourage the WG > participants to submit additional items for discussion. If you want to > discuss a particular item, please change the subject line so that one > keep track of the threads. > > > A) Glare handling: How does the signaling handle situations where both > end-points initiate negotiation, updates or re-negotiate at the same > time (i.e. messages pass each other in-flight between the peers)? I believe that this question has an underlying assumption that this is a well-formed question for all cases. In the case of a specification where the offer/answer state machine is not part of the standard implemented in the browser, I believe this question is not well-formed. Instead, it needs to be broken down further: - Is it clear which set of configuration-changing API calls on each side leads to a state where communication happens? - Is it clear which set of configuration-changing API calls on each side can lead from a given configuration state to another given configuration state? - Is it clear which set of configuration-changing API calls start, stop and change media flows, and when their effects happen? - Are there sequencing constraints between these API calls on the two sides that can lead to non-communication if the sequencing constraints are not obeyed? As an extreme example, consider a case where, for JSEP supporting a peer-to-peer chat, a centralized application takes people's createOffer SDP blobs, computes an appropriate SetLocalDescription SDP blob and a SetRemoteDescription SDP blob for them, and transmits those to each participant. As long as nobody starts sending media until the configurations have been installed on each side, this should work fine, no matter what the sequence of calls is - and there is no possibility of glare, since any time something is renegotiated, it is mediated by the central processor - the local app never makes independent decisions to do SetLocal or SetRemote. Harald From oscar.ohlsson@ericsson.com Tue Jan 24 05:04:39 2012 Return-Path: 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 062C921F84FA for ; Tue, 24 Jan 2012 05:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZIJn6aqVYzPP for ; Tue, 24 Jan 2012 05:04:38 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D9CFB21F84F6 for ; Tue, 24 Jan 2012 05:04:37 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-dd-4f1eac64405d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.85.27041.46CAE1F4; Tue, 24 Jan 2012 14:04:37 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.48]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 24 Jan 2012 14:04:36 +0100 From: Oscar Ohlsson To: "rtcweb@ietf.org" Date: Tue, 24 Jan 2012 14:04:36 +0100 Thread-Topic: SDES draft posted Thread-Index: AczamLkmxJ01MFolQbCHRCQyikwf5w== Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 13:04:39 -0000 Hi, I've submitted a draft that explains the benefits of allowing SDES as an op= tional keying mechanism in WebRTC. It also attempts to address the security= concerns that have been raised on this mailing list and in the security dr= aft. http://www.ietf.org/id/draft-ohlsson-rtcweb-sdes-support-00.txt The purpose of the draft is to collect all arguments into one place and try= to stimulate discussion so that a decision can be reached. Best regards, Oscar Ohlsson = From magnus.westerlund@ericsson.com Tue Jan 24 05:20:52 2012 Return-Path: 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 10A2E21F85C2 for ; Tue, 24 Jan 2012 05:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.841 X-Spam-Level: X-Spam-Status: No, score=-109.841 tagged_above=-999 required=5 tests=[AWL=0.758, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DN7A-jwqJ29z for ; Tue, 24 Jan 2012 05:20:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1821F85D1 for ; Tue, 24 Jan 2012 05:20:49 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-89-4f1eb0305a1f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 55.68.27041.030BE1F4; Tue, 24 Jan 2012 14:20:48 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 24 Jan 2012 14:20:47 +0100 Message-ID: <4F1EB02E.8040209@ericsson.com> Date: Tue, 24 Jan 2012 14:20:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1E6DB0.3000709@ericsson.com> <4F1E878A.402@alvestrand.no> In-Reply-To: <4F1E878A.402@alvestrand.no> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Glare and when it's relevant (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 13:20:52 -0000 Thanks Harald for splitting out a new name. Comments as individual On 2012-01-24 11:27, Harald Alvestrand wrote: > In accordance with the chair's request, I'm starting a new thread on > this issue. There will be more. > > On 01/24/2012 09:37 AM, Magnus Westerlund wrote: >> There is no particular order among the issues, they are alphabetically >> numbered to help you keep track of them. I also encourage the WG >> participants to submit additional items for discussion. If you want to >> discuss a particular item, please change the subject line so that one >> keep track of the threads. >> >> >> A) Glare handling: How does the signaling handle situations where both >> end-points initiate negotiation, updates or re-negotiate at the same >> time (i.e. messages pass each other in-flight between the peers)? > I believe that this question has an underlying assumption that this is a > well-formed question for all cases. > > In the case of a specification where the offer/answer state machine is > not part of the standard implemented in the browser, I believe this > question is not well-formed. Agreed, and indeed my intention was to indicate areas well worth thinking over in more details. And yes, there are differences between the proposals that have different set of issues or considerations. > > Instead, it needs to be broken down further: > > - Is it clear which set of configuration-changing API calls on each side > leads to a state where communication happens? > - Is it clear which set of configuration-changing API calls on each side > can lead from a given configuration state to another given configuration > state? > - Is it clear which set of configuration-changing API calls start, stop > and change media flows, and when their effects happen? > - Are there sequencing constraints between these API calls on the two > sides that can lead to non-communication if the sequencing constraints > are not obeyed? Highly relevant considerations. But there is a clear overlap with B) (Media clipping). > > As an extreme example, consider a case where, for JSEP supporting a > peer-to-peer chat, a centralized application takes people's createOffer > SDP blobs, computes an appropriate SetLocalDescription SDP blob and a > SetRemoteDescription SDP blob for them, and transmits those to each > participant. As long as nobody starts sending media until the > configurations have been installed on each side, this should work fine, > no matter what the sequence of calls is - and there is no possibility of > glare, since any time something is renegotiated, it is mediated by the > central processor - the local app never makes independent decisions to > do SetLocal or SetRemote. To my understanding this can not cause GLARE in the sense that offers from the different participants don't occur due to a single central nodes decides. However, I think your bullet: > - Is it clear which set of configuration-changing API calls start, > stop and change media flows, and when their effects happen? Is applicable and causing a situation where things aren't clear and communication fails unless some ordered sequence happens. One alternative: 1. Server(S) orders all Clients(C) to halt media transmission. 2. S awaits sufficient time, or get reports that the last fragment of media has been delivered or is considered lost by all Cs. 3. S sends out new local and remote configurations. 4. S awaits acknowledge from all Cs. 5. Sends out a command that media transmission can be started. Another alternative: If the extended media halting is to be avoided, one have to take care to install local configurations that are both capable of the previous remote configuration and the new remote configuration. When that has occurred then a new remote configuration can be configured. This to avoid that any outstanding media packets gets dropped at reception due to failure to meat the configuration for incoming packets. This is to my knowledge deeply encoded in SDP Offer/Answer in that at the point of sending any Offer the reception must be ready to receive what is being offered. To me this appears to spill over into JSEP also. In fact it appears to prevent both the browser core and the JS application manipulating the Offer and Answer from being non-aware of this and keeping track of the state. The browser core will need to always emit offers that has the property of being compliant with the currently set LocalDescription if any. If the JS forgets about it several things appear to possible to occur. - The Local description is reduced so that the configuration for the currently received media stream prior the peers remote description being updated are not possible to decode when SetLocalDescription is done. - SetRemoteDesription is called at the Peer prior to the originating side having done SetLocalDesciption, thus making the peers new media configuration arrive prior to the local side being configured. >From that perspective I think Section 5.4 of the JSEP draft 00 is way to unspecified to avoid communication interruptions. I also think it is a bit misleading to say that JSEP manages to decouple the browser core from the Offer/Answer state machine. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ldecicco@gmail.com Tue Jan 24 08:11:54 2012 Return-Path: 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 7E49121F845D for ; Tue, 24 Jan 2012 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] 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 HSzNE5KKsUlP for ; Tue, 24 Jan 2012 08:11:54 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F01D421F845C for ; Tue, 24 Jan 2012 08:11:53 -0800 (PST) Received: by qcsf16 with SMTP id f16so1462588qcs.31 for ; Tue, 24 Jan 2012 08:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=InBFx0nsTIU5mOJmD0/BlbIXizA00AU79dgr/O3RUMo=; b=oA2qXGAjFF1tlFoDW+PJ8BdCiTqWUTO+TT5fJXxXwTY+LDqhbt+jp5GOH0GJs2lOCH ElRWOFyMP/Mvi4sVsuqJ3JJBsk8yT5KOOHmckTPPMUcE9IWV25jDwNHRXIsS4G/7dHXt gAyEt2qIkRzkHXyBlksmnfxEET4hIQe/I6GDQ= MIME-Version: 1.0 Received: by 10.229.136.65 with SMTP id q1mr4734760qct.42.1327421513345; Tue, 24 Jan 2012 08:11:53 -0800 (PST) Received: by 10.229.185.136 with HTTP; Tue, 24 Jan 2012 08:11:51 -0800 (PST) Date: Tue, 24 Jan 2012 17:11:51 +0100 Message-ID: From: Luca De Cicco To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] CPU overload X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 16:11:54 -0000 Dear all, sorry if this was already dealt in other threads. I was just wondering if there is any ongoing effort in drafting a CPU overload control in the RTC Web. Thank you, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 From ekr@rtfm.com Tue Jan 24 08:55:36 2012 Return-Path: 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 1A7DC11E8079 for ; Tue, 24 Jan 2012 08:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 VQzp6AcFrv4Z for ; Tue, 24 Jan 2012 08:55:35 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82D2F11E8075 for ; Tue, 24 Jan 2012 08:55:35 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3155504vcb.31 for ; Tue, 24 Jan 2012 08:55:34 -0800 (PST) Received: by 10.220.215.68 with SMTP id hd4mr8370694vcb.10.1327424132986; Tue, 24 Jan 2012 08:55:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Tue, 24 Jan 2012 08:54:44 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Tue, 24 Jan 2012 08:54:44 -0800 Message-ID: To: Oscar Ohlsson X-Gm-Message-State: ALoCoQnw1SEXbXPpQ7wuUO8puR23SEakJHhIVXSapx86xUaT+cpwX2hYgmWHMa6tj6YYVGDvoLzE Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 16:55:36 -0000 Hi Oscar. Thanks for writing this up. I'm not sure I 100% agree about the security claims you make in Section 3, but I think that Section 2.1-2.2 is a good summary of the relevant interop issues. A big question for me is to what extent existing SIP systems are prepared to do SDES-SRTP in practice. If the answer is, as you suggest, that most are, then it sure makes SDES-SRTP look like an attractive option for interop with those endpoints, especially if we can use it in lieu of RTP. Best, -Ekr On Tue, Jan 24, 2012 at 5:04 AM, Oscar Ohlsson wrote: > Hi, > > I've submitted a draft that explains the benefits of allowing SDES as an optional keying mechanism in WebRTC. It also attempts to address the security concerns that have been raised on this mailing list and in the security draft. > > http://www.ietf.org/id/draft-ohlsson-rtcweb-sdes-support-00.txt > > The purpose of the draft is to collect all arguments into one place and try to stimulate discussion so that a decision can be reached. > > Best regards, > > Oscar Ohlsson > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From kpfleming@digium.com Tue Jan 24 09:47:59 2012 Return-Path: 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 F15AC21F8573 for ; Tue, 24 Jan 2012 09:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dGpvluC8r14P for ; Tue, 24 Jan 2012 09:47:58 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3021F84EC for ; Tue, 24 Jan 2012 09:47:58 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RpkTN-0007v5-BS for rtcweb@ietf.org; Tue, 24 Jan 2012 11:47:57 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 50480D8004 for ; Tue, 24 Jan 2012 11:47:57 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osOq5s8pZNd7 for ; Tue, 24 Jan 2012 11:47:56 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id EA92BD8002 for ; Tue, 24 Jan 2012 11:47:56 -0600 (CST) Message-ID: <4F1EEECC.80200@digium.com> Date: Tue, 24 Jan 2012 11:47:56 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 17:47:59 -0000 On 01/24/2012 10:54 AM, Eric Rescorla wrote: > Hi Oscar. > > Thanks for writing this up. > > I'm not sure I 100% agree about the security claims you make in Section 3, > but I think that Section 2.1-2.2 is a good summary of the relevant interop > issues. > > A big question for me is to what extent existing SIP systems are prepared > to do SDES-SRTP in practice. If the answer is, as you suggest, that > most are, then it sure makes SDES-SRTP look like an attractive option > for interop with those endpoints, especially if we can use it in lieu of > RTP. I believe SRTP with SDES keying is the most commonly deployed method today. That doesn't mean it's supported by any large percentage of SIP endpoints, but it's a large percentage of those that support SRTP :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ekr@rtfm.com Tue Jan 24 10:24:52 2012 Return-Path: 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 7B5FE11E80AC for ; Tue, 24 Jan 2012 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 XLEzIIvrxlLB for ; Tue, 24 Jan 2012 10:24:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E235411E80AA for ; Tue, 24 Jan 2012 10:24:50 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3237596vcb.31 for ; Tue, 24 Jan 2012 10:24:50 -0800 (PST) Received: by 10.52.64.211 with SMTP id q19mr7346172vds.28.1327429490163; Tue, 24 Jan 2012 10:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Tue, 24 Jan 2012 10:24:09 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F1EEECC.80200@digium.com> References: <4F1EEECC.80200@digium.com> From: Eric Rescorla Date: Tue, 24 Jan 2012 10:24:09 -0800 Message-ID: To: "Kevin P. Fleming" X-Gm-Message-State: ALoCoQkjyYvbjjf7t7v4JilhtQyVwB1SLkSMkPri8GIiWADN41TT7ICWuiFZxfJGcry4diIH7tQm Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 18:24:52 -0000 On Tue, Jan 24, 2012 at 9:47 AM, Kevin P. Fleming wrote: > On 01/24/2012 10:54 AM, Eric Rescorla wrote: >> >> Hi Oscar. >> >> Thanks for writing this up. >> >> I'm not sure I 100% agree about the security claims you make in Section 3, >> but I think that Section 2.1-2.2 is a good summary of the relevant interop >> issues. >> >> A big question for me is to what extent existing SIP systems are prepared >> to do SDES-SRTP in practice. If the answer is, as you suggest, that >> most are, then it sure makes SDES-SRTP look like an attractive option >> for interop with those endpoints, especially if we can use it in lieu of >> RTP. > > > I believe SRTP with SDES keying is the most commonly deployed method today. > That doesn't mean it's supported by any large percentage of SIP endpoints, > but it's a large percentage of those that support SRTP :-) I'm sure that's true. It's deployment of the fraction of SIP endpoints that is the question I think is most interesting. -Ekr From roman@telurix.com Tue Jan 24 10:24:52 2012 Return-Path: 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 8F2EA11E80AA for ; Tue, 24 Jan 2012 10:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HORZ7Be4SSAm for ; Tue, 24 Jan 2012 10:24:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC5FA11E80AB for ; Tue, 24 Jan 2012 10:24:50 -0800 (PST) Received: by iagf6 with SMTP id f6so6242123iag.31 for ; Tue, 24 Jan 2012 10:24:50 -0800 (PST) Received: by 10.43.48.132 with SMTP id uw4mr12307289icb.17.1327429490621; Tue, 24 Jan 2012 10:24:50 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id va6sm30522046igc.6.2012.01.24.10.24.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 10:24:47 -0800 (PST) Received: by pbbb11 with SMTP id b11so1318396pbb.31 for ; Tue, 24 Jan 2012 10:24:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.68 with SMTP id r4mr32609555pbv.102.1327429486478; Tue, 24 Jan 2012 10:24:46 -0800 (PST) Received: by 10.68.44.197 with HTTP; Tue, 24 Jan 2012 10:24:46 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Jan 2012 13:24:46 -0500 Message-ID: From: Roman Shpount To: Oscar Ohlsson X-Gm-Message-State: ALoCoQmLs9t96wC/W1fgLcER9sM2iu+72YDEJLHomNMZDgJ/Eq9tEPxNPbg9YH9S6OgeZUPZfUGE Content-Type: multipart/alternative; boundary=bcaec54696a101860a04b74a4308 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 18:24:52 -0000 --bcaec54696a101860a04b74a4308 Content-Type: text/plain; charset=ISO-8859-1 If we allow SRTP to improve the interop while disregarding the associated security concerns, why won't we allow RTP as well? It would address a much wider set of interop concerns. To be honest, anything (including SRTP-DTLS) is insecure without end-to-end identity verification, so we should either make DTLS-SRTP with identity verification mandatory or allow insecure communications. _____________ Roman Shpount On Tue, Jan 24, 2012 at 8:04 AM, Oscar Ohlsson wrote: > Hi, > > I've submitted a draft that explains the benefits of allowing SDES as an > optional keying mechanism in WebRTC. It also attempts to address the > security concerns that have been raised on this mailing list and in the > security draft. > > http://www.ietf.org/id/draft-ohlsson-rtcweb-sdes-support-00.txt > > The purpose of the draft is to collect all arguments into one place and > try to stimulate discussion so that a decision can be reached. > > Best regards, > > Oscar Ohlsson > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec54696a101860a04b74a4308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we allow SRTP to improve the interop while disregarding the associated s= ecurity concerns, why won't we allow RTP as well? It would address a mu= ch wider set of interop concerns. To be honest, anything (including SRTP-DT= LS) is insecure without end-to-end identity verification, so we should eith= er make DTLS-SRTP with identity verification mandatory or allow insecure co= mmunications.
_____________
Roman Shpount


On Tue, Jan 24, 2012 at 8:04 AM, Oscar O= hlsson <= oscar.ohlsson@ericsson.com> wrote:
Hi,

I've submitted a draft that explains the benefits of allowing SDES as a= n optional keying mechanism in WebRTC. It also attempts to address the secu= rity concerns that have been raised on this mailing list and in the securit= y draft.

http://www.ietf.org/id/draft-ohlsson-rtcweb-sdes-support= -00.txt

The purpose of the draft is to collect all arguments into one place and try= to stimulate discussion so that a decision can be reached.

Best regards,

Oscar Ohlsson
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec54696a101860a04b74a4308-- From kpfleming@digium.com Tue Jan 24 11:24:53 2012 Return-Path: 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 7D60B1F0C3E for ; Tue, 24 Jan 2012 11:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 0uJB3NTWxQBw for ; Tue, 24 Jan 2012 11:24:52 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id B34D21F0C3D for ; Tue, 24 Jan 2012 11:24:52 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RplzA-0000t8-D3 for rtcweb@ietf.org; Tue, 24 Jan 2012 13:24:52 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 5CB4AD8004 for ; Tue, 24 Jan 2012 13:24:52 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-DoN7jHcv+A for ; Tue, 24 Jan 2012 13:24:52 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1F2DCD8002 for ; Tue, 24 Jan 2012 13:24:52 -0600 (CST) Message-ID: <4F1F0583.7070202@digium.com> Date: Tue, 24 Jan 2012 13:24:51 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4F1EEECC.80200@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 19:24:53 -0000 On 01/24/2012 12:24 PM, Eric Rescorla wrote: > On Tue, Jan 24, 2012 at 9:47 AM, Kevin P. Fleming wrote: >> On 01/24/2012 10:54 AM, Eric Rescorla wrote: >>> >>> Hi Oscar. >>> >>> Thanks for writing this up. >>> >>> I'm not sure I 100% agree about the security claims you make in Section 3, >>> but I think that Section 2.1-2.2 is a good summary of the relevant interop >>> issues. >>> >>> A big question for me is to what extent existing SIP systems are prepared >>> to do SDES-SRTP in practice. If the answer is, as you suggest, that >>> most are, then it sure makes SDES-SRTP look like an attractive option >>> for interop with those endpoints, especially if we can use it in lieu of >>> RTP. >> >> >> I believe SRTP with SDES keying is the most commonly deployed method today. >> That doesn't mean it's supported by any large percentage of SIP endpoints, >> but it's a large percentage of those that support SRTP :-) > > I'm sure that's true. It's deployment of the fraction of SIP endpoints that > is the question I think is most interesting. SIPit 29 - 80% of endpoints. SIPit 28 - 56% of endpoints. SIPit 27 - 60% of endpoints. I'd say it's a fair bet that at least 50% of the SIP UA implementations available on the market (by market share, not count of implementations) support SRTP with SDES. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From fluffy@fluffy.im Tue Jan 24 11:29:08 2012 Return-Path: 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 4FD8F11E80A5 for ; Tue, 24 Jan 2012 11:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 898RU3WlMdDs for ; Tue, 24 Jan 2012 11:29:07 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1356811E8072 for ; Tue, 24 Jan 2012 11:29:07 -0800 (PST) Received: by pbbb11 with SMTP id b11so1369748pbb.31 for ; Tue, 24 Jan 2012 11:29:06 -0800 (PST) Received: by 10.68.239.170 with SMTP id vt10mr5867757pbc.0.1327433346760; Tue, 24 Jan 2012 11:29:06 -0800 (PST) Received: from dhcp-171-68-21-102.cisco.com (dhcp-171-68-21-102.cisco.com. [171.68.21.102]) by mx.google.com with ESMTPS id p9sm80265pbb.9.2012.01.24.11.29.05 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 11:29:06 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1251.1) From: Cullen Jennings In-Reply-To: <4F1F0583.7070202@digium.com> Date: Tue, 24 Jan 2012 11:29:09 -0800 Message-Id: <6AA53668-4C93-4CC2-94C2-D1666D8EBFF4@iii.ca> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQm7F/pfOKqJn5KzigFmhgbnaPhgDQSowAtZAEVXHZSrR2jzsBnfPSg39VOj853YI55uuo07 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 19:29:08 -0000 On Jan 24, 2012, at 11:24 , Kevin P. Fleming wrote: >=20 > SIPit 29 - 80% of endpoints. > SIPit 28 - 56% of endpoints. > SIPit 27 - 60% of endpoints. >=20 > I'd say it's a fair bet that at least 50% of the SIP UA = implementations available on the market (by market share, not count of = implementations) support SRTP with SDES. Got any feel for what the percentages of ports on gateways to the PSTN = support SDES/SRTP ? My feel is it also pretty high but obviously I end up with a sample set = pretty skewed towards Cisco equipment.=20 From ted.ietf@gmail.com Tue Jan 24 11:56:34 2012 Return-Path: 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 817F511E8085 for ; Tue, 24 Jan 2012 11:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HuSjdFVKa4Uz for ; Tue, 24 Jan 2012 11:56:34 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B311E8072 for ; Tue, 24 Jan 2012 11:56:33 -0800 (PST) Received: by yenm3 with SMTP id m3so2205822yen.31 for ; Tue, 24 Jan 2012 11:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ed4C7b3S4UQqzl0H4y9Gp1Vb+7V3hU3bKlxepgU8Ovk=; b=OH8zttmq3atXABBbNGYGXOKebxV8dPz+/ySZydPlJd4qvo7n7SJ+hZFOr4oSYfaegf it3VHTA8zIDV79u+tMBzF89Imv8DhO7V/q9Oo+NIbsOf9WjIIzsGdUp9JluHOBLi72Yn caGx1dXqcmRbeMaxQ/e8r9uRmr3zSGRDRLxb0= MIME-Version: 1.0 Received: by 10.236.128.232 with SMTP id f68mr20919298yhi.17.1327434993606; Tue, 24 Jan 2012 11:56:33 -0800 (PST) Received: by 10.236.180.230 with HTTP; Tue, 24 Jan 2012 11:56:33 -0800 (PST) Date: Tue, 24 Jan 2012 11:56:33 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Updated agenda X-BeenThere: rtcweb@ietf.org 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: Tue, 24 Jan 2012 19:56:34 -0000 Based on some of the feedback received, the chairs are putting forward this updated agenda. Further agenda bashing is welcome; please understand that if we can converge quickly on some of these issues (especially in signaling), we may be able to recover time and move things up. Day 1 8:00-900: Breakfast 9:00-9:15: Chair introduction -Administrivia (blue sheets, scribes, etc.) -What decisions do we expect to reach during this meeting 9:15-11:15 JSEP (Justin) -Document review (diffs between -01 and 00, for example, if a 01 is published) -Design decisions -Implementation considerations -Interoperablity considerations 11:15-12:15 ROAP (Cullen) -Updates since last presenation -Contrast between JSEP and ROAP 12:15-13:00 Lunch 13:00-13:30 MSID (Harald) 13:30-16:30 Signaling design resolution (Chairs) -Where will we keep state (Browser/Application) -Format for offer/answer -ICE connection and RTP session relationship 16:30-17:30 Data channel (1) (Randall) 17:30-18:00 Demos Day 2 8:00-9:00 Breakfast 9:00-9:15 Administrivia (Chairs) 9:15-10:15 Data channel (2) (Randall) 10:15-12:15 Security Architecture (EKR) IDP (EKR) SDES (Oscar) Lunch and transition to WEBRTC group meeting From bernard_aboba@hotmail.com Tue Jan 24 17:23:34 2012 Return-Path: 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 32CB711E809A for ; Tue, 24 Jan 2012 17:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, 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 2rI4npBKeihG for ; Tue, 24 Jan 2012 17:23:33 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE611E8086 for ; Tue, 24 Jan 2012 17:23:33 -0800 (PST) Received: from BLU152-DS6 ([65.55.116.72]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 17:23:32 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Cullen Jennings'" , "'Kevin P. Fleming'" References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <6AA53668-4C93-4CC2-94C2-D1666D8EBFF4@iii.ca> In-Reply-To: <6AA53668-4C93-4CC2-94C2-D1666D8EBFF4@iii.ca> Date: Tue, 24 Jan 2012 17:23:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ4nkAaIYa+krUT0DviqzjWkyCjsAIqi97tAhFTGPkBSqRjjAJvTQlUAQ06spGUfKqkIA== Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2012 01:23:32.0627 (UTC) FILETIME=[F3A7AE30:01CCDAFF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 01:23:34 -0000 The majority of PSTN gateways I see at customer sites (enterprise models) support SDES/SRTP now. There are still some interop bugs here and there, but they are getting cleaned up. -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Tuesday, January 24, 2012 11:29 AM To: Kevin P. Fleming Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted On Jan 24, 2012, at 11:24 , Kevin P. Fleming wrote: > > SIPit 29 - 80% of endpoints. > SIPit 28 - 56% of endpoints. > SIPit 27 - 60% of endpoints. > > I'd say it's a fair bet that at least 50% of the SIP UA implementations available on the market (by market share, not count of implementations) support SRTP with SDES. Got any feel for what the percentages of ports on gateways to the PSTN support SDES/SRTP ? My feel is it also pretty high but obviously I end up with a sample set pretty skewed towards Cisco equipment. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Tue Jan 24 23:27:04 2012 Return-Path: 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 4FF2F21F862B for ; Tue, 24 Jan 2012 23:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599] 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 pXGwxxuBIqnN for ; Tue, 24 Jan 2012 23:27:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B939921F84E1 for ; Tue, 24 Jan 2012 23:27:02 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 28436754A8AA; Wed, 25 Jan 2012 07:27:01 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4F1EEECC.80200@digium.com> Date: Wed, 25 Jan 2012 08:27:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F517596-5FB4-42D7-94C2-AC70E23F278C@edvina.net> References: <4F1EEECC.80200@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 07:27:04 -0000 24 jan 2012 kl. 18:47 skrev Kevin P. Fleming: > On 01/24/2012 10:54 AM, Eric Rescorla wrote: >> Hi Oscar. >>=20 >> Thanks for writing this up. >>=20 >> I'm not sure I 100% agree about the security claims you make in = Section 3, >> but I think that Section 2.1-2.2 is a good summary of the relevant = interop >> issues. >>=20 >> A big question for me is to what extent existing SIP systems are = prepared >> to do SDES-SRTP in practice. If the answer is, as you suggest, that >> most are, then it sure makes SDES-SRTP look like an attractive option >> for interop with those endpoints, especially if we can use it in lieu = of >> RTP. >=20 > I believe SRTP with SDES keying is the most commonly deployed method = today. That doesn't mean it's supported by any large percentage of SIP = endpoints, but it's a large percentage of those that support SRTP :-) While everyone knows that DTLS is the way to go, they haven't developed = the support for it yet, everyone is waiting for everyone else (like we = discussed before). =46rom what I hear from OpenSSL and GnuTLS = developers, the code is there and ready to use now.=20 I don't think we should use this as a reference for making any decisions = in rtcweb. Distributing keys in the open is not something I want to see = in the web space too. Hopefully we can move away from it in the SIP = world. /O= From oej@edvina.net Tue Jan 24 23:29:54 2012 Return-Path: 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 35BA721F864F for ; Tue, 24 Jan 2012 23:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] 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 bXrS1fzJ9Iet for ; Tue, 24 Jan 2012 23:29:53 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A721F864D for ; Tue, 24 Jan 2012 23:29:53 -0800 (PST) Received: from [192.168.40.4] (unknown [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D8FA1754A8AA; Wed, 25 Jan 2012 07:29:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4F1F0583.7070202@digium.com> Date: Wed, 25 Jan 2012 08:29:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> To: "Kevin P. Fleming" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 07:29:54 -0000 24 jan 2012 kl. 20:24 skrev Kevin P. Fleming: > On 01/24/2012 12:24 PM, Eric Rescorla wrote: >> On Tue, Jan 24, 2012 at 9:47 AM, Kevin P. = Fleming wrote: >>> On 01/24/2012 10:54 AM, Eric Rescorla wrote: >>>>=20 >>>> Hi Oscar. >>>>=20 >>>> Thanks for writing this up. >>>>=20 >>>> I'm not sure I 100% agree about the security claims you make in = Section 3, >>>> but I think that Section 2.1-2.2 is a good summary of the relevant = interop >>>> issues. >>>>=20 >>>> A big question for me is to what extent existing SIP systems are = prepared >>>> to do SDES-SRTP in practice. If the answer is, as you suggest, that >>>> most are, then it sure makes SDES-SRTP look like an attractive = option >>>> for interop with those endpoints, especially if we can use it in = lieu of >>>> RTP. >>>=20 >>>=20 >>> I believe SRTP with SDES keying is the most commonly deployed method = today. >>> That doesn't mean it's supported by any large percentage of SIP = endpoints, >>> but it's a large percentage of those that support SRTP :-) >>=20 >> I'm sure that's true. It's deployment of the fraction of SIP = endpoints that >> is the question I think is most interesting. >=20 > SIPit 29 - 80% of endpoints. > SIPit 28 - 56% of endpoints. > SIPit 27 - 60% of endpoints. >=20 > I'd say it's a fair bet that at least 50% of the SIP UA = implementations available on the market (by market share, not count of = implementations) support SRTP with SDES. This is NOT the installed base - it's available on the market. The = installed base has a very low amount of SRTP implementations that are = interoperable. /O= From xavier.marjou@gmail.com Tue Jan 24 23:55:14 2012 Return-Path: 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 72AFC21F861C for ; Tue, 24 Jan 2012 23:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 4lBRqKWZT7Qn for ; Tue, 24 Jan 2012 23:55:14 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6DD621F8620 for ; Tue, 24 Jan 2012 23:55:13 -0800 (PST) Received: by obbwc12 with SMTP id wc12so6321464obb.31 for ; Tue, 24 Jan 2012 23:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=hV3Ruebj+PzE0ymc0GRJFNGvVrtmTHHZ/GP4nESKHvw=; b=xgkBbOof2R0Gu1By6Cd9mj1PfxMIATJdRkOhTkHBx2HSmSleIGDlSbQulGorTXHhpO 2HxSmoAELi+6WENF057KDgBGYTq0bXJ+LM5SI91OuJhEk75vJZt/BVQUxkvCPxFs21Ts L08pOR2xPhOrQcrTaMCgJIJNFWM49NsutxcOQ= MIME-Version: 1.0 Received: by 10.182.231.100 with SMTP id tf4mr5578807obc.56.1327478113530; Tue, 24 Jan 2012 23:55:13 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.60.2.70 with HTTP; Tue, 24 Jan 2012 23:55:13 -0800 (PST) In-Reply-To: References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <6AA53668-4C93-4CC2-94C2-D1666D8EBFF4@iii.ca> Date: Wed, 25 Jan 2012 08:55:13 +0100 X-Google-Sender-Auth: KdzGnAaOzQtst7uxx_i0YuX4iE0 Message-ID: From: Xavier Marjou To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d044796156774dd04b755958f Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 07:55:14 -0000 --f46d044796156774dd04b755958f Content-Type: text/plain; charset=ISO-8859-1 The PSTN gateways I see also support SDES/SRTP now. So I also support SDES. On Wed, Jan 25, 2012 at 2:23 AM, Bernard Aboba wrote: > The majority of PSTN gateways I see ... support SDES/SRTP now. > --f46d044796156774dd04b755958f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The PSTN gateways I see also support SDES/SRTP now. So I also support SDES.=

On Wed, Jan 25, 2012 at 2:23 AM, Bernard= Aboba <b= ernard_aboba@hotmail.com> wrote:
The majority of PSTN gateways I see ... supp= ort SDES/SRTP now.
--f46d044796156774dd04b755958f-- From harald@alvestrand.no Wed Jan 25 06:17:41 2012 Return-Path: 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 EAC6821F8504 for ; Wed, 25 Jan 2012 06:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.472 X-Spam-Level: X-Spam-Status: No, score=-110.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 h2UkOJ7l7MXb for ; Wed, 25 Jan 2012 06:17:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0921F853D for ; Wed, 25 Jan 2012 06:17:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3AB7039E123 for ; Wed, 25 Jan 2012 15:17:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItV9aNzGIEw for ; Wed, 25 Jan 2012 15:17:39 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8D8C839E048 for ; Wed, 25 Jan 2012 15:17:39 +0100 (CET) Message-ID: <4F200F03.6090309@alvestrand.no> Date: Wed, 25 Jan 2012 15:17:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------080200030907010803030005" Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 14:17:42 -0000 This is a multi-part message in MIME format. --------------080200030907010803030005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem. Comments appreciated. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt Date: Wed, 25 Jan 2012 05:25:44 -0800 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: harald@alvestrand.no A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-msid Revision: 01 Title: Signalling Media Stream ID in the Session Description Protocol Creation date: 2012-01-25 WG ID: Individual Submission Number of pages: 9 Abstract: This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of"media stream" /"media stream track" is carried using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. The IETF Secretariat --------------080200030907010803030005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

                    Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat
--------------080200030907010803030005-- From harald@alvestrand.no Wed Jan 25 08:44:23 2012 Return-Path: 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 45E7C21F8545 for ; Wed, 25 Jan 2012 08:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yOd4yDRgc+lK for ; Wed, 25 Jan 2012 08:44:22 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B421F853A for ; Wed, 25 Jan 2012 08:44:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DA7D639E123; Wed, 25 Jan 2012 17:44:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBqQ0vEmYYlY; Wed, 25 Jan 2012 17:44:21 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5CC3839E048; Wed, 25 Jan 2012 17:44:21 +0100 (CET) Message-ID: <4F203165.90808@alvestrand.no> Date: Wed, 25 Jan 2012 17:44:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Magnus Westerlund References: <4F1E6DB0.3000709@ericsson.com> In-Reply-To: <4F1E6DB0.3000709@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 16:44:23 -0000 Forking off another thread: > B) Can media clipping occur at the initial media establishment? Can it > occur at re-negotiations? Initially this shouldn't happen as long as > media configuration is in place prior to ICE promotes any candidate > pairs. However, at media re-negotiation this could occur. And when you > split the transport setup from media negotiation it becomes an issue again. The experience we have had when doing SIP-like negotiation is that an important thing causing clipping (or rather, errors that have the net result of clipping) is the lack of crypto keys at the initiator for decoding incoming traffic. This occurs at the sender when the following things occur: - Initiator sends an offer with his encryption keys and ICE candidates - Initiator starts listening for ICE exchanges on his proposed ports - Responder sends an answer with his encryption keys and ICE candidates - Responder starts *and completes* ICE negotiation - Responder starts sending media - Response (SDP answer) arrives at sender. The result is that the initiator doesn't have the crypto keys to decrypt the responder's media. This will of course happen only when signalling messages are slow and media is fast; a common case for that is when the two ends are in the same office while the signaling server is on another continent. One solution suggested in ROAP was the "OK" message, which went from initiator to responder, and delaying the sending of media until you see an "OK"; this will of course not transfer across a SIP gateway, since SIP has no corresponding message. If keys are negotiated inband, as with DTLS-SRTP, this problem disappears, since the recipient will know when the sender knows the crypto keys (the negotiation has completed). If the key exchange was one where the responder suggested the key that the initiator should use for encryption, and vice versa, the problem would also not occur (the decrypting party would always know the key before the encrypting party), but that was not our reading of the RFCs. Note: I think the same problem can also occur if the responder is free to add codecs, track descriptions and so on in the answer that are not in the offer, but this has not been a clearly discernible problem in our deployments yet. Harald From ibc@aliax.net Wed Jan 25 09:14:02 2012 Return-Path: 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 C898A21F8627 for ; Wed, 25 Jan 2012 09:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 3sww-z4EXQni for ; Wed, 25 Jan 2012 09:14:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 367E221F8620 for ; Wed, 25 Jan 2012 09:14:02 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so4093046vbb.31 for ; Wed, 25 Jan 2012 09:13:55 -0800 (PST) Received: by 10.52.93.77 with SMTP id cs13mr9730021vdb.71.1327511635211; Wed, 25 Jan 2012 09:13:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.4.149 with HTTP; Wed, 25 Jan 2012 09:13:34 -0800 (PST) In-Reply-To: <4F203165.90808@alvestrand.no> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 25 Jan 2012 18:13:34 +0100 Message-ID: To: Harald Alvestrand X-Gm-Message-State: ALoCoQnOo8JlY6unBJZXZQOjaSn62ktrfI4Aj9DK9shvqEXuzgghX8c4CPHKuWWdxkT8yFeoHKsY Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 17:14:02 -0000 2012/1/25 Harald Alvestrand : > - Initiator sends an offer with his encryption keys and ICE candidates > - Initiator starts listening for ICE exchanges on his proposed ports > - Responder sends an answer with his encryption keys and ICE candidates > - Responder starts *and completes* ICE negotiation > - Responder starts sending media > - Response (SDP answer) arrives at sender. > > The result is that the initiator doesn't have the crypto keys to decrypt = the > responder's media. > > This will of course happen only when signalling messages are slow and med= ia > is fast; a common case for that is when the two ends are in the same offi= ce > while the signaling server is on another continent. Maybe I'm wrong, but in case the sender sends an offer with with his encryption keys, then the SDP answer MUST also contain encryption keys (am I wrong?). If so, the sender could just ignore any RTP received before the SDP answer. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Wed Jan 25 09:30:17 2012 Return-Path: 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 8182921F85FD for ; Wed, 25 Jan 2012 09:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.336 X-Spam-Level: X-Spam-Status: No, score=-110.336 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 Q2ev84SQ69Ml for ; Wed, 25 Jan 2012 09:30:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7821F85FB for ; Wed, 25 Jan 2012 09:30:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E508439E123; Wed, 25 Jan 2012 18:30:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6HdugjaOOuA; Wed, 25 Jan 2012 18:29:50 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9960C39E048; Wed, 25 Jan 2012 18:29:50 +0100 (CET) Message-ID: <4F203C0E.8050909@alvestrand.no> Date: Wed, 25 Jan 2012 18:29:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 17:30:17 -0000 On 01/25/2012 06:13 PM, Iñaki Baz Castillo wrote: > 2012/1/25 Harald Alvestrand: >> - Initiator sends an offer with his encryption keys and ICE candidates >> - Initiator starts listening for ICE exchanges on his proposed ports >> - Responder sends an answer with his encryption keys and ICE candidates >> - Responder starts *and completes* ICE negotiation >> - Responder starts sending media >> - Response (SDP answer) arrives at sender. >> >> The result is that the initiator doesn't have the crypto keys to decrypt the >> responder's media. >> >> This will of course happen only when signalling messages are slow and media >> is fast; a common case for that is when the two ends are in the same office >> while the signaling server is on another continent. > Maybe I'm wrong, but in case the sender sends an offer with with his > encryption keys, then the SDP answer MUST also contain encryption keys > (am I wrong?). > > If so, the sender could just ignore any RTP received before the SDP answer. > Yes, the loss of those packets is what causes the clipping. From ibc@aliax.net Wed Jan 25 09:44:38 2012 Return-Path: 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 5ADEA21F8613 for ; Wed, 25 Jan 2012 09:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 ibWnKjXGwNzu for ; Wed, 25 Jan 2012 09:44:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE07621F860B for ; Wed, 25 Jan 2012 09:44:37 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so4118032vcb.31 for ; Wed, 25 Jan 2012 09:44:37 -0800 (PST) Received: by 10.52.95.37 with SMTP id dh5mr9784288vdb.88.1327513477246; Wed, 25 Jan 2012 09:44:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.4.149 with HTTP; Wed, 25 Jan 2012 09:44:16 -0800 (PST) In-Reply-To: <4F203C0E.8050909@alvestrand.no> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 25 Jan 2012 18:44:16 +0100 Message-ID: To: Harald Alvestrand X-Gm-Message-State: ALoCoQmyN33Ppmquf4UGQpaUh9hE687Gh7XkpD8Ok/uG4bwaXXwrYXjNZHKeOSfjhcuKEsFPgIcm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 17:44:38 -0000 2012/1/25 Harald Alvestrand : >> Maybe I'm wrong, but in case the sender sends an offer with with his >> encryption keys, then the SDP answer MUST also contain encryption keys >> (am I wrong?). >> >> If so, the sender could just ignore any RTP received before the SDP >> answer. >> > Yes, the loss of those packets is what causes the clipping. Well, then this is just an audio processing question. It's not hard at all to alter an audio wave by applying a volume linear mask from 0 to 100% during the first ~50ms after receiving the first valid RTP packet (once the encryption keys have been received). That would remove the audio clipping. Not hard at all. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Wed Jan 25 09:56:46 2012 Return-Path: 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 9741321F8596 for ; Wed, 25 Jan 2012 09:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.334 X-Spam-Level: X-Spam-Status: No, score=-110.334 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 2uk1DYykiWuF for ; Wed, 25 Jan 2012 09:56:46 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EB88011E8073 for ; Wed, 25 Jan 2012 09:56:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37B5F39E123; Wed, 25 Jan 2012 18:56:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaypjhV69BcW; Wed, 25 Jan 2012 18:56:44 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9873639E048; Wed, 25 Jan 2012 18:56:44 +0100 (CET) Message-ID: <4F20425C.5000900@alvestrand.no> Date: Wed, 25 Jan 2012 18:56:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 17:56:46 -0000 On 01/25/2012 06:44 PM, Iñaki Baz Castillo wrote: > 2012/1/25 Harald Alvestrand: >>> Maybe I'm wrong, but in case the sender sends an offer with with his >>> encryption keys, then the SDP answer MUST also contain encryption keys >>> (am I wrong?). >>> >>> If so, the sender could just ignore any RTP received before the SDP >>> answer. >>> >> Yes, the loss of those packets is what causes the clipping. > Well, then this is just an audio processing question. It's not hard at > all to alter an audio wave by applying a volume linear mask from 0 to > 100% during the first ~50ms after receiving the first valid RTP packet > (once the encryption keys have been received). That would remove the > audio clipping. Not hard at all. > It's a bit harder if those packets were the first parts of the first I-frame on a video connection. From randell-ietf@jesup.org Wed Jan 25 09:59:16 2012 Return-Path: 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 6C91221F8596 for ; Wed, 25 Jan 2012 09:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tZ8t6pJTe9Sy for ; Wed, 25 Jan 2012 09:59:15 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E59EA21F8573 for ; Wed, 25 Jan 2012 09:59:14 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240] helo=[10.250.5.67]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rq77q-0006A2-6P for rtcweb@ietf.org; Wed, 25 Jan 2012 11:59:14 -0600 Message-ID: <4F2042EF.2020009@jesup.org> Date: Wed, 25 Jan 2012 09:59:11 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> In-Reply-To: <4F203165.90808@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 17:59:16 -0000 On 1/25/2012 8:44 AM, Harald Alvestrand wrote: > Forking off another thread: >> B) Can media clipping occur at the initial media establishment? Can it >> occur at re-negotiations? Initially this shouldn't happen as long as >> media configuration is in place prior to ICE promotes any candidate >> pairs. However, at media re-negotiation this could occur. And when you >> split the transport setup from media negotiation it becomes an issue >> again. > The result is that the initiator doesn't have the crypto keys to decrypt > the responder's media. > > This will of course happen only when signalling messages are slow and > media is fast; a common case for that is when the two ends are in the > same office while the signaling server is on another continent. > If keys are negotiated inband, as with DTLS-SRTP, this problem > disappears, since the recipient will know when the sender knows the > crypto keys (the negotiation has completed). Another mark in favor of DTLS-SRTP :-) > If the key exchange was one where the responder suggested the key that > the initiator should use for encryption, and vice versa, the problem > would also not occur (the decrypting party would always know the key > before the encrypting party), but that was not our reading of the RFCs. I believe you are correct; I vaguely remember discussion over this years ago in AVT or one of the related IETF groups, and there was some security-based reason for it. Perhaps because it increases the vulnerability to MITM attacks. > Note: I think the same problem can also occur if the responder is free > to add codecs, track descriptions and so on in the answer that are not > in the offer, but this has not been a clearly discernible problem in our > deployments yet. In that case I would guess the responder might wait until it got a response from the initiator indicating reception (3-way handshake) before sending. We've used that trick in the past to deal with certain routers set up with a DMZ device; if traffic arrives before the initiator starts sending on that port (i.e. media from responder beats the OK), then the router will send the media to the DMZ and lock in that mapping. Ouch. Only reasonable solution was to wait to send media until ACK. It did help with some issues like clipping, and users didn't get tripped up by it because we didn't show the other person or change to the in-call UI until we were ready to send. The wonders of annoying routers... -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed Jan 25 10:07:10 2012 Return-Path: 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 6D20321F85A3 for ; Wed, 25 Jan 2012 10:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 X1N0EpY7c2Yb for ; Wed, 25 Jan 2012 10:07:10 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3121F859E for ; Wed, 25 Jan 2012 10:07:09 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240] helo=[10.250.5.67]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rq7FV-0002JL-KM for rtcweb@ietf.org; Wed, 25 Jan 2012 12:07:09 -0600 Message-ID: <4F2044CB.4060207@jesup.org> Date: Wed, 25 Jan 2012 10:07:07 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> In-Reply-To: <4F20425C.5000900@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 18:07:10 -0000 On 1/25/2012 9:56 AM, Harald Alvestrand wrote: > On 01/25/2012 06:44 PM, Iñaki Baz Castillo wrote: >> 2012/1/25 Harald Alvestrand: >>>> Maybe I'm wrong, but in case the sender sends an offer with with his >>>> encryption keys, then the SDP answer MUST also contain encryption keys >>>> (am I wrong?). >>>> >>>> If so, the sender could just ignore any RTP received before the SDP >>>> answer. >>>> >>> Yes, the loss of those packets is what causes the clipping. >> Well, then this is just an audio processing question. It's not hard at >> all to alter an audio wave by applying a volume linear mask from 0 to >> 100% during the first ~50ms after receiving the first valid RTP packet >> (once the encryption keys have been received). That would remove the >> audio clipping. Not hard at all. >> > It's a bit harder if those packets were the first parts of the first > I-frame on a video connection. Or the "Hel" of "Hello?" - quite annoying, and that's a tough case when a use case is "click to answer" - you don't have the 0.1-0.5s delay for the answerer to get a handset to their mouth. When I refer to "clipping" in this context, that's the sort of thing I'm referring to (and Harald's as well). -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Wed Jan 25 10:16:17 2012 Return-Path: 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 E4A3221F85E5 for ; Wed, 25 Jan 2012 10:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XmRb-RoXVyaY for ; Wed, 25 Jan 2012 10:16:17 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9D21F85E1 for ; Wed, 25 Jan 2012 10:16:17 -0800 (PST) Received: by ghbg16 with SMTP id g16so2291022ghb.31 for ; Wed, 25 Jan 2012 10:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PLV27aefOQElz4SrFUcb+gqQD+iIWDcpe1ar44pPk70=; b=sF4TaRdGop0N6DpWGRpY5WbI+sFdAzIy/anutNTIhXq9+TVM5ov47anw736Ts2JImr St52oDZAuZC+gEmWXq/zg3P2c7ENgrQzHmFgFu37seKLIlWaqzN3ZeFkn40XqFVDvz+i Y/OMZetWtcGDuPzA4wLsQnLs5AtCz0LG4riwk= MIME-Version: 1.0 Received: by 10.236.154.232 with SMTP id h68mr3267374yhk.51.1327515374349; Wed, 25 Jan 2012 10:16:14 -0800 (PST) Received: by 10.236.180.230 with HTTP; Wed, 25 Jan 2012 10:16:14 -0800 (PST) In-Reply-To: <4F200F03.6090309@alvestrand.no> References: <4F200F03.6090309@alvestrand.no> Date: Wed, 25 Jan 2012 10:16:14 -0800 Message-ID: From: Ted Hardie To: Harald Alvestrand Content-Type: multipart/alternative; boundary=20cf303dd29e526f8004b75e4206 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 18:16:18 -0000 --20cf303dd29e526f8004b75e4206 Content-Type: text/plain; charset=ISO-8859-1 Given that the aim is to have these be unique over an SDP session's lifetime 1 character seems to small and 64 too big, so I think the range needs some tweaking. I would personal make these UUIDs or reserved values (you "default"), just to get the code re-use, but your mileage may vary. Ted On Wed, Jan 25, 2012 at 6:17 AM, Harald Alvestrand wrote: > ** > I have updated this draft with a proposal to add an identifier for the > index of the mediastreamtrack inside a mediastream, and an > inclusion-by-reference that is my proposal to solve the muting problem. > > Comments appreciated. > > Harald > > -------- Original Message -------- Subject: New Version Notification for > draft-alvestrand-rtcweb-msid-01.txt Date: Wed, 25 Jan 2012 05:25:44 -0800 From: > internet-drafts@ietf.org To: harald@alvestrand.no CC: > harald@alvestrand.no > > A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-rtcweb-msid > Revision: 01 > Title: Signalling Media Stream ID in the Session Description Protocol > Creation date: 2012-01-25 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document specifies how the association between the RTP concept > of SSRC and the WebRTC concept of "media stream" / "media stream > track" is carried using SDP signalling. > > This document is an input document for discussion. It should be > discussed in the RTCWEB WG list, rtcweb@ietf.org. > > > > > > The IETF Secretariat > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303dd29e526f8004b75e4206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given that the aim is to have these be unique over an SDP session's lif= etime 1 character seems to small and 64 too big, so I think the range needs= some tweaking.=A0 I would personal make these UUIDs or reserved values (yo= u "default"), just to get the code re-use, but your mileage may v= ary.

Ted

On Wed, Jan 25, 2012 at 6:17 AM, = Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: har= ald@alvestrand.no
CC: har= ald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been=
 successfully submitted by Harald Alvestrand and posted to the IETF reposit=
ory.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &am=
p;quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                           =
      =20


The IETF Secretariat

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--20cf303dd29e526f8004b75e4206-- From roman@telurix.com Wed Jan 25 11:26:14 2012 Return-Path: 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 15E8E21F85FB for ; Wed, 25 Jan 2012 11:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 4pF9+5er81P8 for ; Wed, 25 Jan 2012 11:26:13 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8916821F85CC for ; Wed, 25 Jan 2012 11:26:07 -0800 (PST) Received: by pbbb11 with SMTP id b11so47278pbb.31 for ; Wed, 25 Jan 2012 11:26:07 -0800 (PST) Received: by 10.68.211.38 with SMTP id mz6mr981035pbc.130.1327519567285; Wed, 25 Jan 2012 11:26:07 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id lk11sm4673410pbb.0.2012.01.25.11.26.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 11:26:06 -0800 (PST) Received: by pbbb11 with SMTP id b11so47244pbb.31 for ; Wed, 25 Jan 2012 11:26:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.115.195 with SMTP id jq3mr1218833pbb.34.1327519565067; Wed, 25 Jan 2012 11:26:05 -0800 (PST) Received: by 10.68.44.197 with HTTP; Wed, 25 Jan 2012 11:26:05 -0800 (PST) In-Reply-To: <4F200F03.6090309@alvestrand.no> References: <4F200F03.6090309@alvestrand.no> Date: Wed, 25 Jan 2012 14:26:05 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand X-Gm-Message-State: ALoCoQnOWHQWKv83gSgadhvvs3smU5c4aHnJZzdExw1WjOKVtnJSeZ8sF4aZzfpsdZkYw+TGsvrj Content-Type: multipart/alternative; boundary=047d7b15a3891bb62b04b75f3c42 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 19:26:14 -0000 --047d7b15a3891bb62b04b75f3c42 Content-Type: text/plain; charset=ISO-8859-1 Harald, One major functionality gap that is present in this proposal is ability to negotiate codecs or codec parameters per SSRC. Imagine a situation where you are communicating with a remote party that is sending you 3 video streams. How would you be able to indicate that you want larger resolution for one video stream and smaller resolution for two of the others? Or that you want to allocate more bandwidth to one stream vs the others? Also, imagine a situation where you are trying to implement the SBC that bridges a network with SSRC multiplexing with a traditional one by implementing signaling conversion and stream demultiplexing. You get an offer that lists multiple SSRC streams per m-line and convert it into an offer with multiple m-lines each corresponding to a single stream. You send this offer to the traditional network and you get back an SDP where for whatever reason, different codecs (or codecs with different parameters) where accepted for different m-lines. How do you convert this answer into an answer where those multiple m-line correspond to a single m-line in SSRC multiplexed offer? _____________ Roman Shpount On Wed, Jan 25, 2012 at 9:17 AM, Harald Alvestrand wrote: > ** > I have updated this draft with a proposal to add an identifier for the > index of the mediastreamtrack inside a mediastream, and an > inclusion-by-reference that is my proposal to solve the muting problem. > > Comments appreciated. > > Harald > > -------- Original Message -------- Subject: New Version Notification for > draft-alvestrand-rtcweb-msid-01.txt Date: Wed, 25 Jan 2012 05:25:44 -0800 From: > internet-drafts@ietf.org To: harald@alvestrand.no CC: > harald@alvestrand.no > > A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-rtcweb-msid > Revision: 01 > Title: Signalling Media Stream ID in the Session Description Protocol > Creation date: 2012-01-25 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document specifies how the association between the RTP concept > of SSRC and the WebRTC concept of "media stream" / "media stream > track" is carried using SDP signalling. > > This document is an input document for discussion. It should be > discussed in the RTCWEB WG list, rtcweb@ietf.org. > > > > > > The IETF Secretariat > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b15a3891bb62b04b75f3c42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Harald,

One major functionality gap that is present in this proposal= is ability to negotiate codecs or codec parameters per SSRC. Imagine a sit= uation where you are communicating with a remote party that is sending you = 3 video streams. How would you be able to indicate that you want larger res= olution for one video stream and smaller resolution for two of the others? = Or that you want to allocate more bandwidth to one stream vs the others?
Also, imagine a situation where you are trying to implement the SBC tha= t bridges a network with SSRC multiplexing with a traditional one by implem= enting signaling conversion and stream demultiplexing. You get an offer tha= t lists multiple SSRC streams per m-line and convert it into an offer with = multiple m-lines each corresponding to a single stream. You send this offer= to the traditional network and you get back an SDP where for whatever reas= on, different codecs (or codecs with different parameters) where accepted f= or different m-lines. How do you convert this answer into an answer where t= hose multiple m-line correspond to a single m-line in SSRC multiplexed offe= r?
_____________
Roman Shpount


On Wed, Jan 25, 2012 at 9:17 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: har= ald@alvestrand.no
CC: har= ald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been=
 successfully submitted by Harald Alvestrand and posted to the IETF reposit=
ory.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &am=
p;quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                           =
      =20


The IETF Secretariat

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b15a3891bb62b04b75f3c42-- From harald@alvestrand.no Wed Jan 25 11:47:18 2012 Return-Path: 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 98AF221F84B6 for ; Wed, 25 Jan 2012 11:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 4A4-jOVqlrtI for ; Wed, 25 Jan 2012 11:47:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD621F84B4 for ; Wed, 25 Jan 2012 11:47:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A35D339E12B; Wed, 25 Jan 2012 20:47:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3FF7njW4ZZl; Wed, 25 Jan 2012 20:47:09 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D6D3A39E048; Wed, 25 Jan 2012 20:47:09 +0100 (CET) Message-ID: <4F205C3B.70701@alvestrand.no> Date: Wed, 25 Jan 2012 20:47:07 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Roman Shpount References: <4F200F03.6090309@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060704030804020605080505" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 19:47:18 -0000 This is a multi-part message in MIME format. --------------060704030804020605080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/25/2012 08:26 PM, Roman Shpount wrote: > Harald, > > One major functionality gap that is present in this proposal is > ability to negotiate codecs or codec parameters per SSRC. Imagine a > situation where you are communicating with a remote party that is > sending you 3 video streams. How would you be able to indicate that > you want larger resolution for one video stream and smaller resolution > for two of the others? Or that you want to allocate more bandwidth to > one stream vs the others? If you want to do that using SDP, you may want to use more RTP sessions - even on separate ports, if you want the network to help you treat them differently. If the connection setup negotiation and its SDP description is just a small part of the communication that occurs between the communication partners and the servers that support them, this can be handled by entirely different means, ones that don't need to be standardized. This proposal only speaks to the issue of uniquely identifying the streams; once we have an identifier for them, we can speak about them using other protocols. (And muting them, because it seemed simple.) > > Also, imagine a situation where you are trying to implement the SBC > that bridges a network with SSRC multiplexing with a traditional one > by implementing signaling conversion and stream demultiplexing. You > get an offer that lists multiple SSRC streams per m-line and convert > it into an offer with multiple m-lines each corresponding to a single > stream. You send this offer to the traditional network and you get > back an SDP where for whatever reason, different codecs (or codecs > with different parameters) where accepted for different m-lines. How > do you convert this answer into an answer where those multiple m-line > correspond to a single m-line in SSRC multiplexed offer? What application have you downloaded into the browser that would cause this to happen? If you want an application in the browser that will connect well to a traditional SBC, which has behind it a telephone network, you will likely avoid using multiple SSRCs at all. Not all applications will be telephones. In fact, I think most of them won't be. > _____________ > Roman Shpount > > > On Wed, Jan 25, 2012 at 9:17 AM, Harald Alvestrand > > wrote: > > I have updated this draft with a proposal to add an identifier for > the index of the mediastreamtrack inside a mediastream, and an > inclusion-by-reference that is my proposal to solve the muting > problem. > > Comments appreciated. > > Harald > > -------- Original Message -------- > Subject: New Version Notification for > draft-alvestrand-rtcweb-msid-01.txt > Date: Wed, 25 Jan 2012 05:25:44 -0800 > From: internet-drafts@ietf.org > To: harald@alvestrand.no > CC: harald@alvestrand.no > > > > A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-rtcweb-msid > Revision: 01 > Title: Signalling Media Stream ID in the Session Description Protocol > Creation date: 2012-01-25 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document specifies how the association between the RTP concept > of SSRC and the WebRTC concept of"media stream" /"media stream > track" is carried using SDP signalling. > > This document is an input document for discussion. It should be > discussed in the RTCWEB WG list,rtcweb@ietf.org . > > > > > > The IETF Secretariat > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------060704030804020605080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/25/2012 08:26 PM, Roman Shpount wrote:
Harald,

One major functionality gap that is present in this proposal is ability to negotiate codecs or codec parameters per SSRC. Imagine a situation where you are communicating with a remote party that is sending you 3 video streams. How would you be able to indicate that you want larger resolution for one video stream and smaller resolution for two of the others? Or that you want to allocate more bandwidth to one stream vs the others?
If you want to do that using SDP, you may want to use more RTP sessions - even on separate ports, if you want the network to help you treat them differently.

If the connection setup negotiation and its SDP description is just a small part of the communication that occurs between the communication partners and the servers that support them, this can be handled by entirely different means, ones that don't need to be standardized.

This proposal only speaks to the issue of uniquely identifying the streams; once we have an identifier for them, we can speak about them using other protocols.
(And muting them, because it seemed simple.)

Also, imagine a situation where you are trying to implement the SBC that bridges a network with SSRC multiplexing with a traditional one by implementing signaling conversion and stream demultiplexing. You get an offer that lists multiple SSRC streams per m-line and convert it into an offer with multiple m-lines each corresponding to a single stream. You send this offer to the traditional network and you get back an SDP where for whatever reason, different codecs (or codecs with different parameters) where accepted for different m-lines. How do you convert this answer into an answer where those multiple m-line correspond to a single m-line in SSRC multiplexed offer?
What application have you downloaded into the browser that would cause this to happen?

If you want an application in the browser that will connect well to a traditional SBC, which has behind it a telephone network, you will likely avoid using multiple SSRCs at all.

Not all applications will be telephones. In fact, I think most of them won't be.

_____________
Roman Shpount


On Wed, Jan 25, 2012 at 9:17 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

                    Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--------------060704030804020605080505-- From juberti@google.com Wed Jan 25 12:36:22 2012 Return-Path: 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 1D96621F8505 for ; Wed, 25 Jan 2012 12:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.981 X-Spam-Level: X-Spam-Status: No, score=-101.981 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 Luag4yEj3+YV for ; Wed, 25 Jan 2012 12:36:21 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82A6611E8087 for ; Wed, 25 Jan 2012 12:36:10 -0800 (PST) Received: by ggnq4 with SMTP id q4so2509420ggn.31 for ; Wed, 25 Jan 2012 12:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=vw+c7u46J6T8YrcXLxTfw+OyYmJ2RdwLQYn6x2zPOtk=; b=QGysPEsyJeifd22LnW/eDBkVBJ/1vOVN3iRvGy+OIpvzo71G/belznDJSG7A206RmC 7Om7akPKXqY5Jm2HimV1i5CXHY/xoO1g6xPG9TlTGgczRo+6c6/lyOdw8LGmCLaYzf26 q8oYrsRZENm4CdzAwqZV6UQlzcydNdDN7N4tQ= Received: by 10.50.89.196 with SMTP id bq4mr7502417igb.26.1327523770385; Wed, 25 Jan 2012 12:36:10 -0800 (PST) Received: by 10.50.89.196 with SMTP id bq4mr7502406igb.26.1327523770312; Wed, 25 Jan 2012 12:36:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Wed, 25 Jan 2012 12:35:48 -0800 (PST) In-Reply-To: <4F2044CB.4060207@jesup.org> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org> From: Justin Uberti Date: Wed, 25 Jan 2012 15:35:48 -0500 Message-ID: To: Randell Jesup X-System-Of-Record: true X-Gm-Message-State: ALoCoQmS8SH5Wulb32OgzcUOebC+XE+UruTY2wXSS3tuxuqypheT7xbktTgQFxtDhwhll5veYMmAVoQZBmKOfLXQry+ZEBZlZnpduof7tRP7qibr9fCtcJgft5z7Sv8sz6w7X9ivUceEmBTF5usA4ebcRYX0dCTWHQ== Content-Type: multipart/alternative; boundary=e89a8f3ba681c2a60e04b76036f5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 20:36:22 -0000 --e89a8f3ba681c2a60e04b76036f5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup wrot= e: > On 1/25/2012 9:56 AM, Harald Alvestrand wrote: > >> On 01/25/2012 06:44 PM, I=C3=B1aki Baz Castillo wrote: >> >>> 2012/1/25 Harald Alvestrand >>> >: >>> >>>> Maybe I'm wrong, but in case the sender sends an offer with with his >>>>> encryption keys, then the SDP answer MUST also contain encryption key= s >>>>> (am I wrong?). >>>>> >>>>> If so, the sender could just ignore any RTP received before the SDP >>>>> answer. >>>>> >>>>> Yes, the loss of those packets is what causes the clipping. >>>> >>> Well, then this is just an audio processing question. It's not hard at >>> all to alter an audio wave by applying a volume linear mask from 0 to >>> 100% during the first ~50ms after receiving the first valid RTP packet >>> (once the encryption keys have been received). That would remove the >>> audio clipping. Not hard at all. >>> >>> It's a bit harder if those packets were the first parts of the first >> I-frame on a video connection. >> > > > Or the "Hel" of "Hello?" - quite annoying, and that's a tough case when a > use case is "click to answer" - you don't have the 0.1-0.5s delay for the > answerer to get a handset to their mouth. When I refer to "clipping" in > this context, that's the sort of thing I'm referring to (and Harald's as > well). Right. Note that this is not fully solved by the OK message mentioned above, since even if the answerer waits to get the OK before transmitting, the "Hel" may be already lost. The best approach I've seen so far to deal with this is to allow the transport and encryption functionality to be brought up while waiting for the answerer to respond, so that transmission can begin immediately upon answer. (e.g. using trickle candidates and DTLS-SRTP) > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8f3ba681c2a60e04b76036f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 25, 2012 at 1:07 PM, Randell= Jesup <randell-ietf@jesup.org> wrote:
On 1/25/2012 9:56 AM, Harald Alvestrand wrote:
On 01/25/2012 06:44 PM, I=C3=B1aki Baz Castillo wrote:
2012/1/25 Harald Alvestrand<harald@alvestrand.no>:
Maybe I'm wrong, but in case the sender sends an offer with with his encryption keys, then the SDP answer MUST also contain encryption keys
(am I wrong?).

If so, the sender could just ignore any RTP received before the SDP
answer.

Yes, the loss of those packets is what causes the clipping.
Well, then this is just an audio processing question. It's not hard at<= br> all to alter an audio wave by applying a volume linear mask from 0 to
100% during the first ~50ms after receiving the first valid RTP packet
(once the encryption keys have been received). That would remove the
audio clipping. Not hard at all.

It's a bit harder if those packets were the first parts of the first I-frame on a video connection.


Or the "Hel" of "Hello?" - quite annoying, and that'= ;s a tough case when a use case is "click to answer" - you don= 9;t have the 0.1-0.5s delay for the answerer to get a handset to their mout= h. =C2=A0When I refer to "clipping" in this context, that's t= he sort of thing I'm referring to (and Harald's as well).

Right. Note that this is not fully solved by the OK mes= sage mentioned above, since even if the answerer waits to get the OK before= transmitting, the "Hel" may be already lost.

The best approach I've seen so far to deal with this is to a= llow the transport and encryption functionality to be brought up while wait= ing for the answerer to respond, so that transmission can begin immediately= upon answer.
(e.g. using trickle candidates and DTLS-SRTP)




--
Randell Jesup
randell-ietf@je= sup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f3ba681c2a60e04b76036f5-- From harald@alvestrand.no Wed Jan 25 12:48:36 2012 Return-Path: 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 2E9EF21F857A for ; Wed, 25 Jan 2012 12:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.298 X-Spam-Level: X-Spam-Status: No, score=-110.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 6ylkzbUb5G7X for ; Wed, 25 Jan 2012 12:48:35 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48121F8577 for ; Wed, 25 Jan 2012 12:48:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5052D39E13F; Wed, 25 Jan 2012 21:48:34 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzpXsL4t8ioE; Wed, 25 Jan 2012 21:48:33 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2B7D539E12B; Wed, 25 Jan 2012 21:48:33 +0100 (CET) Message-ID: <4F206AA0.5040600@alvestrand.no> Date: Wed, 25 Jan 2012 21:48:32 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Justin Uberti References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020503060401030600070609" Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 20:48:36 -0000 This is a multi-part message in MIME format. --------------020503060401030600070609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 01/25/2012 09:35 PM, Justin Uberti wrote: > > > On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup > wrote: > > On 1/25/2012 9:56 AM, Harald Alvestrand wrote: > > On 01/25/2012 06:44 PM, Iñaki Baz Castillo wrote: > > 2012/1/25 Harald Alvestrand >: > > Maybe I'm wrong, but in case the sender sends an > offer with with his > encryption keys, then the SDP answer MUST also > contain encryption keys > (am I wrong?). > > If so, the sender could just ignore any RTP > received before the SDP > answer. > > Yes, the loss of those packets is what causes the > clipping. > > Well, then this is just an audio processing question. It's > not hard at > all to alter an audio wave by applying a volume linear > mask from 0 to > 100% during the first ~50ms after receiving the first > valid RTP packet > (once the encryption keys have been received). That would > remove the > audio clipping. Not hard at all. > > It's a bit harder if those packets were the first parts of the > first > I-frame on a video connection. > > > > Or the "Hel" of "Hello?" - quite annoying, and that's a tough case > when a use case is "click to answer" - you don't have the 0.1-0.5s > delay for the answerer to get a handset to their mouth. When I > refer to "clipping" in this context, that's the sort of thing I'm > referring to (and Harald's as well). > > > Right. Note that this is not fully solved by the OK message mentioned > above, since even if the answerer waits to get the OK before > transmitting, the "Hel" may be already lost. > > The best approach I've seen so far to deal with this is to allow the > transport and encryption functionality to be brought up while waiting > for the answerer to respond, so that transmission can begin > immediately upon answer. > (e.g. using trickle candidates and DTLS-SRTP) Note - this is something that is strongly application dependent. If the answerer has no expectation of privacy of location, like a call center, it makes perfect sense to do the whole offer/answer/crypto/so-on exchange while waiting for the human to react to the ring tone. If the answerer has expectation of privacy of location, or even of presence, he may not want to send *any* packet (including ICE probes) in the direction of the caller until he's thought carefully about whether or not he has sufficient proof that the caller is someone who he's comfortable with knowing his network location, and made his choice known by hitting "answer" or "reject". In the first case, clipping should be a non-problem; machines are usually faster than humans. In the second case, the "...lo" problem can only reasonably be solved by shaping the dialog so that the user doesn't think he can start speaking until everything's set up. In both cases, much can be done if we expose to the application the state of media flow (not ready / ready / flowing). --------------020503060401030600070609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/25/2012 09:35 PM, Justin Uberti wrote:


On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 1/25/2012 9:56 AM, Harald Alvestrand wrote:
On 01/25/2012 06:44 PM, Iñaki Baz Castillo wrote:
2012/1/25 Harald Alvestrand<harald@alvestrand.no>:
Maybe I'm wrong, but in case the sender sends an offer with with his
encryption keys, then the SDP answer MUST also contain encryption keys
(am I wrong?).

If so, the sender could just ignore any RTP received before the SDP
answer.

Yes, the loss of those packets is what causes the clipping.
Well, then this is just an audio processing question. It's not hard at
all to alter an audio wave by applying a volume linear mask from 0 to
100% during the first ~50ms after receiving the first valid RTP packet
(once the encryption keys have been received). That would remove the
audio clipping. Not hard at all.

It's a bit harder if those packets were the first parts of the first
I-frame on a video connection.


Or the "Hel" of "Hello?" - quite annoying, and that's a tough case when a use case is "click to answer" - you don't have the 0.1-0.5s delay for the answerer to get a handset to their mouth.  When I refer to "clipping" in this context, that's the sort of thing I'm referring to (and Harald's as well).

Right. Note that this is not fully solved by the OK message mentioned above, since even if the answerer waits to get the OK before transmitting, the "Hel" may be already lost.

The best approach I've seen so far to deal with this is to allow the transport and encryption functionality to be brought up while waiting for the answerer to respond, so that transmission can begin immediately upon answer.
(e.g. using trickle candidates and DTLS-SRTP)
Note - this is something that is strongly application dependent.

If the answerer has no expectation of privacy of location, like a call center, it makes perfect sense to do the whole offer/answer/crypto/so-on exchange while waiting for the human to react to the ring tone.

If the answerer has expectation of privacy of location, or even of presence, he may not want to send *any* packet (including ICE probes) in the direction of the caller until he's thought carefully about whether or not he has sufficient proof that the caller is someone who he's comfortable with knowing his network location, and made his choice known by hitting "answer" or "reject".

In the first case, clipping should be a non-problem; machines are usually faster than humans.

In the second case, the "...lo" problem can only reasonably be solved by shaping the dialog so that the user doesn't think he can start speaking until everything's set up.

In both cases, much can be done if we expose to the application the state of media flow (not ready / ready / flowing).


--------------020503060401030600070609-- From randell-ietf@jesup.org Wed Jan 25 13:17:40 2012 Return-Path: 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 CB3D721F8552 for ; Wed, 25 Jan 2012 13:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IxVQXUcxkqGw for ; Wed, 25 Jan 2012 13:17:40 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4E21F8551 for ; Wed, 25 Jan 2012 13:17:40 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240] helo=[10.250.5.67]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqADq-0007Fz-TZ for rtcweb@ietf.org; Wed, 25 Jan 2012 15:17:39 -0600 Message-ID: <4F207170.1080400@jesup.org> Date: Wed, 25 Jan 2012 13:17:36 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org> <4F206AA0.5040600@alvestrand.no> In-Reply-To: <4F206AA0.5040600@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 21:17:40 -0000 On 1/25/2012 12:48 PM, Harald Alvestrand wrote: > On 01/25/2012 09:35 PM, Justin Uberti wrote: >> >> >> On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup > > wrote: >> [SNIP] >> >> Or the "Hel" of "Hello?" - quite annoying, and that's a tough case >> when a use case is "click to answer" - you don't have the 0.1-0.5s >> delay for the answerer to get a handset to their mouth. When I >> refer to "clipping" in this context, that's the sort of thing I'm >> referring to (and Harald's as well). >> >> >> Right. Note that this is not fully solved by the OK message mentioned >> above, since even if the answerer waits to get the OK before >> transmitting, the "Hel" may be already lost. >> >> The best approach I've seen so far to deal with this is to allow the >> transport and encryption functionality to be brought up while waiting >> for the answerer to respond, so that transmission can begin >> immediately upon answer. >> (e.g. using trickle candidates and DTLS-SRTP) > Note - this is something that is strongly application dependent. > > If the answerer has no expectation of privacy of location, like a call > center, it makes perfect sense to do the whole offer/answer/crypto/so-on > exchange while waiting for the human to react to the ring tone. > > If the answerer has expectation of privacy of location, or even of > presence, he may not want to send *any* packet (including ICE probes) in > the direction of the caller until he's thought carefully about whether > or not he has sufficient proof that the caller is someone who he's > comfortable with knowing his network location, and made his choice known > by hitting "answer" or "reject". Correct - the use-case discussed before was someone calling their estranged wife and sniffing the network traffic to figure out where she's hiding from him (to use a particularly nasty example). I won't repeat it all; it's in the archives, but it may make sense to review. > In the first case, clipping should be a non-problem; machines are > usually faster than humans. > > In the second case, the "...lo" problem can only reasonably be solved by > shaping the dialog so that the user doesn't think he can start speaking > until everything's set up. Right; that's largely how we did it - it's easier when you have visible UI, and doubly so when there's an expectation of seeing video from the far end. > In both cases, much can be done if we expose to the application the > state of media flow (not ready / ready / flowing). Yes. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Wed Jan 25 13:18:34 2012 Return-Path: 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 5AC8F21F862A for ; Wed, 25 Jan 2012 13:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 qYOq9mGNde6Q for ; Wed, 25 Jan 2012 13:18:33 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2521F8600 for ; Wed, 25 Jan 2012 13:18:33 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so4305327vcb.31 for ; Wed, 25 Jan 2012 13:18:33 -0800 (PST) Received: by 10.220.154.135 with SMTP id o7mr9020187vcw.2.1327526313188; Wed, 25 Jan 2012 13:18:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.4.149 with HTTP; Wed, 25 Jan 2012 13:18:11 -0800 (PST) In-Reply-To: <4F2044CB.4060207@jesup.org> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 25 Jan 2012 22:18:11 +0100 Message-ID: To: Randell Jesup X-Gm-Message-State: ALoCoQkHFR5xrRO/kNJt3WtWsdDJDY3n1emvueplKAAk1enxid50Y+bAlGarvjtOHte3IMuEK0uD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 21:18:34 -0000 2012/1/25 Randell Jesup : > Or the "Hel" of "Hello?" - quite annoying, and that's a tough case when a > use case is "click to answer" - you don't have the 0.1-0.5s delay for the > answerer to get a handset to their mouth. =C2=A0When I refer to "clipping= " in > this context, that's the sort of thing I'm referring to (and Harald's as > well). Ok, that's not what I call "clipping" in the audio/music world ;) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Jan 25 14:31:20 2012 Return-Path: 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 2C30411E80D4 for ; Wed, 25 Jan 2012 14:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.899 X-Spam-Level: X-Spam-Status: No, score=-8.899 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 xVKoNq1R2iGO for ; Wed, 25 Jan 2012 14:31:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40811E80B9 for ; Wed, 25 Jan 2012 14:31:19 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-57-4f2082b6cfa3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 39.4D.02613.6B2802F4; Wed, 25 Jan 2012 23:31:18 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 25 Jan 2012 23:31:17 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Randell Jesup Date: Wed, 25 Jan 2012 23:31:17 +0100 Thread-Topic: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) Thread-Index: AczbpudmzbaN9Vb8Sgqb/ruSA8fy4gACGKQ4 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D31B998@ESESSCMS0356.eemea.ericsson.se> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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: Wed, 25 Jan 2012 22:31:20 -0000 Hi Harald, I may have missunderstood something, but in your use-case the crypto keys w= ere sent already in the first answer, together with the ICE candidates. So, when the ICE negotiation etc has finished, and the "final" answer is se= nt, the offerer already has the keys. >From my experience, clipping during call setup it not a big real life probl= em. TECHNICALLY, clipping during session modification is more difficult, especi= ally if the change affects IP, CPU resources. In the SIP world it is said t= hat an offerer must be able to handle media both using the old media parame= ters, and the new ones offered, but it is not always possible. But, I am no= t sure whether it's a real life problem either. You also said: "One solution suggested in ROAP was the "OK" message, which went from initiator to responder, and delaying the sending of media until you see an "OK"; this will of course not transfer across a SIP gateway, since SIP has no corresponding message." In SIP you do have the precondition mechanism (which you could use to not e= ven alarm the remote user until the ICE negotiations etc have completed). Or, you could simply use the direction attributes. Keep the connection "ina= ctive" until you're ready to receive media. How well it would map with ROAP, I haven't checked :) Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of I=F1ak= i Baz Castillo [ibc@aliax.net] Sent: Wednesday, January 25, 2012 11:18 PM To: Randell Jesup Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing th= e signaling proposals) 2012/1/25 Randell Jesup : > Or the "Hel" of "Hello?" - quite annoying, and that's a tough case when a > use case is "click to answer" - you don't have the 0.1-0.5s delay for the > answerer to get a handset to their mouth. When I refer to "clipping" in > this context, that's the sort of thing I'm referring to (and Harald's as > well). Ok, that's not what I call "clipping" in the audio/music world ;) -- I=F1aki Baz Castillo _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Wed Jan 25 20:13:05 2012 Return-Path: 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 7B00D21F8528 for ; Wed, 25 Jan 2012 20:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.897 X-Spam-Level: X-Spam-Status: No, score=-101.897 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 6gT5LjSluKUt for ; Wed, 25 Jan 2012 20:13:04 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8976421F8525 for ; Wed, 25 Jan 2012 20:13:04 -0800 (PST) Received: by qcsf16 with SMTP id f16so100034qcs.31 for ; Wed, 25 Jan 2012 20:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=bAJwZwM4z/xbDEpf0CizXbZUsL3xLIsVbPIMsCWLpEk=; b=uN/weZsiNClIWyE6ddzCivUnsOIt89GCLqbDhMnwIllUlmC6UVI/dnSLuJjEf/1gyH t0X3ApLHa7pCQl5iUFJw3Tfg6+pzCX0T0gzJoc3LEKZ6N4cP3DyXQR0PvAfbYu3t6jrD xHZOW/p43Dn9LmJFrwdMCiosOa2TzB+wvmwM0= Received: by 10.224.180.142 with SMTP id bu14mr620351qab.30.1327551183448; Wed, 25 Jan 2012 20:13:03 -0800 (PST) Received: by 10.224.180.142 with SMTP id bu14mr620338qab.30.1327551183320; Wed, 25 Jan 2012 20:13:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.133.131 with HTTP; Wed, 25 Jan 2012 20:12:43 -0800 (PST) In-Reply-To: <4F207170.1080400@jesup.org> References: <4F1E6DB0.3000709@ericsson.com> <4F203165.90808@alvestrand.no> <4F203C0E.8050909@alvestrand.no> <4F20425C.5000900@alvestrand.no> <4F2044CB.4060207@jesup.org> <4F206AA0.5040600@alvestrand.no> <4F207170.1080400@jesup.org> From: Justin Uberti Date: Wed, 25 Jan 2012 23:12:43 -0500 Message-ID: To: Randell Jesup X-System-Of-Record: true Content-Type: multipart/alternative; boundary=485b397dce45b3f72904b7669838 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Clipping (Re: Questions to consider when analyzing the signaling proposals) X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 04:13:05 -0000 --485b397dce45b3f72904b7669838 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 25, 2012 at 4:17 PM, Randell Jesup wrote: > On 1/25/2012 12:48 PM, Harald Alvestrand wrote: > >> On 01/25/2012 09:35 PM, Justin Uberti wrote: >> >>> >>> >>> On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup >> > wrote: >>> >>> [SNIP] > > >>> Or the "Hel" of "Hello?" - quite annoying, and that's a tough case >>> when a use case is "click to answer" - you don't have the 0.1-0.5s >>> delay for the answerer to get a handset to their mouth. When I >>> refer to "clipping" in this context, that's the sort of thing I'm >>> referring to (and Harald's as well). >>> >>> >>> Right. Note that this is not fully solved by the OK message mentioned >>> above, since even if the answerer waits to get the OK before >>> transmitting, the "Hel" may be already lost. >>> >>> The best approach I've seen so far to deal with this is to allow the >>> transport and encryption functionality to be brought up while waiting >>> for the answerer to respond, so that transmission can begin >>> immediately upon answer. >>> (e.g. using trickle candidates and DTLS-SRTP) >>> >> Note - this is something that is strongly application dependent. >> >> If the answerer has no expectation of privacy of location, like a call >> center, it makes perfect sense to do the whole offer/answer/crypto/so-on >> exchange while waiting for the human to react to the ring tone. >> > Or even before playing the ring tone. > >> If the answerer has expectation of privacy of location, or even of >> presence, he may not want to send *any* packet (including ICE probes) in >> the direction of the caller until he's thought carefully about whether >> or not he has sufficient proof that the caller is someone who he's >> comfortable with knowing his network location, and made his choice known >> by hitting "answer" or "reject". >> > > Correct - the use-case discussed before was someone calling their > estranged wife and sniffing the network traffic to figure out where she's > hiding from him (to use a particularly nasty example). I won't repeat it > all; it's in the archives, but it may make sense to review. Right; I recall the solution suggested for this case was to only use TURN candidates until the call had been accepted, although I don't think it's been scrutinized. > > > In the first case, clipping should be a non-problem; machines are >> usually faster than humans. >> >> In the second case, the "...lo" problem can only reasonably be solved by >> shaping the dialog so that the user doesn't think he can start speaking >> until everything's set up. >> > > Right; that's largely how we did it - it's easier when you have visible > UI, and doubly so when there's an expectation of seeing video from the far > end. > > > In both cases, much can be done if we expose to the application the >> state of media flow (not ready / ready / flowing). >> > > Yes. > > > -- > Randell Jesup > randell-ietf@jesup.org > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --485b397dce45b3f72904b7669838 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Jan 25, 2012 at 4:17 PM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 1/25/2012 12:48 PM, Harald Alvestrand wrote:
On 01/25/2012 09:35 PM, Justin Uberti wrote:


On Wed, Jan 25, 2012 at 1:07 PM, Randell Jesup <randell-ietf@jesup.org
<mailto:rand= ell-ietf@jesup.org>> wrote:

[SNIP]


=C2=A0 =C2=A0Or the "Hel" of "Hello?" - quite annoying= , and that's a tough case
=C2=A0 =C2=A0when a use case is "click to answer" - you don'= t have the 0.1-0.5s
=C2=A0 =C2=A0delay for the answerer to get a handset to their mouth. When = I
=C2=A0 =C2=A0refer to "clipping" in this context, that's the= sort of thing I'm
=C2=A0 =C2=A0referring to (and Harald's as well).


Right. Note that this is not fully solved by the OK message mentioned
above, since even if the answerer waits to get the OK before
transmitting, the "Hel" may be already lost.

The best approach I've seen so far to deal with this is to allow the transport and encryption functionality to be brought up while waiting
for the answerer to respond, so that transmission can begin
immediately upon answer.
(e.g. using trickle candidates and DTLS-SRTP)
Note - this is something that is strongly application dependent.

If the answerer has no expectation of privacy of location, like a call
center, it makes perfect sense to do the whole offer/answer/crypto/so-on exchange while waiting for the human to react to the ring tone.

Or even before playing the ring= tone.
=C2=A0

If the answerer has expectation of privacy of location, or even of
presence, he may not want to send *any* packet (including ICE probes) in the direction of the caller until he's thought carefully about whether<= br> or not he has sufficient proof that the caller is someone who he's
comfortable with knowing his network location, and made his choice known by hitting "answer" or "reject".

Correct - the use-case discussed before was someone calling their estranged= wife and sniffing the network traffic to figure out where she's hiding= from him (to use a particularly nasty example). =C2=A0I won't repeat i= t all; it's in the archives, but it may make sense to review.

Right; I recall the solution suggested for this case wa= s to only use TURN candidates until the call had been accepted, although I = don't think it's been scrutinized.


In the first case, clipping should be a non-problem; machines are
usually faster than humans.

In the second case, the "...lo" problem can only reasonably be so= lved by
shaping the dialog so that the user doesn't think he can start speaking=
until everything's set up.

Right; that's largely how we did it - it's easier when you have vis= ible UI, and doubly so when there's an expectation of seeing video from= the far end.


In both cases, much can be done if we expose to the application the
state of media flow (not ready / ready / flowing).

Yes.


--
Randell Jesup
randell-ietf@je= sup.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--485b397dce45b3f72904b7669838-- From fluffy@fluffy.im Thu Jan 26 11:04:56 2012 Return-Path: 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 9E9AA21F8615 for ; Thu, 26 Jan 2012 11:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6ELiIKlnEc1W for ; Thu, 26 Jan 2012 11:04:56 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4641E21F85D1 for ; Thu, 26 Jan 2012 11:04:56 -0800 (PST) Received: by mail-pw0-f44.google.com with SMTP id u7so542866pbd.31 for ; Thu, 26 Jan 2012 11:04:56 -0800 (PST) Received: by 10.68.196.232 with SMTP id ip8mr7392997pbc.19.1327604696016; Thu, 26 Jan 2012 11:04:56 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id a5sm13364940pbh.15.2012.01.26.11.04.54 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 11:04:55 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 12:04:53 -0700 Message-Id: To: rtcweb@ietf.org, Justin Uberti Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - When do resource reservations happen ? X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 19:04:56 -0000 Here is one question about JSEP that I hope you can respond to quickly, = it's really just a clarification on how JSEP works but it seems very = important to really analyzing how JSEP will work.=20 A lot of operations require allocating resources, such as UDP ports, = DSPs, etc. Are those allocated when you invoke createOffer() or when you = invoke setLocalDescription()? So, say you only have one DSP, if someone = calls createOffer() in tab A, does that make the DSP unavailable in tab = B? Thanks, Cullen From ekr@rtfm.com Thu Jan 26 11:25:14 2012 Return-Path: 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 7D63D21F86C3 for ; Thu, 26 Jan 2012 11:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 sGZDHHD-a6dT for ; Thu, 26 Jan 2012 11:25:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD85221F86C2 for ; Thu, 26 Jan 2012 11:25:13 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so716053vbb.31 for ; Thu, 26 Jan 2012 11:25:13 -0800 (PST) Received: by 10.52.69.116 with SMTP id d20mr1656979vdu.24.1327605913386; Thu, 26 Jan 2012 11:25:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Thu, 26 Jan 2012 11:24:33 -0800 (PST) X-Originating-IP: [74.95.2.173] From: Eric Rescorla Date: Thu, 26 Jan 2012 11:24:33 -0800 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 19:25:14 -0000 Hi Justin, i=92ve been thinking about how ICE works in JSEP and ISTM that the API may not be emitting enough information to work here. As I understand it, the following is a reasonable order of operations: Alice->Bob: Offer Alice->Bob: ICE candidates Bob->Alice: ICE candidates // ICE happens // Bob answers Bob->Alice: Answer Unless I=92m missing something, though, Alice and Bob can=92t start doing ICE until they have exchanged the ice-ufrag and ice-pwd properties. Alice sends these in her offer, so this is no problem, but they would ordinarily be in Bob=92s answer, but that gets delayed, and they=92re not in Bob=92s ICE candidates, so I don=92t think they can start ICE until Bob=92s answer arrives. I suspect that what we need here is something more like an XEP-0176 element, which would contain the pwd and ufrag. This also has the potential to solve the problem you raise at the end of how to associate each candidate with the relevant media stream, since we can stuff a pointer in that structure. [Note: I am not an SDP expert, so I don=92t have an opinion on the best form of that pointer. As you know, in ordinary ICE-SDP, this info is just assocaited with the m-line by counting.] While we=92re on the topic of stuffing stuff here, it would be pretty nice to know in advance if you are going to bundle, so you=92re not thinking you=92re going to do ICE on channels which you don=92t want. As you pointed out in another message, it=92s also natural to put the DTLS info here, so that we can get DTLS started early. In general, I think if we=92re going to separate transport and media signaling, we should probably be thinking about if there is anything else that really needs to be delivered prior to Bob=92s decision to answer the phone. Finally, as you point out in Appendix A, we don=92t currently know when you have all your candidates, which makes it hard to implement SIP compatibility from this API. I=92m not 100% sure what the best API is here: do we want to know when all candidates are found or just all for a given flow? -Ekr From fluffy@fluffy.im Thu Jan 26 11:43:30 2012 Return-Path: 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 10AB621F8666 for ; Thu, 26 Jan 2012 11:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 r0HrHMPlQzFx for ; Thu, 26 Jan 2012 11:43:29 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7488221F8639 for ; Thu, 26 Jan 2012 11:43:29 -0800 (PST) Received: by pbdu7 with SMTP id u7so578614pbd.31 for ; Thu, 26 Jan 2012 11:43:29 -0800 (PST) Received: by 10.68.115.133 with SMTP id jo5mr7583789pbb.50.1327607009283; Thu, 26 Jan 2012 11:43:29 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id w4sm6228850pbf.4.2012.01.26.11.43.27 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 11:43:28 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 12:43:26 -0700 Message-Id: <05E6868A-250C-4287-A67A-E41517372BC5@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - Question about ICE trickle stats X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 19:43:30 -0000 It seems to me there are a roughly three types of addresses used for = ICE/RTP in something like Hangouts. The local address, the NAT (server = reflexive) address, and the relayed address. A browser always knows the = local addresses but the NAT and relay take a bit longer thus the = argument for trickle. In trying to model how this all works it would be = really nice to know on a deployment such as Hangouts some of the = following stats: What percentage of media flows end up sending RTP via the relay? What = percentage does the server reflexive address get used? and what = percentage have the far end sending directly to the local address?=20 What is the average time to get a relay address? to find the server = reflexive address?=20 What is the typical RTT for messages from one browser to the other = browser for the signaling data? Having a rough of idea of the above would be really helpful in looking = at timing of various parts. Justin, Any chance you can provide some of these measurements? From fluffy@fluffy.im Thu Jan 26 12:41:49 2012 Return-Path: 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 B555E21F8722 for ; Thu, 26 Jan 2012 12:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iSIx1giQ+KtI for ; Thu, 26 Jan 2012 12:41:49 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7F21F871D for ; Thu, 26 Jan 2012 12:41:49 -0800 (PST) Received: by pbdu7 with SMTP id u7so631357pbd.31 for ; Thu, 26 Jan 2012 12:41:49 -0800 (PST) Received: by 10.68.193.167 with SMTP id hp7mr8127869pbc.3.1327610508974; Thu, 26 Jan 2012 12:41:48 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id x8sm13981402pbr.11.2012.01.26.12.41.47 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 12:41:48 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 13:41:46 -0700 Message-Id: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - Modifying the SDP X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 20:41:49 -0000 =20 I've like to understand what parts of the SDP the JS app can change = between the createOffer and the setLocal. And similarly the createAnswer = and setLocal? =20 So for some specific examples - say the SDP had a v4 and v6 address - = could the JS remove one? can it change the SSRC? ports ? Can it remove a = codec? what can it do to things like bandwidth limits? Can it change the = video resolution to a smaller resolution? any limits on this? can it = change the aspect ratio? can it change to square pixels? frame rate? = Can it change the profile information for a video codec? =20 What parts of SDP is the createOffer allowed to use - can it use any = valid SDP extension? If the browser wants to modify the SDP to use some = SDP extension, what extensions does the browser need to be able to = support in setLocal? If due to some prior knowledge such as a previous session on the same = browser, the application knows that the browser supports what it needs, = can the JS just create it own offer and never call createOffer but just = directly call setLocalSDP ? This might seem sort of far fetched but if = the JS was going to talk to a conference bridge for a game that only = supported G.711, it might be reasonable for the JS to just create an = offer that was only 711 and if you were on a browser that did not = support that, it was never going to work anyways. Anyways, is this sort = of use of the API allowed ? Related to this is the issues of what sort of errors will be reported on = a setLocal. I don't really care how they are reported, exceptions, error = codes, whatever - but I would like to see a list of all the different = error. This seems pretty important to decide how complex the JS code = needs to be to decide to recover from these error and also will impact = how flexible the mechanism ends up being. What are you thinking of as = the list of errors?= From fluffy@fluffy.im Thu Jan 26 12:55:38 2012 Return-Path: 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 46CE821F8666 for ; Thu, 26 Jan 2012 12:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hlfkOGcaWp7E for ; Thu, 26 Jan 2012 12:55:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD821F854D for ; Thu, 26 Jan 2012 12:55:37 -0800 (PST) Received: by ggnq4 with SMTP id q4so584199ggn.31 for ; Thu, 26 Jan 2012 12:55:37 -0800 (PST) Received: by 10.50.160.131 with SMTP id xk3mr3841850igb.19.1327611337011; Thu, 26 Jan 2012 12:55:37 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id h9sm5231768ibh.11.2012.01.26.12.55.35 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 12:55:36 -0800 (PST) Sender: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: Date: Thu, 26 Jan 2012 13:55:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BE64805-3E71-45F4-BE8B-494F782E2D90@iii.ca> References: To: Eric Rescorla , rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 20:55:38 -0000 On Jan 26, 2012, at 12:24 PM, Eric Rescorla wrote: > Hi Justin, >=20 > i=92ve been thinking about how ICE works in JSEP and ISTM that the API > may not be emitting enough information to work here. As I understand > it, the following is a reasonable order of operations: >=20 > Alice->Bob: Offer > Alice->Bob: ICE candidates > Bob->Alice: ICE candidates > // ICE happens > // Bob answers > Bob->Alice: Answer >=20 > Unless I=92m missing something, though, Alice and Bob can=92t start = doing > ICE until they have exchanged the ice-ufrag and ice-pwd > properties. Alice sends these in her offer, so this is no problem, but > they would ordinarily be in Bob=92s answer, but that gets delayed, and > they=92re not in Bob=92s ICE candidates, so I don=92t think they can = start > ICE until Bob=92s answer arrives. I suspect that what we need here is > something more like an XEP-0176 element, which would > contain the pwd and ufrag. This also has the potential to solve the > problem you raise at the end of how to associate each candidate with > the relevant media stream, since we can stuff a pointer in that > structure. [Note: I am not an SDP expert, so I don=92t have an opinion > on the best form of that pointer. As you know, in ordinary ICE-SDP, > this info is just assocaited with the m-line by counting.] >=20 > While we=92re on the topic of stuffing stuff here, it would be pretty > nice to know in advance if you are going to bundle, so you=92re not > thinking you=92re going to do ICE on channels which you don=92t want. = As > you pointed out in another message, it=92s also natural to put the = DTLS > info here, so that we can get DTLS started early. In general, I think > if we=92re going to separate transport and media signaling, we should > probably be thinking about if there is anything else that really needs > to be delivered prior to Bob=92s decision to answer the phone. >=20 > Finally, as you point out in Appendix A, we don=92t currently know = when > you have all your candidates, which makes it hard to implement SIP > compatibility from this API. I=92m not 100% sure what the best API is > here: do we want to know when all candidates are found or just all for > a given flow? >=20 > -Ekr >=20 In the past, I have considered adding an CANDIDATES message to ROAP to = allow extra candidates to be augmented to an existing offer or answer = but it never been clear if the optimization guided by this was worth the = complexity. Definitely worth thinking about.=20 From fluffy@fluffy.im Thu Jan 26 13:04:22 2012 Return-Path: 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 732B021F85AD for ; Thu, 26 Jan 2012 13:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1El2ZrvuvCMC for ; Thu, 26 Jan 2012 13:04:22 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF421F85A5 for ; Thu, 26 Jan 2012 13:04:22 -0800 (PST) Received: by dado14 with SMTP id o14so950497dad.31 for ; Thu, 26 Jan 2012 13:04:21 -0800 (PST) Received: by 10.68.212.73 with SMTP id ni9mr8175739pbc.82.1327611861837; Thu, 26 Jan 2012 13:04:21 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id i4sm14164176pbl.2.2012.01.26.13.04.20 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 13:04:21 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> Date: Thu, 26 Jan 2012 14:04:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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, 26 Jan 2012 21:04:22 -0000 On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >> I'd say it's a fair bet that at least 50% of the SIP UA = implementations available on the market (by market share, not count of = implementations) support SRTP with SDES. >=20 > This is NOT the installed base - it's available on the market. The = installed base has a very low amount of SRTP implementations that are = interoperable Uh, I pretty much disagree with that thought I don't have hard stats I = can point you at. A large percentage of the deployed endpoints and = gateways do work with SRTP and I don't see a lot of bugs logged against = them.=20 From andrew.hutton@siemens-enterprise.com Fri Jan 27 05:25:28 2012 Return-Path: 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 BCA3921F8514 for ; Fri, 27 Jan 2012 05:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] 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 elIy5NNCfVhp for ; Fri, 27 Jan 2012 05:25:28 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 015C821F850D for ; Fri, 27 Jan 2012 05:25:27 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 7983123F04C7; Fri, 27 Jan 2012 14:25:26 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 27 Jan 2012 14:25:26 +0100 From: "Hutton, Andrew" To: Cullen Jennings , Olle E.Johansson Date: Fri, 27 Jan 2012 14:25:25 +0100 Thread-Topic: [rtcweb] SDES draft posted Thread-Index: AczcbheLIxxkdy7ESSmxjfB6NTq20wAh+cUg Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> In-Reply-To: <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 13:25:28 -0000 Also I don't have hard stats but of course SDES is what is implemented toda= y in endpoints and gateways that have a requirement for SRTP which I think = is a large percentage and growing. SDES is also pretty much interoperable b= etween implementations the main issues that arise are around best effort SR= TP and that fact that sdp-neg (RFC 5939) is not widely implemented. So if SDES, DTLS-SRTP and possibly even RTP are going to be options in RTCW= EB the issue that needs to be clearly specified is the negotiation mechanis= m be it RFC 5939 or something else. I don't believe that a fallback mechani= sm based on failure and re-try would be acceptable. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: 26 January 2012 21:04 > To: Olle E.Johansson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SDES draft posted >=20 >=20 > On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >=20 > >> I'd say it's a fair bet that at least 50% of the SIP UA > implementations available on the market (by market share, not count of > implementations) support SRTP with SDES. > > > > This is NOT the installed base - it's available on the market. The > installed base has a very low amount of SRTP implementations that are > interoperable >=20 > Uh, I pretty much disagree with that thought I don't have hard stats I > can point you at. A large percentage of the deployed endpoints and > gateways do work with SRTP and I don't see a lot of bugs logged against > them. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Fri Jan 27 05:52:12 2012 Return-Path: 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 00D4D21F8591 for ; Fri, 27 Jan 2012 05:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 CwN7kGw850my for ; Fri, 27 Jan 2012 05:52:10 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C2EAD21F8572 for ; Fri, 27 Jan 2012 05:52:09 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0RDqmmu021085; Fri, 27 Jan 2012 08:52:48 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 08:51:23 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 19:21:26 +0530 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Fri, 27 Jan 2012 19:21:25 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Cullen Jennings , "Olle E.Johansson" Thread-Topic: [rtcweb] SDES draft posted Thread-Index: AczamLkmxJ01MFolQbCHRCQyikwf5///5BgAgAAO3QCAAAofgIAAEPWAgADKlACAAnXggIABEh6A//+fyKA= Date: Fri, 27 Jan 2012 13:51:25 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 13:51:26.0163 (UTC) FILETIME=[C3316230:01CCDCFA] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 13:52:12 -0000 Andy, Even though the discussion is to provide RTP, SDES, DTLS-SRTP, till now I didn't see anybody ask for fallback mechanism within these=20 mechanism as it will lead to bid-down attack. I agree with you that=20 any fallback mechanism makes the implementation Complex and unacceptable.=20 Also, I could not see the point in supporting both SDES and DTLS-SRTP. In case WebRTC webserver is always trusted, SDES is the solution and Webserver is not trusted, DTLS-SRTP is the solution.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Friday, January 27, 2012 6:55 PM >To: Cullen Jennings; Olle E.Johansson >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] SDES draft posted > >Also I don't have hard stats but of course SDES is what is implemented >today in endpoints and gateways that have a requirement for SRTP which I >think is a large percentage and growing. SDES is also pretty much >interoperable between implementations the main issues that arise are >around best effort SRTP and that fact that sdp-neg (RFC 5939) is not >widely implemented. > >So if SDES, DTLS-SRTP and possibly even RTP are going to be options in >RTCWEB the issue that needs to be clearly specified is the negotiation >mechanism be it RFC 5939 or something else. I don't believe that a >fallback mechanism based on failure and re-try would be acceptable. > >Regards >Andy > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: 26 January 2012 21:04 >> To: Olle E.Johansson >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] SDES draft posted >> >> >> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >> >> >> I'd say it's a fair bet that at least 50% of the SIP UA >> implementations available on the market (by market share, not count of >> implementations) support SRTP with SDES. >> > >> > This is NOT the installed base - it's available on the market. The >> installed base has a very low amount of SRTP implementations that are >> interoperable >> >> Uh, I pretty much disagree with that thought I don't have hard stats I >> can point you at. A large percentage of the deployed endpoints and >> gateways do work with SRTP and I don't see a lot of bugs logged >> against them. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@fluffy.im Fri Jan 27 07:19:15 2012 Return-Path: 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 A212421F85E0 for ; Fri, 27 Jan 2012 07:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 V1-1Roxy8Oij for ; Fri, 27 Jan 2012 07:19:15 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 307D221F85FD for ; Fri, 27 Jan 2012 07:19:15 -0800 (PST) Received: by pbdu7 with SMTP id u7so1458904pbd.31 for ; Fri, 27 Jan 2012 07:19:14 -0800 (PST) Received: by 10.68.211.38 with SMTP id mz6mr14964045pbc.130.1327677554614; Fri, 27 Jan 2012 07:19:14 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id n8sm20698884pbq.7.2012.01.27.07.19.13 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 07:19:13 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 08:19:12 -0700 Message-Id: <34BD2D90-CBE0-4C8E-ACC6-D2A837F2A6DF@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - Blocking SDP operations ? X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 15:19:15 -0000 =20 The basic question is there any limitations on when setLocal and = setRemote can be called.=20 Imagine the case where side A does a createOffer and setLocal and is = waiting for an answer from the far side. Before the answer arrives, a = camera is added to side A and side A wants to send an updated offer that = includes video. Can it do this? can it create a new offer and call = setLocal a second time before receiving the answer from the far side?=20 I have a hard time seeing how this is going to work. Similarly you could = have a case where the camera was removed before the answer had been = received.=20 SDP has some very interesting assumptions and invariants about the = pairing of offers and answers. I think SDP introduces the need for = constraints on how and when setLocal and setRemote can be called by the = JS. I don't have my head around this yet but can you explain what = sequences of operations you think are legal and which aren=92t? From fluffy@fluffy.im Fri Jan 27 07:22:36 2012 Return-Path: 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 1586621F850C for ; Fri, 27 Jan 2012 07:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qzN6ZmHfQw2D for ; Fri, 27 Jan 2012 07:22:35 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86F21F8507 for ; Fri, 27 Jan 2012 07:22:35 -0800 (PST) Received: by dado14 with SMTP id o14so1757801dad.31 for ; Fri, 27 Jan 2012 07:22:35 -0800 (PST) Received: by 10.68.75.132 with SMTP id c4mr15152403pbw.23.1327677755433; Fri, 27 Jan 2012 07:22:35 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id i1sm20672509pbt.19.2012.01.27.07.22.34 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 07:22:34 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 08:22:32 -0700 Message-Id: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - Removing and modifying streams X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 15:22:36 -0000 Imagine that two browsers (A and B) have set up audio and video streams = and are happily chatting away. At this point side A unplugs the camera. = What happens next? how does this get notified ? how does the = PeerConnection end up telling the JS that a new offer / answer exchange = needs to be done to indicate this video stream is gone? It seems like a = callback indicating something like this needed would be an good way to = solve this.=20 I think this come up in another context where the browser wants to = change the the video resolution of frame rate due to congestion control. = We have not sorted out how the congestion control story works but some = of the nicer systems end up significantly renovating video where there = is a substantial change of bandwidth. You can imagine that you are at = home, have 100% of a DSL link for incoming HD video, then someone starts = iTunes and it downloading 3 TV shows and suddenly you go from 100% of = DSL to 25% of DSL.=20 From fluffy@fluffy.im Fri Jan 27 07:33:07 2012 Return-Path: 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 50B3721F85F4 for ; Fri, 27 Jan 2012 07:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1RNHEn-jpUYS for ; Fri, 27 Jan 2012 07:33:06 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7A21F85CD for ; Fri, 27 Jan 2012 07:33:06 -0800 (PST) Received: by dado14 with SMTP id o14so1766899dad.31 for ; Fri, 27 Jan 2012 07:33:06 -0800 (PST) Received: by 10.68.115.232 with SMTP id jr8mr14935084pbb.122.1327678386602; Fri, 27 Jan 2012 07:33:06 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id t5sm20799520pbn.3.2012.01.27.07.33.05 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 07:33:06 -0800 (PST) Sender: Cullen Jennings From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 08:33:04 -0700 Message-Id: <13B61BA8-4E76-4641-B617-485251EC73BB@iii.ca> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] JSEP - Order of SDP and RTP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 15:33:07 -0000 I=92m having a little trouble understanding what the permitted order of = setLocal()/setRemote() are. In the basic call setup case, you have: Caller::setLocal() Callee::setRemote() Callee::setLocal() Caller::setRemote() But then in Section 7.3, you show something different: Responder::setRemote() Responder:setLocal() Initiator::setLocal() Initiator::setRemote() This seems a bit different than SDP which says when you send an offer in = SDP, you need to be able to receive the media described in the offer. = What might happen in some cases is if the RTP from the responder (with = the new SDP parameters) arrives at the initiator before the initiator is = ready to receive it, one way or another the RTP may be rejected. For = example, if initiator has not opened the port in the SDP, the host may = send an ICMP destination unreachable. Some firewalls seeing this from = the side to the outside would use it block future packets on the same = flow for some period of time so even after A did open the port, future = RTP packets could be blocked. Other implementation that received a RTP = packets for a codec that was not yet negotiated would consider it a = serious error and some implementation would close the DTLS connection as = things were clearly messed up. If the web side was gatewaying to SIP = that inspected by SBC, firewalls other other policy devices, they would = almost all discard RTP for codecs that were not yet negotiated in the = SDP and many would terminate the session as an attack. Any thoughts on = how this is going to work in practice? From randell-ietf@jesup.org Fri Jan 27 07:57:39 2012 Return-Path: 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 8879121F8507 for ; Fri, 27 Jan 2012 07:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 F0KA7nrWA5L1 for ; Fri, 27 Jan 2012 07:57:39 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 071FF21F84B2 for ; Fri, 27 Jan 2012 07:57:38 -0800 (PST) Received: from [12.131.214.66] (helo=[10.61.33.151]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqoBG-0004nX-9h for rtcweb@ietf.org; Fri, 27 Jan 2012 09:57:38 -0600 Message-ID: <4F22C971.7050805@jesup.org> Date: Fri, 27 Jan 2012 07:57:37 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> In-Reply-To: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] JSEP - Removing and modifying streams X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 15:57:39 -0000 On 1/27/2012 7:22 AM, Cullen Jennings wrote: > Imagine that two browsers (A and B) have set up audio and video streams and are happily chatting away. At this point side A unplugs the camera. What happens next? how does this get notified ? how does the PeerConnection end up telling the JS that a new offer / answer exchange needs to be done to indicate this video stream is gone? It seems like a callback indicating something like this needed would be an good way to solve this. Yes; we need something associated with a MediaStream to tell the app - this appears to be the 'removetrack' event (3.2.1) on the MediaStreamTrackList. That should trigger the application to renegotiate the connection to tell the other side. I should note this is not removestream on PeerConnection. > > I think this come up in another context where the browser wants to change the the video resolution of frame rate due to congestion control. We have not sorted out how the congestion control story works but some of the nicer systems end up significantly renovating video where there is a substantial change of bandwidth. You can imagine that you are at home, have 100% of a DSL link for incoming HD video, then someone starts iTunes and it downloading 3 TV shows and suddenly you go from 100% of DSL to 25% of DSL. I'll respond to this later today. -- Randell Jesup randell-ietf@jesup.org From fluffy@fluffy.im Fri Jan 27 09:45:20 2012 Return-Path: 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 BA8BF21F864A for ; Fri, 27 Jan 2012 09:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 xW2swlNR8vyQ for ; Fri, 27 Jan 2012 09:45:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B526021F8649 for ; Fri, 27 Jan 2012 09:45:19 -0800 (PST) Received: by iagf6 with SMTP id f6so2925164iag.31 for ; Fri, 27 Jan 2012 09:45:19 -0800 (PST) Received: by 10.42.168.197 with SMTP id x5mr6028398icy.6.1327686319172; Fri, 27 Jan 2012 09:45:19 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id vg9sm4137601igb.4.2012.01.27.09.45.18 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 09:45:18 -0800 (PST) Sender: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <4F1E6DB0.3000709@ericsson.com> Date: Fri, 27 Jan 2012 10:45:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F6E466C-EF8A-4934-93F8-81423F324587@iii.ca> References: <4F1E6DB0.3000709@ericsson.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Analyzing ROAP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 17:45:20 -0000 Here are the answers for ROAP to the questions Magnus sent. As Magnus = asked, if you want to respond to one of these, please change the subject = line so that we can keep track of the threads.=20 A) Glare handling: How does the signaling handle situations where both end-points initiate negotiation, updates or re-negotiate at the same time (i.e. messages pass each other in-flight between the peers)? At a high level both sides realize that each has tried to change the SDP = at the same time, one side =93wins=94 and that side=92s SDP attempted = change is used and the losing side responds to it - the losing side is = informed of an error so it can retry their change at an appropriate = time. At all points both sides have a consistent view of the evolving = state of the SDP offer/answer pair which is critical for there not to be = confusion about matching m-lines in SDP. Each side needs to implement = the same algorithm for determining the winner; the specific algorithm in = ROAP is designed to both work for federated use cases and to be = interoperable with SIP without state on the SIP gateway. B) Can media clipping occur at the initial media establishment? Can it occur at re-negotiations? Initially this shouldn't happen as long as media configuration is in place prior to ICE promotes any candidate pairs. However, at media re-negotiation this could occur. And when you split the transport setup from media negotiation it becomes an issue = again. The only way media clipping can occur at initial establishment is if the = callee decides to send media before a valid ICE candidate has been = found. If the systems wishes to make sure that ICE gets set up an early = as possible, probably the best thing to do is to use an initial offer = with only a data channel possibly marked as inactive and full muxing, so = that that channel can the be used for the media. This will require some = thought about ensuring address privacy and making sure there is a hint = in the API that restricts ICE to relayed candidates until the caller has = answered (or otherwise approved revealing local IP addresses). C) Does the glare handling result in periods where either side is prevented from updating offers? For example is it possible to send a new offer immediately after sending an answer to the peer's Offer? This becomes important as we are likely having declarative media stream information, like the Media Stream ID mapping to SSRCs for each media stream an end-point intends to send. RFC 3264 prohibits sending offers at certain times, such as when you = have an offer outstanding. ROAP maintains those invariants. The support = for final answers allows the callee side to have the necessary control = to indicate if it needs to keep the offer outstanding or not. This is = designed both to meet use cases for WebRTC and to be possible to gateway = to SIP without a media gateway. It may turn out that we want to define = some other set of messages that can say things that are =93safe=94 when = the offer is outstanding, as below (see question D) with ICE candidates, = but a large class of changes can=92t be treated this way without = breaking the 3264 model. D) Is it possible to provide additional ICE candidate's after the initial offer? What level of complexities does that incur? Yes - using an updated offer but as discussed above, there are limits of = when that can be sent. It=92s pretty clear we could extend ROAP to allow = additional ICE candidates at any phase by adding a CANDIDATE message = that can only contain the new candidates. We haven=92t done it because = we=92re uncertain how much additional benefit there is. E) Is it possible to establish transport session which completes ICE processing without negotiating any media, or at least without forcing the user to assign media resource to it (not having to run getUserMedia in the API)? Some versions of WhatWG API did establish a data channel by default, which could be one option but other possibilities do exist. I think the question you=92re asking here is whether I can arrange to = complete ICE for all media streams without actually having to send or = receive any media. =46rom a ROAP perspective, this is principally an SDP = question: the answerer sends a tentative answer with all the streams = marked as =93inactive=94 but provides ICE candidates. This will cause = the offerer and the answerer to do ICE right away, and then when the = callee decides to accept the phone call, a new final answer is sent with = the streams marked as active. Note that as ROAP is separate from the = signaling, the application could be designed such that this can all = happen before the UI alerts the callee in any way.=20 The above should work even without bundling, but obviously if it=92s = performance you=92re after then you also want bundling, so we need to = make sure that the bundle draft supports bundling even if (a) the = streams are inactive and (b) I eventually reject one or more of the = streams. I think this is probably true, but we need to check it. The = advantage of this is that you then don=92t need to worry about doing = unnecessary ICEs for media channels which you don=92t end up using. If = someone offers Audio and Video and we don=92t bundle, then I have to do = ICE on both, even if I eventually only take Audio. However, if we know = we=92re bundling here, then the ICE cost is the same regardless. The answer to question G also sheds some light on this question F) How does one support forking, and specifically can one deal with; - F1) Parallel forking? I.e. deal with multiple answers to a given offer and establish multiple flows? We can either choose Same as SIP or not allow this. I don=92t care and = it does not change ROAP.=20 - F2) Sequential/Serial Forking? i.e. receive one answer and later get a second answer to the same initial offer and use that to replace the first? Yes, this is legal, same as in SIP. This is just the simple case of the = final answers replaces any existing provisional answers.=20 G) How does the proposal attempt to improve the time until media is negotiated and can flow between the peers. So, as answered in (E) above, you can get ICE going prior to having the = callee agree to answer, which helps a lot. There are a number of optimizations available beyond that: 1) TURN can start whenever the JS application wishes including starting = when the page is loaded or when a user opens a dialog to select which = other party they wish to communicate with. [Though we probably need some = new API support for this].=20 2) The offerer can offer only a data channel then later add voice and = video, thus allowing parallelism between the ICE setup and the = authorization dialog. Obviously you=92d want to use bundle here, which = imposes a requirement on the bundle draft that you be able to negotiate = use of bundle even if initially you only had one stream and to add = streams to the bundle later. The current bundle draft looks like it = supports this. Both of these optimizations are designed to set up a speculative channel = that can then be quickly upgraded to a media channel with a signaling RT = (actually one-way signaling and then media flows immediately in the = opposite direction.) Note that you can actually start (2) even if the = client hasn=92t indicated they want to make a call, if you=92re going to = be really aggressive. This only makes sense, of course, if there is a = high probability that they will call this particular person. In most cases, using this type of approach would allow the callee to = start sending media as soon as the user had accepted the call with no = media clipping. And once the callee had accepted the call, we would have = the one way latency of notifying the caller of this and then the caller = can send media.=20 H) What explicit indication or other hints can the upper layer get from the proposal get that this might be a suitable time to perform a re-negotiation or is it automatically triggered by the browser core? Currently ROAP assumes an API where the browser calls a callback in the = JS to tell it a new offer is ready and pass the new offer to the JS = application.=20 An alternative design would be that the callback only indicates that = something has changed and that the application needs to prompt the = browser core to generate a new offer. [Note that we=92ll need to be = careful with the API design to make sure that odd stuff doesn=92t happen = if the application is slow about requesting the offer, so the events = pile up.] This would be a little closer to how JSEP works and still work = fine in ROAP, since it would put the state changes at the control of the = app, so it seems like a fine alternative to consider.=20 From juberti@google.com Fri Jan 27 11:11:05 2012 Return-Path: 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 EEDD321F8664 for ; Fri, 27 Jan 2012 11:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 ZMwmpES+w0aN for ; Fri, 27 Jan 2012 11:11:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D01AA21F8589 for ; Fri, 27 Jan 2012 11:11:03 -0800 (PST) Received: by iagf6 with SMTP id f6so3020932iag.31 for ; Fri, 27 Jan 2012 11:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=BuyLwPnUO31Iv5url8sLcMzZuWV99JueovRyop1ys+E=; b=iYS/xPGqXjXmtwmbl6EaAKIts2qkR5PsnlSUzBkcJPjnOa7j4+rUXNciKcwN3pt8ZR hpmEYyJvu/XwC/gjEw0fGpggEgmv+7nTj57HjGsHzGBJyDmbs3moMcmS/vsCr7IV5Cii jblNfaZoKynga/aJGNRZeY0Yrwy6hbWWdGFN4= Received: by 10.43.51.66 with SMTP id vh2mr6036553icb.39.1327691463417; Fri, 27 Jan 2012 11:11:03 -0800 (PST) Received: by 10.43.51.66 with SMTP id vh2mr6036543icb.39.1327691463328; Fri, 27 Jan 2012 11:11:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 11:10:43 -0800 (PST) In-Reply-To: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> References: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> From: Justin Uberti Date: Fri, 27 Jan 2012 14:10:43 -0500 Message-ID: To: Cullen Jennings X-System-Of-Record: true Content-Type: multipart/alternative; boundary=bcaec5299be90b04a404b7874243 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Modifying the SDP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:11:05 -0000 --bcaec5299be90b04a404b7874243 Content-Type: text/plain; charset=UTF-8 Good questions. Inline. On Thu, Jan 26, 2012 at 3:41 PM, Cullen Jennings wrote: > > I've like to understand what parts of the SDP the JS app can change > between the createOffer and the setLocal. And similarly the createAnswer > and setLocal? > Regarding what the application can change in the offer/answer it generates and supplies as its own local description, I think most things should be fair game, provided the offer or answer still properly adheres to the relevant RFCs (e.g. answer must have a single a=crypto: line, etc) > > So for some specific examples - say the SDP had a v4 and v6 address - > could the JS remove one? Candidates aren't part of the session descriptions; the ICE mechanism runs separately. Even so, the JS could eat generated or received v4/v6 candidates. > can it change the SSRC? yes. > ports ? no, since ICE is controlled separately. > Can it remove a codec? yes. > what can it do to things like bandwidth limits? If you mean "b:", it could add its own, or change the generated value. > Can it change the video resolution to a smaller resolution? any limits on > this? can it change the aspect ratio? can it change to square pixels? > frame rate? Can it change the profile information for a video codec? > I don't think we've defined exactly how we intend resolution negotiation to work in WebRTC (RFC 6236?) so I'm going to defer on these questions for now. That said, I think it should be possible to control the requested resolution. > > What parts of SDP is the createOffer allowed to use - can it use any valid > SDP extension? If the browser wants to modify the SDP to use some SDP > extension, what extensions does the browser need to be able to support in > setLocal? > There is a general question of what SDP/RTP features must be supported for a conformant WebRTC implementation. http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-01 covers some of this. createOffer will generate SDP that is compliant with the baseline requirements, and may include optional features that the implementation knows it supports. If the application wants to modify the SDP, it cannot add optional features that are not part of the baseline (unless it has some caps or similar mechanism to determine browser support). > > If due to some prior knowledge such as a previous session on the same > browser, the application knows that the browser supports what it needs, can > the JS just create it own offer and never call createOffer but just > directly call setLocalSDP ? yes. > This might seem sort of far fetched but if the JS was going to talk to a > conference bridge for a game that only supported G.711, it might be > reasonable for the JS to just create an offer that was only 711 and if you > were on a browser that did not support that, it was never going to work > anyways. Anyways, is this sort of use of the API allowed ? > sure. If you can generate a compatible session description through some other mechanism, that is fine. There are a number of scenarios where I think this makes sense (including Matthew's example of pushing session state back down to resurrect a call). > > Related to this is the issues of what sort of errors will be reported on a > setLocal. I don't really care how they are reported, exceptions, error > codes, whatever - but I would like to see a list of all the different > error. This seems pretty important to decide how complex the JS code needs > to be to decide to recover from these error and also will impact how > flexible the mechanism ends up being. What are you thinking of as the list > of errors? > Agree this is important, but sort of beyond the scope of an -00. Anyway, I think there are a few classes of errors we could return: - invalid-syntax (malformed SDP) - invalid-state (offer or answer at wrong time) - invalid-content (SDP was invalid, e.g. conflicting payload types) - unsupported-codecs (desc contains unknown codec) - unsupported-crypto (desc contains unknown crypto parameters) - insufficient-resources (too many decoders, or decoders already in use) - invalid-format (bad audio sampling rate, or unsupported video resolution) - unsupported-option (app tried to use a SDP option the impl doesn't support) This is just an initial list, and while I'm sure there are more, I'm not sure how many are recoverable. I imagine that most of these represent programming errors, and only things like insufficient-resources or invalid-format would actually involve retry behavior. We also need to keep in mind that exposing very granular error info could allow this to be used for fingerprinting. (The same goes for setRemoteDescription, of course, and affects probably any API we could choose.) > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec5299be90b04a404b7874243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good questions. Inline.

On Thu, Jan 26, 2= 012 at 3:41 PM, Cullen Jennings <fluffy@iii.ca> wrote:

I've like to understand what parts of the SDP the JS app can change bet= ween the createOffer and the setLocal. And similarly the createAnswer and s= etLocal?

Regarding what the application= can change in the offer/answer it generates and supplies as its own local = description, I think most things should be fair game, provided the offer or= answer still properly adheres to the relevant RFCs (e.g. answer must have = a single a=3Dcrypto: line, etc)

So for some specific examples - say the SDP had a v4 and v6 address - could= the JS remove one?

Candidates aren't p= art of the session descriptions; the ICE mechanism runs separately. Even so= , the JS could eat generated or received v4/v6 candidates.
=C2=A0
can it change the SSRC?

yes.
=C2=A0
ports ?

no, since ICE is controlled separat= ely.
=C2=A0
Can it remove a = codec?

yes.=C2=A0
=C2=A0
what can it do to things like bandwidth limits?

If you mean "b:", it could add its own, or change the genera= ted value.
=C2=A0
Can it chan= ge the video resolution to a smaller resolution? any limits on this? can it= change the aspect ratio? can it change to square pixels? =C2=A0frame rate?= Can it change the profile information for a video codec?

I don't think we've defined exactl= y how we intend resolution negotiation to work in WebRTC (RFC 6236?) so I&#= 39;m going to defer on these questions for now. That said, I think it shoul= d be possible to control the requested resolution.=C2=A0

What parts of SDP is the createOffer allowed to use - can it use any valid = SDP extension? If the browser wants to modify the SDP to use some SDP exten= sion, what extensions does the browser need to be able to support in setLoc= al?

There is a general question of what SDP/RT= P features must be supported for a conformant WebRTC implementation.=C2=A0<= a href=3D"http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-01">http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-01 covers some of this= .

createOffer will generate SDP that is compliant with th= e baseline requirements, and may include optional features that the impleme= ntation knows it supports. If the application wants to modify the SDP, it c= annot add optional features that are not part of the baseline (unless it ha= s some caps or similar mechanism to determine browser support).

If due to some prior knowledge such as a previous session on the same brows= er, the application knows that the browser supports what it needs, can the = JS just create it own offer and never call createOffer but just directly ca= ll setLocalSDP ?

yes.
=C2=A0
This might seem sort of far fetched but if the JS was going to talk to = a conference bridge for a game that only supported G.711, it might be reaso= nable for the JS to just create an offer that was only 711 and if you were = on a browser that did not support that, it was never going to work anyways.= Anyways, is this sort of use of the API allowed ?

sure. If you can generate a compatible ses= sion description through some other mechanism, that is fine. There are a nu= mber of scenarios where I think this makes sense (including Matthew's e= xample of pushing session state back down to resurrect a call).

=C2=A0

Related to this is the issues of what sort of errors will be reported on a = setLocal. I don't really care how they are reported, exceptions, error = codes, whatever - but I would like to see a list of all the different error= . This seems pretty important to decide how complex the JS code needs to be= to decide to recover from these error and also will impact how flexible th= e mechanism ends up being. What are you thinking of as the list of errors?<= br>

Agree this is important, but sort of beyon= d the scope of an -00. Anyway, I think there are a few classes of errors we= could return:
- invalid-syntax (malformed SDP)
- inval= id-state (offer or answer at wrong time)
- invalid-content (SDP was invalid, e.g. conflicting payload types)
- unsupported-codecs (desc contains unknown codec)
- unsu= pported-crypto (desc contains unknown crypto parameters)
- insuff= icient-resources (too many decoders, or decoders already in use)
- invalid-format (bad audio sampling rate, or unsupported video resolu= tion)
- unsupported-option (app tried to use a SDP option the imp= l doesn't support)

This is just an initial lis= t, and while I'm sure there are more, I'm not sure how many are rec= overable. I imagine that most of these represent programming errors, and on= ly things like insufficient-resources or invalid-format would actually invo= lve retry behavior. We also need to keep in mind that exposing very granula= r error info could allow this to be used for fingerprinting.
(The same goes for setRemoteDescription, of course, and affects probab= ly any API we could choose.)
=C2=A0
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec5299be90b04a404b7874243-- From juberti@google.com Fri Jan 27 11:28:30 2012 Return-Path: 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 BC6D721F85EA for ; Fri, 27 Jan 2012 11:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.696 X-Spam-Level: X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 xCYaS0sE3x5w for ; Fri, 27 Jan 2012 11:28:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5A9421F85E0 for ; Fri, 27 Jan 2012 11:28:29 -0800 (PST) Received: by iagf6 with SMTP id f6so3039358iag.31 for ; Fri, 27 Jan 2012 11:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=C1ZRhU1A3hBD9flF3HujJzICOVmWIzakGxR+07QhOVQ=; b=rvMzyNgin3oNo9Op+z4OC6TX1uu1u8cjpBqObCD0NIL0hTWPHbESpq63FAcChkLReZ tU8PcoQgGLKDS/ecpA3hx0o4ZxdyXA8+c1MKz2yYa1vKh5OWOOKdXhwi/idkPa6O3PlX hxTGHH/Ei9i+lOqY+9iKo5CH/Ssd54qOZ/91s= Received: by 10.50.194.199 with SMTP id hy7mr8104893igc.26.1327692509482; Fri, 27 Jan 2012 11:28:29 -0800 (PST) Received: by 10.50.194.199 with SMTP id hy7mr8104884igc.26.1327692509397; Fri, 27 Jan 2012 11:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 11:28:09 -0800 (PST) In-Reply-To: <34BD2D90-CBE0-4C8E-ACC6-D2A837F2A6DF@iii.ca> References: <34BD2D90-CBE0-4C8E-ACC6-D2A837F2A6DF@iii.ca> From: Justin Uberti Date: Fri, 27 Jan 2012 14:28:09 -0500 Message-ID: To: Cullen Jennings X-System-Of-Record: true Content-Type: multipart/alternative; boundary=14dae9399c1f64c33b04b7878070 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Blocking SDP operations ? X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:28:30 -0000 --14dae9399c1f64c33b04b7878070 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2012 at 10:19 AM, Cullen Jennings wrote: > > The basic question is there any limitations on when setLocal and setRemot= e > can be called. > > Imagine the case where side A does a createOffer and setLocal and is > waiting for an answer from the far side. Before the answer arrives, a > camera is added to side A and side A wants to send an updated offer that > includes video. Can it do this? can it create a new offer and call setLoc= al > a second time before receiving the answer from the far side? > Surely it can, but it means the app protocol needs to have some notion of sequence number, and in the case that the answer that is received is an answer to the initial offer, it gets a bit messy. setLocalDescription needs to be called again with the initial offer to roll the local description back to the original state, and then setRemoteDescription will be called with the answer, and lastly setLocalDescription will be called with the second offer, as a new offer-answer exchanged is kicked off. In short, it's definitely possible, but I imagine most app signaling protocols won't support this. > > I have a hard time seeing how this is going to work. Similarly you could > have a case where the camera was removed before the answer had been > received. > > SDP has some very interesting assumptions and invariants about the pairin= g > of offers and answers. I think SDP introduces the need for constraints on > how and when setLocal and setRemote can be called by the JS. I don't have > my head around this yet but can you explain what sequences of operations > you think are legal and which aren=E2=80=99t? > I think the general rules are: - OFFERs need to always be followed by an ANSWER from the other side - ANSWERs must be preceded by an OFFER from the remote side - You can update your own OFFER prior to getting a remote ANSWER, if you're prepared to handle the hard case - An ANSWER can also be updated by another ANSWER from the remote side (needs more details here; the first ANSWER most likely needs to be marked as provisional) Simple cases: setLocal(OFFER) -> setRemote(ANSWER) setRemote(OFFER) -> setLocal(ANSWER) Simple error cases: setLocal(OFFER) -> setRemote(OFFER) setRemote(OFFER) -> setLocal(OFFER) setLocal(ANSWER) setRemote(ANSWER) Early media case: setLocal(OFFER) -> setRemote(ANSWER1) -> setRemote(ANSWER2) // probably need some sort of "moreToFollow" on ANSWER1 Case above, easy path: setLocal(OFFER1) -> setLocal(OFFER2) -> setRemote(ANSWER2) Case above, complex path: setLocal(OFFER1) -> setLocal(OFFER2) -> setLocal(OFFER1) -> setRemote(ANSWER1) -> setLocal(OFFER2) -> setRemote(ANSWER2) Does this match what you're thinking? > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae9399c1f64c33b04b7878070 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2012 at 10:19 AM, Cullen= Jennings <fluffy@iii= .ca> wrote:

The basic question is there any limitations on when setLocal and setRemote = can be called.

Imagine the case where side A does a createOffer and setLocal and is waitin= g for an answer from the far side. Before the answer arrives, a camera is a= dded to side A and side A wants to send an updated offer that includes vide= o. Can it do this? can it create a new offer and call setLocal a second tim= e before receiving the answer from the far side?

Surely it can, but it means the app protoc= ol needs to have some notion of sequence number, and in the case that the a= nswer that is received is an answer to the initial offer, it gets a bit mes= sy. setLocalDescription needs to be called again with the initial offer to = roll the local description back to the original state, and then setRemoteDe= scription will be called with the answer, and lastly setLocalDescription wi= ll be called with the second offer, as a new offer-answer exchanged is kick= ed off.

In short, it's definitely possible, but I imagine m= ost app signaling protocols won't support this.

I have a hard time seeing how this is going to work. Similarly you could ha= ve a case where the camera was removed before the answer had been received.=

SDP has some very interesting assumptions and invariants about the pairing = of offers and answers. I think SDP introduces the need for constraints on h= ow and when setLocal and setRemote can be called by the JS. I don't hav= e my head around this yet but can you explain what sequences of operations = you think are legal and which aren=E2=80=99t?

I think the general rules are:
-= OFFERs need to always be followed by an ANSWER from the other side
- ANSWERs must be preceded by an OFFER from the remote side
- You can update your own OFFER prior to getting a remote ANSWER, if you= 9;re prepared to handle the hard case
- An ANSWER can also be upd= ated by another ANSWER from the remote side (needs more details here; the f= irst ANSWER most likely needs to be marked as provisional)

Simple cases:
setLocal(OFFER) -> setRemote= (ANSWER)=C2=A0
setRemote(OFFER) -> setLocal(ANSWER)
=
Simple error cases:
setLocal(OFFER) -> setRemot= e(OFFER)
setRemote(OFFER) -> setLocal(OFFER)
setLocal(ANSWER)
setRemote(ANSWER)

Early media case:
setLocal(OFFER) -> setRemote(ANSWER1) -> setRemote(ANSWER2) =C2=A0/= / probably need some sort of "moreToFollow" on ANSWER1

Case above, easy path:
setLocal(OFFER1) ->= setLocal(OFFER2) -> setRemote(ANSWER2)

Case ab= ove, complex path:
setLocal(OFFER1) -> setLocal(OFFER2) -> = setLocal(OFFER1) -> setRemote(ANSWER1) -> setLocal(OFFER2) -> setR= emote(ANSWER2)

Does this match what you're thinking?




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--14dae9399c1f64c33b04b7878070-- From juberti@google.com Fri Jan 27 11:41:16 2012 Return-Path: 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 99E6E21F863E for ; Fri, 27 Jan 2012 11:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.722 X-Spam-Level: X-Spam-Status: No, score=-102.722 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 c8lVKyF-gJzz for ; Fri, 27 Jan 2012 11:41:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D297A21F863B for ; Fri, 27 Jan 2012 11:41:15 -0800 (PST) Received: by iagf6 with SMTP id f6so3052638iag.31 for ; Fri, 27 Jan 2012 11:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=7Qr2ECtf2UG4xe54id1+DMFbhV+nwj6L5o6zdSn+9/k=; b=ZTIbdAlpjTE0RB9+xKG4GLnu7lwqv5Hkbcd5q6EIpXzrWm9PXzPkIFacZQnvVlWwi4 KoIpaRAP2uOzfI0JG9p8c4vBguXFGGiGCabgyEfkuG+oHS3rNSv73ggoJYZheqIIgDS2 8L3/3H1+tcZHQZ43v8NAGKkoM8F5EwK5VKGh0= Received: by 10.42.175.5 with SMTP id ay5mr6178990icb.47.1327693275434; Fri, 27 Jan 2012 11:41:15 -0800 (PST) Received: by 10.42.175.5 with SMTP id ay5mr6178979icb.47.1327693275307; Fri, 27 Jan 2012 11:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 11:40:55 -0800 (PST) In-Reply-To: <13B61BA8-4E76-4641-B617-485251EC73BB@iii.ca> References: <13B61BA8-4E76-4641-B617-485251EC73BB@iii.ca> From: Justin Uberti Date: Fri, 27 Jan 2012 14:40:55 -0500 Message-ID: To: Cullen Jennings X-System-Of-Record: true Content-Type: multipart/alternative; boundary=90e6ba6e8f380b9ff504b787aedc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Order of SDP and RTP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:41:16 -0000 --90e6ba6e8f380b9ff504b787aedc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2012 at 10:33 AM, Cullen Jennings wrote: > > I=E2=80=99m having a little trouble understanding what the permitted orde= r of > setLocal()/setRemote() are. > In the basic call setup case, you have: > > Caller::setLocal() > Callee::setRemote() > Callee::setLocal() > Caller::setRemote() > > But then in Section 7.3, you show something different: > > > Responder::setRemote() > Responder:setLocal() > Initiator::setLocal() > Initiator::setRemote() > > > This seems a bit different than SDP which says when you send an offer in > SDP, you need to be able to receive the media described in the offer. Wha= t > might happen in some cases is if the RTP from the responder (with the ne= w > SDP parameters) arrives at the initiator before the initiator is ready to > receive it, one way or another the RTP may be rejected. For example, if > initiator has not opened the port in the SDP, the host may send an ICMP > destination unreachable. Some firewalls seeing this from the side to the > outside would use it block future packets on the same flow for some perio= d > of time so even after A did open the port, future RTP packets could be > blocked. Other implementation that received a RTP packets for a codec tha= t > was not yet negotiated would consider it a serious error and some > implementation would close the DTLS connection as things were clearly > messed up. If the web side was gatewaying to SIP that inspected by SBC, > firewalls other other policy devices, they would almost all discard RTP f= or > codecs that were not yet negotiated in the SDP and many would terminate t= he > session as an attack. Any thoughts on how this is going to work in practi= ce? > The thinking here was to allow easy handling of the case where the remote side rejects the request, i.e. it becomes a no-op. I was also thinking that in the add-source case, each offer/answer exchange would add a unidirectional stream (from offerer to answerer), so the race you mention above would be less of an issue. That being said, I see your point and it's not hard to change the behavior around to be like 7.1. It just means the old description needs to be kept around and re-installed in the event the offer is rejected (which is admittedly a corner case). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --90e6ba6e8f380b9ff504b787aedc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2012 at 10:33 AM, Cullen= Jennings <fluffy@iii= .ca> wrote:

I=E2=80=99m having a little trouble understanding what the permitted order = of setLocal()/setRemote() are.
In the basic call setup case, you have:

Caller::setLocal()
Callee::setRemote()
Callee::setLocal()
Caller::setRemote()

But then in Section 7.3, you show something different:


Responder::setRemote()
Responder:setLocal()
Initiator::setLocal()
Initiator::setRemote()


This seems a bit different than SDP which says when you send an offer in SD= P, you need to be able to receive the media described in the offer. What mi= ght =C2=A0happen in some cases is if the RTP from the responder (with the n= ew SDP parameters) arrives at the initiator before the initiator is ready t= o receive it, one way or another the RTP may be rejected. For example, if i= nitiator has not opened the port in the SDP, the host may send an ICMP dest= ination unreachable. Some firewalls seeing this from the side to the outsid= e would use it block future packets on the same flow for some period of tim= e so even after A did open the port, future RTP packets could be blocked. O= ther implementation that received a RTP packets for a codec that was not ye= t negotiated would consider it a serious error and some implementation woul= d close the DTLS connection as things were clearly messed up. If the web si= de was gatewaying to SIP that inspected by SBC, firewalls other other polic= y devices, they would almost all discard RTP for codecs that were not yet n= egotiated in the SDP and many would terminate the session as an attack. Any= thoughts on how this is going to work in practice?

The thinking here was to allow easy handli= ng of the case where the remote side rejects the request, i.e. it becomes a= no-op. I was also thinking that in the add-source case, each offer/answer = exchange would add a unidirectional stream (from offerer to answerer), so t= he race you mention above would be less of an issue.=C2=A0

That being said, I see your point and it's not hard= to change the behavior around to be like 7.1. It just means the old descri= ption needs to be kept around and re-installed in the event the offer is re= jected (which is admittedly a corner case).

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--90e6ba6e8f380b9ff504b787aedc-- From juberti@google.com Fri Jan 27 11:49:26 2012 Return-Path: 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 1741021F8656 for ; Fri, 27 Jan 2012 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 7VX2FBdc0vlO for ; Fri, 27 Jan 2012 11:49:25 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1642E21F8652 for ; Fri, 27 Jan 2012 11:49:25 -0800 (PST) Received: by iagf6 with SMTP id f6so3061488iag.31 for ; Fri, 27 Jan 2012 11:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=6mX6IIVcLhVIYYn8UlWQqJYhxsmOdr3CaxSOwQ758wM=; b=nCxLJodwjOWaE+kunTGW/zh4TwyBS1DYGmi0/5z0XZbeL5Bf0rmYqGBF1vJ8GKzAEY MsTIW8Qcj4gBSEGeNO6eGhVdng8sjejJv9dkvEBjTpDu6C6IugVFz4qQ1AbaGDOPUvVw xFawhUM5jRe8ffZJ5lKqdk+wTFxDVy9vOnQx8= Received: by 10.43.51.66 with SMTP id vh2mr6129493icb.39.1327693764748; Fri, 27 Jan 2012 11:49:24 -0800 (PST) Received: by 10.43.51.66 with SMTP id vh2mr6129484icb.39.1327693764626; Fri, 27 Jan 2012 11:49:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 11:49:03 -0800 (PST) In-Reply-To: <4F22C971.7050805@jesup.org> References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> <4F22C971.7050805@jesup.org> From: Justin Uberti Date: Fri, 27 Jan 2012 14:49:03 -0500 Message-ID: To: Randell Jesup X-System-Of-Record: true Content-Type: multipart/alternative; boundary=bcaec5299be9360ab104b787cb67 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Removing and modifying streams X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:49:26 -0000 --bcaec5299be9360ab104b787cb67 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 27, 2012 at 10:57 AM, Randell Jesup wrote: > On 1/27/2012 7:22 AM, Cullen Jennings wrote: > >> Imagine that two browsers (A and B) have set up audio and video streams >> and are happily chatting away. At this point side A unplugs the camera. >> What happens next? how does this get notified ? how does the PeerConnection >> end up telling the JS that a new offer / answer exchange needs to be done >> to indicate this video stream is gone? It seems like a callback indicating >> something like this needed would be an good way to solve this. >> > > Yes; we need something associated with a MediaStream to tell the app - > this appears to be the 'removetrack' event (3.2.1) on the > MediaStreamTrackList. That should trigger the application to renegotiate > the connection to tell the other side. I should note this is not > removestream on PeerConnection. Agree. > > > >> I think this come up in another context where the browser wants to change >> the the video resolution of frame rate due to congestion control. We have >> not sorted out how the congestion control story works but some of the nicer >> systems end up significantly renovating video where there is a substantial >> change of bandwidth. You can imagine that you are at home, have 100% of a >> DSL link for incoming HD video, then someone starts iTunes and it >> downloading 3 TV shows and suddenly you go from 100% of DSL to 25% of DSL. >> > > I'll respond to this later today. > The encoder already is going to get feedback from the bandwidth estimator to tell it to adjust its output bitrate, typically by changing QP. In cases where a suitable QP cannot be maintained, I imagine the encoder pipeline will internally start reducing resolution and framerate. While I generally like the idea of the app being able to control these sorts of things, I think we'd need to be able to expose more info to the app (e.g. QP values) in order to allow it to do a good job. Note that a similar issue exists where the app wants to reduce resolution or framerate due to CPU overload, and should probably be solved similarly. --bcaec5299be9360ab104b787cb67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2012 at 10:57 AM, Randel= l Jesup <ran= dell-ietf@jesup.org> wrote:
On 1/27/2012 7:22 AM, Cullen Jennings wrote:
Imagine that two browsers (A and B) =C2=A0have set up audio and video strea= ms and are happily chatting away. At this point side A unplugs the camera. = What happens next? how does this get notified ? how does the PeerConnection= end up telling the JS that a new offer / answer exchange needs to be done = to indicate this video stream is gone? It seems like a callback indicating = something like this needed would be an good way to solve this.

Yes; we need something associated with a MediaStream to tell the app - this= appears to be the 'removetrack' event (3.2.1) on the MediaStreamTr= ackList. =C2=A0That should trigger the application to renegotiate the conne= ction to tell the other side. =C2=A0I should note this is not removestream = on PeerConnection.

Agree.=C2=A0



I think this come up in another context where the browser wants to change t= he the video resolution of frame rate due to congestion control. We have no= t sorted out how the congestion control story works but some of the nicer s= ystems end up significantly renovating video where there is a substantial c= hange of bandwidth. You can imagine that you are at home, have 100% of a DS= L link for incoming HD video, then someone starts iTunes and it downloading= 3 TV shows and suddenly you go from 100% of DSL to 25% of DSL.

I'll respond to this later today.

The encoder alr= eady is going to get feedback from the bandwidth estimator to tell it to ad= just its output bitrate, typically by changing QP. In cases where a suitabl= e QP cannot be maintained, I imagine the encoder pipeline will internally s= tart reducing resolution and framerate.

While I generally like the idea of the app being able t= o control these sorts of things, I think we'd need to be able to expose= more info to the app (e.g. QP values) in order to allow it to do a good jo= b.

Note that a similar issue exists where the app wants to= reduce resolution or framerate due to CPU overload, and should probably be= solved similarly.

--bcaec5299be9360ab104b787cb67-- From juberti@google.com Fri Jan 27 11:51:42 2012 Return-Path: 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 9360621F865D for ; Fri, 27 Jan 2012 11:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 ch5I3gP0mb4n for ; Fri, 27 Jan 2012 11:51:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D509121F8664 for ; Fri, 27 Jan 2012 11:51:41 -0800 (PST) Received: by iagf6 with SMTP id f6so3064527iag.31 for ; Fri, 27 Jan 2012 11:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=XyGURqBr+NZRvQbz6x+Z9tK/A/9arrT/kRtytreAP8Y=; b=Z06BOBTWp5oR4c6TTBsJIc7PzLKTP4QxV6oVK8sG4oyf2rhGGh+4pU4quEmlhhw7Rb ornSXOvEkXV8Ha1+E2QKLxqK+FsSCmDj+Jyy0C3qEfwfjOzcP/EIr4HKLawz/EJntnwS ap7IDrzpzBFcoF5EGtkfE6qrZY4e+eUK4hwYs= Received: by 10.42.175.5 with SMTP id ay5mr6204468icb.47.1327693901408; Fri, 27 Jan 2012 11:51:41 -0800 (PST) Received: by 10.42.175.5 with SMTP id ay5mr6204462icb.47.1327693901339; Fri, 27 Jan 2012 11:51:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 11:51:21 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Fri, 27 Jan 2012 14:51:21 -0500 Message-ID: To: Cullen Jennings X-System-Of-Record: true Content-Type: multipart/alternative; boundary=90e6ba6e8f385c1a9104b787d3dd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - When do resource reservations happen ? X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:51:42 -0000 --90e6ba6e8f385c1a9104b787d3dd Content-Type: text/plain; charset=UTF-8 Resources are allocated on setLocal/RemoteDescription(). createOffer/Answer() do not change state. On Thu, Jan 26, 2012 at 2:04 PM, Cullen Jennings wrote: > > Here is one question about JSEP that I hope you can respond to quickly, > it's really just a clarification on how JSEP works but it seems very > important to really analyzing how JSEP will work. > > A lot of operations require allocating resources, such as UDP ports, DSPs, > etc. Are those allocated when you invoke createOffer() or when you invoke > setLocalDescription()? So, say you only have one DSP, if someone calls > createOffer() in tab A, does that make the DSP unavailable in tab B? > > Thanks, Cullen > > --90e6ba6e8f385c1a9104b787d3dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Resources are allocated on setLocal/RemoteDescription(). createOffer/Answer= () do not change state.

On Thu, Jan 26, 2= 012 at 2:04 PM, Cullen Jennings <fluffy@iii.ca> wrote:

Here is one question about JSEP that I hope you can respond to quickly, it&= #39;s really just a clarification on how JSEP works but it seems very impor= tant to really analyzing how JSEP will work.

A lot of operations require allocating resources, such as UDP ports, DSPs, = etc. Are those allocated when you invoke createOffer() or when you invoke s= etLocalDescription()? So, say you only have one DSP, if someone calls creat= eOffer() in tab A, does that make the DSP unavailable in tab B?

Thanks, Cullen


--90e6ba6e8f385c1a9104b787d3dd-- From ekr@rtfm.com Fri Jan 27 11:59:28 2012 Return-Path: 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 B072E21F85BD for ; Fri, 27 Jan 2012 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.896 X-Spam-Level: X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 JjiheExM54xl for ; Fri, 27 Jan 2012 11:59:28 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEB021F8655 for ; Fri, 27 Jan 2012 11:59:28 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1622049vbb.31 for ; Fri, 27 Jan 2012 11:59:27 -0800 (PST) Received: by 10.52.95.233 with SMTP id dn9mr3694556vdb.7.1327694367136; Fri, 27 Jan 2012 11:59:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Fri, 27 Jan 2012 11:58:46 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> From: Eric Rescorla Date: Fri, 27 Jan 2012 11:58:46 -0800 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Modifying the SDP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 19:59:28 -0000 On Fri, Jan 27, 2012 at 11:10 AM, Justin Uberti wrote: > sure. If you can generate a compatible session description through some > other mechanism, that is fine. There are a number of scenarios where I think > this makes sense (including Matthew's example of pushing session state back > down to resurrect a call). I wonder if this has API implications. What I mean here is: Does the API (capabilities, I guess) need to provide enough information that one can independently write myCreateOffer() in JS? Or do I generally need to use createOffer(), but under some limited circumstances I can get away with taking an extant offer, modifying it, and pushing it down? -Ekr From juberti@google.com Fri Jan 27 12:03:57 2012 Return-Path: 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 528E121F8670 for ; Fri, 27 Jan 2012 12:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 ijpK1zMofjRk for ; Fri, 27 Jan 2012 12:03:56 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9ACF21F8663 for ; Fri, 27 Jan 2012 12:03:56 -0800 (PST) Received: by iagf6 with SMTP id f6so3077654iag.31 for ; Fri, 27 Jan 2012 12:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=qEJuwm5fzwapXzUaNWiwB4jpvDif6c4O4VNI7ZaM8jQ=; b=0zSJchDW936256IHuR/nufvDaEQzdjlXx7QMebGz84P0MWM1hqlHbvf1Li0v9aS3OU JlymNmXIrHHpdA7Dsxn808X10lCQWEWRRpBmjbQGxNpBuK5VoU+MttQaMp1X6jlcvr3n NnT4j5c4xuQ3hEo/cS5mcHszIw9nZmKAXbCRU= Received: by 10.50.135.1 with SMTP id po1mr7782540igb.26.1327694636428; Fri, 27 Jan 2012 12:03:56 -0800 (PST) Received: by 10.50.135.1 with SMTP id po1mr7782533igb.26.1327694636352; Fri, 27 Jan 2012 12:03:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 12:03:36 -0800 (PST) In-Reply-To: References: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> From: Justin Uberti Date: Fri, 27 Jan 2012 15:03:36 -0500 Message-ID: To: Eric Rescorla X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f6432c22b852604b787ff62 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Modifying the SDP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 20:03:57 -0000 --e89a8f6432c22b852604b787ff62 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 27, 2012 at 2:58 PM, Eric Rescorla wrote: > On Fri, Jan 27, 2012 at 11:10 AM, Justin Uberti > wrote: > > sure. If you can generate a compatible session description through some > > other mechanism, that is fine. There are a number of scenarios where I > think > > this makes sense (including Matthew's example of pushing session state > back > > down to resurrect a call). > > I wonder if this has API implications. What I mean here is: > Does the API (capabilities, I guess) need to provide enough information > that > one can independently write myCreateOffer() in JS? No. We might decide we want to support that in the future, but for now, that's not a requirement. > Or do I generally need to > use createOffer(), but under some limited circumstances I can get away > with taking an extant offer, modifying it, and pushing it down? > > More or less. In addition to rehydrating calls, you can use a previously generated offer to rollback to a previous state (perhaps if the remote side rejected a session modification). Of course, if you really know what you're doing, you could generate your own offer based on what you think you know about the browser and the mandatory-to-implement WebRTC SDP features (e.g. Cullen's G.711 example). --e89a8f6432c22b852604b787ff62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2012 at 2:58 PM, Eric Re= scorla <ekr@rtfm.com> wrote:
On Fri, Jan 27, 2012 at 11:10 AM, Justin Uberti <juberti@google.com> wrote:
> sure. If you can generate a compatible session description through som= e
> other mechanism, that is fine. There are a number of scenarios where I= think
> this makes sense (including Matthew's example of pushing session s= tate back
> down to resurrect a call).

I wonder if this has API implications. What I mean here is:
Does the API (capabilities, I guess) need to provide enough information tha= t
one can independently write myCreateOffer() in JS?

No. We might decide we want to support that in the future, but for = now, that's not a requirement.
=C2=A0
Or do I generally need to
use createOffer(), but under some limited circumstances I can get away
with taking an extant offer, modifying it, and pushing it down?

=C2=A0
More or less. In addition to rehydra= ting calls, you can use a previously generated offer to rollback to a previ= ous state (perhaps if the remote side rejected a session modification).=C2= =A0

Of course, if you really know what you're doing, yo= u could generate your own offer based on what you think you know about the = browser and the mandatory-to-implement WebRTC SDP features (e.g. Cullen'= ;s G.711 example).

--e89a8f6432c22b852604b787ff62-- From ekr@rtfm.com Fri Jan 27 12:05:21 2012 Return-Path: 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 3C72121F868A for ; Fri, 27 Jan 2012 12:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 UKPk25+AQyqI for ; Fri, 27 Jan 2012 12:05:20 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A386A21F8674 for ; Fri, 27 Jan 2012 12:05:20 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1626009vbb.31 for ; Fri, 27 Jan 2012 12:05:20 -0800 (PST) Received: by 10.52.95.233 with SMTP id dn9mr3702409vdb.7.1327694720135; Fri, 27 Jan 2012 12:05:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Fri, 27 Jan 2012 12:04:40 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> From: Eric Rescorla Date: Fri, 27 Jan 2012 12:04:40 -0800 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Modifying the SDP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 20:05:21 -0000 On Fri, Jan 27, 2012 at 12:03 PM, Justin Uberti wrote: > > > On Fri, Jan 27, 2012 at 2:58 PM, Eric Rescorla wrote: >> >> On Fri, Jan 27, 2012 at 11:10 AM, Justin Uberti >> wrote: >> > sure. If you can generate a compatible session description through some >> > other mechanism, that is fine. There are a number of scenarios where I >> > think >> > this makes sense (including Matthew's example of pushing session state >> > back >> > down to resurrect a call). >> >> I wonder if this has API implications. What I mean here is: >> Does the API (capabilities, I guess) need to provide enough information >> that >> one can independently write myCreateOffer() in JS? > > > No. We might decide we want to support that in the future, but for now, > that's not a requirement. WFM. >> >> Or do I generally need to >> use createOffer(), but under some limited circumstances I can get away >> with taking an extant offer, modifying it, and pushing it down? >> > > More or less. In addition to rehydrating calls, you can use a previously > generated offer to rollback to a previous state (perhaps if the remote side > rejected a session modification). Rehydrate... I like that. -Ekr From juberti@google.com Fri Jan 27 12:11:32 2012 Return-Path: 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 DF1AA21F8694 for ; Fri, 27 Jan 2012 12:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 aaGNAZllaCeW for ; Fri, 27 Jan 2012 12:11:30 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C02FC21F8631 for ; Fri, 27 Jan 2012 12:11:29 -0800 (PST) Received: by iagf6 with SMTP id f6so3086925iag.31 for ; Fri, 27 Jan 2012 12:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=3R7d4k3GiQgvpoTM8ekIJcwEwGL7u0yC8gRLPLeJwEk=; b=JUqkw+KQCXZHTWDpQCtUhEYpG+thRgIyPEG/RuoZtJ/l+H1yTOiNUSF5FCAw5K6yh5 kSUk6KaLehPQba3qzfyByhY06Gh3AKNf0gvupjRdNUvt0b0pC8HQlZzYekzUirnv7MH7 XZjM6hAK+QPfvdJbcIGl3sCTHk42t8r52edrA= Received: by 10.50.160.234 with SMTP id xn10mr8181004igb.30.1327695089386; Fri, 27 Jan 2012 12:11:29 -0800 (PST) Received: by 10.50.160.234 with SMTP id xn10mr8180994igb.30.1327695089299; Fri, 27 Jan 2012 12:11:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 12:11:09 -0800 (PST) In-Reply-To: <05E6868A-250C-4287-A67A-E41517372BC5@iii.ca> References: <05E6868A-250C-4287-A67A-E41517372BC5@iii.ca> From: Justin Uberti Date: Fri, 27 Jan 2012 15:11:09 -0500 Message-ID: To: Cullen Jennings X-System-Of-Record: true Content-Type: multipart/alternative; boundary=14dae93403032af14204b7881a89 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP - Question about ICE trickle stats X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 20:11:33 -0000 --14dae93403032af14204b7881a89 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 26, 2012 at 2:43 PM, Cullen Jennings wrote: > > It seems to me there are a roughly three types of addresses used for > ICE/RTP in something like Hangouts. The local address, the NAT (server > reflexive) address, and the relayed address. A browser always knows the > local addresses but the NAT and relay take a bit longer thus the argument > for trickle. In trying to model how this all works it would be really nice > to know on a deployment such as Hangouts some of the following stats: > > What percentage of media flows end up sending RTP via the relay? What > percentage does the server reflexive address get used? and what percentage > have the far end sending directly to the local address? > > What is the average time to get a relay address? to find the server > reflexive address? > > What is the typical RTT for messages from one browser to the other browser > for the signaling data? > > Having a rough of idea of the above would be really helpful in looking at > timing of various parts. > > Justin, Any chance you can provide some of these measurements? > > Some of this data is easy to get, some of it is a bit trickier. Some of it is also a bit sensitive. If you have a particular question you're looking to answer, such as the typical time the offerer would need to wait to get local+stun+turn candidates, I can try to see if I can get the data to answer it. Also, note that the mean in many of these cases may not be the right value to look at, since the standard deviation can be very large (i.e. the worst 10% is much much worse than the mean) --14dae93403032af14204b7881a89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 26, 2012 at 2:43 PM, Cullen = Jennings <fluffy@iii.= ca> wrote:

It seems to me there are a roughly three types of addresses used for ICE/RT= P in something like Hangouts. The local address, the NAT (server reflexive)= address, and the relayed address. A browser always knows the local address= es but the NAT and relay take a bit longer thus the argument for trickle. I= n trying to model how this all works it would be really nice to know on a d= eployment such as Hangouts some of the following stats:

What percentage of media flows end up sending RTP via the relay? What perce= ntage does the server reflexive address get used? and what percentage have = the far end sending directly to the local address?

What is the average time to get a relay address? to find the server reflexi= ve address?

What is the typical RTT for messages from one browser to the other browser = for the signaling data?

Having a rough of idea of the above would be really helpful in looking at t= iming of various parts.

Justin, Any chance you can provide some of these measurements?

Some of this data is easy to get, some of it is a bit tr= ickier. Some of it is also a bit sensitive. If you have a particular questi= on you're looking to answer, such as the typical time the offerer would= need to wait to get local+stun+turn candidates, I can try to see if I can = get the data to answer it.

Also, note that the mean in many of these cases may not be t= he right value to look at, since the standard deviation can be very large (= i.e. the worst 10% is much much worse than the mean)
--14dae93403032af14204b7881a89-- From juberti@google.com Fri Jan 27 12:17:14 2012 Return-Path: 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 0709621F84DA for ; Fri, 27 Jan 2012 12:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 JldP4010p4-h for ; Fri, 27 Jan 2012 12:17:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 063FA21F8645 for ; Fri, 27 Jan 2012 12:17:06 -0800 (PST) Received: by iagf6 with SMTP id f6so3093950iag.31 for ; Fri, 27 Jan 2012 12:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=3UKm1/aZVrL2n2B0U/SPoRRkhL7QU3aBKluDLNtd3wg=; b=BOq4YlFRUyDfBDTGD3OB638XhuyN0AF9ZUZ9eVmwglZRXNn0ccINlZ2XNOUrJRtxGa S/yXJTMycjM8hJg1lUgXJ+ZoVY0Ljonox7Uc5SqKlMJvR+omKhmYKY9nyepdk6tBHDLx 4+OVjyEPniIxx8snXutLCZ3MRdlNo/gmijE6Q= Received: by 10.50.153.198 with SMTP id vi6mr7760968igb.30.1327695426448; Fri, 27 Jan 2012 12:17:06 -0800 (PST) Received: by 10.50.153.198 with SMTP id vi6mr7760958igb.30.1327695426350; Fri, 27 Jan 2012 12:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 12:16:46 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Fri, 27 Jan 2012 15:16:46 -0500 Message-ID: To: Eric Rescorla X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f22c68141eee004b7882e34 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 20:17:14 -0000 --e89a8f22c68141eee004b7882e34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 26, 2012 at 2:24 PM, Eric Rescorla wrote: > Hi Justin, > > i=E2=80=99ve been thinking about how ICE works in JSEP and ISTM that the = API > may not be emitting enough information to work here. As I understand > it, the following is a reasonable order of operations: > > Alice->Bob: Offer > Alice->Bob: ICE candidates > Bob->Alice: ICE candidates > // ICE happens > // Bob answers > Bob->Alice: Answer > > Unless I=E2=80=99m missing something, though, Alice and Bob can=E2=80=99t= start doing > ICE until they have exchanged the ice-ufrag and ice-pwd > properties. Alice sends these in her offer, so this is no problem, but > they would ordinarily be in Bob=E2=80=99s answer, but that gets delayed, = and > they=E2=80=99re not in Bob=E2=80=99s ICE candidates, so I don=E2=80=99t t= hink they can start > ICE until Bob=E2=80=99s answer arrives. I suspect that what we need here = is > something more like an XEP-0176 element, which would > contain the pwd and ufrag. This also has the potential to solve the > problem you raise at the end of how to associate each candidate with > the relevant media stream, since we can stuff a pointer in that > structure. [Note: I am not an SDP expert, so I don=E2=80=99t have an opin= ion > on the best form of that pointer. As you know, in ordinary ICE-SDP, > this info is just assocaited with the m-line by counting.] > While we=E2=80=99re on the topic of stuffing stuff here, it would be pret= ty > nice to know in advance if you are going to bundle, so you=E2=80=99re not > thinking you=E2=80=99re going to do ICE on channels which you don=E2=80= =99t want. As > you pointed out in another message, it=E2=80=99s also natural to put the = DTLS > info here, so that we can get DTLS started early. In general, I think > if we=E2=80=99re going to separate transport and media signaling, we shou= ld > probably be thinking about if there is anything else that really needs > to be delivered prior to Bob=E2=80=99s decision to answer the phone. > Yes; I think if the IceCallback provides the application with ice-ufrag, ice-pwd, BUNDLE info, and cert fingerprint (in addition to candidates), this would solve this problem (by effectively making IceCallback a transport-info generator). > > Finally, as you point out in Appendix A, we don=E2=80=99t currently know = when > you have all your candidates, which makes it hard to implement SIP > compatibility from this API. I=E2=80=99m not 100% sure what the best API = is > here: do we want to know when all candidates are found or just all for > a given flow? > I think you need to know when all candidates needed for the offer are obtained. Simplest way to do this in the proposed API is to add a |morePending| flag to the IceCallback. > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f22c68141eee004b7882e34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 26, 2012 at 2:24 PM, Eric Re= scorla <ekr@rtfm.com> wrote:
Hi Justin,

i=E2=80=99ve been thinking about how ICE works in JSEP and ISTM that the AP= I
may not be emitting enough information to work here. As I understand
it, the following is a reasonable order of operations:

Alice->Bob: Offer
Alice->Bob: ICE candidates
Bob->Alice: ICE candidates
// ICE happens
// Bob answers
Bob->Alice: Answer

Unless I=E2=80=99m missing something, though, Alice and Bob can=E2=80=99t s= tart doing
ICE until they have exchanged the ice-ufrag and ice-pwd
properties. Alice sends these in her offer, so this is no problem, but
they would ordinarily be in Bob=E2=80=99s answer, but that gets delayed, an= d
they=E2=80=99re not in Bob=E2=80=99s ICE candidates, so I don=E2=80=99t thi= nk they can start
ICE until Bob=E2=80=99s answer arrives. I suspect that what we need here is=
something more like an XEP-0176 <transport/> element, which would
contain the pwd and ufrag. This also has the potential to solve the
problem you raise at the end of how to associate each candidate with
the relevant media stream, since we can stuff a pointer in that
structure. [Note: I am not an SDP expert, so I don=E2=80=99t have an opinio= n
on the best form of that pointer. As you know, in ordinary ICE-SDP,
this info is just assocaited with the m-line by counting.]

While we=E2=80=99re on the topic of stuffing stuff here, it would be pretty=
nice to know in advance if you are going to bundle, so you=E2=80=99re not thinking you=E2=80=99re going to do ICE on channels which you don=E2=80=99t= want. As
you pointed out in another message, it=E2=80=99s also natural to put the DT= LS
info here, so that we can get DTLS started early. In general, I think
if we=E2=80=99re going to separate transport and media signaling, we should=
probably be thinking about if there is anything else that really needs
to be delivered prior to Bob=E2=80=99s decision to answer the phone.

Yes; I think if the IceCallback provides the = application with ice-ufrag, ice-pwd, BUNDLE info, and cert fingerprint (in = addition to candidates), this would solve this problem (by effectively maki= ng IceCallback a transport-info generator).=C2=A0=C2=A0=C2=A0

Finally, as you point out in Appendix A, we don=E2=80=99t currently know wh= en
you have all your candidates, which makes it hard to implement SIP
compatibility from this API. I=E2=80=99m not 100% sure what the best API is=
here: do we want to know when all candidates are found or just all for
a given flow?


--e89a8f22c68141eee004b7882e34-- From juberti@google.com Fri Jan 27 14:56:35 2012 Return-Path: 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 0C01921F863E for ; Fri, 27 Jan 2012 14:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, 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 HwAXVU0Mt0ua for ; Fri, 27 Jan 2012 14:56:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE80021F865A for ; Fri, 27 Jan 2012 14:56:30 -0800 (PST) Received: by iagf6 with SMTP id f6so3268986iag.31 for ; Fri, 27 Jan 2012 14:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:x-system-of-record :content-type; bh=xsdrdaYzcijTrCN48IxPalR5X0sRozF4xXkB0hYF8Ws=; b=xwjw6vtWLap6ZzmTG0sPHCyZXH+Ubtr3wiTdsPwwHwP1dyD3Ty6egbci9AXciIXDkB 1Aaf3FEDEQVD9tqkhra53nwwOY5xoYXJHwDM4PCw8XvRe+VycOefYp498cpTUPOqb9Bt 0fIGFVJKjw7jv91mm96pjHJWKA4LHU7JzSXZQ= Received: by 10.42.175.5 with SMTP id ay5mr6631063icb.47.1327704990561; Fri, 27 Jan 2012 14:56:30 -0800 (PST) Received: by 10.42.175.5 with SMTP id ay5mr6631057icb.47.1327704990438; Fri, 27 Jan 2012 14:56:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 14:56:10 -0800 (PST) From: Justin Uberti Date: Fri, 27 Jan 2012 17:56:10 -0500 Message-ID: To: rtcweb@ietf.org X-System-Of-Record: true Content-Type: multipart/alternative; boundary=90e6ba6e8f3852568404b78a6895 Subject: [rtcweb] Analyzing JSEP X-BeenThere: rtcweb@ietf.org 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: Fri, 27 Jan 2012 22:56:35 -0000 --90e6ba6e8f3852568404b78a6895 Content-Type: text/plain; charset=UTF-8 Here are the answers to Magnus' questions from the JSEP standpoint. Please reply in a new thread regarding specific points. A) Glare handling: How does the signaling handle situations where both end-points initiate negotiation, updates or re-negotiate at the same time (i.e. messages pass each other in-flight between the peers)? As JSEP is agnostic of signaling protocol, these details are left to the application and/or the previously mentioned JSEP-to-your-favorite-signaling-protocol JS library. In other words, the application can use an existing mitigation strategy from ROAP, Jingle, or SIP, or if it has special needs, it can implement its own algorithm to determine who wins (such as perhaps always favoring the server's change, in a centralized conferencing scenario). B) Can media clipping occur at the initial media establishment? Can it occur at re-negotiations? Initially this shouldn't happen as long as media configuration is in place prior to ICE promotes any candidate pairs. However, at media re-negotiation this could occur. And when you split the transport setup from media negotiation it becomes an issue again. There are various ways media clipping can typically occur at media establishment: a) ICE has not completed by the time of the callee's answer b) when using SDES-SRTP, the race that occurs between the answer's keys (in signaling) and the ciphertext media c) when using DTLS-SRTP, DTLS-SRTP is not established by the time of the callee's answer d) delays between the callee answering and media transmission starting (if media transmission does not start at the time of the answer) JSEP can help with preventing these problems. For (a), JSEP can allow ICE to start more quickly, by virtue of the fact that candidates can be supplied as soon as they are gathered (subject to previous discussions about address privacy); this can also be extended to (c), allowing DTLS to be brought up while the offer is pending. (The ringtone for the callee could even be delayed until these protocols complete.) For (d), media transmission can begin immediately upon the callee's answer, so this is not an issue. (b) is not directly addressed in the current JSEP draft, but one could imagine an application signaling protocol that decoupled callee consent from the callee's session description, allowing the SRTP keys to be provided while waiting for the callee's answer. This would simply mean adding a new API to JSEP that controls when media transmission should start. Similar issues exist when adding media to an existing session, which can be handled as shown above with JSEP. C) Does the glare handling result in periods where either side is prevented from updating offers? For example is it possible to send a new offer immediately after sending an answer to the peer's Offer? This becomes important as we are likely having declarative media stream information, like the Media Stream ID mapping to SSRCs for each media stream an end-point intends to send. In JSEP, it is possible to send an offer while an offer is outstanding, providing you are willing to handle the complex outcome of the callee accepting the initial offer. This decision is left up to the application; if the application chooses to use a signaling protocol that does not permit re-offers, the application won't have this flexibility (or complexity). The only invalid states in JSEP involve sending an unsolicited answer, or replying to an offer with an offer. JSEP's handling of early media requires more specification, to avoid the final answer from being treated as an unsolicited answer. D) Is it possible to provide additional ICE candidate's after the initial offer? What level of complexities does that incur? Yes. JSEP allows additional candidates to be provided at any time. However, when using signaling protocols that do not permit candidates to be sent after the initial offer, applications will need to choose at what point they decide to stop gathering candidates and transmit their offer. JSEP will provide applications with information about the allocation process so that they can know when all expected candidates have been gathered (and potentially, when 'enough' candidates have been gathered, e.g. local+turn for at least 1 interface). Since candidates are handled separately from the rest of the session description, some work is required by the application to glue the gathered candidates into the session description. This could easily be done by the JS library mentioned above. E) Is it possible to establish transport session which completes ICE processing without negotiating any media, or at least without forcing the user to assign media resource to it (not having to run getUserMedia in the API)? Some versions of WhatWG API did establish a data channel by default, which could be one option but other possibilities do exist. Yes. Using JSEP, the application can establish a "placeholder" session, i.e. an audio/video session with no mediastreams attached. An offer for such a session can be done by calling createOffer with the appropriate hints to enable audio/video. Or, it could create a session with just a data channel, by adding a DataStream to the session before calling createOffer. Depending on the callee, this may cause some problems; clients that don't expect these kinds of placeholder sessions will end up doing ghost rings. F) How does one support forking, and specifically can one deal with; - F1) Parallel forking? I.e. deal with multiple answers to a given offer and establish multiple flows? This is a signaling protocol issue, and JSEP can handle this however the application wants to deal with it. JSEP can receive candidates from multiple endpoints, and proceed with the endpoint that accepts the call. - F2) Sequential/Serial Forking? i.e. receive one answer and later get a second answer to the same initial offer and use that to replace the first? This is handled the same way JSEP will deal with early media, specifically by having some notion of a non-final answer. G) How does the proposal attempt to improve the time until media is negotiated and can flow between the peers. As mentioned in (D), JSEP allows the initial candidates to be transmitted immediately, with other candidates provided later. It can also bring up ICE and DTLS while waiting for the remote side to accept. If the endpoint of the call is known a priori, and it is a compatible endpoint, the techniques in (E) could be employed to have the call live and simply waiting for media to be added. H) What explicit indication or other hints can the upper layer get from the proposal get that this might be a suitable time to perform a re-negotiation or is it automatically triggered by the browser core? Renegotiation will typically need to be done explicitly by the application when a condition that requires re-signaling occurs (e.g. when a media/data stream is added/removed/stopped). --90e6ba6e8f3852568404b78a6895 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are the answers to Magnus' questions from the JSEP standpoint= . Please reply in a new thread regarding specific points.

A) Glare handling: How does the signaling handle situations where b= oth
end-points initiate negotiation, updates or re-negotiate at the same
time (i.e. messages pass each other in-flight between the peers)?<= /div>

As JSEP is agnostic of signaling protocol, these d= etails are left to the application and/or the previously mentioned JSEP-to-= your-favorite-signaling-protocol JS library. In other words, the applicatio= n can use an existing mitigation strategy from ROAP, Jingle, or SIP, or if = it has special needs, it can implement its own algorithm to determine who w= ins (such as perhaps always favoring the server's change, in a centrali= zed conferencing scenario).

B) Can media clipping occur at the initial media establ= ishment? Can it
occur at re-negotiations? Initially this shouldn&= #39;t happen as long as
media configuration is in place prior to = ICE promotes any candidate
pairs. However, at media re-negotiation this could occur. And when you=
split the transport setup from media negotiation it becomes an i= ssue again.

There are various ways media clipping = can typically occur at media establishment:
a) ICE has not completed by the time of the callee's answer
<= div>b) when using SDES-SRTP, the race that occurs between the answer's = keys (in signaling) and the ciphertext media
c) when using DTLS-S= RTP, DTLS-SRTP is not established by the time of the callee's answer
d) delays between the callee answering and media transmission starting= (if media transmission does not start at the time of the answer)

JSEP can help with preventing these problems. For (a), JSEP= can allow ICE to start more quickly, by virtue of the fact that candidates= can be supplied as soon as they are gathered (subject to previous discussi= ons about address privacy); this can also be extended to (c), allowing DTLS= to be brought up while the offer is pending. (The ringtone for the callee = could even be delayed until these protocols complete.) For (d), media trans= mission can begin immediately upon the callee's answer, so this is not = an issue.

(b) is not directly addressed in the current JSEP draft= , but one could imagine an application signaling protocol that decoupled ca= llee consent from the callee's session description, allowing the SRTP k= eys to be provided while waiting for the callee's answer. This would si= mply mean adding a new API to JSEP that controls when media transmission sh= ould start.

Similar issues exist when adding media to an existing s= ession, which can be handled as shown above with JSEP.

=
C) Does the glare handling result in periods where either side is
prevented from updating offers? For example is it possible to send a n= ew
offer immediately after sending an answer to the peer's Of= fer? This
becomes important as we are likely having declarative m= edia stream
information, like the Media Stream ID mapping to SSRCs for each media<= /div>
stream an end-point intends to send.

In = JSEP, it is possible to send an offer while an offer is outstanding, provid= ing you are willing to handle the complex outcome of the callee accepting t= he initial offer. This decision is left up to the application; if the appli= cation chooses to use a signaling protocol that does not permit re-offers, = the application won't have this flexibility (or complexity).

The only invalid states in JSEP involve sending an unso= licited answer, or replying to an offer with an offer. JSEP's handling = of early media requires more specification, to avoid the final answer from = being treated as an unsolicited answer.

D) Is it possible to provide additional ICE candidate&#= 39;s after the
initial offer? What level of complexities does tha= t incur?

Yes. JSEP allows additional candidates to= be provided at any time. However, when using signaling protocols that do n= ot permit candidates to be sent after the initial offer, applications will = need to choose at what point they decide to stop gathering candidates and t= ransmit their offer. JSEP will provide applications with information about = the allocation process so that they can know when all expected candidates h= ave been gathered (and potentially, when 'enough' candidates have b= een gathered, e.g. local+turn for at least 1 interface).

Since candidates are handled separately from the rest o= f the session description, some work is required by the application to glue= the gathered candidates into the session description. This could easily be= done by the JS library mentioned above.

E) Is it possible to establish transport session which = completes ICE
processing without negotiating any media, or at lea= st without forcing
the user to assign media resource to it (not h= aving to run getUserMedia
in the API)? Some versions of WhatWG API did establish a data channel = by
default, which could be one option but other possibilities do = exist.

Yes. Using JSEP, the application can establ= ish a "placeholder" session, i.e. an audio/video session with no = mediastreams attached. An offer for such a session can be done by calling c= reateOffer with the appropriate hints to enable audio/video. Or, it could c= reate a session with just a data channel, by adding a DataStream to the ses= sion before calling createOffer.

Depending on the callee, this may cause some problems; = clients that don't expect these kinds of placeholder sessions will end = up doing ghost rings.

F) How does one support fork= ing, and specifically can one deal with;

=C2=A0- F1) Parallel forking? I.e. deal with multiple a= nswers to
=C2=A0 =C2=A0 =C2=A0 a given offer and establish multip= le flows?
=C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2= =A0 This is a signaling protocol issue, and JSEP can handle this however th= e application wants to deal with it. JSEP can receive candidates from multi= ple endpoints, and proceed with the endpoint that accepts the call.

=C2=A0- F2) Sequential/Serial Forking? i.e. receive one= answer and
=C2=A0 =C2=A0 =C2=A0 later get a second answer to the= same initial offer and
=C2=A0 =C2=A0 =C2=A0 use that to replace = the first?
=C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 This is handled the same way JSEP will deal with = early media, specifically by having some notion of a non-final answer.

G) How does the proposal attempt to improve the time u= ntil media is
negotiated and can flow between the peers.

As= mentioned in (D), JSEP allows the initial candidates to be transmitted imm= ediately, with other candidates provided later. It can also bring up ICE an= d DTLS while waiting for the remote side to accept.=C2=A0

If the endpoint of the call is known a priori, and it i= s a compatible endpoint, the techniques in (E) could be employed to have th= e call live and simply waiting for media to be added.

H) What explicit indication or other hints can the upper layer get fro= m
the proposal get that this might be a suitable time to perform = a
re-negotiation or is it automatically triggered by the browser = core?

Renegotiation will typically need to be done explicitly= by the application when a condition that requires re-signaling occurs (e.g= . when a media/data stream is added/removed/stopped).

--90e6ba6e8f3852568404b78a6895-- From randell-ietf@jesup.org Fri Jan 27 17:12:46 2012 Return-Path: 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 A110521F8503 for ; Fri, 27 Jan 2012 17:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 8l2JBSPEml3a for ; Fri, 27 Jan 2012 17:12:46 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id DC59721F84FB for ; Fri, 27 Jan 2012 17:12:45 -0800 (PST) Received: from corp-240.mv.mozilla.com ([63.245.220.240] helo=[10.250.6.124]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqwqS-0000mM-VZ for rtcweb@ietf.org; Fri, 27 Jan 2012 19:12:45 -0600 Message-ID: <4F234B8B.4020204@jesup.org> Date: Fri, 27 Jan 2012 17:12:43 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> <4F22C971.7050805@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] JS app interaction with congestion control X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 01:12:46 -0000 On 1/27/2012 11:49 AM, Justin Uberti wrote: > > > On Fri, Jan 27, 2012 at 10:57 AM, Randell Jesup > > wrote: > > On 1/27/2012 7:22 AM, Cullen Jennings wrote: > > Imagine that two browsers (A and B) have set up audio and > video streams and are happily chatting away. At this point > side A unplugs the camera. What happens next? how does this > get notified ? how does the PeerConnection end up telling the > JS that a new offer / answer exchange needs to be done to > indicate this video stream is gone? It seems like a callback > indicating something like this needed would be an good way to > solve this. > > > Yes; we need something associated with a MediaStream to tell the > app - this appears to be the 'removetrack' event (3.2.1) on the > MediaStreamTrackList. That should trigger the application to > renegotiate the connection to tell the other side. I should note > this is not removestream on PeerConnection. > > > Agree. Note that I believe this means that the app will be required (pretty much) to monitor every MediaStreamTrackList for removetrack events; so that's another block of "mandatory" code the app needs to include. > > I think this come up in another context where the browser > wants to change the the video resolution of frame rate due to > congestion control. We have not sorted out how the congestion > control story works but some of the nicer systems end up > significantly renovating video where there is a substantial > change of bandwidth. You can imagine that you are at home, > have 100% of a DSL link for incoming HD video, then someone > starts iTunes and it downloading 3 TV shows and suddenly you > go from 100% of DSL to 25% of DSL. > > > I'll respond to this later today. > > > The encoder already is going to get feedback from the bandwidth > estimator to tell it to adjust its output bitrate, typically by > changing QP. In cases where a suitable QP cannot be maintained, I > imagine the encoder pipeline will internally start reducing resolution > and framerate. I agree. Bitrate (and thus QP for video) will adjust automatically, and the browser is allowed to change the resolution within whatever negotiated parameters exist to provide a good experience (and I would encourage it to adjust resolution). > While I generally like the idea of the app being able to control these > sorts of things, I think we'd need to be able to expose more info to > the app (e.g. QP values) in order to allow it to do a good job. > > Note that a similar issue exists where the app wants to reduce > resolution or framerate due to CPU overload, and should probably be > solved similarly. Agreed. I'm going to try to throw together a strawman proposal for the app's interface to the congestion control parameters for the Interim... at least a starting point for really discussing it, instead of waving hands as we have been, including me. Sooo... (And this is rough, and a first cut, but we need to start somewhere) I propose we add a callback on PeerConnection and some attributes on it and MediaTracks: { ... attribute unsigned long maxBitrate; // allow app to limit bitrate used for the PeerConnection attribute readonly unsigned long currentBitrate; // [Open issue] - how much smoothing? attribute readonly long deltaBitrate; // maybe drop this attribute Function? onBitrateChange; attribute Function? onResolutionChange; // not strictly needed // These are global settings that can be overridden on a per-track basis attribute float minFramerate; attribute float maxFramerate; // might not be needed attribute boolean preferMotion; // false means preference for Resolution } I'm considering a 'hysterisis' value you can set to suppress minor changes in bandwidth from notifying you all the time. To each MediaTrack: { ... // If the app bumps up the currentBitrate of one track and doesn't lower another track, the // system will make cuts to keep the total bitrate within bounds. attribute unsigned long currentBitrate; attribute short priority; // for allocating bits // The rest of these are for video (is short guaranteed enough, always? Probably) attribute unsigned short width; // Let app override the values chosen automatically attribute unsigned short height; attribute float framerate; attribute float minFramerate; attribute float maxFramerate; // might not be needed attribute boolean preferMotion; // false means preference for Resolution attribute readonly unsigned short videoQuality; // audioQuality?? } Should some of these be echoed in MediaTrackLists or MediaStreams? -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Fri Jan 27 17:38:01 2012 Return-Path: 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 5B7D521F85CE for ; Fri, 27 Jan 2012 17:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.888 X-Spam-Level: X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[AWL=-1.744, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 JujSUZg7dhS7 for ; Fri, 27 Jan 2012 17:38:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3923921F85C5 for ; Fri, 27 Jan 2012 17:38:00 -0800 (PST) Received: by iagf6 with SMTP id f6so3421030iag.31 for ; Fri, 27 Jan 2012 17:37:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=r4QBjU9Y6iQsY6TOKoQIZfBoaQj+v5hYcGRzCi7mzfs=; b=t9Vh269jw0v/KFMVSLnuW+2bSatUMYKzEggfMMTUnrx6HvLs1k1RABjTv9DUGwPB+q 8CkJYK6QDRM3zGC51V2SAa8ZP034Pl9xVte4EdgHHJPDp1GZ0qODeB6gUgeEqaDs4rJ8 GqYTcATpF583EXwKGLNiz37ksy7yEdcTeOUE0= Received: by 10.50.89.196 with SMTP id bq4mr8635739igb.26.1327714679723; Fri, 27 Jan 2012 17:37:59 -0800 (PST) Received: by 10.50.89.196 with SMTP id bq4mr8635676igb.26.1327714678294; Fri, 27 Jan 2012 17:37:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.85.132 with HTTP; Fri, 27 Jan 2012 17:37:38 -0800 (PST) In-Reply-To: <4F234B8B.4020204@jesup.org> References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> <4F22C971.7050805@jesup.org> <4F234B8B.4020204@jesup.org> From: Justin Uberti Date: Fri, 27 Jan 2012 20:37:38 -0500 Message-ID: To: Randell Jesup X-System-Of-Record: true Content-Type: multipart/alternative; boundary=e89a8f3ba681c34a5904b78ca9c7 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JS app interaction with congestion control X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 01:38:01 -0000 --e89a8f3ba681c34a5904b78ca9c7 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 27, 2012 at 8:12 PM, Randell Jesup wrote: > On 1/27/2012 11:49 AM, Justin Uberti wrote: > >> >> >> On Fri, Jan 27, 2012 at 10:57 AM, Randell Jesup > randell-ietf@jesup.org**>> wrote: >> >> On 1/27/2012 7:22 AM, Cullen Jennings wrote: >> >> Imagine that two browsers (A and B) have set up audio and >> video streams and are happily chatting away. At this point >> side A unplugs the camera. What happens next? how does this >> get notified ? how does the PeerConnection end up telling the >> JS that a new offer / answer exchange needs to be done to >> indicate this video stream is gone? It seems like a callback >> indicating something like this needed would be an good way to >> solve this. >> >> >> Yes; we need something associated with a MediaStream to tell the >> app - this appears to be the 'removetrack' event (3.2.1) on the >> MediaStreamTrackList. That should trigger the application to >> renegotiate the connection to tell the other side. I should note >> this is not removestream on PeerConnection. >> >> >> Agree. >> > > Note that I believe this means that the app will be required (pretty much) > to monitor every MediaStreamTrackList for removetrack events; so that's > another block of "mandatory" code the app needs to include. > The app will probably need to monitor this regardless, if for no other reason than to not display frozen video in its preview windows when the track dies. > >> I think this come up in another context where the browser >> wants to change the the video resolution of frame rate due to >> congestion control. We have not sorted out how the congestion >> control story works but some of the nicer systems end up >> significantly renovating video where there is a substantial >> change of bandwidth. You can imagine that you are at home, >> have 100% of a DSL link for incoming HD video, then someone >> starts iTunes and it downloading 3 TV shows and suddenly you >> go from 100% of DSL to 25% of DSL. >> >> >> I'll respond to this later today. >> >> >> The encoder already is going to get feedback from the bandwidth estimator >> to tell it to adjust its output bitrate, typically by changing QP. In cases >> where a suitable QP cannot be maintained, I imagine the encoder pipeline >> will internally start reducing resolution and framerate. >> > > I agree. Bitrate (and thus QP for video) will adjust automatically, and > the browser is allowed to change the resolution within whatever negotiated > parameters exist to provide a good experience (and I would encourage it to > adjust resolution). > > While I generally like the idea of the app being able to control these >> sorts of things, I think we'd need to be able to expose more info to the >> app (e.g. QP values) in order to allow it to do a good job. >> >> Note that a similar issue exists where the app wants to reduce resolution >> or framerate due to CPU overload, and should probably be solved similarly. >> > > Agreed. > > I'm going to try to throw together a strawman proposal for the app's > interface to the congestion control parameters for the Interim... at least > a starting point for really discussing it, instead of waving hands as we > have been, including me. > > Sooo... (And this is rough, and a first cut, but we need to start > somewhere) > I propose we add a callback on PeerConnection and some attributes on it > and MediaTracks: > > { > ... > attribute unsigned long maxBitrate; // allow app to limit bitrate used > for the PeerConnection > attribute readonly unsigned long currentBitrate; // [Open issue] - how > much smoothing? > I assume this is total Tx bitrate, including FEC and RTX? > attribute readonly long deltaBitrate; // maybe drop this > What does |deltaBitrate| measure? I think we also want estimated send and recv bandwidth, RTX bitrate, and "regular" Tx bitrate. > > attribute Function? onBitrateChange; > This will probably be changing frequently, so it might just be best to let the app poll it. > attribute Function? onResolutionChange; // not strictly needed > > // These are global settings that can be overridden on a per-track basis > attribute float minFramerate; > This is may be difficult to use because the camera framerate may fluctuate significantly due to lighting. > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > } > > > I'm considering a 'hysterisis' value you can set to suppress minor changes > in bandwidth from notifying you all the time. > > To each MediaTrack: > > { > ... > // If the app bumps up the currentBitrate of one track and doesn't > lower another track, the > // system will make cuts to keep the total bitrate within bounds. > attribute unsigned long currentBitrate; > I tend to think for v1 the app should choose priorities but let the PC allocate bits. attribute short priority; // for allocating bits > > // The rest of these are for video (is short guaranteed enough, always? > Probably) > attribute unsigned short width; // Let app override the values chosen > automatically > attribute unsigned short height; > attribute float framerate; > attribute float minFramerate; > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > > attribute readonly unsigned short videoQuality; > Is this QP, or something that maps to it? > // audioQuality?? > > } > > Should some of these be echoed in MediaTrackLists or MediaStreams? I think this, as is, is a good start. > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --e89a8f3ba681c34a5904b78ca9c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 27, 2012 at 8:12 PM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 1/27/2012 11:49 AM, Justin Uberti wrote:


On Fri, Jan 27, 2012 at 10:57 AM, Randell Jesup <randell-ietf@jesup.org <mailto:= randell-ietf@je= sup.org>> wrote:

=C2=A0 =C2=A0On 1/27/2012 7:22 AM, Cullen Jennings wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0Imagine that two browsers (A and B) =C2=A0have = set up audio and
=C2=A0 =C2=A0 =C2=A0 =C2=A0video streams and are happily chatting away. At= this point
=C2=A0 =C2=A0 =C2=A0 =C2=A0side A unplugs the camera. What happens next? h= ow does this
=C2=A0 =C2=A0 =C2=A0 =C2=A0get notified ? how does the PeerConnection end = up telling the
=C2=A0 =C2=A0 =C2=A0 =C2=A0JS that a new offer / answer exchange needs to = be done to
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate this video stream is gone? It seems li= ke a callback
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicating something like this needed would be = an good way to
=C2=A0 =C2=A0 =C2=A0 =C2=A0solve this.


=C2=A0 =C2=A0Yes; we need something associated with a MediaStream to tell = the
=C2=A0 =C2=A0app - this appears to be the 'removetrack' event (3.2= .1) on the
=C2=A0 =C2=A0MediaStreamTrackList. =C2=A0That should trigger the applicati= on to
=C2=A0 =C2=A0renegotiate the connection to tell the other side. =C2=A0I sh= ould note
=C2=A0 =C2=A0this is not removestream on PeerConnection.


Agree.

Note that I believe this means that the app will be required (pretty much) = to monitor every MediaStreamTrackList for removetrack events; so that's= another block of "mandatory" code the app needs to include.

The app will probably need to monitor this= regardless, if for no other reason than to not display frozen video in its= preview windows when the track dies.



=C2=A0 =C2=A0 =C2=A0 =C2=A0I think this come up in another context where t= he browser
=C2=A0 =C2=A0 =C2=A0 =C2=A0wants to change the the video resolution of fra= me rate due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control. We have not sorted out how = the congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0control story works but some of the nicer syste= ms end up
=C2=A0 =C2=A0 =C2=A0 =C2=A0significantly renovating video where there is a= substantial
=C2=A0 =C2=A0 =C2=A0 =C2=A0change of bandwidth. You can imagine that you a= re at home,
=C2=A0 =C2=A0 =C2=A0 =C2=A0have 100% of a DSL link for incoming HD video, = then someone
=C2=A0 =C2=A0 =C2=A0 =C2=A0starts iTunes and it downloading 3 TV shows and= suddenly you
=C2=A0 =C2=A0 =C2=A0 =C2=A0go from 100% of DSL to 25% of DSL.


=C2=A0 =C2=A0I'll respond to this later today.


The encoder already is going to get feedback from the bandwidth estimator t= o tell it to adjust its output bitrate, typically by changing QP. In cases = where a suitable QP cannot be maintained, I imagine the encoder pipeline wi= ll internally start reducing resolution and framerate.

I agree. =C2=A0Bitrate (and thus QP for video) will adjust automatically, a= nd the browser is allowed to change the resolution within whatever negotiat= ed parameters exist to provide a good experience (and I would encourage it = to adjust resolution).

While I generally like the idea of the app being able to control these sort= s of things, I think we'd need to be able to expose more info to the ap= p (e.g. QP values) in order to allow it to do a good job.

Note that a similar issue exists where the app wants to reduce resolution o= r framerate due to CPU overload, and should probably be solved similarly.

Agreed.

I'm going to try to throw together a strawman proposal for the app'= s interface to the congestion control parameters for the Interim... =C2=A0a= t least a starting point for really discussing it, instead of waving hands = as we have been, including me.

Sooo... =C2=A0(And this is rough, and a first cut, but we need to start som= ewhere)=C2=A0

I propose we add a callback on PeerConnection and some attributes on it and= MediaTracks:

{
...
=C2=A0 =C2=A0attribute unsigned long maxBitrate; // allow app to limit bit= rate used for the PeerConnection
=C2=A0 =C2=A0attribute readonly unsigned long currentBitrate; =C2=A0// [Op= en issue] - how much smoothing?

I assum= e this is total Tx bitrate, including FEC and RTX? =C2=A0
=C2=A0 =C2=A0attribute readonly long deltaBitrate; // maybe drop this
<= /blockquote>

What does |deltaBitrate| measure?=C2=A0

I think we also want estimated send and recv bandwidt= h, RTX bitrate, and "regular" Tx bitrate.=C2=A0

=C2=A0 =C2=A0attribute Function? onBitrateChange;
This will probably be changing frequently, so it might just be = best to let the app poll it.
=C2=A0
=C2=A0 =C2=A0attribute Function? onResolutionChange; =C2=A0// not strictly= needed

=C2=A0 =C2=A0// These are global settings that can be overridden on a per-= track basis
=C2=A0 =C2=A0attribute float minFramerate;

=
This is may be difficult to use because the camera framerate may fluct= uate significantly due to lighting.=C2=A0
=C2=A0 =C2=A0attribute float maxFramerate; // might not be needed
=C2=A0 =C2=A0attribute boolean preferMotion; =C2=A0// false means preferen= ce for Resolution
}
=C2=A0

I'm considering a 'hysterisis' value you can set to suppress mi= nor changes in bandwidth from notifying you all the time.

To each MediaTrack:

{
...
=C2=A0 =C2=A0// If the app bumps up the currentBitrate of one track and do= esn't lower another track, the
=C2=A0 =C2=A0// system will make cuts to keep the total bitrate within bou= nds.
=C2=A0 =C2=A0attribute unsigned long currentBitrate;
=
I tend to think for v1 the app should choose priorities but = let the PC allocate bits.

=C2=A0 =C2=A0// audioQuality??

}

Should some of these be echoed in MediaTrackLists or MediaStreams?

I think this, as is, is a good start.=C2=A0


--
Randell Jesup
randell-ietf@je= sup.org

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f3ba681c34a5904b78ca9c7-- From bernard_aboba@hotmail.com Fri Jan 27 19:37:36 2012 Return-Path: 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 B782121F84C3 for ; Fri, 27 Jan 2012 19:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.033 X-Spam-Level: X-Spam-Status: No, score=-101.033 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_40=-0.185, 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 zGl1IkVKjNEq for ; Fri, 27 Jan 2012 19:37:36 -0800 (PST) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 13DB121F84B8 for ; Fri, 27 Jan 2012 19:37:36 -0800 (PST) Received: from BLU152-W1 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 19:37:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2f6c7c51-be13-4593-a471-aa697e232549_" X-Originating-IP: [131.107.0.78] From: Bernard Aboba To: , , Date: Fri, 27 Jan 2012 19:37:35 -0800 Importance: Normal In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> References: , , <4F1EEECC.80200@digium.com>, , <4F1F0583.7070202@digium.com>, <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net>, <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca>, <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2012 03:37:35.0377 (UTC) FILETIME=[2CBF3010:01CCDD6E] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 03:37:36 -0000 --_2f6c7c51-be13-4593-a471-aa697e232549_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Andy said: > Also I don't have hard stats but of course SDES is what is implemented to= day in endpoints and gateways that have a requirement for SRTP which I thin= k is a large percentage and growing. SDES is also pretty much interoperable= between implementations the main issues that arise are around best effort = SRTP and that fact that sdp-neg (RFC 5939) is not widely implemented. >=20 > So if SDES=2C DTLS-SRTP and possibly even RTP are going to be options in = RTCWEB the issue that needs to be clearly specified is the negotiation mech= anism be it RFC 5939 or something else. I don't believe that a fallback mec= hanism based on failure and re-try would be acceptable. [BA] I agree that multiple rounds of offer/answer is undesirable. However= =2C I am not convinced that RFC 5939 is the solution=2C based on the (lack= of) deployment.=20 This seems to point to a reduction in the number of potential options. Fro= m the discussion that has occurred so far I believe that we can probably di= spense with RTP=2C except for debugging and require SRTP both be implemente= d and used.=20 This leaves us with SAVP(F) as the profile=2C with SDES and/or DTLS/SRTP as= the offered keying mechanism.=20 = --_2f6c7c51-be13-4593-a471-aa697e232549_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Andy said:

>=3B Also I don't have hard stats but of course SD= ES is what is implemented today in endpoints and gateways that have a requi= rement for SRTP which I think is a large percentage and growing. SDES is al= so pretty much interoperable between implementations the main issues that a= rise are around best effort SRTP and that fact that sdp-neg (RFC 5939) is n= ot widely implemented.
>=3B
>=3B So if SDES=2C DTLS-SRTP and pos= sibly even RTP are going to be options in RTCWEB the issue that needs to be= clearly specified is the negotiation mechanism be it RFC 5939 or something= else. I don't believe that a fallback mechanism based on failure and re-tr= y would be acceptable.

[BA] I agree that multiple rounds of offer/an= swer is undesirable. =3B However=2C I am not convinced that RFC 5939 is= the solution=2C =3B based on the (lack of) deployment.

This se= ems to point to a reduction in the number of potential options. =3B Fro= m the discussion that has occurred so far I believe that we can probably di= spense with RTP=2C except for debugging and require SRTP both be implemente= d and used.

This leaves us with SAVP(F) as the profile=2C with SDES= and/or DTLS/SRTP as the offered keying mechanism.




= --_2f6c7c51-be13-4593-a471-aa697e232549_-- From bernard_aboba@hotmail.com Fri Jan 27 19:59:10 2012 Return-Path: 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 6847421F85D5 for ; Fri, 27 Jan 2012 19:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.464, 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 ODnMdm78E43c for ; Fri, 27 Jan 2012 19:59:09 -0800 (PST) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8721F85D4 for ; Fri, 27 Jan 2012 19:59:09 -0800 (PST) Received: from BLU152-W27 ([65.55.116.73]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 19:59:09 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b039aa20-b9ea-4372-9690-b65be94f13cb_" X-Originating-IP: [131.107.0.78] From: Bernard Aboba To: Date: Fri, 27 Jan 2012 19:59:09 -0800 Importance: Normal In-Reply-To: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> References: <2F48359C-277B-42F1-BDEF-E786DFF6CD56@iii.ca> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jan 2012 03:59:09.0003 (UTC) FILETIME=[2FCED9B0:01CCDD71] Subject: Re: [rtcweb] Modifying SDP (and why SDP is a tarbaby) X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 03:59:10 -0000 --_b039aa20-b9ea-4372-9690-b65be94f13cb_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that these are great questions=2C but we need to keep them in conte= xt.=20 Most of these questions arise=2C not just for JSEP=2C but also with respect= to the existing API.=20 In fact=2C I would argue that most of them will probably arise with respect= to *any* API that utilizes SDP.=20 I'd also argue that many of these questions arise outside of the kind of ba= sic scenarios that we are targeting for these "high level" APIs. =20 And one question that comes to mind is whether any SDP-based API can reason= ably be expected to provide all the flexibility that an advanced developer = (e.g. someone looking to develop an interoperable telepresence app=2C for e= xample) would want.=20 My answer to that is NO=2C because such an application would be highly like= ly to demand a level of SDP functionality that goes beyond what a browser m= ight be expected to provide natively. Think about all the things that such= an application might need in terms of SDP: security (ICE=2C SDES=2C SRTP)= =2C RTP profiles (SAVP/SAVPF)=2C layering=2C bundling=2C capability negotia= tion=2C etc. =20 Do we *really* think that all of this will be implemented natively and that= (as importantly) it is likely to interoperate if it were?=20 Experience tells us that the answer is no. =20 If you compare what SDP functionality is needed for some of the most advanc= ed use cases versus what is widely implemented today=2C it's hard to escape= the conclusion that an SDP-based API will be very painful to advanced deve= lopers and that such an API is highly likely to deliver interoperability in= complex scenarios=2C even if lots of other issues are worked out (e.g. cod= ecs).=20 Don't get me wrong -- IMHO JSEP is a *major* step forward=2C because it get= s the SDP state machine out of the browser=2C and will potentially make bas= ic functionality more resilient. =20 However=2C JSEP (or ROAP for that matter) is not the answer to every scenar= io in the use case document.=20 For some of those use cases a lower level API will be required=2C and IMHO = that API will have no SDP dependency at all. JSEP can be built on top of = that. =20 = --_b039aa20-b9ea-4372-9690-b65be94f13cb_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree that these are great questions=2C but we need to keep them in conte= xt.

Most of these questions arise=2C not just for JSEP=2C but also = with respect to the existing API.

In fact=2C I would argue that mos= t of them will probably arise with respect to *any* API that utilizes SDP. =

I'd also argue that many of these questions arise outside of the ki= nd of basic scenarios that we are targeting for these "high level" APIs.&nb= sp=3B

And one question that comes to mind is whether any SDP-based = API can reasonably be expected to provide all the flexibility that an advan= ced developer (e.g. someone looking to develop an interoperable telepresenc= e app=2C for example) would want.

My answer to that is NO=2C becaus= e such an application would be highly likely to demand a level of SDP funct= ionality that goes beyond what a browser might be expected to provide nativ= ely. =3B Think about all the things that such an application might need= in terms of SDP: =3B security (ICE=2C SDES=2C SRTP)=2C RTP profiles (S= AVP/SAVPF)=2C layering=2C bundling=2C capability negotiation=2C etc. = =3B =3B

Do we *really* think that all of this will be implement= ed natively and that (as importantly) it is likely to interoperate if it we= re?

Experience tells us that the answer is no. =3B

If y= ou compare what SDP functionality is needed for some of the most advanced u= se cases versus what is widely implemented today=2C it's hard to escape the= conclusion that an SDP-based API will be very painful to advanced develope= rs and that such an API is highly likely to deliver interoperability in com= plex scenarios=2C even if lots of other issues are worked out (e.g. codecs)= .

Don't get me wrong -- IMHO JSEP is a *major* step forward=2C beca= use it gets the SDP state machine out of the browser=2C and will potentiall= y make basic functionality more resilient. =3B

However=2C JSEP = (or ROAP for that matter) is not the answer to every scenario in the use ca= se document.

For some of those use cases a lower level API will be = required=2C and IMHO that API will have no SDP dependency at all. =3B&n= bsp=3B JSEP can be built on top of that. =3B
= --_b039aa20-b9ea-4372-9690-b65be94f13cb_-- From randell-ietf@jesup.org Fri Jan 27 23:27:33 2012 Return-Path: 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 855E021F8487 for ; Fri, 27 Jan 2012 23:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 omrIjU7PxEqg for ; Fri, 27 Jan 2012 23:27:33 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D46A221F8486 for ; Fri, 27 Jan 2012 23:27:32 -0800 (PST) Received: from [12.131.214.66] (helo=[10.61.33.151]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rr2hA-0001Y7-03 for rtcweb@ietf.org; Sat, 28 Jan 2012 01:27:32 -0600 Message-ID: <4F23A364.5040606@jesup.org> Date: Fri, 27 Jan 2012 23:27:32 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> <4F22C971.7050805@jesup.org> <4F234B8B.4020204@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] JS app interaction with congestion control X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 07:27:33 -0000 On 1/27/2012 5:37 PM, Justin Uberti wrote: > > > On Fri, Jan 27, 2012 at 8:12 PM, Randell Jesup > wrote: > Note that I believe this means that the app will be required (pretty > much) to monitor every MediaStreamTrackList for removetrack events; > so that's another block of "mandatory" code the app needs to include. > > > The app will probably need to monitor this regardless, if for no other > reason than to not display frozen video in its preview windows when the > track dies. And so that the other side doesn't show a frozen image. We should (perhaps are part of example code) pull together all the "you really should have this" code blocks. > I'm going to try to throw together a strawman proposal for the app's > interface to the congestion control parameters for the Interim... > at least a starting point for really discussing it, instead of > waving hands as we have been, including me. > > Sooo... (And this is rough, and a first cut, but we need to start > somewhere) > > > I propose we add a callback on PeerConnection and some attributes on > it and MediaTracks: > > { > ... > attribute unsigned long maxBitrate; // allow app to limit > bitrate used for the PeerConnection > attribute readonly unsigned long currentBitrate; // [Open > issue] - how much smoothing? > > > I assume this is total Tx bitrate, including FEC and RTX? Yes. > > attribute readonly long deltaBitrate; // maybe drop this > > > What does |deltaBitrate| measure? It was an idea that probably (as I went through it) I should have removed - the idea was deltabitrate since last onbitratechange. If the app cares, it's easy for it to calculate that itself. > > I think we also want estimated send and recv bandwidth, RTX bitrate, and > "regular" Tx bitrate. Probably, though that's more a function of a statistics module than input to the app for congestion reaction reasons (maybe RTX is useful). > > > attribute Function? onBitrateChange; > > > This will probably be changing frequently, so it might just be best to > let the app poll it. I hate polling... The app may be relatively idle most of the time in stable, in-call scenarios otherwise. The frequent changes are the reason I suggested some (settable) hysteresis before notification. > > attribute Function? onResolutionChange; // not strictly needed > > // These are global settings that can be overridden on a > per-track basis > attribute float minFramerate; > > > This is may be difficult to use because the camera framerate may > fluctuate significantly due to lighting. In some cases it may not be possible to meet this requirement - but that doesn't mean you shouldn't try. It also helps the system know that the app wants us to start trading off other things (resolution, color rendition, noise, etc) for framerate at a certain point, even if the setting is for preferResolution. For most "video-call-like" uses I'd rather the camera stay over 15fps on low light (preferably over 20 or 25), and damn the resolution/noise/etc. I realize some webcams are shitty and won't let us do that. > > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > } > > > I'm considering a 'hysterisis' value you can set to suppress minor > changes in bandwidth from notifying you all the time. > > To each MediaTrack: > > { > ... > // If the app bumps up the currentBitrate of one track and > doesn't lower another track, the > // system will make cuts to keep the total bitrate within bounds. > attribute unsigned long currentBitrate; > > > I tend to think for v1 the app should choose priorities but let the PC > allocate bits. Maybe. I don't see this as major problem to implement (given the other items), but I'd be ok with it as readonly to start. (I think apps will start playing "chase the desired codec bitrate" by fiddling priorities and watching the results.) > > attribute short priority; // for allocating bits > > // The rest of these are for video (is short guaranteed enough, > always? Probably) > attribute unsigned short width; // Let app override the values > chosen automatically > attribute unsigned short height; > attribute float framerate; > attribute float minFramerate; > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > > attribute readonly unsigned short videoQuality; > > > Is this QP, or something that maps to it? Yes; nominally QP, though that's not really a quality measurement. > > // audioQuality?? > > } > > Should some of these be echoed in MediaTrackLists or MediaStreams? > > > I think this, as is, is a good start. Thanks. This is basically what I've (we've) been suggesting from the start, and people generally seemed to like - letting the app have more input into how to react the bandwidth changes - who loses bits, who gains them, and when thresholds are reached removing (or adding) video streams, changing resolutions, etc. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Sat Jan 28 08:18:28 2012 Return-Path: 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 2727421F84D7 for ; Sat, 28 Jan 2012 08:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.802 X-Spam-Level: X-Spam-Status: No, score=-7.802 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8] 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 P6w1XBG8j6Sl for ; Sat, 28 Jan 2012 08:18:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E443D21F84D2 for ; Sat, 28 Jan 2012 08:18:26 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-20-4f241fd155fd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.AC.27041.1DF142F4; Sat, 28 Jan 2012 17:18:26 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 28 Jan 2012 17:18:24 +0100 Message-ID: <4F241FD0.1080200@ericsson.com> Date: Sat, 28 Jan 2012 17:18:24 +0100 From: Stefan Hakansson LK User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3E43BCC3-F2DF-4890-BE8C-65E178511C91@iii.ca> <4F22C971.7050805@jesup.org> <4F234B8B.4020204@jesup.org> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] JS app interaction with congestion control X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 16:18:28 -0000 On 01/28/2012 02:37 AM, Justin Uberti wrote: > > > On Fri, Jan 27, 2012 at 8:12 PM, Randell Jesup > wrote: > > On 1/27/2012 11:49 AM, Justin Uberti wrote: > > > > On Fri, Jan 27, 2012 at 10:57 AM, Randell Jesup > > __>> wrote: > > On 1/27/2012 7:22 AM, Cullen Jennings wrote: > > Imagine that two browsers (A and B) have set up audio and > video streams and are happily chatting away. At this point > side A unplugs the camera. What happens next? how does this > get notified ? how does the PeerConnection end up > telling the > JS that a new offer / answer exchange needs to be done to > indicate this video stream is gone? It seems like a callback > indicating something like this needed would be an good > way to > solve this. > > > Yes; we need something associated with a MediaStream to tell the > app - this appears to be the 'removetrack' event (3.2.1) on the > MediaStreamTrackList. That should trigger the application to > renegotiate the connection to tell the other side. I should > note > this is not removestream on PeerConnection. My understanding was that if the camera is unplugged this would mean that the associated track enters state "ended" and the app is notified via the "ended" event. > > > Agree. > > > Note that I believe this means that the app will be required (pretty > much) to monitor every MediaStreamTrackList for removetrack events; > so that's another block of "mandatory" code the app needs to include. > > > The app will probably need to monitor this regardless, if for no other > reason than to not display frozen video in its preview windows when the > track dies. > > > > I think this come up in another context where the browser > wants to change the the video resolution of frame rate > due to > congestion control. We have not sorted out how the > congestion > control story works but some of the nicer systems end up > significantly renovating video where there is a substantial > change of bandwidth. You can imagine that you are at home, > have 100% of a DSL link for incoming HD video, then someone > starts iTunes and it downloading 3 TV shows and suddenly you > go from 100% of DSL to 25% of DSL. > > > I'll respond to this later today. > > > The encoder already is going to get feedback from the bandwidth > estimator to tell it to adjust its output bitrate, typically by > changing QP. In cases where a suitable QP cannot be maintained, > I imagine the encoder pipeline will internally start reducing > resolution and framerate. > > > I agree. Bitrate (and thus QP for video) will adjust automatically, > and the browser is allowed to change the resolution within whatever > negotiated parameters exist to provide a good experience (and I > would encourage it to adjust resolution). > > While I generally like the idea of the app being able to control > these sorts of things, I think we'd need to be able to expose > more info to the app (e.g. QP values) in order to allow it to do > a good job. > > Note that a similar issue exists where the app wants to reduce > resolution or framerate due to CPU overload, and should probably > be solved similarly. > > > Agreed. > > I'm going to try to throw together a strawman proposal for the app's > interface to the congestion control parameters for the Interim... > at least a starting point for really discussing it, instead of > waving hands as we have been, including me. > > Sooo... (And this is rough, and a first cut, but we need to start > somewhere) > > > I propose we add a callback on PeerConnection and some attributes on > it and MediaTracks: > > { > ... > attribute unsigned long maxBitrate; // allow app to limit > bitrate used for the PeerConnection > attribute readonly unsigned long currentBitrate; // [Open > issue] - how much smoothing? > > > I assume this is total Tx bitrate, including FEC and RTX? > > attribute readonly long deltaBitrate; // maybe drop this > > > What does |deltaBitrate| measure? > > I think we also want estimated send and recv bandwidth, RTX bitrate, and > "regular" Tx bitrate. > > > attribute Function? onBitrateChange; > > > This will probably be changing frequently, so it might just be best to > let the app poll it. > > attribute Function? onResolutionChange; // not strictly needed > > // These are global settings that can be overridden on a > per-track basis > attribute float minFramerate; > > > This is may be difficult to use because the camera framerate may > fluctuate significantly due to lighting. > > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > } > > > I'm considering a 'hysterisis' value you can set to suppress minor > changes in bandwidth from notifying you all the time. > > To each MediaTrack: > > { > ... > // If the app bumps up the currentBitrate of one track and > doesn't lower another track, the > // system will make cuts to keep the total bitrate within bounds. > attribute unsigned long currentBitrate; > > > I tend to think for v1 the app should choose priorities but let the PC > allocate bits. > > attribute short priority; // for allocating bits > > // The rest of these are for video (is short guaranteed enough, > always? Probably) > attribute unsigned short width; // Let app override the values > chosen automatically > attribute unsigned short height; > attribute float framerate; > attribute float minFramerate; > attribute float maxFramerate; // might not be needed > attribute boolean preferMotion; // false means preference for > Resolution > > attribute readonly unsigned short videoQuality; > > > Is this QP, or something that maps to it? > > // audioQuality?? > > } > > Should some of these be echoed in MediaTrackLists or MediaStreams? > > > I think this, as is, is a good start. > > > > -- > Randell Jesup > randell-ietf@jesup.org > > _________________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/__listinfo/rtcweb > > > From fluffy@fluffy.im Sat Jan 28 09:31:55 2012 Return-Path: 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 C0F8021F8523 for ; Sat, 28 Jan 2012 09:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EKub2EOtD09i for ; Sat, 28 Jan 2012 09:31:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5821F8516 for ; Sat, 28 Jan 2012 09:31:48 -0800 (PST) Received: by dado14 with SMTP id o14so2730665dad.31 for ; Sat, 28 Jan 2012 09:31:48 -0800 (PST) Received: by 10.68.74.230 with SMTP id x6mr24724374pbv.49.1327771908567; Sat, 28 Jan 2012 09:31:48 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id i4sm30572374pbl.2.2012.01.28.09.31.46 (version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 09:31:47 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> Date: Sat, 28 Jan 2012 10:31:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <55CF25A1-4ED9-492D-A89C-95E7BD53C63B@iii.ca> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Sat, 28 Jan 2012 17:31:55 -0000 Uh, just for the record ... with my chair hat on.=20 There are clearly some people that want more than just DTLS-SRTP and = they want fallback negotiation. I'm not making any consensus call, and = I'm not saying there is consensus for one thing or another - I'm just = pointing out there are people that want this. Cullen On Jan 27, 2012, at 6:51 AM, Ravindran, Parthasarathi wrote: > Andy, >=20 > Even though the discussion is to provide RTP, SDES, DTLS-SRTP, > till now I didn't see anybody ask for fallback mechanism within these=20= > mechanism as it will lead to bid-down attack. I agree with you that=20 > any fallback mechanism makes the implementation Complex and = unacceptable.=20 >=20 > Also, I could not see the point in supporting both SDES and DTLS-SRTP. > In case WebRTC webserver is always trusted, SDES is the solution and > Webserver is not trusted, DTLS-SRTP is the solution.=20 >=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of Hutton, Andrew >> Sent: Friday, January 27, 2012 6:55 PM >> To: Cullen Jennings; Olle E.Johansson >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] SDES draft posted >>=20 >> Also I don't have hard stats but of course SDES is what is = implemented >> today in endpoints and gateways that have a requirement for SRTP = which I >> think is a large percentage and growing. SDES is also pretty much >> interoperable between implementations the main issues that arise are >> around best effort SRTP and that fact that sdp-neg (RFC 5939) is not >> widely implemented. >>=20 >> So if SDES, DTLS-SRTP and possibly even RTP are going to be options = in >> RTCWEB the issue that needs to be clearly specified is the = negotiation >> mechanism be it RFC 5939 or something else. I don't believe that a >> fallback mechanism based on failure and re-try would be acceptable. >>=20 >> Regards >> Andy >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Cullen Jennings >>> Sent: 26 January 2012 21:04 >>> To: Olle E.Johansson >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] SDES draft posted >>>=20 >>>=20 >>> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >>>=20 >>>>> I'd say it's a fair bet that at least 50% of the SIP UA >>> implementations available on the market (by market share, not count = of >>> implementations) support SRTP with SDES. >>>>=20 >>>> This is NOT the installed base - it's available on the market. The >>> installed base has a very low amount of SRTP implementations that = are >>> interoperable >>>=20 >>> Uh, I pretty much disagree with that thought I don't have hard stats = I >>> can point you at. A large percentage of the deployed endpoints and >>> gateways do work with SRTP and I don't see a lot of bugs logged >>> against them. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From andrew.hutton@siemens-enterprise.com Sun Jan 29 06:06:16 2012 Return-Path: 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 317E921F854F for ; Sun, 29 Jan 2012 06:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] 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 FSJFV1feKdNr for ; Sun, 29 Jan 2012 06:06:15 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF721F8548 for ; Sun, 29 Jan 2012 06:06:15 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id A4C351EB8421; Sun, 29 Jan 2012 15:06:13 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Sun, 29 Jan 2012 15:06:13 +0100 From: "Hutton, Andrew" To: "Ravindran, Parthasarathi" , Cullen Jennings , Olle E.Johansson Date: Sun, 29 Jan 2012 15:06:13 +0100 Thread-Topic: [rtcweb] SDES draft posted Thread-Index: AczamLkmxJ01MFolQbCHRCQyikwf5///5BgAgAAO3QCAAAofgIAAEPWAgADKlACAAnXggIABEh6A//+fyKD//dohYA== Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Sun, 29 Jan 2012 14:06:16 -0000 See below. > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: 27 January 2012 13:51 > To: Hutton, Andrew; Cullen Jennings; Olle E.Johansson > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] SDES draft posted >=20 > Andy, >=20 > Even though the discussion is to provide RTP, SDES, DTLS-SRTP, > till now I didn't see anybody ask for fallback mechanism within these > mechanism as it will lead to bid-down attack. I agree with you that > any fallback mechanism makes the implementation Complex and > unacceptable. [AndyH] - I did not say it had to be complex or that any fallback mechanism= would be unacceptable.=20 >=20 > Also, I could not see the point in supporting both SDES and DTLS-SRTP. > In case WebRTC webserver is always trusted, SDES is the solution and > Webserver is not trusted, DTLS-SRTP is the solution. [AndyH] - I don't think the choice can be made on the basis of whether the = webserver is as trusted DTLS-SRTP may be desirable over SDES even when the = webserver is trusted. It could be for example that SDES is used as an inter= im solution until a gateway is updated with support for DTLS-SRTP and after= upgrading the gateway DTLS-SRTP should just work.=20 >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >Of Hutton, Andrew > >Sent: Friday, January 27, 2012 6:55 PM > >To: Cullen Jennings; Olle E.Johansson > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] SDES draft posted > > > >Also I don't have hard stats but of course SDES is what is implemented > >today in endpoints and gateways that have a requirement for SRTP which > I > >think is a large percentage and growing. SDES is also pretty much > >interoperable between implementations the main issues that arise are > >around best effort SRTP and that fact that sdp-neg (RFC 5939) is not > >widely implemented. > > > >So if SDES, DTLS-SRTP and possibly even RTP are going to be options in > >RTCWEB the issue that needs to be clearly specified is the negotiation > >mechanism be it RFC 5939 or something else. I don't believe that a > >fallback mechanism based on failure and re-try would be acceptable. > > > >Regards > >Andy > > > > > > > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Cullen Jennings > >> Sent: 26 January 2012 21:04 > >> To: Olle E.Johansson > >> Cc: rtcweb@ietf.org > >> Subject: Re: [rtcweb] SDES draft posted > >> > >> > >> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: > >> > >> >> I'd say it's a fair bet that at least 50% of the SIP UA > >> implementations available on the market (by market share, not count > of > >> implementations) support SRTP with SDES. > >> > > >> > This is NOT the installed base - it's available on the market. The > >> installed base has a very low amount of SRTP implementations that > are > >> interoperable > >> > >> Uh, I pretty much disagree with that thought I don't have hard stats > I > >> can point you at. A large percentage of the deployed endpoints and > >> gateways do work with SRTP and I don't see a lot of bugs logged > >> against them. > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >_______________________________________________ > >rtcweb mailing list > >rtcweb@ietf.org > >https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Sun Jan 29 09:27:12 2012 Return-Path: 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 4BA4621F84E7 for ; Sun, 29 Jan 2012 09:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 q8XCY4qk9-gZ for ; Sun, 29 Jan 2012 09:27:11 -0800 (PST) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB421F84E2 for ; Sun, 29 Jan 2012 09:27:11 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RrYWz-0007Rl-ak; Sun, 29 Jan 2012 17:27:09 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_8931C5BC-A96F-4FC8-8804-2B08C7AD4E4C" From: Colin Perkins In-Reply-To: <4F200F03.6090309@alvestrand.no> Date: Sun, 29 Jan 2012 17:27:07 +0000 Message-Id: <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org> References: <4F200F03.6090309@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Sun, 29 Jan 2012 17:27:12 -0000 --Apple-Mail=_8931C5BC-A96F-4FC8-8804-2B08C7AD4E4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Harald, A couple of minor points on this draft: - Section 2 lists an open issue on when the recipient should signal that = a track is closed, suggesting either when the maid disappears from the = description, when a BYE packet is received, or when a timeout passes = with no media as options. The RTP rules for the latter two cases are = defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be = appropriate for this draft to follow, and reference, then, rather than = trying to define something new. - Section 3: is "a=3Dssrc:??? sending:off" is signalled, clarify whether = RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out in = the RTP code). Colin On 25 Jan 2012, at 14:17, Harald Alvestrand wrote: > I have updated this draft with a proposal to add an identifier for the = index of the mediastreamtrack inside a mediastream, and an = inclusion-by-reference that is my proposal to solve the muting problem. >=20 > Comments appreciated. >=20 > Harald >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-alvestrand-rtcweb-msid-01.txt > Date: Wed, 25 Jan 2012 05:25:44 -0800 > From: internet-drafts@ietf.org > To: harald@alvestrand.no > CC: harald@alvestrand.no >=20 > A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been = successfully submitted by Harald Alvestrand and posted to the IETF = repository. >=20 > Filename: draft-alvestrand-rtcweb-msid > Revision: 01 > Title: Signalling Media Stream ID in the Session = Description Protocol > Creation date: 2012-01-25 > WG ID: Individual Submission > Number of pages: 9 >=20 > Abstract: > This document specifies how the association between the RTP concept > of SSRC and the WebRTC concept of "media stream" / = "media stream > track" is carried using SDP signalling. >=20 > This document is an input document for discussion. It should be > discussed in the RTCWEB WG list, rtcweb@ietf.org. >=20 >=20 > = =20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_8931C5BC-A96F-4FC8-8804-2B08C7AD4E4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Colin


<= div>
On 25 Jan 2012, at 14:17, Harald Alvestrand = wrote:
=20 =20
I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

=             &n= bsp;       Harald

-------- Original Message -------- =
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: = Wed, 25 Jan 2012 05:25:44 -0800
From: = internet-drafts@ietf.org
To: = harald@alvestrand.no
CC: = harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has =
been successfully submitted by Harald Alvestrand and posted to the IETF =
repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description =
Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / =
&quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                         =
        =20


The IETF Secretariat
_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



-- 
Colin Perkins



= --Apple-Mail=_8931C5BC-A96F-4FC8-8804-2B08C7AD4E4C-- From randell-ietf@jesup.org Sun Jan 29 09:27:52 2012 Return-Path: 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 6227321F84E2 for ; Sun, 29 Jan 2012 09:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 Fg93IkV0WaB6 for ; Sun, 29 Jan 2012 09:27:51 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A238C21F84D7 for ; Sun, 29 Jan 2012 09:27:51 -0800 (PST) Received: from [12.131.214.66] (helo=[10.61.33.151]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RrYXa-0000Xn-Kx for rtcweb@ietf.org; Sun, 29 Jan 2012 11:27:46 -0600 Message-ID: <4F258193.3080100@jesup.org> Date: Sun, 29 Jan 2012 09:27:47 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Sun, 29 Jan 2012 17:27:52 -0000 On 1/29/2012 6:06 AM, Hutton, Andrew wrote: > See below. > >> -----Original Message----- >> From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 27 January 2012 13:51 >> To: Hutton, Andrew; Cullen Jennings; Olle E.Johansson >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] SDES draft posted >> >> Andy, >> >> Even though the discussion is to provide RTP, SDES, DTLS-SRTP, >> till now I didn't see anybody ask for fallback mechanism within these >> mechanism as it will lead to bid-down attack. I agree with you that >> any fallback mechanism makes the implementation Complex and >> unacceptable. > [AndyH] - I did not say it had to be complex or that any fallback mechanism would be unacceptable. > >> Also, I could not see the point in supporting both SDES and DTLS-SRTP. >> In case WebRTC webserver is always trusted, SDES is the solution and >> Webserver is not trusted, DTLS-SRTP is the solution. > [AndyH] - I don't think the choice can be made on the basis of whether the webserver is as trusted DTLS-SRTP may be desirable over SDES even when the webserver is trusted. It could be for example that SDES is used as an interim solution until a gateway is updated with support for DTLS-SRTP and after upgrading the gateway DTLS-SRTP should just work. Right, but that brings in the entire bid-down (to SDES) issue, and complexity in signalling this. My opinion is we first have to decide if we will talk *directly* to legacy endpoints, without a WebRTC-compliant gateway. This means requiring support for ICE and a security mechanism (SDES or DTLS-SRTP, and Cullen indicates some endpoints do support DTLS-SRTP apparently) or unsecured RTP. We can assume the JS will take the ROAP or JSEP offer and translate it into SIP/SDP (or the server will). Note that ICE is required as part of the "don't be a DDOS element" requirement. Next we have to decide what's the minimum security level required - RTP, SDES, or DTLS-SRTP. Next we have to decide how bid-down attacks would be dealt with, especially if you don't trust the server. While in some/many cases we would trust the server, there are other use-cases where we certainly don't (and having multiple levels of security will invoke our having to decide how to show this (understandably!) to users in browser chrome, since we can't allow the app to control showing security). A proposal for supporting legacy devices must answer all of these (in some manner) to be a viable candidate for consideration. My personal (and Mozilla's opinion) is strongly in favor of strong privacy & security guarantees, and in particular requiring DTLS-SRTP between WebRTC clients. If a solution to the above issues without compromising WebRTC<->WebRTC security can be found, I'm open. I haven't heard one yet, and so lean towards hard security guarantees and requiring a gateway to talk to legacy. So if you do know how to do the entire package, we need that proposal on the table ASAP. > >> Thanks >> Partha >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf >>> Of Hutton, Andrew >>> Sent: Friday, January 27, 2012 6:55 PM >>> To: Cullen Jennings; Olle E.Johansson >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] SDES draft posted >>> >>> Also I don't have hard stats but of course SDES is what is implemented >>> today in endpoints and gateways that have a requirement for SRTP which >> I >>> think is a large percentage and growing. SDES is also pretty much >>> interoperable between implementations the main issues that arise are >>> around best effort SRTP and that fact that sdp-neg (RFC 5939) is not >>> widely implemented. >>> >>> So if SDES, DTLS-SRTP and possibly even RTP are going to be options in >>> RTCWEB the issue that needs to be clearly specified is the negotiation >>> mechanism be it RFC 5939 or something else. I don't believe that a >>> fallback mechanism based on failure and re-try would be acceptable. >>> >>> Regards >>> Andy >>> >>> >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Cullen Jennings >>>> Sent: 26 January 2012 21:04 >>>> To: Olle E.Johansson >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] SDES draft posted >>>> >>>> >>>> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >>>> >>>>>> I'd say it's a fair bet that at least 50% of the SIP UA >>>> implementations available on the market (by market share, not count >> of >>>> implementations) support SRTP with SDES. >>>>> This is NOT the installed base - it's available on the market. The >>>> installed base has a very low amount of SRTP implementations that >> are >>>> interoperable >>>> >>>> Uh, I pretty much disagree with that thought I don't have hard stats >> I >>>> can point you at. A large percentage of the deployed endpoints and >>>> gateways do work with SRTP and I don't see a lot of bugs logged >>>> against them. >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Sun Jan 29 09:51:02 2012 Return-Path: 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 E290521F859B for ; Sun, 29 Jan 2012 09:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 PM5Wk2WIn5Dt for ; Sun, 29 Jan 2012 09:50:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A12C221F858F for ; Sun, 29 Jan 2012 09:50:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AB4639E0F0; Sun, 29 Jan 2012 18:50:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIxeSaB-wUyR; Sun, 29 Jan 2012 18:50:51 +0100 (CET) Received: from [172.28.88.252] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 42A1C39E03A; Sun, 29 Jan 2012 18:50:51 +0100 (CET) Message-ID: <4F2586FA.3050606@alvestrand.no> Date: Sun, 29 Jan 2012 18:50:50 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Colin Perkins References: <4F200F03.6090309@alvestrand.no> <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org> In-Reply-To: <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org> Content-Type: multipart/alternative; boundary="------------050901050408010609080600" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Sun, 29 Jan 2012 17:51:02 -0000 This is a multi-part message in MIME format. --------------050901050408010609080600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/29/2012 06:27 PM, Colin Perkins wrote: > Harald, > > A couple of minor points on this draft: Thanks for the review! > > - Section 2 lists an open issue on when the recipient should signal > that a track is closed, suggesting either when the maid disappears > from the description, when a BYE packet is received, or when a timeout > passes with no media as options. The RTP rules for the latter two > cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would > be appropriate for this draft to follow, and reference, then, rather > than trying to define something new. Thanks for the pointers! The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% aligned, but if I interpret you correctly, you think that a track should be signalled closed when its corresponding SSRC is removed from the senders list, and not in response to any changes in signalling? Or do you think we should signal a MediaStreamTrack closed in all 3 cases? Do you think we should add an SSRC to the sender table when it is seen in an SDP configuration? If not, MediaStreamTracks that never get any RTP packets never time out, which seems a bit odd. (I assume that the "sender table" in 6.3.4 and the "sender list" in 6.3.5 are the same thing) > > - Section 3: is "a=ssrc:??? sending:off" is signalled, clarify whether > RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out > in the RTP code). Being lazy, and because this is an "elsewhere" definition, I'd prefer to have that clarification made in section 2 of draft-lennox-mmusic-sdp-source-selection. But I agree, and would also think RTCP should be sent for muted streams. > > Colin > > > > On 25 Jan 2012, at 14:17, Harald Alvestrand wrote: >> I have updated this draft with a proposal to add an identifier for >> the index of the mediastreamtrack inside a mediastream, and an >> inclusion-by-reference that is my proposal to solve the muting problem. >> >> Comments appreciated. >> >> Harald >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-alvestrand-rtcweb-msid-01.txt >> Date: Wed, 25 Jan 2012 05:25:44 -0800 >> From: internet-drafts@ietf.org >> To: harald@alvestrand.no >> CC: harald@alvestrand.no >> >> >> >> A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. >> >> Filename: draft-alvestrand-rtcweb-msid >> Revision: 01 >> Title: Signalling Media Stream ID in the Session Description Protocol >> Creation date: 2012-01-25 >> WG ID: Individual Submission >> Number of pages: 9 >> >> Abstract: >> This document specifies how the association between the RTP concept >> of SSRC and the WebRTC concept of"media stream" /"media stream >> track" is carried using SDP signalling. >> >> This document is an input document for discussion. It should be >> discussed in the RTCWEB WG list,rtcweb@ietf.org. >> >> >> >> >> >> The IETF Secretariat >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Colin Perkins > http://csperkins.org/ > > > --------------050901050408010609080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/29/2012 06:27 PM, Colin Perkins wrote:
Harald,

A couple of minor points on this draft:
Thanks for the review!

- Section 2 lists an open issue on when the recipient should signal that a track is closed, suggesting either when the maid disappears from the description, when a BYE packet is received, or when a timeout passes with no media as options. The RTP rules for the latter two cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be appropriate for this draft to follow, and reference, then, rather than trying to define something new.

Thanks for the pointers!

The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% aligned, but if I interpret you correctly, you think that a track should be signalled closed when its corresponding SSRC is removed from the senders list, and not in response to any changes in signalling?

Or do you think we should signal a MediaStreamTrack closed in all 3 cases?

Do you think we should add an SSRC to the sender table when it is seen in an SDP configuration? If not,  MediaStreamTracks that never get any RTP packets never time out, which seems a bit odd.

(I assume that the "sender table" in 6.3.4 and the "sender list" in 6.3.5 are the same thing)


- Section 3: is "a=ssrc:??? sending:off" is signalled, clarify whether RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out in the RTP code).
Being lazy, and because this is an "elsewhere" definition, I'd prefer to have that clarification made in section 2 of draft-lennox-mmusic-sdp-source-selection. But I agree, and would also think RTCP should be sent for muted streams.


Colin



On 25 Jan 2012, at 14:17, Harald Alvestrand wrote:
I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

                    Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no 


A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                                  


The IETF Secretariat
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Colin Perkins


--------------050901050408010609080600-- From csp@csperkins.org Sun Jan 29 10:22:51 2012 Return-Path: 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 EC53921F854E for ; Sun, 29 Jan 2012 10:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 t64iICK1SAFe for ; Sun, 29 Jan 2012 10:22:49 -0800 (PST) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id A9CF221F8541 for ; Sun, 29 Jan 2012 10:22:48 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RrZOR-0003gM-fU; Sun, 29 Jan 2012 18:22:47 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D241173-4E8B-46A0-A028-CE7A01E69024" From: Colin Perkins In-Reply-To: <4F2586FA.3050606@alvestrand.no> Date: Sun, 29 Jan 2012 18:22:22 +0000 Message-Id: <2F4A1674-1CA3-4093-9CDB-1CEC2FA5A403@csperkins.org> References: <4F200F03.6090309@alvestrand.no> <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org> <4F2586FA.3050606@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-alvestrand-rtcweb-msid-01.txt X-BeenThere: rtcweb@ietf.org 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: Sun, 29 Jan 2012 18:22:51 -0000 --Apple-Mail=_9D241173-4E8B-46A0-A028-CE7A01E69024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 29 Jan 2012, at 17:50, Harald Alvestrand wrote: > On 01/29/2012 06:27 PM, Colin Perkins wrote: >>=20 >> Harald, >>=20 >> A couple of minor points on this draft: > Thanks for the review! >>=20 >> - Section 2 lists an open issue on when the recipient should signal = that a track is closed, suggesting either when the maid disappears from = the description, when a BYE packet is received, or when a timeout passes = with no media as options. The RTP rules for the latter two cases are = defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be = appropriate for this draft to follow, and reference, then, rather than = trying to define something new. >=20 > Thanks for the pointers! >=20 > The phenomenon of MediaStreamTrack and the SSRC are not necessarily = 100% aligned, but if I interpret you correctly, you think that a track = should be signalled closed when its corresponding SSRC is removed from = the senders list, and not in response to any changes in signalling? >=20 > Or do you think we should signal a MediaStreamTrack closed in all 3 = cases? I'm not sure I understand the definition of MediaStreamTrack well enough = to answer that question, but if we do use RTCP BYE or RTP-level timeouts = to signal that a track has been closed, it should be done following the = RFC 3550 rules, rather than by inventing a different set of rules.=20 > Do you think we should add an SSRC to the sender table when it is seen = in an SDP configuration? If not, MediaStreamTracks that never get any = RTP packets never time out, which seems a bit odd. Section 5 of RFC 5576 talks about this ("sources that are only known = through SDP, for which neither RTP nor RTCP packets have been received, = MUST NOT be counted for RTP group size estimation", etc.). I interpret = that as saying that you mark an SSRC learnt about via SDP as reserved, = so you don't pick it using random SSRC selection, but don't consider it = as existing in the RTP session until you receive an RTP/RTCP packet with = that SSRC. That is, sending an SDP with an "a=3Dssrc:" line says "I plan = to use this SSRC", but the SSRC doesn't come into being until you send = an RTP or RTCP packet using it.=20 This may mean that MediaStreamTrack needs a "potential" state, as well = as open and closed. > (I assume that the "sender table" in 6.3.4 and the "sender list" in = 6.3.5 are the same thing) Yes. >> - Section 3: is "a=3Dssrc:??? sending:off" is signalled, clarify = whether RTCP is sent for that SSRC (yes, presumably, otherwise it'll = time out in the RTP code). > Being lazy, and because this is an "elsewhere" definition, I'd prefer = to have that clarification made in section 2 of = draft-lennox-mmusic-sdp-source-selection. But I agree, and would also = think RTCP should be sent for muted streams. Sure - I already sent a comment to Jonathan Lennox along those lines. Colin >>=20 >> Colin >>=20 >>=20 >>=20 >> On 25 Jan 2012, at 14:17, Harald Alvestrand wrote: >>> I have updated this draft with a proposal to add an identifier for = the index of the mediastreamtrack inside a mediastream, and an = inclusion-by-reference that is my proposal to solve the muting problem. >>>=20 >>> Comments appreciated. >>>=20 >>> Harald >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-alvestrand-rtcweb-msid-01.txt >>> Date: Wed, 25 Jan 2012 05:25:44 -0800 >>> From: internet-drafts@ietf.org >>> To: harald@alvestrand.no >>> CC: harald@alvestrand.no >>>=20 >>> A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been = successfully submitted by Harald Alvestrand and posted to the IETF = repository. >>>=20 >>> Filename: draft-alvestrand-rtcweb-msid >>> Revision: 01 >>> Title: Signalling Media Stream ID in the Session = Description Protocol >>> Creation date: 2012-01-25 >>> WG ID: Individual Submission >>> Number of pages: 9 >>>=20 >>> Abstract: >>> This document specifies how the association between the RTP = concept >>> of SSRC and the WebRTC concept of "media stream" / = "media stream >>> track" is carried using SDP signalling. >>>=20 >>> This document is an input document for discussion. It should be >>> discussed in the RTCWEB WG list, rtcweb@ietf.org. >>>=20 >>>=20 >>> = =20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ >>=20 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_9D241173-4E8B-46A0-A028-CE7A01E69024 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 =20 =20
On 01/29/2012 06:27 PM, Colin Perkins wrote:
Harald,

A couple of minor points on this draft:
Thanks for the review!

- Section 2 lists an open issue on when the recipient should signal that a track is closed, suggesting either when the maid disappears from the description, when a BYE packet is received, or when a timeout passes with no media as options. The RTP rules for the latter two cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be appropriate for this draft to follow, and reference, then, rather than trying to define something = new.

Thanks for the pointers!

The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% aligned, but if I interpret you correctly, you think that a track should be signalled closed when its corresponding SSRC is removed from the senders list, and not in response to any changes in signalling?

Or do you think we should signal a MediaStreamTrack closed in all 3 cases?

I'm not sure I = understand the definition of MediaStreamTrack well enough to answer that = question, but if we do use RTCP BYE or RTP-level timeouts to signal = that a track has been closed, it should be done following the RFC 3550 = rules, rather than by inventing a different set of = rules. 

Do you think we should add an SSRC to the sender table when it is seen in an SDP configuration? If not,  MediaStreamTracks that = never get any RTP packets never time out, which seems a bit = odd.

Section 5 of RFC 5576 = talks about this ("sources that are only known through SDP, for = which neither RTP nor RTCP packets have been received, MUST NOT be = counted for RTP group size estimation", etc.). I interpret that as = saying that you mark an SSRC learnt about via SDP as reserved, so you = don't pick it using random SSRC selection, but don't consider it as = existing in the RTP session until you receive an RTP/RTCP packet with = that SSRC. That is, sending an SDP with an "a=3Dssrc:" line says "I plan = to use this SSRC", but the SSRC doesn't come into being until you send = an RTP or RTCP packet using it. 

This may = mean that MediaStreamTrack needs a "potential" state, as well as open = and closed.

(I assume that the "sender table" in 6.3.4 and the "sender list" in 6.3.5 are the same = thing)

Yes.

- Section 3: is "a=3Dssrc:??? sending:off" is signalled, clarify whether RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out in the RTP code).
Being lazy, and because this is an "elsewhere" definition, I'd prefer to have that clarification made in section 2 of draft-lennox-mmusic-sdp-source-selection. But I agree, and would also think RTCP should be sent for muted = streams.

Sure - I already sent a = comment to Jonathan Lennox along those = lines.

Colin



Colin



On 25 Jan 2012, at 14:17, Harald Alvestrand wrote:
I have updated = this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

=             &n= bsp;       Harald

-------- Original Message -------- =
Subject: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: Wed, 25 Jan 2012 05:25:44 -0800
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no 


A new version of I-D, =
draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by =
Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description =
Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   This document specifies how the association between the RTP concept
   of SSRC and the WebRTC concept of &quot;media stream&quot; / =
&quot;media stream
   track&quot; is carried using SDP signalling.

   This document is an input document for discussion.  It should be
   discussed in the RTCWEB WG list, rtcweb@ietf.org.


                                                                         =
        =20


The IETF Secretariat
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb



-- 
Colin Perkins


=20


_______________________________________________
rtcweb mailing = list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb



-- 
Colin Perkins



= --Apple-Mail=_9D241173-4E8B-46A0-A028-CE7A01E69024-- From andrew.hutton@siemens-enterprise.com Sun Jan 29 20:54:27 2012 Return-Path: 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 D315A21F8555 for ; Sun, 29 Jan 2012 20:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 mqGeJDb9sYwf for ; Sun, 29 Jan 2012 20:54:27 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0DC21F8552 for ; Sun, 29 Jan 2012 20:54:26 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B8A131EB843D; Mon, 30 Jan 2012 05:54:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 30 Jan 2012 05:54:25 +0100 From: "Hutton, Andrew" To: Randell Jesup , "rtcweb@ietf.org" Date: Mon, 30 Jan 2012 05:54:21 +0100 Thread-Topic: [rtcweb] SDES draft posted Thread-Index: Aczeq1aSoRrHAtzNTXquFd+CMw3ypQAUdaCw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312006AB738@MCHP058A.global-ad.net> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> <4F258193.3080100@jesup.org> In-Reply-To: <4F258193.3080100@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 04:54:28 -0000 On 1/29/2012 17:28am Randell wrote > >> Andy, > >> > >> Even though the discussion is to provide RTP, SDES, DTLS-SRTP, > >> till now I didn't see anybody ask for fallback mechanism within > these > >> mechanism as it will lead to bid-down attack. I agree with you that > >> any fallback mechanism makes the implementation Complex and > >> unacceptable. > > [AndyH] - I did not say it had to be complex or that any fallback > mechanism would be unacceptable. > > > >> Also, I could not see the point in supporting both SDES and DTLS- > SRTP. > >> In case WebRTC webserver is always trusted, SDES is the solution and > >> Webserver is not trusted, DTLS-SRTP is the solution. > > [AndyH] - I don't think the choice can be made on the basis of > whether the webserver is as trusted DTLS-SRTP may be desirable over > SDES even when the webserver is trusted. It could be for example that > SDES is used as an interim solution until a gateway is updated with > support for DTLS-SRTP and after upgrading the gateway DTLS-SRTP should > just work. >=20 >=20 > Right, but that brings in the entire bid-down (to SDES) issue, and > complexity in signalling this. [AndyH] - Agreed we need to way up the pros and cons however I don't think = choosing SDES over DTLS-SRTP based on whether the webserver is trusted is t= he way forward. I see arguments that actually fallback to SDES would not re= ally be a bid-down but if it is considered to be such by the security exper= ts then I don't see a way forward for SDES. >=20 > My opinion is we first have to decide if we will talk *directly* to > legacy endpoints, without a WebRTC-compliant gateway. =20 [AndyH] - I don't see this as a decision we need to make we have to assume = that gateways are going to be needed in some scenarios. We should not do an= ything that prevents a media gateway being deployed. >This means > requiring support for ICE and a security mechanism (SDES or DTLS-SRTP, > and Cullen indicates some endpoints do support DTLS-SRTP apparently) or > unsecured RTP. We can assume the JS will take the ROAP or JSEP offer > and translate it into SIP/SDP (or the server will). Note that ICE is > required as part of the "don't be a DDOS element" requirement. >=20 > Next we have to decide what's the minimum security level required - > RTP, > SDES, or DTLS-SRTP. >=20 [AndyH] - Agreed the whole issue for me relates to whether SDES is consider= ed to be significantly lower security level to DTLS-SRTP or not. > > Next we have to decide how bid-down attacks would be dealt with, > especially if you don't trust the server. While in some/many cases we > would trust the server, there are other use-cases where we certainly > don't (and having multiple levels of security will invoke our having to > decide how to show this (understandably!) to users in browser chrome, > since we can't allow the app to control showing security). >=20 [AndyH] - If fallback to SDES is really a bid-down attack then I don't see = how SDES can be offered in the 1st place. What I don't want to see is a dec= ision to offer SDES being made on the basis that the server is trusted. How= ever it might be possible to offer both SDES and DTLS-SRTP only in the case= when the server is trusted.=20 > A proposal for supporting legacy devices must answer all of these (in > some manner) to be a viable candidate for consideration. >=20 > My personal (and Mozilla's opinion) is strongly in favor of strong > privacy & security guarantees, and in particular requiring DTLS-SRTP > between WebRTC clients. If a solution to the above issues without > compromising WebRTC<->WebRTC security can be found, I'm open. I > haven't > heard one yet, and so lean towards hard security guarantees and > requiring a gateway to talk to legacy. So if you do know how to do the > entire package, we need that proposal on the table ASAP. >=20 [AndyH] Actually I am tending to agree with you my original post was only s= tating that if both SDES and DTLS-SRTP are offered then we must specify the= fallback method. =20 > > > >> Thanks > >> Partha > >> > >>> -----Original Message----- > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf > >>> Of Hutton, Andrew > >>> Sent: Friday, January 27, 2012 6:55 PM > >>> To: Cullen Jennings; Olle E.Johansson > >>> Cc: rtcweb@ietf.org > >>> Subject: Re: [rtcweb] SDES draft posted > >>> > >>> Also I don't have hard stats but of course SDES is what is > implemented > >>> today in endpoints and gateways that have a requirement for SRTP > which > >> I > >>> think is a large percentage and growing. SDES is also pretty much > >>> interoperable between implementations the main issues that arise > are > >>> around best effort SRTP and that fact that sdp-neg (RFC 5939) is > not > >>> widely implemented. > >>> > >>> So if SDES, DTLS-SRTP and possibly even RTP are going to be options > in > >>> RTCWEB the issue that needs to be clearly specified is the > negotiation > >>> mechanism be it RFC 5939 or something else. I don't believe that a > >>> fallback mechanism based on failure and re-try would be acceptable. > >>> > >>> Regards > >>> Andy > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>> Behalf Of Cullen Jennings > >>>> Sent: 26 January 2012 21:04 > >>>> To: Olle E.Johansson > >>>> Cc: rtcweb@ietf.org > >>>> Subject: Re: [rtcweb] SDES draft posted > >>>> > >>>> > >>>> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: > >>>> > >>>>>> I'd say it's a fair bet that at least 50% of the SIP UA > >>>> implementations available on the market (by market share, not > count > >> of > >>>> implementations) support SRTP with SDES. > >>>>> This is NOT the installed base - it's available on the market. > The > >>>> installed base has a very low amount of SRTP implementations that > >> are > >>>> interoperable > >>>> > >>>> Uh, I pretty much disagree with that thought I don't have hard > stats > >> I > >>>> can point you at. A large percentage of the deployed endpoints and > >>>> gateways do work with SRTP and I don't see a lot of bugs logged > >>>> against them. > >>>> > >>>> _______________________________________________ > >>>> rtcweb mailing list > >>>> rtcweb@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@iii.ca Sun Jan 29 21:37:23 2012 Return-Path: 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 1A31D21F84C8 for ; Sun, 29 Jan 2012 21:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, 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 CAdCA4UIEHIL for ; Sun, 29 Jan 2012 21:37:21 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E80EE21F84B5 for ; Sun, 29 Jan 2012 21:37:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHQrJk+rRDoI/2dsb2JhbABDrluBBYFyAQEBAwEBAQEPASc0CwULCxgnBycfEQYTIodaCZojAZ1QBIg8BgMLBAsGBA8BCAEFCQYDBIMZAxUCCwMCZIMIYwSIP5IxjRs X-IronPort-AV: E=Sophos;i="4.71,590,1320624000"; d="scan'208";a="27759799" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Jan 2012 05:37:19 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0U5bJSG005552; Mon, 30 Jan 2012 05:37:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4F0F56AE.80306@jesup.org> Date: Sun, 29 Jan 2012 22:37:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <773E3E2F-8A66-4113-AD76-CAB83E79BFDD@iii.ca> References: <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <4F0DFD0B.2000009@jesup.org> <4F0EA4BA.5040809@alvestrand.no> <4F0F56AE.80 306@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] state of libsrtp maintenance? (Re: SRTP not mandatory-to-use) X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 05:37:23 -0000 Making libsrtp so it had a compile time flag to use the openssl crypto = or select it's own crypto seem like it would be a nice improvement to it = but lots of the places folks want to use libsrtp is a DSP of some sort - = it cab be a big hassle to try and port all of the crypto from openssl to = that type of environment so probably would not want to have it require = openssl.=20 On Jan 12, 2012, at 2:54 PM, Randell Jesup wrote: > On 1/12/2012 11:18 AM, Roman Shpount wrote: >>=20 >> On Thu, Jan 12, 2012 at 9:37 AM, Eric Rescorla > > wrote: >>=20 >> DTLS-SRTP was specifically designed so that one could put together = a >> DTLS >> stack and an SRTP stack with minimal modifications to both (and no >> necessary >> modifications to the SRTP stack). In the case of OpenSSL and >> libsrtp, you >> do the OpenSSL handshake, then use a new interface to export the = keys >> which you then push onto libsrtp using existing interfaces. >>=20 >> My point is if you use OpenSSL crypto functions you can replace = libsrtp >> with a few hundred lines of code. It is almost easier then = integrating >> with libsrtp (and introduce another instance of unoptimized = encryption >> and check sum functions). >=20 > I'm not tied to libsrtp - though I have commit privileges for it, and = made a bunch of improvements and fixes to it back in the 2004-2005 = timeframe (SRTCP was broken, remove dependence on long long, etc), since = which point (around 2006) it's been very stable outside of a very = occasional patch. >=20 > Last set of changes generally seem to be around a year and half ago by = Jonathan Lennox. (A few minor C99 changes this fall). >=20 > It does the job. Perhaps you can replace it with a few hundred lines = of OpenSSL code; I have to say I'd be surprised. But srtp.c is ~2000 = lines; I can believe OpenSSL would replace most of the crypto files; = you'd still need much of the logic in srtp.c and perhaps the replay = code. >=20 > And realize we're not specifying libsrtp, just SRTP - so your comment = that libsrtp can be replaced with OpenSSL plus some code is simply more = indication that SRTP implementations are not a blocker. >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Jan 29 22:44:34 2012 Return-Path: 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 6652121F859B for ; Sun, 29 Jan 2012 22:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] 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 ZkCo6qfOvoZN for ; Sun, 29 Jan 2012 22:44:33 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4077D21F8592 for ; Sun, 29 Jan 2012 22:44:33 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0U6jHNL002212; Mon, 30 Jan 2012 01:45:17 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 01:44:31 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 12:14:27 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Mon, 30 Jan 2012 12:14:26 +0530 From: "Ravindran, Parthasarathi" To: "Hutton, Andrew" , Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] SDES draft posted Thread-Index: AczamLkmxJ01MFolQbCHRCQyikwf5///5BgAgAAO3QCAAAofgIAAEPWAgADKlACAAnXggIABEh6A//+fyKD//dohYIAF7niAgAC/04D//5XjUA== Date: Mon, 30 Jan 2012 06:44:26 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E039ED0@inba-mail01.sonusnet.com> References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> <4F258193.3080100@jesup.org> <101C6067BEC68246B0C3F6843BCCC1E312006AB738@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E312006AB738@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 06:44:27.0237 (UTC) FILETIME=[9C5CC150:01CCDF1A] Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 06:44:34 -0000 [AndyH] - If fallback to SDES is really a bid-down attack then I don= 't see how SDES can be offered in the 1st place. The real question is "fallback to SDES is really bid-down attack" as the we= bserver has the access to the crypto keys and possible to intercept the med= ia without trace. Based on IETF-82 security presentation and the mailing di= scussion, I'm convinced that SDES will lead to bid-down attack. Sec 3.2.1 o= f draft-ohlsson-rtcweb-sdes-support-00 also indicates the same.=20 " If both users read their respective fingerprint values over the voice cha= nnel then they can detect if the conversation is being intercepted. However, it is very unlikely that th= e average user would bother doing this." Please note with the above statement that SRTP-DTLS is the only mechanism e= ven for the power-user to identify whether the data is intercepted or not a= nd it is not possible in SDES.=20 In case there is no requirement to identify whether the webserver intercept= or not, SRTP-DTLS is not required and SDES will sufficient for WebRTC. If = the discussion is between different key mechanism like ZRTP, SRTP-DTLS, the= n it is key mechanism negotiation and not fallback. So Still, I didn't see = the need for fallback mechanism between SRTP-DTLS to SDES within WebRTC.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hutton, Andrew >Sent: Monday, January 30, 2012 10:24 AM >To: Randell Jesup; rtcweb@ietf.org >Subject: Re: [rtcweb] SDES draft posted > >On 1/29/2012 17:28am Randell wrote > >> >> Andy, >> >> >> >> Even though the discussion is to provide RTP, SDES, DTLS-SRTP, till >> >> now I didn't see anybody ask for fallback mechanism within >> these >> >> mechanism as it will lead to bid-down attack. I agree with you that >> >> any fallback mechanism makes the implementation Complex and >> >> unacceptable. >> > [AndyH] - I did not say it had to be complex or that any fallback >> mechanism would be unacceptable. >> > >> >> Also, I could not see the point in supporting both SDES and DTLS- >> SRTP. >> >> In case WebRTC webserver is always trusted, SDES is the solution >> >> and Webserver is not trusted, DTLS-SRTP is the solution. >> > [AndyH] - I don't think the choice can be made on the basis of >> whether the webserver is as trusted DTLS-SRTP may be desirable over >> SDES even when the webserver is trusted. It could be for example that >> SDES is used as an interim solution until a gateway is updated with >> support for DTLS-SRTP and after upgrading the gateway DTLS-SRTP should >> just work. >> >> >> Right, but that brings in the entire bid-down (to SDES) issue, and >> complexity in signalling this. > >[AndyH] - Agreed we need to way up the pros and cons however I don't >think choosing SDES over DTLS-SRTP based on whether the webserver is >trusted is the way forward. I see arguments that actually fallback to >SDES would not really be a bid-down but if it is considered to be such >by the security experts then I don't see a way forward for SDES. > >> >> My opinion is we first have to decide if we will talk *directly* to >> legacy endpoints, without a WebRTC-compliant gateway. > >[AndyH] - I don't see this as a decision we need to make we have to >assume that gateways are going to be needed in some scenarios. We should >not do anything that prevents a media gateway being deployed. > >>This means >> requiring support for ICE and a security mechanism (SDES or DTLS-SRTP, >>and Cullen indicates some endpoints do support DTLS-SRTP apparently) or >>unsecured RTP. We can assume the JS will take the ROAP or JSEP offer >>and translate it into SIP/SDP (or the server will). Note that ICE is >>required as part of the "don't be a DDOS element" requirement. >> >> Next we have to decide what's the minimum security level required - >> RTP, SDES, or DTLS-SRTP. >> > >[AndyH] - Agreed the whole issue for me relates to whether SDES is >considered to be significantly lower security level to DTLS-SRTP or not. > > >> >> Next we have to decide how bid-down attacks would be dealt with, >> especially if you don't trust the server. While in some/many cases >we >> would trust the server, there are other use-cases where we certainly >> don't (and having multiple levels of security will invoke our having >to >> decide how to show this (understandably!) to users in browser chrome, >> since we can't allow the app to control showing security). >> >[AndyH] - If fallback to SDES is really a bid-down attack then I don't >see how SDES can be offered in the 1st place. What I don't want to see >is a decision to offer SDES being made on the basis that the server is >trusted. However it might be possible to offer both SDES and DTLS-SRTP >only in the case when the server is trusted. > >> A proposal for supporting legacy devices must answer all of these (in >> some manner) to be a viable candidate for consideration. >> >> My personal (and Mozilla's opinion) is strongly in favor of strong >> privacy & security guarantees, and in particular requiring DTLS-SRTP >> between WebRTC clients. If a solution to the above issues without >> compromising WebRTC<->WebRTC security can be found, I'm open. I >> haven't >> heard one yet, and so lean towards hard security guarantees and >> requiring a gateway to talk to legacy. So if you do know how to do >the >> entire package, we need that proposal on the table ASAP. >> >[AndyH] Actually I am tending to agree with you my original post was >only stating that if both SDES and DTLS-SRTP are offered then we must >specify the fallback method. > > >> > >> >> Thanks >> >> Partha >> >> >> >>> -----Original Message----- >> >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> >> Behalf >> >>> Of Hutton, Andrew >> >>> Sent: Friday, January 27, 2012 6:55 PM >> >>> To: Cullen Jennings; Olle E.Johansson >> >>> Cc: rtcweb@ietf.org >> >>> Subject: Re: [rtcweb] SDES draft posted >> >>> >> >>> Also I don't have hard stats but of course SDES is what is >> implemented >> >>> today in endpoints and gateways that have a requirement for SRTP >> which >> >> I >> >>> think is a large percentage and growing. SDES is also pretty much >> >>> interoperable between implementations the main issues that arise >> are >> >>> around best effort SRTP and that fact that sdp-neg (RFC 5939) is >> not >> >>> widely implemented. >> >>> >> >>> So if SDES, DTLS-SRTP and possibly even RTP are going to be >options >> in >> >>> RTCWEB the issue that needs to be clearly specified is the >> negotiation >> >>> mechanism be it RFC 5939 or something else. I don't believe that a >> >>> fallback mechanism based on failure and re-try would be >acceptable. >> >>> >> >>> Regards >> >>> Andy >> >>> >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> >>>> Behalf Of Cullen Jennings >> >>>> Sent: 26 January 2012 21:04 >> >>>> To: Olle E.Johansson >> >>>> Cc: rtcweb@ietf.org >> >>>> Subject: Re: [rtcweb] SDES draft posted >> >>>> >> >>>> >> >>>> On Jan 25, 2012, at 12:29 AM, Olle E. Johansson wrote: >> >>>> >> >>>>>> I'd say it's a fair bet that at least 50% of the SIP UA >> >>>> implementations available on the market (by market share, not >> count >> >> of >> >>>> implementations) support SRTP with SDES. >> >>>>> This is NOT the installed base - it's available on the market. >> The >> >>>> installed base has a very low amount of SRTP implementations that >> >> are >> >>>> interoperable >> >>>> >> >>>> Uh, I pretty much disagree with that thought I don't have hard >> stats >> >> I >> >>>> can point you at. A large percentage of the deployed endpoints >and >> >>>> gateways do work with SRTP and I don't see a lot of bugs logged >> >>>> against them. >> >>>> >> >>>> _______________________________________________ >> >>>> rtcweb mailing list >> >>>> rtcweb@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/rtcweb >> >>> _______________________________________________ >> >>> rtcweb mailing list >> >>> rtcweb@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> -- >> Randell Jesup >> randell-ietf@jesup.org >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Mon Jan 30 01:13:16 2012 Return-Path: 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 1605D21F861C for ; Mon, 30 Jan 2012 01:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 Vzh4taCkrkvS for ; Mon, 30 Jan 2012 01:13:14 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BACB821F8619 for ; Mon, 30 Jan 2012 01:13:14 -0800 (PST) Received: from [12.131.214.66] (helo=[10.61.33.151]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RrnIY-0000iV-5S for rtcweb@ietf.org; Mon, 30 Jan 2012 03:13:14 -0600 Message-ID: <4F265F27.50000@jesup.org> Date: Mon, 30 Jan 2012 01:13:11 -0800 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4F1EEECC.80200@digium.com> <4F1F0583.7070202@digium.com> <15FF98F4-EC5F-41C7-BFC5-087BA8DD70AA@edvina.net> <9FCCE6EF-A260-49A7-9F97-E36A6E7808D3@iii.ca> <101C6067BEC68246B0C3F6843BCCC1E312006AB3F0@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C01DD3267@inba-mail02.sonusnet.com> <101C6067BEC68246B0C3F6843BCCC1E312006AB70C@MCHP058A.global-ad.net> <4F258193.3080100@jesup.org> <101C6067BEC68246B0C3F6843BCCC1E312006AB738@MCHP058A.global-ad.net> <387F9047F55E8C42850AD6B3A7A03C6C0E039ED0@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E039ED0@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] SDES draft posted X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 09:13:16 -0000 On 1/29/2012 10:44 PM, Ravindran, Parthasarathi wrote: > [AndyH] - If fallback to SDES is really a bid-down attack then I don't see how SDES can be offered in the 1st place. > > The real question is "fallback to SDES is really bid-down attack" as the webserver has the access to the crypto keys and possible to intercept the media without trace. Based on IETF-82 security presentation and the mailing discussion, I'm convinced that SDES will lead to bid-down attack. Sec 3.2.1 of draft-ohlsson-rtcweb-sdes-support-00 also indicates the same. Correct. There's no doubt that SDES is less secure than DTLS-SRTP, though the added security of DTLS-SRTP may be minor if there's no way to authenticate whom you're connected to (i.e. detect MITM attacks). We should be able to do identity validation, however, so the added security is significant. I have a good usecase ("pokerstars.net") where this added security is really important, where the central server being used may have been compromised by someone wanting to listen in on you planning strategy/bluffs/etc with another player while waiting for your round. There are other ones involving political movements. > " If both users read their respective fingerprint values over the voice channel then they can detect if the > conversation is being intercepted. However, it is very unlikely that the average user would bother doing this." > > Please note with the above statement that SRTP-DTLS is the only mechanism even for the power-user to identify whether the data is intercepted or not and it is not possible in SDES. Exactly. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Mon Jan 30 11:10:26 2012 Return-Path: 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 C065821F85FC for ; Mon, 30 Jan 2012 11:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] 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 53oWXaiWPfeu for ; Mon, 30 Jan 2012 11:10:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19921F85E1 for ; Mon, 30 Jan 2012 11:10:18 -0800 (PST) Received: by ghbg16 with SMTP id g16so2144519ghb.31 for ; Mon, 30 Jan 2012 11:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=uV7EhvkOVw0JFr5fSYZX4hbdEPnX1Q8X+Qppd/fl3e0=; b=qQlB0DuMZa3Tva8VEmQbQY0mvYaA74xHE2wgR3apnKFbxRMMs5zEqivCMHghyfpdk+ RHkreGGfODGZ/LC+UvvQX9nirNs/7MFY5kHI9d2fVOXv0Zz4PFp//33hAgaWM6kh1UJ2 wZZNVJ0YLJTZvrvggC5A+xG3xFPu1kliKu++o= MIME-Version: 1.0 Received: by 10.236.200.164 with SMTP id z24mr28648388yhn.52.1327950618606; Mon, 30 Jan 2012 11:10:18 -0800 (PST) Received: by 10.236.103.232 with HTTP; Mon, 30 Jan 2012 11:10:18 -0800 (PST) Date: Mon, 30 Jan 2012 11:10:18 -0800 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Webex details for interim meeting X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 19:10:26 -0000 Thanks to Cullen for providing this webex session for us. > Topic: IETF & W3C WebRTC Meeting > Date: Every 1 day, from Tuesday, January 31, 2012 to Wednesday, February 1, 2012 > Time: 8:30 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 200 918 637 > Meeting Password: webrtc > > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=184776042&UID=482186897&PW=NZjdjOGUzZTVl&RT=MiM0 > 2. Log in to your account. > 3. Click "Start Now". > 4. Follow the instructions that appear on your screen. > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". > To add this meeting to your calendar program (for example Microsoft Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=184776042&UID=482186897&ICS=MS&LD=1&RD=2&ST=1&SHA2=A5cExiZhVPaUjrT9yAMN4m2uank2iLcpulQBZ6s2ncE= > > To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://cisco.webex.com/ciscosales/systemdiagnosis.php > > http://www.webex.com > From giles@thaumas.net Mon Jan 30 11:56:04 2012 Return-Path: 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 42F9E11E80B0 for ; Mon, 30 Jan 2012 11:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 OwqXCBS0bCtU for ; Mon, 30 Jan 2012 11:56:03 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A281D11E80AF for ; Mon, 30 Jan 2012 11:56:03 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so3348182vcb.31 for ; Mon, 30 Jan 2012 11:56:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.148.196 with SMTP id q4mr10158777vcv.42.1327953363181; Mon, 30 Jan 2012 11:56:03 -0800 (PST) Received: by 10.220.115.81 with HTTP; Mon, 30 Jan 2012 11:56:03 -0800 (PST) X-Originating-IP: [184.71.182.138] In-Reply-To: References: Date: Tue, 31 Jan 2012 08:56:03 +1300 Message-ID: From: Ralph Giles To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Webex details for interim meeting X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 19:56:04 -0000 On 31 January 2012 08:10, Ted Hardie wrote: > Thanks to Cullen for providing this webex session for us. Thanks! No webrtc option? :-) -r From henry.sinnreich@gmail.com Mon Jan 30 12:07:06 2012 Return-Path: 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 8C69811E8093 for ; Mon, 30 Jan 2012 12:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 77z8sSZ+gidk for ; Mon, 30 Jan 2012 12:07:05 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4E11E8091 for ; Mon, 30 Jan 2012 12:07:05 -0800 (PST) Received: by yhnn12 with SMTP id n12so2161351yhn.31 for ; Mon, 30 Jan 2012 12:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type; bh=PFwSVBS6/29cvq0OonqnYWELeht7XzxoBAessDOp4ic=; b=J1uQSXrs2CaDX6dvSSQaXdokuBaOnpfvBBKbdOav48mojxTzCTQ4KrhUVo8+eIvJol B6mTKdMnuGsm47hd/YmdyH6u9FBnGKsdPfM//jOBai5MeBYcX9RWVHAXDoobWnWn0Smd /RE2gRv6w8D4UqnNIsCx3hmj5sDWYTR8P7LfM= Received: by 10.236.128.205 with SMTP id f53mr28805726yhi.111.1327954025284; Mon, 30 Jan 2012 12:07:05 -0800 (PST) Received: from [192.168.0.91] (cpe-76-184-228-98.tx.res.rr.com. [76.184.228.98]) by mx.google.com with ESMTPS id k16sm48945978ani.5.2012.01.30.12.07.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 12:07:04 -0800 (PST) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 30 Jan 2012 14:07:03 -0600 From: Henry Sinnreich To: Justin Uberti , Message-ID: Thread-Topic: JSEP terminology Thread-Index: Aczfirtvo2A/DBs1m0CWQ5c/P7Z+OQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3410777225_3895988" Subject: [rtcweb] JSEP terminology X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 20:07:06 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3410777225_3895988 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Here is just a nit to an otherwise true groundbreaking and quite frankly, IMHO long overdue and refreshing approach and it=B9s about terminology. What is the =B3media plane=B2 (par 4.3)? Does it have two dimensions and if yes= , what are they? IMO there are many other terms that are better suited, such as =B3media streams=B2, etc. =20 As is, the =B3media plane=B2 terminology is just a reminder of certain legacy =B3control planes=B2 that should remain here unnamed :-) Thanks, Henry --B_3410777225_3895988 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable JSEP terminology Here is just a nit to an otherwise true groundbreaking and quite frankly, = IMHO long overdue and refreshing approach and it’s about terminology.<= BR>
What is the “media plane” (par 4.3)? Does it have two dimension= s and if yes, what are they?
IMO there are many other terms that are better suited, such as “media= streams”, etc.
 
As is, the “media plane” terminology is just a reminder of cert= ain legacy “control planes” that should remain here unnamed :-)<= BR>
Thanks, Henry --B_3410777225_3895988-- From dwing@cisco.com Mon Jan 30 15:37:17 2012 Return-Path: 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 D27F211E80DC for ; Mon, 30 Jan 2012 15:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 xqIvE7aGJ+8G for ; Mon, 30 Jan 2012 15:37:17 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1211E80D7 for ; Mon, 30 Jan 2012 15:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2839; q=dns/txt; s=iport; t=1327966637; x=1329176237; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=AJt/JvI+EEHOBKUqrYFWD1bRAlbZoo8SIGzZzgBUv38=; b=MsJsBTMhQ1Z84ImASyKrFP5DkRJ4JTGPrzjlZWZL7AymVlksDj2sX3eN OIFmL+pvmYXzwmMcr6DXObg554K41UrFdac7Opz2Bvbrnl2FdgOPhV/kq +43dyfNBQcLPV4LAFaNRMuiRYxCUeaSbYovDnBrzXRojmEONUwv6lzu3A 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMooJ0+rRDoG/2dsb2JhbABDn2eOcIEFgXIBAQEDAQEBAQUKARQDEDEDEAcBAwIJDgECBAEBKAcZDhUKCQgBAQQBEgsXh1oJmh4BnjkEin8BKQwBAQkEFAsPCoQOAhKDWASIP4UEmkk X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="27908990" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Jan 2012 23:37:17 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0UNbGpJ002087; Mon, 30 Jan 2012 23:37:16 GMT From: "Dan Wing" To: "'Eric Rescorla'" , References: In-Reply-To: Date: Mon, 30 Jan 2012 15:37:16 -0800 Message-ID: <062f01ccdfa8$19fd4430$4df7cc90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczcYD1H4eEWGZ7nTCincGBdTe6hKADR01HQ Content-Language: en-us Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Mon, 30 Jan 2012 23:37:17 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Thursday, January 26, 2012 11:25 AM > To: rtcweb@ietf.org > Subject: [rtcweb] Trickle ICE in practice > > Hi Justin, > > i've been thinking about how ICE works in JSEP and ISTM that the API > may not be emitting enough information to work here. As I understand > it, the following is a reasonable order of operations: > > Alice->Bob: Offer > Alice->Bob: ICE candidates > Bob->Alice: ICE candidates > // ICE happens > // Bob answers > Bob->Alice: Answer > > Unless I'm missing something, though, Alice and Bob can't start doing > ICE until they have exchanged the ice-ufrag and ice-pwd > properties. Alice sends these in her offer, so this is no problem, but > they would ordinarily be in Bob's answer, but that gets delayed, and > they're not in Bob's ICE candidates, so I don't think they can start > ICE until Bob's answer arrives. Alice can respond to Bob's incoming connectivity checks before receiving Bob's answer. However, Alice cannot validate the incoming connectivity checks really came from Bob until she receives Bob's ice-ufrag and ice-pwd. That isn't a problem; she can validate them later. -d > I suspect that what we need here is > something more like an XEP-0176 element, which would > contain the pwd and ufrag. This also has the potential to solve the > problem you raise at the end of how to associate each candidate with > the relevant media stream, since we can stuff a pointer in that > structure. [Note: I am not an SDP expert, so I don't have an opinion > on the best form of that pointer. As you know, in ordinary ICE-SDP, > this info is just assocaited with the m-line by counting.] > > While we're on the topic of stuffing stuff here, it would be pretty > nice to know in advance if you are going to bundle, so you're not > thinking you're going to do ICE on channels which you don't want. As > you pointed out in another message, it's also natural to put the DTLS > info here, so that we can get DTLS started early. In general, I think > if we're going to separate transport and media signaling, we should > probably be thinking about if there is anything else that really needs > to be delivered prior to Bob's decision to answer the phone. > > Finally, as you point out in Appendix A, we don't currently know when > you have all your candidates, which makes it hard to implement SIP > compatibility from this API. I'm not 100% sure what the best API is > here: do we want to know when all candidates are found or just all for > a given flow? > > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Mon Jan 30 16:08:29 2012 Return-Path: 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 A281811E80DF for ; Mon, 30 Jan 2012 16:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 nyKzSjFA+d1R for ; Mon, 30 Jan 2012 16:08:29 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2DBC11E80D9 for ; Mon, 30 Jan 2012 16:08:28 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3500988vbb.31 for ; Mon, 30 Jan 2012 16:08:28 -0800 (PST) Received: by 10.52.95.233 with SMTP id dn9mr9197383vdb.7.1327968508222; Mon, 30 Jan 2012 16:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Mon, 30 Jan 2012 16:07:48 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <062f01ccdfa8$19fd4430$4df7cc90$@com> References: <062f01ccdfa8$19fd4430$4df7cc90$@com> From: Eric Rescorla Date: Mon, 30 Jan 2012 16:07:48 -0800 Message-ID: To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 00:08:29 -0000 On Mon, Jan 30, 2012 at 3:37 PM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Thursday, January 26, 2012 11:25 AM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Trickle ICE in practice >> >> Hi Justin, >> >> i've been thinking about how ICE works in JSEP and ISTM that the API >> may not be emitting enough information to work here. As I understand >> it, the following is a reasonable order of operations: >> >> Alice->Bob: Offer >> Alice->Bob: ICE candidates >> Bob->Alice: ICE candidates >> // ICE happens >> // Bob answers >> Bob->Alice: Answer >> >> Unless I'm missing something, though, Alice and Bob can't start doing >> ICE until they have exchanged the ice-ufrag and ice-pwd >> properties. Alice sends these in her offer, so this is no problem, but >> they would ordinarily be in Bob's answer, but that gets delayed, and >> they're not in Bob's ICE candidates, so I don't think they can start >> ICE until Bob's answer arrives. > > Alice can respond to Bob's incoming connectivity checks before receiving > Bob's answer. =A0However, Alice cannot validate the incoming connectivity > checks really came from Bob until she receives Bob's ice-ufrag and > ice-pwd. =A0That isn't a problem; she can validate them later. If both are behind address-restricted NATs, don't Bob's connectivity checks just get dropped? -Ekr From dwing@cisco.com Mon Jan 30 17:31:03 2012 Return-Path: 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 2EA3511E80D9 for ; Mon, 30 Jan 2012 17:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 paz3vFuZTlqA for ; Mon, 30 Jan 2012 17:31:02 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3421F873C for ; Mon, 30 Jan 2012 17:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3229; q=dns/txt; s=iport; t=1327973462; x=1329183062; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=rhppP0kC/DpfqxJ9Q6pHUXqOPzAvt9qS8G5Hj6/yC1Y=; b=VnMRXNWjIkKBooM8CUFA3wwF6jVbpbcbjNoP0kiQgIFQutgtRLlRnVev IPZ+DmwHh9xx9s6LFZ+sM8ubYf6pc1d+zfbgm+iO829qSLvZWNZIVpemL ZdweLixtc9jij0Ujri5k+dykoruShhSbBgKp69qBq/MVFy04CAue/Gjne M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAH5DJ0+rRDoH/2dsb2JhbABDn2eOcIEFgXIBAQEECAoBFANGCQwBAwIJDgECBAEBAScHGSMKCQgBAQQTCw4Joh0BnkqKfisMAQEJBBQLDwqEDgISg1gEiAwzhQSaSQ X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="26202424" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 31 Jan 2012 01:31:02 +0000 Received: from dwingWS ([10.32.240.198]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0V1V2Aj024374; Tue, 31 Jan 2012 01:31:02 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <062f01ccdfa8$19fd4430$4df7cc90$@com> In-Reply-To: Date: Mon, 30 Jan 2012 17:31:02 -0800 Message-ID: <06f901ccdfb7$fe466fe0$fad34fa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczfrH4bmvb1Fg0aRmahE95D/mBiuQACc4/w Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 01:31:03 -0000 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Monday, January 30, 2012 4:08 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Trickle ICE in practice >=20 > On Mon, Jan 30, 2012 at 3:37 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Thursday, January 26, 2012 11:25 AM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Trickle ICE in practice > >> > >> Hi Justin, > >> > >> i've been thinking about how ICE works in JSEP and ISTM that the = API > >> may not be emitting enough information to work here. As I = understand > >> it, the following is a reasonable order of operations: > >> > >> Alice->Bob: Offer > >> Alice->Bob: ICE candidates > >> Bob->Alice: ICE candidates > >> // ICE happens > >> // Bob answers > >> Bob->Alice: Answer > >> > >> Unless I'm missing something, though, Alice and Bob can't start > doing > >> ICE until they have exchanged the ice-ufrag and ice-pwd > >> properties. Alice sends these in her offer, so this is no problem, > but > >> they would ordinarily be in Bob's answer, but that gets delayed, = and > >> they're not in Bob's ICE candidates, so I don't think they can = start > >> ICE until Bob's answer arrives. > > > > Alice can respond to Bob's incoming connectivity checks before > receiving > > Bob's answer. =A0However, Alice cannot validate the incoming > connectivity > > checks really came from Bob until she receives Bob's ice-ufrag and > > ice-pwd. =A0That isn't a problem; she can validate them later. >=20 > If both are behind address-restricted NATs, don't Bob's connectivity > checks just get dropped? Bob is sending the packets to Alice, so his NAT's filtering does not come into play. You are correct that if Alice has an address-filtering NAT, Bob's connectivity checks will be dropped by Alice's NAT. They will be dropped until Alice receives Bob's Answer and Alice sends a=20 connectivity check to Bob's IP address. At that point, Bob's connectivity checks will be allowed by Alice's NAT. ICE has Bob send that connectivity check immediately upon receiving=20 a check from Alice, for just this reason. How often a typical "Alice" might be behind an address-filtering NAT is something that can be measured in the wild. I have not=20 seen reliable numbers of such testing in the wild, but 25% has=20 been mentioned. There are known geographies (e.g., Switzerland)=20 where the number is higher because the major ISP provided address-filtering NAT to their subscribers. The same problem described above also exists for IPv6, because=20 IPv6 residential-class CPE ship with filtering enabled by default. I expect small/medium businesses and enterprises will also do IPv6 filtering for all the (good) reasons the do IPv4 filtering today. Said another way - it ain't just NAT's fault that life is like this. If Alice's client application (and/or OS) and NAT (or firewall)=20 implement a mapping protocol (e.g., NAT-PMP, UPnP IGD, or PCP),=20 then Bob's connectivity checks will not suffer any delay. -d From harald@alvestrand.no Mon Jan 30 21:59:04 2012 Return-Path: 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 6230521F8795 for ; Mon, 30 Jan 2012 21:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.53 X-Spam-Level: X-Spam-Status: No, score=-109.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, 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 FKJXn1TC558Q for ; Mon, 30 Jan 2012 21:59:02 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCC21F8799 for ; Mon, 30 Jan 2012 21:59:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C123639E0F5; Tue, 31 Jan 2012 06:58:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnQ8U8S3ku-K; Tue, 31 Jan 2012 06:58:58 +0100 (CET) Received: from [192.168.128.222] (173-164-173-13-SFBA.hfc.comcastbusiness.net [173.164.173.13]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 724D539E0E7; Tue, 31 Jan 2012 06:58:57 +0100 (CET) Message-ID: <4F26E84B.7010301@alvestrand.no> Date: Mon, 30 Jan 2012 19:58:19 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Michael Tuexen References: <4F15A1A3.6000304@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 05:59:04 -0000 Thanks again! I've now spent a little time playing with it - it's been long since I've worked with C at this level! One question I have is the handling of port numbers ... the way it currently seems to be structured, the SCTP layer is initialized with a listening UDP port number as a parameter to the sctp_init function, and the remote port is set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, on the listening socket (from discard_server.c) and the active socket (from client.c). So both when listening and when calling out, the remote UDP port is a necessary property of the socket. This would mean that the mode of operation in an SCTP implementation embedded in a browser would be: For each browser: - Initialize SCTP to a single random local UDP port For each PeerConnection desiring to use data: - Perform ICE candidate finding to get candidates for this UDP port (or reuse) - Perform ICE negotiation to associate the single UDP port to a remote UDP port - Open an userspace SCTP socket and bind this to the remote UDP port (and address) of the best candidate - (Use some DTLS mechanism to initialize DTLS as an encrypting sublayer for SCTP) - One of the ends takes the initiative to set up the SCTP connection between the two - Channels are then opened at will Does that seem approximately right to you? Harald On 01/20/2012 01:02 PM, Michael Tuexen wrote: > On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: > >> (after a long delay) >> thank you very much for the input! >> >> I've downloaded and compiled the code, but haven't yet found out how to do the typical "hello world" call with the binaries provided. >> >> Could you give us a note saying "do this and see the packets flow"? > Hi Harald, > > an updated version of the user-land stack is available from > http://sctp.fh-muenster.de/sctp-user-land-stack.html > > It now supports the platforms Windows in addition to FreeBSD, Linux and Mac OS X. > It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation variants > SCTP/UDP/IPv4 and SCTP/UDP/IPv6. > > In libusrsctp-0.9.0/programs you find examples programs. > > Please note that you need to run the programs with root privileges, > if you want to use native SCTP/IPv4 or SCTP/IPv6. > > For example, you can run > sudo ./discard_server > in one shell and > sudo ./client 127.0.0.1 9 > in another shell. > Whatever you type on the console will be sent to the discard server. > Wireshark will show the packets. > > If you want to use UDP encapsulation, you can run > ./discard_server 9899 9999 > in one shell and > ./client 127.0.0.1 9 9999 9899 > in another shell. > > Things are simpler, if you run the stack on two separate machines: > ./discard_server > on one machine. > ./client a.b.c.d 9 9899 9899 > on the other. > > Please note that the demo programs disable the sending of ABORTs > in response to out of the blue packets to allow running multiple > stacks on the same host. This is done by the line > SCTP_BASE_SYSCTL(sctp_blackhole) = 2; > in the code. (On FreeBSD / Mac OS X kernel versions, you have such > a sysctl). > > I hope this helps. If you have any further questions or issues, > please let me know. > > Best regards > Michael >> Harald, experimenter >> >> On 11/18/2011 02:17 PM, Michael Tüxen wrote: >>> Dear all, >>> >>> I just wanted to let you know that the initial version of the >>> SCTP user-land stack based on the FreeBSD kernel code for SCTP >>> is available at >>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>> >>> It currently support FreeBSD, Linux and Mac OS X. We are >>> currently working on adding support for Windows, adding >>> more examples and improving the API. >>> >>> Best regards >>> Michael >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> > From ekr@rtfm.com Mon Jan 30 22:06:52 2012 Return-Path: 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 85C2E21F87B6 for ; Mon, 30 Jan 2012 22:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 sKmiO9xwhRsK for ; Mon, 30 Jan 2012 22:06:51 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A321F87B2 for ; Mon, 30 Jan 2012 22:06:38 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so3672755vbb.31 for ; Mon, 30 Jan 2012 22:06:37 -0800 (PST) Received: by 10.52.27.70 with SMTP id r6mr9567975vdg.41.1327989996124; Mon, 30 Jan 2012 22:06:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.71.19 with HTTP; Mon, 30 Jan 2012 22:05:56 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F26E84B.7010301@alvestrand.no> References: <4F15A1A3.6000304@alvestrand.no> <4F26E84B.7010301@alvestrand.no> From: Eric Rescorla Date: Mon, 30 Jan 2012 22:05:56 -0800 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 06:06:52 -0000 On Mon, Jan 30, 2012 at 10:58 AM, Harald Alvestrand wrote: > Thanks again! > > I've now spent a little time playing with it - it's been long since I've > worked with C at this level! > > One question I have is the handling of port numbers ... the way it curren= tly > seems to be structured, the SCTP layer is initialized with a listening UD= P > port number as a parameter to the sctp_init function, and the remote port= is > set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, on the listening soc= ket > (from discard_server.c) and the active socket (from client.c). So both wh= en > listening and when calling out, the remote UDP port is a necessary proper= ty > of the socket. > > This would mean that the mode of operation in an SCTP implementation > embedded in a browser would be: > > For each browser: > - Initialize SCTP to a single random local UDP port > For each PeerConnection desiring to use data: > - Perform ICE candidate finding to get candidates for this UDP port (or > reuse) > - Perform ICE negotiation to associate the single UDP port to a remote UD= P > port > - Open an userspace SCTP socket and bind this to the remote UDP port (and > address) of the best candidate This seems problematic, since the ICE stack can change candidates unbeknownst to the upper layers. IMO the SCTP stack needs to be bound to an abstract datagram channel API, not to UDP transport. This is certainly how I've anticipated DTLS would work in the absence of SCTP. > - (Use some DTLS mechanism to initialize DTLS as an encrypting sublayer f= or > SCTP) I'm not sure I understand this. If you're going to use SCTP over DTLS, then you would put a DTLS shim under the SCTP layer (see above about the abstract API). OTOH, if you're going to do DTLS over SCTP, then you would probably just do SCTP negotiation and then stack DTLS over top. -Ekr > - One of the ends takes the initiative to set up the SCTP connection betw= een > the two > - Channels are then opened at will > > Does that seem approximately right to you? > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > On 01/20/2012 01:02 PM, Michael Tuexen wrote: >> >> On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: >> >>> (after a long delay) >>> thank you very much for the input! >>> >>> I've downloaded and compiled the code, but haven't yet found out how to >>> do the typical "hello world" call with the binaries provided. >>> >>> Could you give us a note saying "do this and see the packets flow"? >> >> Hi Harald, >> >> an updated version of the user-land stack is available from >> http://sctp.fh-muenster.de/sctp-user-land-stack.html >> >> It now supports the platforms Windows in addition to FreeBSD, Linux and >> Mac OS X. >> It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation variant= s >> SCTP/UDP/IPv4 and SCTP/UDP/IPv6. >> >> In libusrsctp-0.9.0/programs you find examples programs. >> >> Please note that you need to run the programs with root privileges, >> if you want to use native SCTP/IPv4 or SCTP/IPv6. >> >> For example, you can run >> sudo ./discard_server >> in one shell and >> sudo ./client 127.0.0.1 9 >> in another shell. >> Whatever you type on the console will be sent to the discard server. >> Wireshark will show the packets. >> >> If you want to use UDP encapsulation, you can run >> ./discard_server 9899 9999 >> in one shell and >> ./client 127.0.0.1 9 9999 9899 >> in another shell. >> >> Things are simpler, if you run the stack on two separate machines: >> ./discard_server >> on one machine. >> ./client a.b.c.d 9 9899 9899 >> on the other. >> >> Please note that the demo programs disable the sending of ABORTs >> in response to out of the blue packets to allow running multiple >> stacks on the same host. This is done by the line >> =A0 =A0 =A0 =A0SCTP_BASE_SYSCTL(sctp_blackhole) =3D 2; >> in the code. (On FreeBSD / Mac OS X kernel versions, you have such >> a sysctl). >> >> I hope this helps. If you have any further questions or issues, >> please let me know. >> >> Best regards >> Michael >>> >>> =A0 =A0 =A0 =A0 =A0 Harald, experimenter >>> >>> On 11/18/2011 02:17 PM, Michael T=FCxen wrote: >>>> >>>> Dear all, >>>> >>>> I just wanted to let you know that the initial version of the >>>> SCTP user-land stack based on the FreeBSD kernel code for SCTP >>>> is available at >>>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>>> >>>> It currently support FreeBSD, Linux and Mac OS X. We are >>>> currently working on adding support for Windows, adding >>>> more examples and improving the API. >>>> >>>> Best regards >>>> Michael >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Jan 30 22:30:43 2012 Return-Path: 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 AA3DB21F871A for ; Mon, 30 Jan 2012 22:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 v+NN53Rqd1Ft for ; Mon, 30 Jan 2012 22:30:41 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3021F8551 for ; Mon, 30 Jan 2012 22:30:41 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0V6VOYk026291; Tue, 31 Jan 2012 01:31:24 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 01:22:30 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 11:52:28 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 31 Jan 2012 11:52:27 +0530 From: "Ravindran, Parthasarathi" To: Justin Uberti , "rtcweb@ietf.org" , "public-webrtc@w3.org" Thread-Topic: [rtcweb] Initial JSEP draft posted Thread-Index: AQHM2l0nX3kc25ZM2UOzSeJiqbKZKJYmCSGg Date: Tue, 31 Jan 2012 06:22:26 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03B687@inba-mail01.sonusnet.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.56] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E03B687inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2012 06:22:28.0528 (UTC) FILETIME=[B4C37B00:01CCDFE0] Subject: Re: [rtcweb] Initial JSEP draft posted X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 06:30:43 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03B687inbamail01sonus_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpNeSBpbml0aWFsIHJldmlldyBjb21tZW50cyBhcmUgYXMgZm9sbG93czoN Cg0KMSkgU2VjIDEgKEludHJvZHVjdGlvbikgUGFyYSAzIGluZGljYXRlcyB0aGUgZHJhd2JhY2sg d2l0aCBTRFAgYmxvYiBmcm9tIHRoZSBicm93c2VyIGlzIHRoYXQgZGV0ZXJtaW5pbmcgb2ZmZXIv YW5zd2VyIGluZm9ybWF0aW9uIGluIHRoZSBicm93c2VyLiBNeSByZWFkaW5nIGZyb20gdGhpcyBz dGF0ZW1lbnQgaXMgdGhhdCBicm93c2VyIG5lZWRzIG9mZmVyL2Fuc3dlciBzdGF0ZSBtYWNoaW5l LiBBbHNvLCBTZWMgMiAoSlNFUCBhcHByb2FjaCkgUGFyYSAyIGNhbGxzIGNyZWF0ZU9mZmVyIEFQ SSBpbiBicm93c2VyIHRvIHNldCB0aGUgb2ZmZXIgaW4gdGhlIGJyb3dzZXIgPyBTbywgSlNFUCAg ZG9lcyBub3QgbW92ZSBvZmZlci9hbnN3ZXIgc3RhdGUgbWFjaGluZSB0byBKYXZhU2NyaXB0IGJ1 dCBsb29rcyBsaWtlIHRoZSBhaW0gb2YgSlNFUCBpcyB0byBtb3ZlIGRldGVybWluaW5nIG9mZmVy L2Fuc3dlciBvdXQgb2YgYnJvd3NlciBhbmQgaW5mb3JtIG9mZmVyL2Fuc3dlciB3aGVuZXZlciBu ZWVkZWQgdG8gdGhlIGJyb3dzZXIuICBGU00gaXMgaW4gSmF2YVNjcmlwdCBhbmQgYWN0aW9uIGhh bmRsZXIgYXJlIGluIGJyb3dzZXIuIFdoZXRoZXIgdGhpcyB1bmRlcnN0YW5kaW5nIGlzIGNvcnJl Y3Qgb3Igbm90Pw0KDQoyKSBNeSB1bmRlcnN0YW5kaW5nIG9mIFNlYyAxIChJbnRyb2R1Y3Rpb24p IFBhcmEgNCBpcyB0aGF0IG9mZmVyL2Fuc3dlciAoUkZDIDMyNjQpIGlzIG5vdCBtZWV0aW5nIHRo ZSByZXF1aXJlbWVudHMgb2YgSmluZ2xlIGtpbmQgb2Ygc2lnbmFsaW5nIHByb3RvY29sLiBJIGFn cmVlIHRoYXQgaXQgaXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IHRvIFJPQVAgaW4gdGhlIGN1cnJl bnQgZm9ybS4gQnV0IEknbSBub3QgY29udmluY2VkIHRoYXQgdGhlIHNvbHV0aW9uIGZvciB0aGlz IHJlcXVpcmVtZW50IGlzIHRvIG1vdmUgb2ZmZXIvYW5zd2VyIG1lY2hhbmlzbSB0byB0aGUgYXBw bGljYXRpb24gKEphdmFTY3JpcHQpLiBJTU8sIHdlIG5lZWQgdG8gdW5kZXJzdGFuZCBtb3JlIG9m ZmVyL2Fuc3dlciByZXF1aXJlbWVudCBsaWtlIEppbmdsZSBhbmQgdHJ5IHRvIGNvbWUgdXAgd2l0 aCB0aGUgZW5oYW5jZWQgb2ZmZXIvYW5zd2VyIG1lY2hhbmlzbSBmb3IgV2ViUlRDIHJhdGhlciB0 aGFuIHB1c2hpbmcgdGhlIGludGVsbGlnZW5jZSB0byBhcHBsaWNhdGlvbi4gUGxlYXNlIG5vdGUg dGhhdCBldmVuIGluIGNhc2Ugb2YgU0lQIGltcGxlbWVudGF0aW9uLCBSRkMgMzI2MSAmIFJGQyA2 MzM3IGhhcyB0byBiZSBjb25zaWRlcmVkIGFwYXJ0IGZyb20gUkZDIDMyNjQgZm9yIHNtb290aCBp bnRlcm9wIG9mIGJhc2ljIHNlc3Npb24gZXN0YWJsaXNobWVudC4NCg0KMykgSXQgaXMgbm90IHBv c3NpYmxlIHRvIG1haW50YWluIG9mZmVyL2Fuc3dlciBzdGF0ZSBtYWNoaW5lIGluIGJyb3dzZXIg KGR1cmluZyBicm93c2VyIHJlbG9hZCkgaG93IGl0IGlzIHBvc3NpYmxlIHRvIG1haW50YWluIElD RSBzdGF0ZSBtYWNoaW5lDQoNCjQpIEphdmFTY3JpcHQgbGlicmFyeSB3aWxsIG5ldmVyIGJlIHRo ZSBzb2x1dGlvbiBhbmQgaXQgaXMganVzdCBhIHdvcmthcm91bmQgZnJvbSB0aGUgcHJvdG9jb2wg c3RhbmRwb2ludC4gVGhlIHByb2JsZW0gd2l0aCAzcmQgcGFydHkgSmF2YVNjcmlwdCBsaWJyYXJ5 IGlzIHRoYXQgZGVwZW5kZW5jeSBvbiB0aGUgcHJvcHJpZXRhcnkgQVBJIHJhdGhlciB0aGFuIHN0 YW5kYXJkIEFQSSBsaWtlIFczQy4gSW4gY2FzZSBsb3cgbGV2ZWwgQVBJIGxpa2UgSlNFUCBpcyB0 aGUgZm9jdXMgb2YgV2ViUlRDIHRoZW4gYXQgbGVhc3QgaXQgaXMgcHJlZmVycmVkIHRvIHByb3Zp ZGUgdGhlIGhpZ2ggbGV2ZWwgQVBJIGxpa2UgUk9BUCBhcyB3ZWxsIGZvciBub3ZpY2UgV2ViUlRD IHVzZXJzLiAgTXkgcHJvcG9zYWwgaXMgdG8gaGF2ZSB0d28gbGV2ZWwgQVBJ4oCZcyBpbnN0ZWFk IG9mIGN1cnJlbnQgb25lLg0KDQo1KSBJbiBjYXNlIHRoZSB0YXJnZXQgYXVkaWVuY2UgZm9yIHRo ZSBsb3dlciBsZXZlbCBBUEkgKEpTRVApIGlzIHBvd2VyLXVzZXIgb2YgV2ViUlRDLCAgdGhlbiBK U0VQIHNoYWxsIHByb3ZpZGUgc3RpbGwgbG93ZXIgbGV2ZWwgQVBJIGZvciBTRFAgYXR0cmlidXRl cyB3aGljaCBpcyBhIGNvbW1vbiBwcmFjdGljZSBpbiBTSVAgYW5kIG90aGVyIFZvSVAgZGVwbG95 bWVudC4gSXQgd2lsbCBub3QgYmUgdG9vIG11Y2ggQVBJIGJhc2VkIG9uIG15IGltcGxlbWVudGF0 aW9uIHVuZGVyc3RhbmRpbmcuIEluIHRoZSBoaWdoIGxldmVsLCBTRFAgQVBJIHNoYWxsIGJlIGNs YXNzaWZpZWQgYXMNCg0KDQphKSAgICAgIEdsb2JhbCBhdHRyaWJ1dGUgc2V0L2dldCBBUEkNCg0K YikgICAgICBNZWRpYSBsZXZlbCBhdHRyaWJ1dGUgc2V0L2dldCBBUEkuIEVhY2ggbWVkaWEgbGV2 ZWwgYXR0cmlidXRlIHNoYWxsIGJlIGlkZW50aWZpZWQgYnkgaW5kZXggb2YgdGhlIOKAmG3igJkg IGxpbmUgb3IgbGFiZWwgb2Yg4oCcbeKAnSBsaW5lLg0KDQpUaGFua3MNClBhcnRoYQ0KDQpGcm9t OiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNCwg MjAxMiAxMToyNyBBTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZzsgcHVibGljLXdlYnJ0Y0B3My5vcmcN ClN1YmplY3Q6IFtydGN3ZWJdIEluaXRpYWwgSlNFUCBkcmFmdCBwb3N0ZWQNCg0KSSd2ZSBqdXN0 IHN1Ym1pdHRlZCB0aGUgLTAwIHZlcnNpb24gb2YgdGhlIEpTRVAgc2lnbmFsaW5nIHByb3Bvc2Fs IGF0Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXViZXJ0aS1ydGN3ZWItanNlcC0w MC50eHQNCg0KSSd2ZSByZWNlaXZlZCBhIG51bWJlciBvZiBjb21tZW50cyBhbmQgcXVlc3Rpb25z IHRoYXQgSSdtIHN0aWxsIHdvcmtpbmcgdGhyb3VnaCwgbW9zdCBvZiB0aGVtIGxpc3RlZCBpbiB0 aGUgb3BlbiBpc3N1ZXMgYXBwZW5kaXggb2YgdGhlIGRvY3VtZW50LiBJIGV4cGVjdCB0byByZXNv bHZlIG1hbnkgb2YgdGhlbSBpbiBhIGZvcnRoY29taW5nIC0wMSB2ZXJzaW9uLCBiZWZvcmUgdGhl IGludGVyaW0gbWVldGluZy4NCg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03B687inbamail01sonus_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyODA2NTMyODk7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTg1MzAxNDA0IC0y MzA3NjU5NjIgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgaW5pdGlhbCByZXZp ZXcgY29tbWVudHMgYXJlIGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xKSBTZWMgMSAoSW50cm9kdWN0 aW9uKSBQYXJhIDMgaW5kaWNhdGVzIHRoZSBkcmF3YmFjayB3aXRoIFNEUCBibG9iIGZyb20gdGhl IGJyb3dzZXIgaXMgdGhhdCBkZXRlcm1pbmluZyBvZmZlci9hbnN3ZXIgaW5mb3JtYXRpb24gaW4g dGhlIGJyb3dzZXIuIE15IHJlYWRpbmcNCiBmcm9tIHRoaXMgc3RhdGVtZW50IGlzIHRoYXQgYnJv d3NlciBuZWVkcyBvZmZlci9hbnN3ZXIgc3RhdGUgbWFjaGluZS4gQWxzbywgU2VjIDIgKEpTRVAg YXBwcm9hY2gpIFBhcmEgMiBjYWxscyBjcmVhdGVPZmZlciBBUEkgaW4gYnJvd3NlciB0byBzZXQg dGhlIG9mZmVyIGluIHRoZSBicm93c2VyID8gU28sIEpTRVAmbmJzcDsgZG9lcyBub3QgbW92ZSBv ZmZlci9hbnN3ZXIgc3RhdGUgbWFjaGluZSB0byBKYXZhU2NyaXB0IGJ1dCBsb29rcyBsaWtlIHRo ZQ0KIGFpbSBvZiBKU0VQIGlzIHRvIG1vdmUgZGV0ZXJtaW5pbmcgb2ZmZXIvYW5zd2VyIG91dCBv ZiBicm93c2VyIGFuZCBpbmZvcm0gb2ZmZXIvYW5zd2VyIHdoZW5ldmVyIG5lZWRlZCB0byB0aGUg YnJvd3Nlci4gJm5ic3A7RlNNIGlzIGluIEphdmFTY3JpcHQgYW5kIGFjdGlvbiBoYW5kbGVyIGFy ZSBpbiBicm93c2VyLiBXaGV0aGVyIHRoaXMgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0IG9yIG5v dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjIpIE15IHVuZGVyc3RhbmRpbmcgb2YgU2VjIDEgKEludHJvZHVjdGlvbikg UGFyYSA0IGlzIHRoYXQgb2ZmZXIvYW5zd2VyIChSRkMgMzI2NCkgaXMgbm90IG1lZXRpbmcgdGhl IHJlcXVpcmVtZW50cyBvZiBKaW5nbGUga2luZCBvZiBzaWduYWxpbmcgcHJvdG9jb2wuIEkgYWdy ZWUNCiB0aGF0IGl0IGlzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0byBST0FQIGluIHRoZSBjdXJy ZW50IGZvcm0uIEJ1dCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IHRoZSBzb2x1dGlvbiBmb3IgdGhp cyByZXF1aXJlbWVudCBpcyB0byBtb3ZlIG9mZmVyL2Fuc3dlciBtZWNoYW5pc20gdG8gdGhlIGFw cGxpY2F0aW9uIChKYXZhU2NyaXB0KS4gSU1PLCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgbW9yZSBv ZmZlci9hbnN3ZXIgcmVxdWlyZW1lbnQgbGlrZSBKaW5nbGUNCiBhbmQgdHJ5IHRvIGNvbWUgdXAg d2l0aCB0aGUgZW5oYW5jZWQgb2ZmZXIvYW5zd2VyIG1lY2hhbmlzbSBmb3IgV2ViUlRDIHJhdGhl ciB0aGFuIHB1c2hpbmcgdGhlIGludGVsbGlnZW5jZSB0byBhcHBsaWNhdGlvbi4gUGxlYXNlIG5v dGUgdGhhdCBldmVuIGluIGNhc2Ugb2YgU0lQIGltcGxlbWVudGF0aW9uLCBSRkMgMzI2MSAmYW1w OyBSRkMgNjMzNyBoYXMgdG8gYmUgY29uc2lkZXJlZCBhcGFydCBmcm9tIFJGQyAzMjY0IGZvciBz bW9vdGggaW50ZXJvcA0KIG9mIGJhc2ljIHNlc3Npb24gZXN0YWJsaXNobWVudC4gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4zKSBJdCBpcyBub3QgcG9zc2libGUgdG8gbWFpbnRhaW4gb2ZmZXIvYW5zd2VyIHN0YXRlIG1h Y2hpbmUgaW4gYnJvd3NlciAoZHVyaW5nIGJyb3dzZXIgcmVsb2FkKSBob3cgaXQgaXMgcG9zc2li bGUgdG8gbWFpbnRhaW4gSUNFIHN0YXRlIG1hY2hpbmUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+NCkgSmF2YVNjcmlw dCBsaWJyYXJ5IHdpbGwgbmV2ZXIgYmUgdGhlIHNvbHV0aW9uIGFuZCBpdCBpcyBqdXN0IGEgd29y a2Fyb3VuZCBmcm9tIHRoZSBwcm90b2NvbCBzdGFuZHBvaW50LiBUaGUgcHJvYmxlbSB3aXRoIDNy ZCBwYXJ0eSBKYXZhU2NyaXB0IGxpYnJhcnkgaXMNCiB0aGF0IGRlcGVuZGVuY3kgb24gdGhlIHBy b3ByaWV0YXJ5IEFQSSByYXRoZXIgdGhhbiBzdGFuZGFyZCBBUEkgbGlrZSBXM0MuIEluIGNhc2Ug bG93IGxldmVsIEFQSSBsaWtlIEpTRVAgaXMgdGhlIGZvY3VzIG9mIFdlYlJUQyB0aGVuIGF0IGxl YXN0IGl0IGlzIHByZWZlcnJlZCB0byBwcm92aWRlIHRoZSBoaWdoIGxldmVsIEFQSSBsaWtlIFJP QVAgYXMgd2VsbCBmb3Igbm92aWNlIFdlYlJUQyB1c2Vycy4gJm5ic3A7TXkgcHJvcG9zYWwgaXMg dG8gaGF2ZQ0KIHR3byBsZXZlbCBBUEnigJlzIGluc3RlYWQgb2YgY3VycmVudCBvbmUuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj41KSBJbiBjYXNlIHRoZSB0YXJnZXQgYXVkaWVuY2UgZm9yIHRoZSBsb3dlciBsZXZlbCBB UEkgKEpTRVApIGlzIHBvd2VyLXVzZXIgb2YgV2ViUlRDLCAmbmJzcDt0aGVuIEpTRVAgc2hhbGwg cHJvdmlkZSBzdGlsbCBsb3dlciBsZXZlbCBBUEkgZm9yIFNEUCBhdHRyaWJ1dGVzIHdoaWNoDQog aXMgYSBjb21tb24gcHJhY3RpY2UgaW4gU0lQIGFuZCBvdGhlciBWb0lQIGRlcGxveW1lbnQuIEl0 IHdpbGwgbm90IGJlIHRvbyBtdWNoIEFQSSBiYXNlZCBvbiBteSBpbXBsZW1lbnRhdGlvbiB1bmRl cnN0YW5kaW5nLiBJbiB0aGUgaGlnaCBsZXZlbCwgU0RQIEFQSSBzaGFsbCBiZSBjbGFzc2lmaWVk IGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1 aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkdsb2JhbCBhdHRyaWJ1dGUgc2V0L2dldCBBUEk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi43NWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yik8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NZWRpYSBsZXZlbCBhdHRyaWJ1dGUgc2V0L2dldCBB UEkuIEVhY2ggbWVkaWEgbGV2ZWwgYXR0cmlidXRlIHNoYWxsIGJlIGlkZW50aWZpZWQgYnkgaW5k ZXggb2YgdGhlIOKAmG3igJkmbmJzcDsgbGluZSBvciBsYWJlbCBvZiDigJxt4oCdIGxpbmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGFydGhhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyNCwg MjAxMiAxMToyNyBBTTxicj4NCjxiPlRvOjwvYj4gcnRjd2ViQGlldGYub3JnOyBwdWJsaWMtd2Vi cnRjQHczLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBJbml0aWFsIEpTRVAgZHJh ZnQgcG9zdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkndmUganVzdCBzdWJtaXR0ZWQgdGhlIC0wMCB2ZXJzaW9uIG9mIHRoZSBKU0VQIHNp Z25hbGluZyBwcm9wb3NhbCBhdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC11 YmVydGktcnRjd2ViLWpzZXAtMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC11YmVydGktcnRjd2ViLWpzZXAtMDAudHh0PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJJ3ZlIHJlY2VpdmVkIGEgbnVt YmVyIG9mIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgdGhhdCBJJ20gc3RpbGwgd29ya2luZyB0aHJv dWdoLCBtb3N0IG9mIHRoZW0gbGlzdGVkIGluIHRoZSBvcGVuIGlzc3VlcyBhcHBlbmRpeCBvZiB0 aGUgZG9jdW1lbnQuIEkgZXhwZWN0IHRvIHJlc29sdmUgbWFueSBvZiB0aGVtIGluIGEgZm9ydGhj b21pbmcgLTAxIHZlcnNpb24sIGJlZm9yZSB0aGUgaW50ZXJpbSBtZWV0aW5nLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_387F9047F55E8C42850AD6B3A7A03C6C0E03B687inbamail01sonus_-- From Michael.Tuexen@lurchi.franken.de Tue Jan 31 00:02:38 2012 Return-Path: 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 5F05421F85A0 for ; Tue, 31 Jan 2012 00:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 3YsGtNQdYcG6 for ; Tue, 31 Jan 2012 00:02:37 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id B958521F8539 for ; Tue, 31 Jan 2012 00:02:35 -0800 (PST) Received: from [192.168.1.103] (p508FB2FE.dip.t-dialin.net [80.143.178.254]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 48A4A1C0C0BCC; Tue, 31 Jan 2012 09:02:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: <4F26E84B.7010301@alvestrand.no> Date: Tue, 31 Jan 2012 09:02:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <650A6437-1728-4346-8D73-39FCA9FAC8D8@lurchi.franken.de> References: <4F15A1A3.6000304@alvestrand.no> <4F26E84B.7010301@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 08:02:38 -0000 On Jan 30, 2012, at 7:58 PM, Harald Alvestrand wrote: > Thanks again! >=20 > I've now spent a little time playing with it - it's been long since = I've worked with C at this level! >=20 > One question I have is the handling of port numbers ... the way it = currently seems to be structured, the SCTP layer is initialized with a = listening UDP port number as a parameter to the sctp_init function, and = the remote port is set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, = on the listening socket (from discard_server.c) and the active socket = (from client.c). So both when listening and when calling out, the remote = UDP port is a necessary property of the socket. Hi Harald, this is correct. >=20 > This would mean that the mode of operation in an SCTP implementation = embedded in a browser would be: >=20 > For each browser: This depends on the stack you use: (a) SCTP/DTLS/UDP Then you would the ICE stuff first, bound the UDP sockets, do the = DTLS handlshake, and finally do the SCTP handshake. Please note that SCTP has to be = changed to run on to of a connection oriented protocol. All stuff related to = IP-addresses and UDP port numbers has to be taken out. (b) DTLS/SCTP/UDP I would assume that you do the ICE stuff first, then configure the = UDP port numbers to SCTP, then do the SCTP handshake, then the DTLS handshake. If ICE changes = UDP port numbers, they can be changed in SCTP (maybe we need to tweak the current = API). Or you use a lower layer which does the UDP encapsulation and run SCTP on top of that. = This is more an implementation issue. Best regards Michael > - Initialize SCTP to a single random local UDP port > For each PeerConnection desiring to use data: > - Perform ICE candidate finding to get candidates for this UDP port = (or reuse) > - Perform ICE negotiation to associate the single UDP port to a remote = UDP port > - Open an userspace SCTP socket and bind this to the remote UDP port = (and address) of the best candidate > - (Use some DTLS mechanism to initialize DTLS as an encrypting = sublayer for SCTP) > - One of the ends takes the initiative to set up the SCTP connection = between the two > - Channels are then opened at will >=20 > Does that seem approximately right to you? >=20 > Harald >=20 > On 01/20/2012 01:02 PM, Michael Tuexen wrote: >> On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: >>=20 >>> (after a long delay) >>> thank you very much for the input! >>>=20 >>> I've downloaded and compiled the code, but haven't yet found out how = to do the typical "hello world" call with the binaries provided. >>>=20 >>> Could you give us a note saying "do this and see the packets flow"? >> Hi Harald, >>=20 >> an updated version of the user-land stack is available from >> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>=20 >> It now supports the platforms Windows in addition to FreeBSD, Linux = and Mac OS X. >> It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation = variants >> SCTP/UDP/IPv4 and SCTP/UDP/IPv6. >>=20 >> In libusrsctp-0.9.0/programs you find examples programs. >>=20 >> Please note that you need to run the programs with root privileges, >> if you want to use native SCTP/IPv4 or SCTP/IPv6. >>=20 >> For example, you can run >> sudo ./discard_server >> in one shell and >> sudo ./client 127.0.0.1 9 >> in another shell. >> Whatever you type on the console will be sent to the discard server. >> Wireshark will show the packets. >>=20 >> If you want to use UDP encapsulation, you can run >> ./discard_server 9899 9999 >> in one shell and >> ./client 127.0.0.1 9 9999 9899 >> in another shell. >>=20 >> Things are simpler, if you run the stack on two separate machines: >> ./discard_server >> on one machine. >> ./client a.b.c.d 9 9899 9899 >> on the other. >>=20 >> Please note that the demo programs disable the sending of ABORTs >> in response to out of the blue packets to allow running multiple >> stacks on the same host. This is done by the line >> SCTP_BASE_SYSCTL(sctp_blackhole) =3D 2; >> in the code. (On FreeBSD / Mac OS X kernel versions, you have such >> a sysctl). >>=20 >> I hope this helps. If you have any further questions or issues, >> please let me know. >>=20 >> Best regards >> Michael >>> Harald, experimenter >>>=20 >>> On 11/18/2011 02:17 PM, Michael T=FCxen wrote: >>>> Dear all, >>>>=20 >>>> I just wanted to let you know that the initial version of the >>>> SCTP user-land stack based on the FreeBSD kernel code for SCTP >>>> is available at >>>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>>>=20 >>>> It currently support FreeBSD, Linux and Mac OS X. We are >>>> currently working on adding support for Windows, adding >>>> more examples and improving the API. >>>>=20 >>>> Best regards >>>> Michael >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=20 >>=20 >=20 >=20 From Michael.Tuexen@lurchi.franken.de Tue Jan 31 00:26:07 2012 Return-Path: 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 1342C21F873A for ; Tue, 31 Jan 2012 00:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wytrPC0VkLwy for ; Tue, 31 Jan 2012 00:26:05 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id F339221F872E for ; Tue, 31 Jan 2012 00:26:04 -0800 (PST) Received: from [192.168.1.103] (p508FB2FE.dip.t-dialin.net [80.143.178.254]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1E9BD1C0C0BCC; Tue, 31 Jan 2012 09:04:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Tue, 31 Jan 2012 09:04:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F15A1A3.6000304@alvestrand.no> <4F26E84B.7010301@alvestrand.no> To: Eric Rescorla X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SCTP user-land stack available X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 08:26:07 -0000 On Jan 31, 2012, at 7:05 AM, Eric Rescorla wrote: > On Mon, Jan 30, 2012 at 10:58 AM, Harald Alvestrand > wrote: >> Thanks again! >>=20 >> I've now spent a little time playing with it - it's been long since = I've >> worked with C at this level! >>=20 >> One question I have is the handling of port numbers ... the way it = currently >> seems to be structured, the SCTP layer is initialized with a = listening UDP >> port number as a parameter to the sctp_init function, and the remote = port is >> set as a socket option, SCTP_REMOTE_UDP_ENCAPS_PORT, on the listening = socket >> (from discard_server.c) and the active socket (from client.c). So = both when >> listening and when calling out, the remote UDP port is a necessary = property >> of the socket. >>=20 >> This would mean that the mode of operation in an SCTP implementation >> embedded in a browser would be: >>=20 >> For each browser: >> - Initialize SCTP to a single random local UDP port >> For each PeerConnection desiring to use data: >> - Perform ICE candidate finding to get candidates for this UDP port = (or >> reuse) >> - Perform ICE negotiation to associate the single UDP port to a = remote UDP >> port >> - Open an userspace SCTP socket and bind this to the remote UDP port = (and >> address) of the best candidate >=20 > This seems problematic, since the ICE stack can change candidates > unbeknownst to the upper layers. IMO the SCTP stack needs to be > bound to an abstract datagram channel API, not to UDP transport. That is an implementation issue. Even with the current SCTP = implementation you can change the remote port on the fly. > This is certainly how I've anticipated DTLS would work in the absence > of SCTP. >=20 >=20 >> - (Use some DTLS mechanism to initialize DTLS as an encrypting = sublayer for >> SCTP) >=20 > I'm not sure I understand this. If you're going to use SCTP over DTLS, = then > you would put a DTLS shim under the SCTP layer (see above about the > abstract API). OTOH, if you're going to do DTLS over SCTP, then you > would probably just do SCTP negotiation and then stack DTLS over > top. >=20 > -Ekr >=20 >> - One of the ends takes the initiative to set up the SCTP connection = between >> the two >> - Channels are then opened at will >>=20 >> Does that seem approximately right to you? >>=20 >>=20 >> Harald >>=20 >> On 01/20/2012 01:02 PM, Michael Tuexen wrote: >>>=20 >>> On Jan 17, 2012, at 5:28 PM, Harald Alvestrand wrote: >>>=20 >>>> (after a long delay) >>>> thank you very much for the input! >>>>=20 >>>> I've downloaded and compiled the code, but haven't yet found out = how to >>>> do the typical "hello world" call with the binaries provided. >>>>=20 >>>> Could you give us a note saying "do this and see the packets flow"? >>>=20 >>> Hi Harald, >>>=20 >>> an updated version of the user-land stack is available from >>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>>=20 >>> It now supports the platforms Windows in addition to FreeBSD, Linux = and >>> Mac OS X. >>> It implemented SCTP/IPv4 and SCTP/IPv6 and the UDP encapsulation = variants >>> SCTP/UDP/IPv4 and SCTP/UDP/IPv6. >>>=20 >>> In libusrsctp-0.9.0/programs you find examples programs. >>>=20 >>> Please note that you need to run the programs with root privileges, >>> if you want to use native SCTP/IPv4 or SCTP/IPv6. >>>=20 >>> For example, you can run >>> sudo ./discard_server >>> in one shell and >>> sudo ./client 127.0.0.1 9 >>> in another shell. >>> Whatever you type on the console will be sent to the discard server. >>> Wireshark will show the packets. >>>=20 >>> If you want to use UDP encapsulation, you can run >>> ./discard_server 9899 9999 >>> in one shell and >>> ./client 127.0.0.1 9 9999 9899 >>> in another shell. >>>=20 >>> Things are simpler, if you run the stack on two separate machines: >>> ./discard_server >>> on one machine. >>> ./client a.b.c.d 9 9899 9899 >>> on the other. >>>=20 >>> Please note that the demo programs disable the sending of ABORTs >>> in response to out of the blue packets to allow running multiple >>> stacks on the same host. This is done by the line >>> SCTP_BASE_SYSCTL(sctp_blackhole) =3D 2; >>> in the code. (On FreeBSD / Mac OS X kernel versions, you have such >>> a sysctl). >>>=20 >>> I hope this helps. If you have any further questions or issues, >>> please let me know. >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> Harald, experimenter >>>>=20 >>>> On 11/18/2011 02:17 PM, Michael T=FCxen wrote: >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> I just wanted to let you know that the initial version of the >>>>> SCTP user-land stack based on the FreeBSD kernel code for SCTP >>>>> is available at >>>>> http://sctp.fh-muenster.de/sctp-user-land-stack.html >>>>>=20 >>>>> It currently support FreeBSD, Linux and Mac OS X. We are >>>>> currently working on adding support for Windows, adding >>>>> more examples and improving the API. >>>>>=20 >>>>> Best regards >>>>> Michael >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From magnus.westerlund@ericsson.com Tue Jan 31 06:02:51 2012 Return-Path: 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 7F44211E8096 for ; Tue, 31 Jan 2012 06:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.881 X-Spam-Level: X-Spam-Status: No, score=-109.881 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 q85qjX1pz2zU for ; Tue, 31 Jan 2012 06:02:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id ABED011E8081 for ; Tue, 31 Jan 2012 06:02:50 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-26-4f27f489900c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 39.23.02613.984F72F4; Tue, 31 Jan 2012 15:02:49 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 31 Jan 2012 15:02:49 +0100 Message-ID: <4F27F484.7040105@ericsson.com> Date: Tue, 31 Jan 2012 06:02:44 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <062f01ccdfa8$19fd4430$4df7cc90$@com> In-Reply-To: <062f01ccdfa8$19fd4430$4df7cc90$@com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 14:02:51 -0000 On 2012-01-30 15:37, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Thursday, January 26, 2012 11:25 AM >> To: rtcweb@ietf.org >> Subject: [rtcweb] Trickle ICE in practice >> >> Hi Justin, >> >> i've been thinking about how ICE works in JSEP and ISTM that the API >> may not be emitting enough information to work here. As I understand >> it, the following is a reasonable order of operations: >> >> Alice->Bob: Offer >> Alice->Bob: ICE candidates >> Bob->Alice: ICE candidates >> // ICE happens >> // Bob answers >> Bob->Alice: Answer >> >> Unless I'm missing something, though, Alice and Bob can't start doing >> ICE until they have exchanged the ice-ufrag and ice-pwd >> properties. Alice sends these in her offer, so this is no problem, but >> they would ordinarily be in Bob's answer, but that gets delayed, and >> they're not in Bob's ICE candidates, so I don't think they can start >> ICE until Bob's answer arrives. > > Alice can respond to Bob's incoming connectivity checks before receiving > Bob's answer. However, Alice cannot validate the incoming connectivity > checks really came from Bob until she receives Bob's ice-ufrag and > ice-pwd. That isn't a problem; she can validate them later. Dan, I think you are wrong here. In the context of ICE the following applies to responding to any Binding Request, per section 7.2 of RFC 5245: The agent MUST use a short-term credential to authenticate the request and perform a message integrity check. So, unless alice has received the ufrag and the password you are dead in the water. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jdrosen@jdrosen.net Tue Jan 31 06:03:18 2012 Return-Path: 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 3D4CD21F8505 for ; Tue, 31 Jan 2012 06:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.665 X-Spam-Level: X-Spam-Status: No, score=-99.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 MB+M9+768ZkL for ; Tue, 31 Jan 2012 06:03:17 -0800 (PST) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.52.42]) by ietfa.amsl.com (Postfix) with ESMTP id C9EE211E8081 for ; Tue, 31 Jan 2012 06:03:17 -0800 (PST) Received: from [184.105.243.51] (port=56413) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RsEIm-0004TI-Tv for rtcweb@ietf.org; Tue, 31 Jan 2012 09:03:17 -0500 Message-ID: <4F27F4A2.5020202@jdrosen.net> Date: Tue, 31 Jan 2012 06:03:14 -0800 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] JSEP and browser reloads X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 14:03:18 -0000 The JSEP draft states an explicit goal of dealing with the case where there is a page reload. The document argues that this is a motivation for removing the O/A state machine out of the browser, and placing it into the JS/server. On this, I agree. However, extraction of the O/A state machine from the browser is necessary - but NOT sufficient - to enable rapid re-establishment of streams upon browser reload. The browser still holds the ICE state machine, which arguably takes longer to run and has more state than the O/A machine. Without also extracting the ICE state machine, we will not solve the browser reload problem. To be clear - the key use case is that a user is in the middle of a call embedded in a page, and while talking, is clicking around in that page. We want to make sure that the call can continue as quickly as possible once the page reloads. Ideally, the JS would be able to directly instruct the browser to conduct a single connectivity check and then start sending media immediately, using previously established keying materials and media destinations. I do not see how the JSEP draft enables that. Do people feel we need to solve the problem of "rapid rehydration" of the media stream on page reload? I think so. Thanks, Jonathan R. From andrew.hutton@siemens-enterprise.com Tue Jan 31 07:34:12 2012 Return-Path: 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 414C911E80A4 for ; Tue, 31 Jan 2012 07:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] 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 enZBFIQZCvYj for ; Tue, 31 Jan 2012 07:34:11 -0800 (PST) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6662211E8081 for ; Tue, 31 Jan 2012 07:34:11 -0800 (PST) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id A83FB23F04FF; Tue, 31 Jan 2012 16:34:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 31 Jan 2012 16:34:09 +0100 From: "Hutton, Andrew" To: Jonathan Rosenberg , "rtcweb@ietf.org" Date: Tue, 31 Jan 2012 16:34:09 +0100 Thread-Topic: [rtcweb] JSEP and browser reloads Thread-Index: AczgIRg4jYE/pd7hQ+aHxvqyVUVNGAADCg1g Message-ID: <101C6067BEC68246B0C3F6843BCCC1E312006AC1CB@MCHP058A.global-ad.net> References: <4F27F4A2.5020202@jdrosen.net> In-Reply-To: <4F27F4A2.5020202@jdrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [rtcweb] JSEP and browser reloads X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 15:34:12 -0000 Yes "Rapid rehydration" is a problem we need to solve. It is one of the pro's for the JSEP mechanism so this looks like it would b= e further improvement. If it can be done without too much impact on the app= lication then that would be nice as well. Regards Andy > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: 31 January 2012 14:03 > To: rtcweb@ietf.org > Subject: [rtcweb] JSEP and browser reloads >=20 > The JSEP draft states an explicit goal of dealing with the case where > there is a page reload. The document argues that this is a motivation > for removing the O/A state machine out of the browser, and placing it > into the JS/server. On this, I agree. >=20 > However, extraction of the O/A state machine from the browser is > necessary - but NOT sufficient - to enable rapid re-establishment of > streams upon browser reload. The browser still holds the ICE state > machine, which arguably takes longer to run and has more state than the > O/A machine. Without also extracting the ICE state machine, we will not > solve the browser reload problem. >=20 > To be clear - the key use case is that a user is in the middle of a > call > embedded in a page, and while talking, is clicking around in that page. > We want to make sure that the call can continue as quickly as possible > once the page reloads. Ideally, the JS would be able to directly > instruct the browser to conduct a single connectivity check and then > start sending media immediately, using previously established keying > materials and media destinations. I do not see how the JSEP draft > enables that. >=20 > Do people feel we need to solve the problem of "rapid rehydration" of > the media stream on page reload? I think so. >=20 > Thanks, > Jonathan R. >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Tue Jan 31 08:36:40 2012 Return-Path: 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 F03BD21F8593 for ; Tue, 31 Jan 2012 08:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wqtFQyW4HZNR for ; Tue, 31 Jan 2012 08:36:39 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5721F8598 for ; Tue, 31 Jan 2012 08:36:38 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-e4-4f2818960df3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D2.1C.02613.698182F4; Tue, 31 Jan 2012 17:36:38 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 31 Jan 2012 17:36:37 +0100 Message-ID: <4F281893.5040107@ericsson.com> Date: Tue, 31 Jan 2012 08:36:35 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Slides for the Interim X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 16:36:40 -0000 WG, The slides for the Interim meeting are available here: http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.html Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From leontsinis@gmail.com Tue Jan 31 09:02:23 2012 Return-Path: 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 238C211E8075 for ; Tue, 31 Jan 2012 09:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 cPjTvVWuzW4e for ; Tue, 31 Jan 2012 09:02:22 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5953C11E8071 for ; Tue, 31 Jan 2012 09:02:22 -0800 (PST) Received: by qafi29 with SMTP id i29so2794412qaf.10 for ; Tue, 31 Jan 2012 09:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ynysbwC4VIVQLnCbr5UE2rWcp+mJHtwk+FJNpOzVC14=; b=SZIOmpAmeZiNMre0prNmUALziqcndn+IniT/tJEMicqcH0A9sC72ZHYdseJrLKgbG8 co+spG96gIu8T1jIw8NPrxsW98lc3DMgyhX0WAO3OJB3hKDjayWQNG7Ho0DAc/L2VWpc EGMDjUMv7hfdoxWYUR43PgiPNpP1QyOgdmbZI= MIME-Version: 1.0 Received: by 10.229.136.79 with SMTP id q15mr4183999qct.149.1328029341648; Tue, 31 Jan 2012 09:02:21 -0800 (PST) Received: by 10.229.240.20 with HTTP; Tue, 31 Jan 2012 09:02:21 -0800 (PST) In-Reply-To: <4F281893.5040107@ericsson.com> References: <4F281893.5040107@ericsson.com> Date: Tue, 31 Jan 2012 19:02:21 +0200 Message-ID: From: Nikos Leontsinis To: Magnus Westerlund Content-Type: multipart/alternative; boundary=00248c71179529068404b7d5ed84 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Slides for the Interim X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 17:02:23 -0000 --00248c71179529068404b7d5ed84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable the audio conference facility has no sound On 31 January 2012 18:36, Magnus Westerlund wrote: > WG, > > The slides for the Interim meeting are available here: > > http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.htm= l > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --=20 Nikos Leontsinis GSM: +306974477561 office:2103301193 ICQ Number: 201-100-938 msn: leontsinis@gmail.com skype: leontsinis2 --00248c71179529068404b7d5ed84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable the audio conference facility has no sound

On 31 January 2012 18:36, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
WG,

The slides for the Interim meeting are available here:

http://www.ietf.org/proceedings/interim/2012/= 01/31/rtcweb/proceedings.html

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb



--
Nikos Leonts= inis
GSM: +306974477561
office:2103301193
ICQ Number:=A0 201-100-= 938
msn: leontsinis@gmail.com
skype: leontsinis2
--00248c71179529068404b7d5ed84-- From ted.ietf@gmail.com Tue Jan 31 09:24:06 2012 Return-Path: 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 D30AA21F8600 for ; Tue, 31 Jan 2012 09:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7lS6ACOZAF2Y for ; Tue, 31 Jan 2012 09:24:06 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4872321F85F7 for ; Tue, 31 Jan 2012 09:24:06 -0800 (PST) Received: by ghbg16 with SMTP id g16so181378ghb.31 for ; Tue, 31 Jan 2012 09:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HyqnHthj5mhQBqJr+ebTzk1OMwpBHOtNBPfR8anrQyE=; b=c9yyC9DRfoaXZMyIRkQrso/K4BDbBLSHRQ7RVPuM/z5ovn5Fal6QddwcRXWsZhLoWg rwHz7hPwr148ekuJk4ShKh8cHvGoOYbiBjHhMZRFLn8MNWOyq4fk2X8gFOZMdGeh64Oi kVtBNRqz/tnGgZT/jjRp6neAWG8IMW7nh+RVw= MIME-Version: 1.0 Received: by 10.101.134.28 with SMTP id l28mr4932796ann.5.1328030645913; Tue, 31 Jan 2012 09:24:05 -0800 (PST) Received: by 10.236.103.232 with HTTP; Tue, 31 Jan 2012 09:24:05 -0800 (PST) In-Reply-To: References: <4F281893.5040107@ericsson.com> Date: Tue, 31 Jan 2012 09:24:05 -0800 Message-ID: From: Ted Hardie To: Nikos Leontsinis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Slides for the Interim X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 17:24:06 -0000 We had the local folks adjust the audio; it is still faint, but you should be able to hear it now (dialing back in may help, as may having the webex system call you). Ted On Tue, Jan 31, 2012 at 9:02 AM, Nikos Leontsinis wr= ote: > the audio conference facility has no sound > > > On 31 January 2012 18:36, Magnus Westerlund > wrote: >> >> WG, >> >> The slides for the Interim meeting are available here: >> >> http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/proceedings.ht= ml >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 >> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > Nikos Leontsinis > GSM: +306974477561 > office:2103301193 > ICQ Number:=A0 201-100-938 > msn: leontsinis@gmail.com > skype: leontsinis2 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From dwing@cisco.com Tue Jan 31 13:56:28 2012 Return-Path: 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 474FA11E8080 for ; Tue, 31 Jan 2012 13:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 DqI3AJUCDWHB for ; Tue, 31 Jan 2012 13:56:27 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7694111E8076 for ; Tue, 31 Jan 2012 13:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4063; q=dns/txt; s=iport; t=1328046987; x=1329256587; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=YOZmpRDB+eT2o9fkf6akcNCMBXaFKa5XfQwwVM5OV8c=; b=D6fFGWuO++fjV1O+q7y6b1V6tgoPJQAmk42p9rOET8iW5cCWlW0cP2i8 B9pXEpW8AEYcV75ixdoRUmOm63HoQ2x744+8c5pyeyz9M0BkTdBWNQyBC gqVS+C3bppMKRd3Al1EsXEusvK+Oei6xZpfCIp4a7Ym1c1B8za7gmHpO9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJJiKE+rRDoJ/2dsb2JhbABCn3yOa4EFgXIBAQEDAQEBAQUEBgEUA0QQBwEBAgIJDwIEAQEBGA8HGQIMFQoJCAEBBAESCxeHWgmaIQGeTwSLAwUBAQEBKwwBAQkEFAsPCoRggxoEiA0zhQWaUA X-IronPort-AV: E=Sophos;i="4.71,598,1320624000"; d="scan'208";a="26372731" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 31 Jan 2012 21:56:27 +0000 Received: from dwingWS (sjc-vpn6-707.cisco.com [10.21.122.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0VLuRVf025660; Tue, 31 Jan 2012 21:56:27 GMT From: "Dan Wing" To: "'Magnus Westerlund'" , References: <062f01ccdfa8$19fd4430$4df7cc90$@com> <4F27F484.7040105@ericsson.com> In-Reply-To: <4F27F484.7040105@ericsson.com> Date: Tue, 31 Jan 2012 13:56:27 -0800 Message-ID: <0a7a01cce063$2e722b40$8b5681c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczgIQk2pxO4enXvSQiflJgy+2+ofwAQUMGw Content-Language: en-us Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Tue, 31 Jan 2012 21:56:28 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Tuesday, January 31, 2012 6:03 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] Trickle ICE in practice >=20 > On 2012-01-30 15:37, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Thursday, January 26, 2012 11:25 AM > >> To: rtcweb@ietf.org > >> Subject: [rtcweb] Trickle ICE in practice > >> > >> Hi Justin, > >> > >> i've been thinking about how ICE works in JSEP and ISTM that the = API > >> may not be emitting enough information to work here. As I = understand > >> it, the following is a reasonable order of operations: > >> > >> Alice->Bob: Offer > >> Alice->Bob: ICE candidates > >> Bob->Alice: ICE candidates > >> // ICE happens > >> // Bob answers > >> Bob->Alice: Answer > >> > >> Unless I'm missing something, though, Alice and Bob can't start > doing > >> ICE until they have exchanged the ice-ufrag and ice-pwd > >> properties. Alice sends these in her offer, so this is no problem, > but > >> they would ordinarily be in Bob's answer, but that gets delayed, = and > >> they're not in Bob's ICE candidates, so I don't think they can = start > >> ICE until Bob's answer arrives. > > > > Alice can respond to Bob's incoming connectivity checks before > receiving > > Bob's answer. However, Alice cannot validate the incoming > connectivity > > checks really came from Bob until she receives Bob's ice-ufrag and > > ice-pwd. That isn't a problem; she can validate them later. >=20 > Dan, >=20 > I think you are wrong here. In the context of ICE the following = applies > to responding to any Binding Request, per section 7.2 of RFC 5245: >=20 > The agent MUST use a short-term credential to authenticate the > request and perform a message integrity check. >=20 > So, unless alice has received the ufrag and the password you are dead > in the water. You neglected to read that entire paragraph. The important part begins with the sentence "It is possible" and continues to=20 the end of the paragraph. It is from=20 http://tools.ietf.org/html/rfc5245#section-7.2, and copied here: The agent MUST use a short-term credential to authenticate the request and perform a message integrity check. The agent MUST consider the username to be valid if it consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in an offer or answer for a session in-progress. It is possible (and in fact very likely) that an offerer will receive a Binding request prior to receiving the answer from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in Section 7.2.1.2). The agent has sufficient information at this point to generate the response; the password from the peer is not required. Once the answer is received, it MUST proceed with the remaining steps required, namely, 7.2.1.3, 7.2.1.4, and 7.2.1.5 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered check queue. -d > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Jan 31 16:29:12 2012 Return-Path: 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 B76B911E808A for ; Tue, 31 Jan 2012 16:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 DKuCGhXfnx9W for ; Tue, 31 Jan 2012 16:29:11 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1311E8087 for ; Tue, 31 Jan 2012 16:29:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A46E139E12B; Wed, 1 Feb 2012 01:29:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WJ74Pm94JZE; Wed, 1 Feb 2012 01:29:09 +0100 (CET) Received: from [172.19.61.69] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BA71839E0F5; Wed, 1 Feb 2012 01:29:08 +0100 (CET) Message-ID: <4F288752.1080307@alvestrand.no> Date: Tue, 31 Jan 2012 16:29:06 -0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050502000108020505080301" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] JSEP terminology X-BeenThere: rtcweb@ietf.org 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: Wed, 01 Feb 2012 00:29:12 -0000 This is a multi-part message in MIME format. --------------050502000108020505080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/30/2012 12:07 PM, Henry Sinnreich wrote: > Here is just a nit to an otherwise true groundbreaking and quite > frankly, IMHO long overdue and refreshing approach and it's about > terminology. > > What is the "media plane" (par 4.3)? Does it have two dimensions and > if yes, what are they? > IMO there are many other terms that are better suited, such as "media > streams", etc. > > As is, the "media plane" terminology is just a reminder of certain > legacy "control planes" that should remain here unnamed :-) I like "media path", mostly because there's already a definition in section 2.4 of draft-ietf-rtcweb-overview, so I don't have to trot out another definition :-) Harald --------------050502000108020505080301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 01/30/2012 12:07 PM, Henry Sinnreich wrote:
JSEP terminology Here is just a nit to an otherwise true groundbreaking and quite frankly, IMHO long overdue and refreshing approach and it’s about terminology.

What is the “media plane” (par 4.3)? Does it have two dimensions and if yes, what are they?
IMO there are many other terms that are better suited, such as “media streams”, etc.
 
As is, the “media plane” terminology is just a reminder of certain legacy “control planes” that should remain here unnamed :-)
I like "media path", mostly because there's already a definition in section 2.4 of draft-ietf-rtcweb-overview, so I don't have to trot out another definition :-)

              Harald

--------------050502000108020505080301-- From magnus.westerlund@ericsson.com Tue Jan 31 16:50:57 2012 Return-Path: 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 897BD21F84CF for ; Tue, 31 Jan 2012 16:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.006 X-Spam-Level: X-Spam-Status: No, score=-110.006 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 RjRZ3YCfBhh6 for ; Tue, 31 Jan 2012 16:50:56 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EEB7D21F84CD for ; Tue, 31 Jan 2012 16:50:55 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-68-4f288c6e2fd6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 70.47.27041.E6C882F4; Wed, 1 Feb 2012 01:50:54 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 1 Feb 2012 01:50:53 +0100 Message-ID: <4F288C6A.7020303@ericsson.com> Date: Tue, 31 Jan 2012 16:50:50 -0800 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dan Wing References: <062f01ccdfa8$19fd4430$4df7cc90$@com> <4F27F484.7040105@ericsson.com> <0a7a01cce063$2e722b40$8b5681c0$@com> In-Reply-To: <0a7a01cce063$2e722b40$8b5681c0$@com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Wed, 01 Feb 2012 00:50:57 -0000 On 2012-01-31 13:56, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Magnus Westerlund >> Sent: Tuesday, January 31, 2012 6:03 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] Trickle ICE in practice >> >> On 2012-01-30 15:37, Dan Wing wrote: >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Eric Rescorla >>>> Sent: Thursday, January 26, 2012 11:25 AM >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] Trickle ICE in practice >>>> >>>> Hi Justin, >>>> >>>> i've been thinking about how ICE works in JSEP and ISTM that the API >>>> may not be emitting enough information to work here. As I understand >>>> it, the following is a reasonable order of operations: >>>> >>>> Alice->Bob: Offer >>>> Alice->Bob: ICE candidates >>>> Bob->Alice: ICE candidates >>>> // ICE happens >>>> // Bob answers >>>> Bob->Alice: Answer >>>> >>>> Unless I'm missing something, though, Alice and Bob can't start >> doing >>>> ICE until they have exchanged the ice-ufrag and ice-pwd >>>> properties. Alice sends these in her offer, so this is no problem, >> but >>>> they would ordinarily be in Bob's answer, but that gets delayed, and >>>> they're not in Bob's ICE candidates, so I don't think they can start >>>> ICE until Bob's answer arrives. >>> >>> Alice can respond to Bob's incoming connectivity checks before >> receiving >>> Bob's answer. However, Alice cannot validate the incoming >> connectivity >>> checks really came from Bob until she receives Bob's ice-ufrag and >>> ice-pwd. That isn't a problem; she can validate them later. >> >> Dan, >> >> I think you are wrong here. In the context of ICE the following applies >> to responding to any Binding Request, per section 7.2 of RFC 5245: >> >> The agent MUST use a short-term credential to authenticate the >> request and perform a message integrity check. >> >> So, unless alice has received the ufrag and the password you are dead >> in the water. > > You neglected to read that entire paragraph. The important part > begins with the sentence "It is possible" and continues to > the end of the paragraph. It is from > http://tools.ietf.org/html/rfc5245#section-7.2, and copied here: > > The agent MUST use a short-term credential to authenticate the > request and perform a message integrity check. The agent MUST > consider the username to be valid if it consists of two values > separated by a colon, where the first value is equal to the username > fragment generated by the agent in an offer or answer for a session > in-progress. It is possible (and in fact very likely) that an > offerer will receive a Binding request prior to receiving the answer > from its peer. If this happens, the agent MUST immediately generate > a response (including computation of the mapped address as described > in Section 7.2.1.2). The agent has sufficient information at this > point to generate the response; the password from the peer is not > required. Once the answer is received, it MUST proceed with the > remaining steps required, namely, 7.2.1.3, 7.2.1.4, and 7.2.1.5 for > full implementations. In cases where multiple STUN requests are > received before the answer, this may cause several pairs to be queued > up in the triggered check queue. > Hmmm, there is something strange here. First, this seems to reduce the incoming verfication to that the request has has a username that contains the agents local ufrag. Secondly, the outgoing response can't be signed by the agent, as it needs the requestors password and ufrag to do that. So how does this achieve the security goals of ensuring that only entities that has the secret responds correctly? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Tue Jan 31 16:56:22 2012 Return-Path: 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 04A9611E8095 for ; Tue, 31 Jan 2012 16:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 lgRWuA0Fijp6 for ; Tue, 31 Jan 2012 16:56:21 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1B11E8087 for ; Tue, 31 Jan 2012 16:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5324; q=dns/txt; s=iport; t=1328057781; x=1329267381; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=4J9mVClX5BlsNbgi2dDajMz5Pah20bPifibC0jfqDow=; b=liNgDIbXh5YuKTQCeqt8+nj1vhCEk7svFTSJVf9DrGiJzizSSTwzDIUC H3/6U+SYTzuQm9X4bEjL4AKXusiOVEE3RfzvlOBGSKxghx/mPJJpovi17 V2IA70LAuLkkdN3cz2qPuk9sKu0HJbo5Bo2HynDOe+dkSamQbPKVwvpT1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAACNKE+rRDoI/2dsb2JhbABDoAKOa4EFgXIBAQEDAQgEBgEUA08FBwEBAgIJDwIEAQEBGA8HGQIhCgkIAQEEEwsXh1oJmmEBnlIEixorDAEBCQQUCw8KhGCDGgSIDTOFBZpQ X-IronPort-AV: E=Sophos;i="4.71,599,1320624000"; d="scan'208";a="28120592" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 01 Feb 2012 00:56:20 +0000 Received: from dwingWS (sjc-vpn6-707.cisco.com [10.21.122.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q110uKI5000704; Wed, 1 Feb 2012 00:56:20 GMT From: "Dan Wing" To: "'Magnus Westerlund'" References: <062f01ccdfa8$19fd4430$4df7cc90$@com> <4F27F484.7040105@ericsson.com> <0a7a01cce063$2e722b40$8b5681c0$@com> <4F288C6A.7020303@ericsson.com> In-Reply-To: <4F288C6A.7020303@ericsson.com> Date: Tue, 31 Jan 2012 16:56:20 -0800 Message-ID: <0b5701cce07c$4fc0be60$ef423b20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczge5o6Sr76P+XxSc+ooQCTFW1uZQAACqIw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Trickle ICE in practice X-BeenThere: rtcweb@ietf.org 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: Wed, 01 Feb 2012 00:56:22 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, January 31, 2012 4:51 PM > To: Dan Wing > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Trickle ICE in practice >=20 > On 2012-01-31 13:56, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Magnus Westerlund > >> Sent: Tuesday, January 31, 2012 6:03 AM > >> To: rtcweb@ietf.org > >> Subject: Re: [rtcweb] Trickle ICE in practice > >> > >> On 2012-01-30 15:37, Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>>> Behalf Of Eric Rescorla > >>>> Sent: Thursday, January 26, 2012 11:25 AM > >>>> To: rtcweb@ietf.org > >>>> Subject: [rtcweb] Trickle ICE in practice > >>>> > >>>> Hi Justin, > >>>> > >>>> i've been thinking about how ICE works in JSEP and ISTM that the > API > >>>> may not be emitting enough information to work here. As I > understand > >>>> it, the following is a reasonable order of operations: > >>>> > >>>> Alice->Bob: Offer > >>>> Alice->Bob: ICE candidates > >>>> Bob->Alice: ICE candidates > >>>> // ICE happens > >>>> // Bob answers > >>>> Bob->Alice: Answer > >>>> > >>>> Unless I'm missing something, though, Alice and Bob can't start > >> doing > >>>> ICE until they have exchanged the ice-ufrag and ice-pwd > >>>> properties. Alice sends these in her offer, so this is no = problem, > >> but > >>>> they would ordinarily be in Bob's answer, but that gets delayed, > and > >>>> they're not in Bob's ICE candidates, so I don't think they can > start > >>>> ICE until Bob's answer arrives. > >>> > >>> Alice can respond to Bob's incoming connectivity checks before > >> receiving > >>> Bob's answer. However, Alice cannot validate the incoming > >> connectivity > >>> checks really came from Bob until she receives Bob's ice-ufrag and > >>> ice-pwd. That isn't a problem; she can validate them later. > >> > >> Dan, > >> > >> I think you are wrong here. In the context of ICE the following > applies > >> to responding to any Binding Request, per section 7.2 of RFC 5245: > >> > >> The agent MUST use a short-term credential to authenticate the > >> request and perform a message integrity check. > >> > >> So, unless alice has received the ufrag and the password you are > dead > >> in the water. > > > > You neglected to read that entire paragraph. The important part > > begins with the sentence "It is possible" and continues to > > the end of the paragraph. It is from > > http://tools.ietf.org/html/rfc5245#section-7.2, and copied here: > > > > The agent MUST use a short-term credential to authenticate the > > request and perform a message integrity check. The agent MUST > > consider the username to be valid if it consists of two values > > separated by a colon, where the first value is equal to the > username > > fragment generated by the agent in an offer or answer for a > session > > in-progress. It is possible (and in fact very likely) that an > > offerer will receive a Binding request prior to receiving the > answer > > from its peer. If this happens, the agent MUST immediately > generate > > a response (including computation of the mapped address as > described > > in Section 7.2.1.2). The agent has sufficient information at = this > > point to generate the response; the password from the peer is not > > required. Once the answer is received, it MUST proceed with the > > remaining steps required, namely, 7.2.1.3, 7.2.1.4, and 7.2.1.5 > for > > full implementations. In cases where multiple STUN requests are > > received before the answer, this may cause several pairs to be > queued > > up in the triggered check queue. > > >=20 > Hmmm, there is something strange here. >=20 > First, this seems to reduce the incoming verfication Yes. The verification is done later, when the Answer arrives. If verification succeeds, all is well. If verification fails, Alice (who was the Offerer) throws away the information received because it was bogus. > to that the > request has has a username that contains the agents local ufrag. >=20 > Secondly, the outgoing response can't be signed by the agent, as it > needs the requestors password and ufrag to do that. It doesn't - the password from the peer isn't required; only the Offerer's password is needed, which the Offerer already knows (because the Offerer sent it in SDP). > So how does this achieve the security goals of ensuring that only > entities that has the secret responds correctly? It does meet that goal. Let's talk in person about it. -d > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------