Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?
Bernard Aboba <bernard_aboba@hotmail.com> Thu, 03 February 2011 18:07 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04A23A67F9 for <dispatch@core3.amsl.com>; Thu, 3 Feb 2011 10:07:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.958
X-Spam-Level:
X-Spam-Status: No, score=-101.958 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNQoEwcxqrB8 for <dispatch@core3.amsl.com>; Thu, 3 Feb 2011 10:07:00 -0800 (PST)
Received: from blu0-omc1-s19.blu0.hotmail.com (blu0-omc1-s19.blu0.hotmail.com [65.55.116.30]) by core3.amsl.com (Postfix) with ESMTP id EF6143A695E for <dispatch@ietf.org>; Thu, 3 Feb 2011 10:06:59 -0800 (PST)
Received: from BLU152-W62 ([65.55.116.9]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 10:10:21 -0800
Message-ID: <BLU152-w62AB751AE874CDBF1D1CB893E70@phx.gbl>
Content-Type: multipart/alternative; boundary="_50b8dae5-70a4-42ee-9f39-c360ce486bff_"
X-Originating-IP: [131.107.0.76]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: harald@alvestrand.no, juberti@google.com
Date: Thu, 03 Feb 2011 10:10:21 -0800
Importance: Normal
In-Reply-To: <4D4ADCD3.3070708@alvestrand.no>
References: <C96F0A4C.18AB4%henry.sinnreich@gmail.com>, <4D49F24C.5000105@alvestrand.no>, <BLU152-w36C75150B0A12F8A63D19C93E70@phx.gbl>, <AANLkTi=JqAa=Cc1mfVikwPAyegf=-YaW+RF6j=Mb0ZD_@mail.gmail.com>, <4D4ADCD3.3070708@alvestrand.no>
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Feb 2011 18:10:21.0935 (UTC) FILETIME=[9F598FF0:01CBC3CD]
Cc: rtc-web@alvestrand.no, dispatch@ietf.org
Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2011 18:07:02 -0000
Given that people have been using workarounds to obtain IP addresses, the value of keeping this out of Javascript seems marginal. However, since the W3C will be handling APIs, not the IETF, this does raise the question of how issues like this will be coordinated. Date: Thu, 3 Feb 2011 08:50:27 -0800 From: harald@alvestrand.no To: juberti@google.com CC: bernard_aboba@hotmail.com; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 02/03/11 01:32, Justin Uberti wrote: I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local, server reflexive, or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)? Apart from the known security concerns that come automatically from sharing IP addresses (such as revealing your network attachment location to whoever gets the IP address), I don't see any huge ones. On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote: Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). Date: Wed, 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no To: rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 02/02/11 11:19, Henry Sinnreich wrote: Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? Nit: UNSAF, not USAF. http://www.rfc-editor.org/rfc/rfc3424.txt “...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.” In our case, the answer that has proved workable is called STUN. Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. Or are the no “sound technical approaches” available at all? I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group. Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever. Harald _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
- [dispatch] Does RTC-WEB need to pick a signaling … Jonathan Rosenberg
- Re: [dispatch] Does RTC-WEB need to pick a signal… Adam Roach
- Re: [dispatch] Does RTC-WEB need to pick a signal… Jonathan Rosenberg
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Erik Lagerway
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Rosenberg, Jonathan
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Richard Shockey
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Erik Lagerway
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Erik Lagerway
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Henry Sinnreich
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Markus.Isomaki
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Matthew Kaufman
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Henry Sinnreich
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Erik Lagerway
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Henry Sinnreich
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Erik Lagerway
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Peter Musgrave
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Justin Uberti
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Markus.Isomaki
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Xavier Marjou
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Henry Sinnreich
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Jonathan Rosenberg
- Re: [dispatch] Does RTC-WEB need to pick a signal… Dean Willis
- Re: [dispatch] Does RTC-WEB need to pick a signal… Dean Willis
- Re: [dispatch] [RTW] Does RTC-WEB need to pick a … Bernard Aboba