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 <[email protected]> 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 [[email protected]] on behalf of Luis Azedo > [[email protected]] > Sent: Wednesday, February 18, 2015 4:44 AM > To: [email protected]; Kamailio (SER) - Development Mailing List > Subject: Re: [sr-dev] registrar - additional features > > Hi Daniel, > > thank you for the contribution. > > see inline > > From: sr-dev [[email protected]] on behalf of > Daniel-Constantin Mierla [[email protected]] > 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 > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
