> Robert Joly wrote: > > > > > >> -----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. > > > > That sounds like a reasonable strategy if we assume that not > being able to get a public address is a permanent condition. > In reality network can have some temporary connectivity > problems that can make some call works and others not. > > It sound to me that what we are doing now is checking for a > transient error condition but only when service starts: I am > not sure it's very helpful. > > What if someone has a backup PSTN gateway: if we prevent > proxy from starting they cannot use it to report the problem. > D.
That is a good point. Woof also made some very good points. Here is the dilemna I have. The main reason why I added sipXrelay as a start-up dependency for sipXproxy is because I wanted sipXproxy to be launched after sipXrelay. Without the dependency, sipXproxy could be started before sipXrelay and sipXproxy would fail to contact sipXrelay as part of its initialization sequence. Now, the question is what do you do in that condition? - Raise an alarm warning the admin that some calls will fail only to clear it shortly after when sipXsupervisor gets around to launching sipXrelay? Alarm log pollution -> not good - Retry to contact sipXrelay for some period of time after which an alarm is raised if sipXrelay still cannot be reached? This brings up a number of questions: 1- What constitutes a long enough wait period considering that the definition of 'long enough' may be affected by external factors? 2- What does the proxy do while it is waiting? Does it block on initialization or does it happily start trying to route calls? Problem with the former is that it slows down the start-up of sipXproxy and we already know from sipXrls experience that start-up delays are not desirable. Problem with the latter is that some calls will not work but no alarm warns the admin of that possibility. The ideal solution would be of have a systematic way of imposing a start-up order in sipXsupervisor. If there was a concept of 'weak startup dependency' in sipXsupervisor whereby one could declare that process B should only be started after launch of process A has been attempted (either passed or failed) then that would provide a really clean solution to the problem as this would allow sipXproxy to immediately raise an alarm when it fails to contact sipXrelay at init and start routing the calls it can. Comments? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
