On Tue, 2009-04-21 at 16:12 -0400, Damian Krzeminski wrote:
> Dale Worley wrote:
[...]
> > As part of the redirection process, whenever a redirector generates a
> > new target, the "authrouter" plug-in adds a Route header to the new
> > target that points back to the proxy. This allows the proxy to take a
> > look at the generated target for any
> > NAT/SIP-trunk/redirection/authorization implications.
> >
> > This Route address is controlled by the
> > SIP_REDIRECT.999-AUTHROUTER.SIPX_PROXY value in
> > etc/sipxpbx/registrar-config. The current value appears to always be
> > the IP-address and port of the proxy on the registrar's host. This
> > should work fine in a single-server system.
> >
> > But in an HA system, this value makes the system vulnerable, since any
> > new targets created by a registrar *must* be processed through the proxy
> > on the same host. As an extreme case, if the proxy on one host failed
> > and the registrar on the other host failed, *no* calls would go through:
> > The call would go through the one proxy, which would fall back to
> > sending the call through the remaining registrar. But the new targets
> > would have Route headers requiring the call to be processed by the
> > failed proxy on the same host as the registrar, would wouldn't work.
> >
[...]
>
> Just to support Dale's question:
> In 3.10 sipXconfig did not generate a registrar-config.in file.
> The values in registrar-config were inserted from config.defs:
>
> SIP_REDIRECT.999-AUTHROUTER.SIPX_PROXY :
> ${PROXY_SERVER_SIP_HOSTPORT};transport=tcp
>
> Current implementation of sipXconfig mirrors what we had then (unless someone
> manually modified the file but I suspect few users did that).
> If sipXconfig is to generate something else, we'll gladly do that but it's
> need to be fairly clear what this "something else" needs to be.
>
This or similar problems could be seen in other HA scenarios. During
the migration from config.defs to full sipxconfig control of config
files, I chose the values for the config files based on what was in my
config.defs on my dev system. However I think that there were cases (HA
in particular) when config.defs values were modified to support
distributed systems after installation in a production environment (is
this correct)? In that case, sipXconfig will not generate the
appropriate values. It definitely *can* generate these values, but it
is not currently configured to do so.
Kevin
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
