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... _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
