[SR-Users] dmq_usrloc - which server?

[Alex Balashov]

Hi Charles, 

A few other questions arise, mostly as a matter of best practices rather
than functional possibility:

(1) Most of the endpoints in question are NAT'd, and I was using
fix_nated_register() and the "received AVP" for mitigation.

Although the "Received" address is replicated by DMQ, using Path to
discover the adjacent "last hop" registrar overwrites the destination
set and stops the 'received' parameter from being utilised. Moreover,
there is no way to intercept it before the lookup() overwrites $du with
Path instead of 'received'.

There are two solutions to this; one is to send the call to the last-hop
registrar and have it re-do the lookup(), reviving the 'received'
attribute. The requires transmitting the original AOR to be looked up as
a custom header or whatnot. The other option is to manually fetch the
'received' attribute subsequent to the lookup() on the source
(first/egress hop) registrar using reg_fetch_contacts(), which is what I
currently do. I stick that in a custom header instead.

Another option is to change the NAT traversal approach altogether and
instead of using the 'received' attribute, use set_contact_alias() to
modify the stored Contact everywhere. 

Perhaps the latter option is the simplest of all, but I am curious as to
whether you have an opinion on possible pitfalls and virtues in the
context of a dmq_usrloc-replicated registrar cluster.

(2) When multiple Contact bindings are available for the same AOR, both
local and remote, it would be desirable to have an easy way of selecting
the most adjacent one (i.e. the local one, in preference to the ones
removed by one Path hop).

Is there a nonobvious easy way to accomplish this, or am I going to have
to switch from lookup() to reg_fetch_contacts() or walk the lookup()'d
branches and find the one I want?

Thanks,

-- Alex

On Mon, Feb 05, 2018 at 03:32:21PM +0000, Charles Chance wrote:

> Hi Alex,
> 
> Thanks for the update - glad you solved it.
> 
> Cheers,
> 
> Charles
> 
> On Mon, 5 Feb 2018 at 14:41, Alex Balashov <abalashov at evaristesys.com>
> wrote:
> 
> > Hi Charles,
> >
> > By way of further update:
> >
> > On Thu, Feb 01, 2018 at 07:06:41PM +0000, Charles Chance wrote:
> >
> > > > > modparam("registrar", "path_mode", 0)
> > > > > modparam("registrar", "path_use_received", 1)
> > > > > modparam("registrar", "path_check_local", 1)
> > > >
> > > > I have the latter set, but left the former two to defaults.
> > > >
> > > >
> > > That may be the issue then, I think. The default for path_mode is 2:
> > >
> > > "The path header is only saved into usrloc, if path support is indicated
> > in
> > > the registration request by the “path” option of the “Supported” header."
> >
> > path_mode 0 + path_check_local + append_hf() + msg_apply_changes() was
> > indeed the winning formula. Thank you.
> >
> > -- Alex
> >
> > --
> > Alex Balashov | Principal | Evariste Systems LLC
> >
> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users at lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> -- 
> *Charles Chance*
> Managing Director
> 
> t. 0330 120 1200    m. 07932 063 891
> 
> -- 
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
> Birmingham Science Park, Birmingham B7 4BB.

> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/