> > Dale Worley wrote:
>
> > > 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.
>
> Damian Krzeminski wrote:
>
> > 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.
>
> We don't currently create/require a DNS SRV name that has the
> desirable properties (we could use the SIP_DOMAIN_NAME, but
> that does not have the property of preferring the local
> system over any other peers).
>
> Given that the message being processed by the
> registry/redirect server came from some proxy, and the
> response it is creating will go back to that same proxy (not
> always the one on the same box, incidentally), chances are
> that the current configuration will work.
Yes and no. Lets assume two systems, the first one composed of Proxy P1
and registrar/Redirect RR1 and the second composed of Proxy P2 and
registrar/Redirect RR2.
When P1 sends an INVITE to RR2, it is true that the resulting 302 will
be sent to P1 however, RR2's AuthRouter redirect plug-in will add a
ROUTE header parameter to the 302 Contacts pointing at P2. When the 302
is processed by P1, the forked INVITEs will be sent to P2 in accordance
with the Route header and if P2 is down, the call will fail.
[...]
> I don't think we need a change for 4.0
I need to find out what that does to NAT traversal...
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
