Since the broken STUN server has bitten someone again today, there is an
urgent need for an interim solution to correct this in 4.6. At the very
least we should avoid the surprises brought about by the default STUN
server which nobody might suspect to even be there if they've never had
prior problems with it after months of being in production. Here is
the interim proposal and I would love to hear some comments.
Version <= 4.4
0. So as not to open up new doors for bugs to come in for 4.4 and
below, it makes sense to just vote for a replacement value. I declare
the floor open for this.
-----------------
Version 4.6
1. Add a new entry "No NAT" in the "Address Type" field and have it as
the default. This address type would mean that sipXconfig would insert
the internal address as the value of the external address. This would
mimic the behavior of "Use STUN" in cases where sipXecs is not sitting
behind a NAT where STUN would yield the same value for the external address
2. Change the Description of "Use STUN" to include a list of known STUN
servers. The user may simply copy and paste a server to their liking.
This is chosen over having a list-box of known STUN servers to avoid
further confusion that the ones listed are the only working/compatible
servers with sipX.
-------------------
Version 4.8 ?
I believe further proposal like hosting DNS/SRV for stun in SipFoundry
have merits and is quite elegant. Let us see where this leads us now
that the idea has been brought up.
On 03/23/2011 05:35 PM, Todd R. Hodgen wrote:
+1
Elegant solution Paul.
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of
*[email protected]
*Sent:* Wednesday, March 23, 2011 1:25 AM
*To:* Discussion list for users of sipXecs software
*Cc:* 'Discussion list for users of sipXecs software';
[email protected]
*Subject:* Re: [sipx-users] All calls were failing... why?
stun01.sipphone.com is gone...
My 2 cents:
The better solution:
From the same web page where the STUN servers were listed I found the
following:
STUN may use DNS SRV
<http://www.voip-info.org/wiki/view/DNS+SRV> records to find STUN
servers attached to a domain. The service name is _stun._udp or
_stun._tcp
And SipX users LOVE SRV records.
So if the maintainer of the sipfoundry DNS would be so kind to create
SRV records for _stun._udp.sipfoundry.org and _stun._tcp.sipfoundry.org
(any other generic domain is good as well) and point these to say 3
(now working) servers from the list in the same web page then we are
almost good.
SipX also needs a small adaptation. The field STUN server should be
changed to STUN domain with value sipfoundry.org,
and SipX should support SRV records for STUN and then, if implemented
correctly, we would have a redundant solution.
Now there is still a small extra burden on the maintainer of the
sipfoundry DNS because if we discover that one of the 3 servers goes
down this entry needs to be replaced.
(There could be an automatic script that runs on a daily basis, after
3 consecutive days of "no reply" of a server it is considered down and
should be replaced)
The faster, simpler solution: make an entry stun.sipfoundry.org that
points to a working STUN server.
The DNS maintainers of sipfoundry.org need to set up some sort of
check to see whether the server is available and
change DNS when needed.
Paul
P.S: This solution will only fail if ..... I can't say it.
"Todd R. Hodgen" <[email protected]> wrote on 23-03-2011 06:18:51:
> On 3/22/11 7:41 PM, Joegen Baclor wrote:
> curl -s --url http://www.ipaddresslocation.org/| grep 'myipaddress' |
> egrep -o '([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}'
> _______________________________________________
> except where n it admins don't know enough about one to one natting,
> and port 80 nats out differently.
> (we sell anti-spam appliances.. we see outbound port 25 and outbound
> 80 natting differently than inbound,lots of times.. and in order to
> SEND email in todays restrictive environment, the public ip needs to
> nat in and out the same!).
> Yes, during setup we use some tricks to try to determine the DEFAULT
> public ip and dns name. but once system is installed, the public ip
> is static.
> Yes, user can change it via networking page, but its not dynamic.
>
> If someone can't tell their public ip address, then sipx isn't going
> to work anyway.
>
> if they can't set srv, naptr records (split dns) then sipx isn't
> going to work anyway.
>
> If they can't set up their firewall with one to one IP ADDRESS
> natting, they sure arn't going to get one to one port natting right.
>
> in sipx today, no one needs stun server to automagically figure out
> the public ip.
>
-----------------------------------------------------------------------------------------------------------------------------------------------
> sipXecs is not always installed in enterprise scenarios. And in
> fact, many times its installed in very small businesses that don’t
> know what their IP address is, nor do they care for the most part.
> If they install from ISO, and use the DNS and DHCP of the server,
> they don’t need to fuss with SRV records at all. And, sipx just
> works for them.
> And, their default router from their ISP might just work fine for
> them, even with an ITSP.
> Yes, there is a need for some to have stun server available to them.
> And, if they have dynamic addressing from their ITSP, it’s essential.
> _______________________________________________
> sipx-users mailing list
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
