Dale Worley wrote:
> I filed an issue on this (XCF-3645), but it really should be discussed
> first:
>
> 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.
>
> So what we need is that these values should be DNS SRV names that
> preferentially route to the proxy on the same server, but fall back to
> the proxy on the other server(s). This should be the similar to the old
> "ap" DNS names. But we don't seem to be generating those names any
> more.
>
> Dale
>
>
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.
D.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
