M. Ranganathan wrote: > On Thu, Jun 11, 2009 at 9:56 AM, Damian Krzeminski<[email protected]> wrote: >> ...or "Make sipXbridge available in the Internet calling Default SBC pull >> down" >> >> As the things are implemented now sipXconfig makes sure that all calls >> directed to configured ITSP are routed through sipXbridge (by generating >> routes to all configured 'trunks' and adding them to forwarding.xml). >> >> Looks like XX-5884 can be solved if sipXconfig were to allow configuring >> sipXbridge as default SBC. This is trivial to do (and you can try it just >> by adding 'sipXbridgeSbcModel.internetCallingSupported=true' to >> sipxconfig.properties). >> >> It would be nice to see an explanation on how this change is to affect >> XX-5884. But I have a simpler question: if we do change this as requested - >> are we to remove automatic routes generation implemented in XX-5623? > > After conferring with Scott this morning, I conclude that the two are > not mutually exclusive. >
Nice. It makes things simpler. > >> Also what type of advise should we be giving to administrator: should >> sipXbridge be always used as default SBC for entire network? Even if there >> are no trunks configured? > > Not sure how or why this relates to selecting sipxbridge in the case > under discussion. If the user selects sipxbridge as the default > gateway in the pulldown menu then internet calls ( regardless of > domain ) will be sent there. > > Let me explain what I mean: in 3.10 if you wanted your URL calls to work you had to enable Internet Calling and configure default SBC. (Otherwise your calls would bypass SBC that among other things provided NAT traversal). It seems to me that in 4.0 it's not really needed since NAT traversal built in the proxy just takes care of that. And what we do instead in 4.0 is to tell administrators to enable internet calling if some other, more complicated calling scenarios, fail. What I am trying to find out is: should we just advise administrators to enable internet calling in all cases? only specific cases? D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
