Hi Tony, See inline
Tony Graziano <[email protected]> wrote on 23-03-2011 22:56:25: > There are three different discussions/functions here: > > 1. What does sipx use a STUN server for, and what are we using as a > default and why. > > It is perhaps simpler to enhance this current config and add > primary, secondary, tertiary (like DNS) into the config. Even > sipfoundry has maintenance windows, like everyone else. Perhaps just > using 2 or 3 is simpler and more fault tolerant. The nice thing about the SRV solution is that you can have a list of X servers that is maintained centrally (the default). A very small administrative overhead for the DNS maintainer of sipfoundry, and not affected by service windows because the DNS records are cached, redundant and probably hosted anyway. It is of course easier to create 2 extra STUN server fields, but we are not doing that for the SIP-servers...I think SRV's are a nice solution for redundancy. With sipfoundry SRV records the "how can I find a STUN server problem" is "in-sourced" by sipfoundry. > 2. What could sipx do with a STUN server is the code is enhanced to do so. > > This is really a deep developer discussion. Currently the STUN > server just helps sipxbridge realize its public facing IP address, > that's all. It does nothing to assist remote users traverse > firewalls, etc. It does not use do anything else to assume what > ports are in use. Currently (since the sip dns srv and all ports > that the proxy, registrar, etc. run on) everything is hard coded, it > would be a much broader change (and enhancement) to expose all those > ports to customization via sipxconfig. Its been discussed lightly > before, so maybe this is an impetus to begin that discussion again > with more meaning behind it. I would reserve this for a separate discussion. This thread deals with the problem that you have to be able to get to a STUN server. > 3. Should/Could/Would sipfoundry become a mecca for folks looking > for a STUN server. > > Um, maybe or maybe not? I kinda of think there are enough public > STUN servers out there that if we had more fields available to put > more in (or pre-populate from a known working list), this would not > really be necessary. sipfoundry would not be a mecca for STUN servers, only for SRV records for STUN servers. As these answers are cached anyhow this would probably give an extra 1 to 5% load on the sipfoundry DNS. It is also possible to create your own STUN SRV records in your own DNS of course. But then all STUN users have to do that (and to be honest, these are normally the people that don't have the biggest infrastructure/knowledge etc) > I never have a need to use a STUN server, so what do I know, except > more is sometimes better. > On Wed, Mar 23, 2011 at 5:35 AM, Todd R. Hodgen <[email protected]> wrote: > +1 > Elegant solution Paul. > > From: [email protected] [mailto:sipx-users- > [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'; sipx-users- > [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 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/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.326.5325 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > > Helpdesk Contract Customers: > http://support.myitdepartment.net > > Blog: > http://blog.myitdepartment.net > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > _______________________________________________ > 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/
