On Wed, Apr 1, 2009 at 11:27 AM, Scott Lawrence <[email protected]> wrote: > On Tue, 2009-03-31 at 21:40 -0400, M. Ranganathan wrote: >> 2009/3/31 Alfred Campbell <[email protected]>: >> > I was just look thought the posts and didn’t see one that talked about >> > this. >> > It seemed Tony was seeing some of this I believe. >> > >> > Problem: Some ITSPs use port 5060 and if that site also requires to use >> > Remote Worker this can be nothing short of challenging to configure. With >> > no ability to change the proxy port via the UI how do we think this is to >> > be >> > configured in the field? I believe someone mentioned a DNS option to solve >> > this however with the challenges we see people having with DNS is this >> > going >> > to be feasible? >> > >> > Since bandwidth.com is very popular should we not look to make this easier >> > to setup? >> > >> > Al >> >> >> I think it would make configuration much simpler to be able to run the >> proxy at a port other than 5060 and make that be configurable via >> sipxconfig. >> >> In addition, It might make sense to add a statless proxy capability to >> sipxbridge. This way, if sipxbridge can identify requests originating >> from remote workers it can statelessly proxy these requests to the >> proxy server ( no relays, SIP Transactions or Dialogs involved - just >> add a Via header and forward the request. Strip the via header for >> responses to proxied requests and forward them ). A single public >> signaling port needs to be configured and exposed through the firewall >> and that port can be 5060. There is no need for split DNS. >> >> The two approaches are not mutually exclusive. >> >> The down side to the stateless proxy is that it winds up being a >> single point of failure. Our redundancy solution of registering the >> remote worker phone with each of the redundant proxy servers will not >> work any more. It also adds signaling overhead. >> >> P.S. This just in from Tony: Bandwidth.com apparently does allow you >> to set the port so you can make it send signaling at any port you >> want. This temporarily solves our problem. Others may not be so >> flexible. > > I'd say that last bit of news is sufficient to consider this closed for > now. > > We should probably think about the bridge/proxy solution for the long > run so that we have only one thing running on the outside... > >
OK I will open up an issue for consideration in 4.2 so we can revisit it then. Thanks for responding. Ranga > -- 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
