<HTML>
<HEAD>
<TITLE>Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol?</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424?<BR>
<a href="http://www.rfc-editor.org/rfc/rfc3424.txt">http://www.rfc-editor.org/rfc/rfc3424.txt</a> <BR>
<BR>
“...</SPAN></FONT><FONT SIZE="2"><FONT FACE="Times, Times New Roman"><SPAN STYLE='font-size:12pt'>a process whereby some<BR>
originating process attempts to determine or fix the address (and<BR>
port) by which it is known - e.g. to be able to use address data in<BR>
the protocol exchange, or to advertise a public address from which it<BR>
will receive connections.<BR>
There are only heuristics and workarounds to attempt to achieve this<BR>
effect; there is no 100% solution. Since NATs may also dynamically<BR>
reclaim or readjust translations, "keep-alive" and periodic re-<BR>
polling may be required. Use of these workarounds MUST be considered<BR>
transitional in IETF protocols, and a better architectural solution<BR>
is being sought. The explicit intention is to deprecate any such<BR>
workarounds when sound technical approaches are available.”<BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'><BR>
Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw.<BR>
There were some early attempts to do SDPng and we know today much more:<BR>
<a href="http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07">http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07</a><BR>
<BR>
Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach?<BR>
For example including Web conferencing displays and UI control capabilities.<BR>
Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. <BR>
<BR>
Or are the no “</SPAN></FONT><FONT SIZE="2"><FONT FACE="Times, Times New Roman"><SPAN STYLE='font-size:12pt'>sound technical approaches</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>” available at all?<BR>
<BR>
Thanks, Henry<BR>
<BR>
<BR>
On 2/2/11 11:55 AM, "Bernard Aboba" <<a href="bernard.aboba@gmail.com">bernard.aboba@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>With respect to b) one challenge is obtaining the IP addresses necessary to create the SDP offer. (see <a href="http://javascript.about.com/library/blip.htm">http://javascript.about.com/library/blip.htm</a> ). <BR>
<BR>
On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <<a href="juberti@google.com">juberti@google.com</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>Great example. <BR>
<BR>
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.<BR>
<BR>
So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today.<BR>
<BR>
The two things that we need to specify are<BR>
a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around)<BR>
b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web).<BR>
<BR>
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?<BR>
<BR>
--justin<BR>
<BR>
On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <<a href="matthew.kaufman@skype.net">matthew.kaufman@skype.net</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'>On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'><BR>
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.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'><BR>
Agreed. Consider the case of Gmail (or any other web-based email)<BR>
<BR>
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.<BR>
<BR>
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.<BR>
<BR>
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.<BR>
<FONT COLOR="#888888"><BR>
Matthew Kaufman<BR>
</FONT><BR>
_______________________________________________<BR>
RTC-Web mailing list<BR>
<a href="RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><BR>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'><BR>
<BR>
_______________________________________________<BR>
RTC-Web mailing list<BR>
<a href="RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><BR>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:13pt'><BR>
<BR>
<HR ALIGN=CENTER SIZE="3" WIDTH="95%"></SPAN></FONT><SPAN STYLE='font-size:13pt'><FONT FACE="Consolas, Courier New, Courier">_______________________________________________<BR>
dispatch mailing list<BR>
<a href="dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href="https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.org/mailman/listinfo/dispatch</a><BR>
</FONT></SPAN></BLOCKQUOTE>
</BODY>
</HTML>