> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of M. > Ranganathan > Sent: Wednesday, March 25, 2009 6:32 PM > To: Tony Graziano > Cc: [email protected] > Subject: Re: [sipX-dev] Consequences seen when sipXbridge > cannot find itsPublicIP address using STUN > > On Wed, Mar 25, 2009 at 6:13 PM, Tony Graziano > <[email protected]> wrote: > > +1 > > > > I can see where the Internet is working and the ITSP is > also, but if someone else's stun server is not working, I'd > certainly want my internal users to be able to use the system > anyway. That's kinda scary to me. > > > > At the same time, does it make sense to be able to input > primary/secondary/tertiary stun servers in to help prvent > this kind of thing? > > > >>>> Chris Parfitt <[email protected]> 03/25/09 4:28 PM >>> > > Would it be possible/practicable to make SIP Proxy more > forgiving in a > > situation when sipXbridge cannot find its Public IP address via the > > default STUN server? > > Its not SIpXbridge which is implicated here. Its SipXRelay. > The behavior you are observing has nothing to do with > sipxbridge. If SipxRelay cannot find its public address and > it is configured to be be behind a NAT then it will not start > hence sipx proxy will not start because a dependency has been > defined in the startup script of sipx proxy. Perhaps this > dependency can be removed. In this case remote worker phones > will not work. However the rest of the system will work. > > If that can be done I vote +1.
If we allowed sipXproxy to run even when sipXrelay is not running, the following would happen: Pros: + sipXproxy would run even when sipXrelay can't reach the STUN server. This would allow some local calls to work. Cons: - In cases where sipXproxy is running and sipXrelay isn't, any call to any endpoint outside our private network will not work. This includes calls to remote workers, ITSPs and remote branches. I introduced the dependency to avoid leaving the system where some basic calls work and some don't. My own personal opinion is that this kind of hit-and-miss behavior is worse than the system not running at all because can give the impression that the system is fine until you try a call that needed sipXrelay. The best proposition I have heard so far is to provide the ability to configure multiple STUN servers. That does not guard against all problems but it will at least make the system resilient to STUN server failures. 8< _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
