<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p>if you just want to accept intermediate every 5-min registrations
based on source ip and port of a successful registration done
every hour, that's quite simple to do in kamailio without any new
module, actually not using uac module at all (see next details).
The uac module is more flexible in some aspects, by allowing local
subscribers to be mapped to subscribers on a remote server with
complete different usernames and passwords, as well as having same
username and password towards another sip system on the same
provider, ...</p>
<p>Anyhow, back to what I think you are looking for, here is the
logic:</p>
<p> - when a registration comes, store userid, source ip and port
in an avp/xavp (e.g., "$fU/$si/$sp")<br>
</p>
<p> - update expires to a an higher value as you want (e.g., 3600)
and forward the registration to main registrar</p>
<p> - if 200ok is received by kamailio, then call save() so contact
details are stored in the local database, then adjust back the
expires (there are functions in textopsx module that allow you
setting header parameters)<br>
</p>
<p> - store in an htable the userid, source ip and port (these
being taken from the xavp/avp created on REGISTER)</p>
<p> - when follow up registrations come, check first if
"$fU/$si/$sp" is matching any key in htable, if yes, just send
200ok after you add the contact headers from register with
append_to_reply(). If no key match in the htable, then do the
steps above<br>
</p>
<p> - htable has to be defined with expires a bit lower than
3600secs (or what is that higher expire value you want), so at
some point the item with the key "$fU/$si/$sp" is deleted, forcing
you to do the steps 1-4 again</p>
<p>As a bonus, if main register supports Path and sends the OPTIONS
keepalive, you skip using registrar/usrloc module (so no more
save()) and you just play with headers updates (ie., change
expires) and storing/checking "security" token "$fU/$si/$sp" in
the htable.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 12.10.20 15:32, David VILLAUME
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:PR2P264MB06078D1FC873991CA8BF5258FD070@PR2P264MB0607.FRAP264.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"Préformaté HTML Car";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
span.PrformatHTMLCar
{mso-style-name:"Préformaté HTML Car";
mso-style-priority:99;
mso-style-link:"Préformaté HTML";
font-family:"Courier New";}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hello,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I just try to reproduce
what we actually have on Oracle or what is done in opensips
mid_registrar module and trust the A leg user as long as it
come from the same IP/port couple that have successfully
registered.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I paste the process
description of the mechanism described on opensips module
page.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">But I can understand
your choice to not go that way.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:13.5pt;mso-fareast-language:FR"
lang="EN-US">Contact throttling<o:p></o:p></span></b></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="mso-fareast-language:FR" lang="EN-US">In "contact
throttling" mode, the mid-registrar can significantly reduce
the registration rate on the main registrar side (between
mid-registrar and main registrar), while coping with a high
registration rate on the end-user side (between end-user and
mid-registrar). This is useful in scenarios were the
end-users are very dynamic and short-lived (like on mobile
devices), but the main registrar cannot cope with large
traffic. <o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="mso-fareast-language:FR" lang="EN-US">Traffic
conversion is done in a
<i>"per-device"</i> manner, according to each unique SIP
Contact header field value. It is achieved by increasing the
"expires" parameter value of each contact, when relaying
registrations to the main registrar. Once such a
registration is completed, subsequent registrations for the
same SIP Contact header field value will be continuously
absorbed by the mid-registrar until, eventually, the
lifetime of the remote registration will have decreased
enough that a refresh (i.e. simply forwarding the next
REGISTER request) is mandatory. <o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="mso-fareast-language:FR" lang="EN-US">A common
occurence is for some SIP User Agents to lose their network
connection (especially when dealing with mobile devices),
hence they do not properly de-register from the
mid-registrar. In this case, in order to avoid stale
registrations on the main registrar (which contains SIP
contacts with greatly extended lifetimes!), the
mid-registrar will appropriately generate De-REGISTER
requests and remove these contacts from the main registrar's
location service as soon as it considers them to have
expired.
<o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="mso-fareast-language:FR" lang="EN-US">The main
practical use for this mode is registration traffic
conversion. By minimizing the strain of processing
registrations on the main registrar, we allow it to dedicate
more system resources to critical areas of the platform,
such as advanced SIP calling features and/or media handling.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><a
href="https://opensips.org/html/docs/modules/2.3.x/mid_registrar.html"
moz-do-not-send="true">https://opensips.org/html/docs/modules/2.3.x/mid_registrar.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="mso-fareast-language:FR"
lang="EN-US">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:FR"
lang="EN-US">David<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="mso-fareast-language:FR" lang="EN-US">From:</span></b><span
style="mso-fareast-language:FR" lang="EN-US">
Daniel-Constantin Mierla <a class="moz-txt-link-rfc2396E" href="mailto:miconda@gmail.com"><miconda@gmail.com></a>
<br>
<b>Sent:</b> Monday, October 12, 2020 3:20 PM<br>
<b>To:</b> Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-rfc2396E" href="mailto:sr-users@lists.kamailio.org"><sr-users@lists.kamailio.org></a>; David VILLAUME
<a class="moz-txt-link-rfc2396E" href="mailto:david.villaume@sewan.fr"><david.villaume@sewan.fr></a><br>
<b>Subject:</b> Re: [SR-Users] Local cache registration<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US">If you do not have access to credentials
on Kamailio, how do you want to authenticate registrations
coming every 5min? If you want to reuse the auth headers
from the 1-hour based registration, then you create a big
security problem, normally nonce is valid very short time to
avoid reply and offline brute force attacks.<o:p></o:p></span></p>
<p><span lang="EN-US">Note that Kamailio can connect to other
databases+tables to fetch username and password, it doesn't
have to be "subscriber" style. You can customize table name
and column names. For example, it can connect to asterisk
realtime database to fetch the password from "secret"
column.<o:p></o:p></span></p>
<p><span lang="EN-US">Cheers,<br>
Daniel<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On 12.10.20 15:02,
David VILLAUME wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span lang="EN-US">I read again the uac doc and didn’t find a way to perform this using the functions that seems to require credentials that I don’t have on the kamailio host.<o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US">Is the uac module really designed to perform this operation is that way ?<o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US">Regards,<o:p></o:p></span></pre>
<pre><span lang="EN-US">David<o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US">El Sun, 11 Oct 2020 20:07:58 +0000<o:p></o:p></span></pre>
<pre><span lang="EN-US">David VILLAUME <</span><a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true"><span lang="EN-US">david.villaume at sewan.fr</span></a><span lang="EN-US">> escribió:<o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> Hello,</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> </i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> I try to perform a registration caching in order to have a short interval</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> registration on phone <> Kamailio (5 minutes) and a longest interval on the</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> leg Kamailio <> registrar(1h).</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> </i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> I’m not so sure about the best way to proceed, does one of you have a working</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> sample or some hints about the way to have it working ?</i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> </i><o:p></o:p></span></pre>
<pre><span lang="EN-US">><i> </i><o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<pre><span lang="EN-US">the uac module does that. You can handle upstream registrations in different<o:p></o:p></span></pre>
<pre><span lang="EN-US">intervals than the ones you receive.<o:p></o:p></span></pre>
<pre><span lang="EN-US"> <o:p></o:p></span></pre>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:FR"
lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<pre><span lang="EN-US">_______________________________________________<o:p></o:p></span></pre>
<pre><span lang="EN-US">Kamailio (SER) - Users Mailing List<o:p></o:p></span></pre>
<pre><a href="mailto:sr-users@lists.kamailio.org" moz-do-not-send="true"><span lang="EN-US">sr-users@lists.kamailio.org</span></a><span lang="EN-US"><o:p></o:p></span></pre>
<pre><a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" moz-do-not-send="true"><span lang="EN-US">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</span></a><span lang="EN-US"><o:p></o:p></span></pre>
</blockquote>
<pre><span lang="EN-US">-- <o:p></o:p></span></pre>
<pre><span lang="EN-US">Daniel-Constantin Mierla -- </span><a href="http://www.asipto.com" moz-do-not-send="true"><span lang="EN-US">www.asipto.com</span></a><span lang="EN-US"><o:p></o:p></span></pre>
<pre><a href="http://www.twitter.com/miconda" moz-do-not-send="true"><span lang="EN-US">www.twitter.com/miconda</span></a><span lang="EN-US"> -- </span><a href="http://www.linkedin.com/in/miconda" moz-do-not-send="true"><span lang="EN-US">www.linkedin.com/in/miconda</span></a><span lang="EN-US"><o:p></o:p></span></pre>
<pre><span lang="EN-US">Funding: </span><a href="https://www.paypal.me/dcmierla" moz-do-not-send="true"><span lang="EN-US">https://www.paypal.me/dcmierla</span></a><span lang="EN-US"><o:p></o:p></span></pre>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
</body>
</html>