<div>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)?</div>
<div><br><div class="gmail_quote">On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba <span dir="ltr"><<a href="mailto:bernard_aboba@hotmail.com">bernard_aboba@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
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). <br>
<hr>Date: Wed, 2 Feb 2011 16:09:48 -0800<br>From: <a href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a><br>To: <a href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a><br>
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?<div>
<div></div><div class="h5"><br><br>
On 02/02/11 11:19, Henry Sinnreich wrote:
<blockquote>
<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><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:13pt">
<a href="http://www.rfc-editor.org/rfc/rfc3424.txt" target="_blank">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><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 href="http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07" target="_blank">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>
<br></div></div>_______________________________________________
RTC-Web mailing list
<a href="mailto:RTC-Web@alvestrand.no" target="_blank">RTC-Web@alvestrand.no</a>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a> </div>
<br>_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
<br></blockquote></div><br></div>