<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body bgcolor="#FFFFFF" fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi,
<div><br>
</div>
<div>made this commit to the pull request.</div>
<div>i think it answers all questions, comments appreciated.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<p class="commit-title" style="box-sizing: border-box; color: rgb(33, 63, 77); margin: 0px 0px 8px; font-size: 18px; font-weight: bold; text-shadow: rgba(255, 255, 255, 0.498039) 0px 1px; font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI Emoji', 'Segoe UI Symbol';">
registrar - match changes</p>
<div class="commit-desc" style="box-sizing: border-box; margin: -5px 0px 10px; color: rgb(51, 51, 51); font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 13px; line-height: 20.2222232818604px;">
<pre style="box-sizing: border-box; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; margin-top: 10px; margin-bottom: 10px; font-stretch: normal; line-height: 1.45; max-width: 100%; color: rgb(89, 96, 99); white-space: pre-wrap; text-shadow: rgba(255, 255, 255, 0.498039) 0px 1px; word-wrap: break-word;">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</pre>
<pre style="box-sizing: border-box; overflow: visible; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; margin-top: 10px; margin-bottom: 10px; font-stretch: normal; line-height: 1.45; max-width: 100%; color: rgb(89, 96, 99); white-space: pre-wrap; text-shadow: rgba(255, 255, 255, 0.498039) 0px 1px; word-wrap: break-word;"><br></pre>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div id="divRpF670947" style="direction: ltr;"><font face="Tahoma" size="2" color="#000000"><b>From:</b> sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Luis Azedo [luis@2600hz.com]<br>
<b>Sent:</b> Wednesday, February 18, 2015 4:44 AM<br>
<b>To:</b> miconda@gmail.com; Kamailio (SER) - Development Mailing List<br>
<b>Subject:</b> Re: [sr-dev] registrar - additional features<br>
</font><br>
</div>
<div></div>
<div>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">Hi Daniel,
<div><br>
</div>
<div>thank you for the contribution.</div>
<div><br>
</div>
<div>see inline</div>
<div><br>
<div style="font-family:Times New Roman; color:#000000; font-size:16px">
<hr tabindex="-1">
<div id="divRpF574814" style="direction:ltr"><font face="Tahoma" size="2" color="#000000"><b>From:</b> sr-dev [sr-dev-bounces@lists.sip-router.org] on behalf of Daniel-Constantin Mierla [miconda@gmail.com]<br>
<b>Sent:</b> Wednesday, February 18, 2015 3:51 AM<br>
<b>To:</b> Kamailio (SER) - Development Mailing List<br>
<b>Subject:</b> Re: [sr-dev] registrar - additional features<br>
</font><br>
</div>
<div></div>
<div>Hello,<br>
<br>
some comments inline.<br>
<br>
<div class="moz-cite-prefix">On 17/02/15 23:25, Luis Azedo wrote:<br>
</div>
<blockquote type="cite"><style type="text/css" id="owaParaStyle">
<!--
-->
</style>
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">Hi,
<div><br>
</div>
<div>please consider the addition of these features to master branch.</div>
<div><br>
</div>
<div>you can view the full PR in <a class="moz-txt-link-freetext" href="https://github.com/kamailio/kamailio/pull/91" target="_blank">https://github.com/kamailio/kamailio/pull/91</a></div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div><span style="">registrar - add user xavp on successful registered call</span></div>
<div><br>
</div>
<div>this commit adds the contact xavp when we call registered()</div>
<div>it acts like lookup without rewriting uri or appending branches</div>
<div>it acts like lookup_to_dest without appending branches</div>
<div><br>
</div>
<div>benefits, used in conjuction with usrloc param xavp_contact</div>
<div>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.</div>
<div><br>
</div>
<div>modparam("usrloc", "xavp_contact", "ulattrs")</div>
<div>..</div>
<div>if(registered("location", "$fu") ) {</div>
<div> $xavp(ulattrs=>my extended information about the contact)</div>
<div>}</div>
<div><br>
</div>
<div>before</div>
<div><span style="font-size:13.3333330154419px">if( registered("location", "$fu") ) {</span></div>
<div><span style="font-size:13.3333330154419px">## lookup_to_dset(</span><span style="font-size:13.3333330154419px">"location", "$fu") ## not available</span></div>
<div><span style="font-size:13.3333330154419px"> lookup("location", "$fu")</span></div>
<div style="font-size:13.3333330154419px"> $xavp(ulattrs=>my extended information about the contact)</div>
</div>
</blockquote>
<br>
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)?<br>
<br>
A : it will add the xavp for the first contact found since registered function exits on first match.<br>
<br>
<blockquote type="cite">
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">
<div>
<p class="commit-title" style="color:rgb(33,63,77); margin-right:0px; margin-bottom:8px; margin-left:0px; font-size:18px; font-weight:bold; font-family:Helvetica,arial,freesans,clean,sans-serif,'Segoe UI Emoji','Segoe UI Symbol'">
registrar - add optional avp params for usrloc comparison</p>
<div class="commit-desc" style="">
<pre style="overflow:visible; font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace; margin-top:10px; margin-bottom:10px; line-height:1.45; max-width:100%; color:rgb(89,96,99); white-space:pre-wrap; word-wrap:break-word">reg_received_avp - match with received field
reg_contact_avp - match with contact field</pre>
</div>
</div>
<div><br>
</div>
<div>this commit adds 2 optional params to be used on the registered function</div>
<div><br>
</div>
<div>prior to this commit, the only restriction available when calling registered was by using a call-id.</div>
<div>the 2 params added allow the match to be more restrictive</div>
<div>. by received column</div>
<div>. by contact column</div>
</div>
</blockquote>
<br>
I see that the match on call-id was added by Henning back in 2008, haven't used it.<br>
<br>
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.<br>
<br>
I am thinking of having a different implementation that is better in terms of performances and flexibility, like:<br>
- 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)<br>
- 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) = "..." ...)<br>
<br>
Practically the search for the values to be match will be done only if the appropriate flag is set.<br>
<br>
The avp for matching call id should be removed.<br>
<br>
In the future, adding another matching rule will be adding a new flag and an inner attribute/value for xavp_cfg.<br>
<br>
What do you think?<br>
<br>
A : i like this approach. trying that.<br>
<blockquote type="cite">
<div style="direction:ltr; font-family:Tahoma; color:#000000; font-size:10pt">
<div><br>
</div>
<br>
<div>
<p class="commit-title" style="color:rgb(33,63,77); margin-right:0px; margin-bottom:8px; margin-left:0px; font-size:18px; font-weight:bold; font-family:Helvetica,arial,freesans,clean,sans-serif,'Segoe UI Emoji','Segoe UI Symbol'">
registrar - add xavp to reg_fetch_contacts</p>
<div class="commit-desc" style="margin:-5px 0px 10px">
<pre style="color:rgb(89,96,99); font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace; font-size:13px; line-height:1.45; overflow:visible; margin-top:10px; margin-bottom:10px; max-width:100%; white-space:pre-wrap; word-wrap:break-word">modparams("usrloc", "xavp_contact", "ulattrs");
</pre>
<pre style="color:rgb(89,96,99); font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace; font-size:13px; line-height:1.45; overflow:visible; margin-top:10px; margin-bottom:10px; max-width:100%; white-space:pre-wrap; word-wrap:break-word">this commit adds the usrloc <span style="color:rgb(0,0,0); font-family:Tahoma; font-size:13.3333330154419px; line-height:normal; white-space:normal">xavp_contact to the returned structure.</span></pre>
<pre style="overflow:visible; margin-top:10px; margin-bottom:10px; max-width:100%; word-wrap:break-word">reg_fetch_contacts("location", "$fu", "caller");
xlog("L_INFO", "$fu xavp = $ulc(caller=>received)");
xlog("L_INFO", "$fu xavp = $ulc(caller=>ulattrs=>MyExtendedInfoOnUser)");</pre>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.</div>
<div> in reg_fetch_contacts the xavp is returned for each contact (not like in registered). </div>
<div> i added it since we are already doing it in the lookup and lookup_to_dset.<br>
<br>
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.<br>
<br>
Cheers,<br>
Daniel<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - <a class="moz-txt-link-freetext" href="http://www.kamailioworld.com" target="_blank">http://www.kamailioworld.com</a></pre>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>