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. > > Why? > > Here are some scenarios: > > If the Border Controller/internal sipXbridge is added and then "Enable > Server Behind NAT" is enabled while one of the following is true the result > is detailed below: > > . The Stun server specified is incorrect/typo > > . The Stun server specified is down/off the air > > . The Sipxecs is not connected/has access to the Internet to contact > STUN server > > Result: > > In the above three scenarios NAT traversal service and the SIP Proxy service > both fail to restart when the user is prompted to restart them. > > SIP Proxy not restarting due to Missing resource: process 'SipXrelay causes > all incoming/outgoing calls to fail via PSTN Gateways, Internal User calls > fail, AA, Voicemail & Conferences fail, Registration fails basically the box > becomes unusable. > > This effect seems a bit extreme just for the fact that sipXbridge cannot > find its STUN server. > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
