[sr-dev] registrar - additional features

[Daniel-Constantin Mierla]

Hello,

some comments inline.

On 17/02/15 23:25, Luis Azedo wrote:
> Hi,
>
> please consider the addition of these features to master branch.
>
> you can view the full PR in https://github.com/kamailio/kamailio/pull/91
>
> the purpose of these additional features is to provide better
> information to configuration script to help in complex routing
> decisions and adding custom headers based on rich information. 
>
> registrar - add user xavp on successful registered call
>
> this commit adds the contact xavp when we call registered()
> it acts like lookup without rewriting uri or appending branches
> it acts like lookup_to_dest without appending branches
>
> benefits, used in conjuction with usrloc param xavp_contact
> prior to this commit, we would have to use sqlops to make a select
> directly into location_attrs, but not all sb engines support raw query
> or we would need to call lookup causing the unnecessary and unwanted
> set of the ruri.
>
> modparam("usrloc", "xavp_contact", "ulattrs")
> ..
> if(registered("location", "$fu") ) {
>    $xavp(ulattrs=>my extended information about the contact)
> }
>
> before
> if( registered("location", "$fu") ) {
> ##    lookup_to_dset("location", "$fu") ## not available
>     lookup("location", "$fu")
>    $xavp(ulattrs=>my extended information about the contact)

will this add the xavp only for first valid contact found in location
table? Or for all contacts (e.g., when a user is registered with many
phones)?


> registrar - add optional avp params for usrloc comparison
>
> reg_received_avp - match with received field
> reg_contact_avp - match with contact field
>
> this commit adds 2 optional params to be used on the registered function
>
> prior to this commit, the only restriction available when calling
> registered was by using a call-id.
> the 2 params added allow the match to be more restrictive
> . by received column
> . by contact column

I see that the match on call-id was added by Henning back in 2008,
haven't used it.

My concern here is about adding too many avps parameters which can endup
in loops across the list of avps to see if they are defined or not.

I am thinking of having a different implementation that is better in
terms of performances and flexibility, like:
- extend the registered parameters to take one more as flags - here will
be a bitmask of what matching rules to be applied (e.g., 1 - callid
matching, 2 - received matching, 4 - contact matching)
- add the values for matching as part of xavp_cfg avp (e.g., say
xavp_cfg is set to 'reg', then will be $xavp(reg=>match_callid) = "...";
$xavp(reg=>match_received) = "..." ...)

Practically the search for the values to be match will be done only if
the appropriate flag is set.

The avp for matching call id should be removed.

In the future, adding another matching rule will be adding a new flag
and an inner attribute/value for xavp_cfg.

What do you think?

>
>
> registrar - add xavp to reg_fetch_contacts
>
> modparams("usrloc", "xavp_contact", "ulattrs");
>
> this commit adds the usrloc xavp_contact to the returned structure.
> reg_fetch_contacts("location", "$fu", "caller");
> xlog("L_INFO", "$fu xavp = $ulc(caller=>received)");
> xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");

I think this can be done also conditionally -- I would add a new
parameter to reg_fetch_contacts where we can specify this behaviour as a
flag.

Thanks for these contributions and let's see if others have other ideas
or commends on my proposal to get to a solution that is fair from
performance/feature ratio point of view.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150218/8c65d13a/attachment.html>