On 3/19/2014 6:41 AM, Olle E. Johansson wrote:
On 19 Mar 2014, at 11:34, Sean Bright <sean.bri...@gmail.com> wrote:
On 3/19/2014 6:30 AM, Olle E. Johansson wrote:
The major one being that ICE was create so that we don't have to mess around
like this. The external IP is just a server-reflexive address. You may want to
make a decision on what you prefer in the C-line depending on the old logic -
what's the most likely address we're going to end up with?
With externaddr/externhost in chan_sip you are effectively hiding the fact that
Asterisk is behind a NAT device. Creating the ICE candidate list using the
local interfaces leaks information that you might not want getting leaked. The
goal of this patch was to make Asterisk appear to be sitting on the public
internet. I've been running it successfully for a few months, but it's not
ready for public consumption in it's current state.
That's a point. I've always been complaining to soft phone guys that the add a
lot of useless ICE candidates from various strange interfaces on my OS/X
created by Pararells, VMware and strange bridges I play with. I should be able
to choose what to expose, as a long list affects call set up time.
Yes, call setup time from a client on my local workstation takes a good
10-12 seconds because of VMWare workstation virtual interfaces.
What you are going to miss is the ability to set up media in the best possible
way with a local phone that still use STUN and use a server reflexive address
in SIP.
Right, but in my environment all of the clients are on the other side of
the NAT, so knowing the host address is useless. Are host candidates
specifically required by ICE? If not, a cleaner approach might be to
simply exclude them altogether and use only the reflexive and relayed
candidates.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
