<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/02/11 11:19, Henry Sinnreich wrote:
<blockquote cite="mid:C96F0A4C.18AB4%25henry.sinnreich@gmail.com"
type="cite">
<title>Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling
protocol?</title>
<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>
</span></font></blockquote>
Nit: UNSAF, not USAF.<br>
<blockquote cite="mid:C96F0A4C.18AB4%25henry.sinnreich@gmail.com"
type="cite"><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 13pt;">
<a moz-do-not-send="true"
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></blockquote>
In our case, the answer that has proved workable is called STUN.<br>
<blockquote cite="mid:C96F0A4C.18AB4%25henry.sinnreich@gmail.com"
type="cite"><font size="2"><font face="Times, Times New Roman"><span
style="font-size: 12pt;">
</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 moz-do-not-send="true"
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?</span></font><br>
</blockquote>
I'm all in favour of replacing SDP, but would not like to require
that before we can produce any output from this group.<br>
<br>
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.<br>
<br>
Harald<br>
<br>
</body>
</html>