[sr-dev] registrar - additional features
Olle E. Johansson
oej at edvina.net
Thu Feb 19 14:18:36 CET 2015
I haven't seen any updates to the doc files - or did I miss them?
/O
On 19 Feb 2015, at 14:08, Luis Azedo <luis at 2600hz.com> wrote:
> Hi,
>
> made this commit to the pull request.
> i think it answers all questions, comments appreciated.
>
>
> registrar - match changes
> add param match_flags bit mask
> 1 callid
> 2 received
> 3 contact
>
> add param match_return_flags - bit mask
> 1 add contact xavp
> in registered adds or sets into the transaction
> in reg_fetch_contacts adds to plc structure
>
> changes to registered
> check the match_flags bit mask value
> and tries to find correspondent field in xavp_cfg
> matches with the fields found
>
> also looks for match_flags, match_return_flags in xavp_cfg to override the params
>
> preserves existing behaviour
> removes reg_callid_avp
>
> From: sr-dev [sr-dev-bounces at lists.sip-router.org] on behalf of Luis Azedo [luis at 2600hz.com]
> Sent: Wednesday, February 18, 2015 4:44 AM
> To: miconda at gmail.com; Kamailio (SER) - Development Mailing List
> Subject: Re: [sr-dev] registrar - additional features
>
> Hi Daniel,
>
> thank you for the contribution.
>
> see inline
>
> From: sr-dev [sr-dev-bounces at lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda at gmail.com]
> Sent: Wednesday, February 18, 2015 3:51 AM
> To: Kamailio (SER) - Development Mailing List
> Subject: Re: [sr-dev] registrar - additional features
>
> 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)?
>
> A : it will add the xavp for the first contact found since registered function exits on first match.
>
>> 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?
>
> A : i like this approach. trying that.
>>
>>
>> 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.
>
> A : instead of a parameter, we could add a parameter "return_xavp_on_match" (or better naming) that would control the addition of the xavp in registered and reg_fetch_contacts.
> in reg_fetch_contacts the xavp is returned for each contact (not like in registered).
> i added it since we are already doing it in the lookup and lookup_to_dset.
>
> 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
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150219/6c849918/attachment-0001.html>
More information about the sr-dev
mailing list