Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?
Henry Sinnreich <henry.sinnreich@gmail.com> Wed, 02 February 2011 19:21 UTC
Return-Path: <henry.sinnreich@gmail.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 020A03A6CDC for <dispatch@core3.amsl.com>; Wed, 2 Feb 2011 11:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 Xc+9yQQkh4t4 for <dispatch@core3.amsl.com>; Wed, 2 Feb 2011 11:20:55 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AE3413A6D79 for <dispatch@ietf.org>; Wed, 2 Feb 2011 11:20:54 -0800 (PST)
Received: by gwb20 with SMTP id 20so159302gwb.31 for <dispatch@ietf.org>; Wed, 02 Feb 2011 11:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type; bh=I0IFYuEH2LYiovL6Ik2wJnDQ9m/8BCx7ZlAV6tKH8n4=; b=n479vyGX2XkrlEQ5GiZ9+FQNqyPZ6yeQE6USiSJrLZFXHZRgfveAepXMp2leyMXNBx 9UPZOHTQV6NnTETxWq8HNugFcPNNC5juplgMRm43zNiJCyR1sy3zSC4AhYhxpM7hcoU7 ah+/8hAS8/G8RHCQN/Sr/yzzTMuD4gq+aYPtc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=fUtAAAvqh1ch0kHnGI0b0m6WHf8gMdJgoA+YQFeSxAyqSEL7uPecKayQYtWrOn8yQQ /zQPgBxEIV65ggalsT4s+Yj7o3tc+/rrn41Nk9Wj3Dk9JGNf8hPfzE4ihUdAJVVnDt8o KCVRhp5Nfbo1Kljel9i+Eelc3/oiKHotcJ1Bg=
Received: by 10.100.232.1 with SMTP id e1mr6211607anh.13.1296674352060; Wed, 02 Feb 2011 11:19:12 -0800 (PST)
Received: from [10.0.1.5] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id p14sm6985983ank.14.2011.02.02.11.19.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 11:19:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.28.0.101117
Date: Wed, 02 Feb 2011 13:19:08 -0600
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, Justin Uberti <juberti@google.com>
Message-ID: <C96F0A4C.18AB4%henry.sinnreich@gmail.com>
Thread-Topic: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?
Thread-Index: AcvDDhBDL3zMQ1q2g0CMQk5QCTMJTw==
In-Reply-To: <AANLkTimXYLpKYQDKiu=hx08OL-8W8rsFugfdwYKiZAaM@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3379497549_2007001"
Cc: rtc-web@alvestrand.no, DISPATCH list <dispatch@ietf.org>, Joerg Ott <jo@netlab.tkk.fi>
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: Wed, 02 Feb 2011 19:21:03 -0000
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? 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.² 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? Thanks, Henry On 2/2/11 11:55 AM, "Bernard Aboba" <bernard.aboba@gmail.com> wrote: > With respect to b) one challenge is obtaining the IP addresses necessary to > create the SDP offer. (see http://javascript.about.com/library/blip.htm ). > > On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti@google.com> wrote: >> Great example. >> >> And just like Gmail uses an SMTP gateway to connect its own HTTP-based >> protocol to the rest of the world, Gmail voice and video uses a XMPP gateway >> to connect its HTTP-based signaling to other XMPP clients. Others in this >> space have done similar things by implementing XMPP clients in Javascript. >> >> So I think we have existence proofs that this approach, in addition to being >> extremely flexible, is entirely workable today. >> >> The two things that we need to specify are >> a) the semantics of the signaling (i.e. the offer-answer mechanism that both >> SIP and XMPP are patterned around) >> b) the mechanism through which session offers and answers will be described >> (e.g. some SDP-ish thing that is suitable for the web). >> >> a) seems rather straightforward. b) will likely be trickier - we need >> something that can be mapped to SDP, for SIP gateways, but we probably want >> it to be represented as JSON for benefit of web developers. So the challenge >> becomes, what format can we define that can be unambiguously mapped to/from >> SDP, but doesn't bring with it all of the baggage of SDP? >> >> --justin >> >> On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net> >> wrote: >>> On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: >>>> >>>> That said, even if one asks the question of whether it is a good idea for >>>> us to pick something, I think the answer is no. The enormous benefit of the >>>> web model is its ability for innovation and velocity. Standardization is >>>> not needed for communications within the domain of the provider; new >>>> features can be developed and deployed as quickly as they can be conceived. >>> >>> Agreed. Consider the case of Gmail (or any other web-based email) >>> >>> Did every web browser on the planet need to be upgraded to speak IMAP or >>> SMTP in order for Gmail to be implemented? No. >>> >>> Does the JavaScript that Gmail sends down to your browser in order to >>> implement its UI need to be standardized among web email platforms? No. >>> >>> Does Google need to use the same JavaScript libraries and PHP back-end that >>> SquirrelMail uses in order to implement a web email application? No. >>> >>> Can Google change that JavaScript tomorrow without breaking >>> interoperability? Yes, and they probably will. >>> >>> But could Gmail be as successful without the worldwide SMTP infrastructure >>> it ties in to? Probably not. >>> >>> I see the same situation here. A web browser with real-time communication >>> capabilities will work in conjunction with a web site that serves up the >>> HTML and JavaScript that makes up the calling application. For some >>> applications, this will be sufficient. For others, one will want to >>> implement SIP or XMPP/Jingle or something else in order to gateway these >>> calls to other networks. The SIP implementation can live in the JavaScript, >>> up in the web server, in a separate gateway, or any combination thereof. >>> >>> Matthew Kaufman >>> >>> _______________________________________________ >>> 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 mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch
- [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