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