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. My 2c... Ranga. > > _______________________________________________ > 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
