> -----Original Message----- > From: Martin Steinmann [mailto:[EMAIL PROTECTED] > Sent: Friday, June 20, 2008 11:42 AM > To: Scott Lawrence > Cc: Joly, Robert (CAR:9D30); Alberto; [email protected] > Subject: RE: [sipx-users] Configuring NAT Traversal in sipxconfig > > > >Cc: Robert Joly; Alberto; [email protected] > >Subject: Re: [sipx-users] Configuring NAT Traversal in sipxconfig > > > > > >On Fri, 2008-06-20 at 09:50 -0400, Martin Steinmann wrote: > > > >> > >> I think I agree with both views, which are a) We need to > >> address cases where the customer uses dynamic addresses and > b) > >> using STUN is not a very reliable way to discover the > external > >> address. > >> > >> However, it seems to me that in exactly those > cases where the > >> customer has a small network with only one gateway to the > >> Internet using a dynamic address STUN would be > quite reliable > >> to discover this external IP address. STUN becomes more > >> unreliable in larger networks with several gateways, but in > >> these cases it is much more likely that the customer uses a > >> fixed IP address assigned by the ITSP. > > > >The caveat with STUN discovery is that it won't always give you the > >right answer unless the the STUN server is at the same IP address as > the > >thing you want to send to. > > > >So if your ITSP has STUN in their proxy, you're good - if not, you > might > >sometimes get the wrong answer by querying a STUN server > somewhere else > >(especially with respect to the ports).
In our case, we would rely on STUN to discover the public IP address only - the port portion would still be handled through port relaying config on the firewall. I think that STUN will be reliable almost everytime if used in that fashion. > Ok, that makes sense. My vote would be then to let the admin > take that decision and not second guess them. > > I think sipXbridge can already use STUN as an option. What > about the NAT traversal feature in the proxy? Does not have it. It would need to be added. In general, I have some issues with relying on STUN to discover the public IP address and track it as it changes over time. If we periodically send STUN binding requests, that creates windows between polls where our representation of the public IP address may be outdated resulting in failed calls - of course that window could be minimized by reducing the polling interval but cannot be closed. I do not like the idea of doing STUN before every call either as call setup time is now dependent on a STUN server that we do not control. I'm toying with a sipXecs-hosted DynDNS relay concept to possibly address these issues. I'll post something on this list once I get something more concrete. > --martin > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
