Scott Lawrence wrote:
> On Mon, 2009-06-15 at 15:27 -0400, Mark Gertsvolf wrote:
> >
> > 1. Allow admin to change the SIP proxy port from standard 5060 to
> > non-standard port. This works around SIP-aware devices and
> non-network
> > neutral service providers. Combined with the ability to
> configure the
> > phone to use non-standard SIP port, we can isolate
> ourselves from and
> > issues introduced by the network.
>
> > In this first case, I would like to have a way to change
> the standard
> > listening SIP ports (both UDP and TCP) via admin UI. At the moment
> > there is no way to do that without manually modifying configuration
> > files, which then get overwritten by configuration changes.
>
> I see no reason not to have an Advanced Setting for changing
> the proxy port (it's already in the proxy configuration
> file). We would also need to modify how the corresponding
> SRV records are generated...
My experiments with sipXproxy running on a custom port indicate that the
solution is not as simple as changing the port in several configuration
files.
My first issue running sipXproxy on a custom port is - REGISTER request
enters a loop. I tracked the issue down to a problem in
forwardinrules.xml.
Rules in forwardingrules.xml match R-URI against the following set of
hostport values (taken from forwardinrules.vm):
<routeFrom>${proxyService.domainName}:${proxyService.sipPort}</routeFrom
>
<routeFrom>${location.address}:${proxyService.sipPort}</routeFrom>
<routeFrom>${location.fqdn}:${proxyService.sipPort}</routeFrom>
<routeFrom>${location.hostname}:${proxyService.sipPort}</routeFrom>
#foreach ($route in ${routes})
<routeFrom>$route</routeFrom>
#end
I configured x-lite to use outbound proxy and the R-URI in outgoing
request is "sip:domain". sipXproxy can't match this R-URI based on the
segment above since all the entries contain a port. When proxy uses
default port, due to URI matching rules "sip:domain" matches
"sip:domain:5060", but when custom port is used there is no match.
Interestingly, an opposite situation is with domain aliases, since the
corresponding routeFrom entry for domain aliases are lacking port.
The solution that worked for me was to add an entry with NO port for
each existing entry in the forwardinrules.vm, as well as add an entry
with port for each domain alias entry. The resulting portion of
forwardingrules.vm looks like this:
<routeFrom>${proxyService.domainName}:${proxyService.sipPort}</routeFrom
>
<routeFrom>${proxyService.domainName}</routeFrom>
<routeFrom>${location.address}:${proxyService.sipPort}</routeFrom>
<routeFrom>${location.address}</routeFrom>
<routeFrom>${location.fqdn}:${proxyService.sipPort}</routeFrom>
<routeFrom>${location.fqdn}</routeFrom>
<routeFrom>${location.hostname}:${proxyService.sipPort}</routeFrom>
<routeFrom>${location.hostname}</routeFrom>
#foreach ($route in ${routes})
<routeFrom>$route:${proxyService.sipPort}</routeFrom>
<routeFrom>$route</routeFrom>
#end
Has anybody ever deployed sipXecs with proxy running on a custom port?
The issues I am encountering with forwardinrules.xml make me think that
I am one of the first to try that. I wonder what other areas in the
product or features might have other unexpected problems.
Thanks,
Mark.
_______________________________________________
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/
