Hello,
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, ...
Anyhow, back to what I think you are looking for, here is the logic:
- when a registration comes, store userid, source ip and port in an
avp/xavp (e.g., "$fU/$si/$sp")
- update expires to a an higher value as you want (e.g., 3600) and
forward the registration to main registrar
- 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)
- store in an htable the userid, source ip and port (these being taken
from the xavp/avp created on REGISTER)
- 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
- 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
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.
Cheers,
Daniel
On 12.10.20 15:32, David VILLAUME wrote:
Hello,
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.
I paste the process description of the mechanism described on opensips
module page.
But I can understand your choice to not go that way.
*Contact throttling*
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.
Traffic conversion is done in a /"per-device"/ 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.
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.
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.
https://opensips.org/html/docs/modules/2.3.x/mid_registrar.html
<https://opensips.org/html/docs/modules/2.3.x/mid_registrar.html>
Regards,
David
*From:*Daniel-Constantin Mierla <miconda(a)gmail.com>
*Sent:* Monday, October 12, 2020 3:20 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>rg>; David VILLAUME <david.villaume(a)sewan.fr>
*Subject:* Re: [SR-Users] Local cache registration
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.
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.
Cheers,
Daniel
On 12.10.20 15:02, David VILLAUME wrote:
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.
Is the uac module really designed to perform this operation is
that way ?
Regards,
David
El Sun, 11 Oct 2020 20:07:58 +0000
David VILLAUME <david.villaume at sewan.fr
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>> escribió:
/Hello,/
//
/I try to perform a registration caching in order
to have a short
interval/
/registration on phone <> Kamailio (5
minutes) and a longest
interval on the/
/leg Kamailio <> registrar(1h)./
//
/I’m not so sure about the best way to proceed,
does one of you
have a working/
/sample or some hints about the way to have it
working ?/
//
//
the uac module does that. You can handle upstream registrations in
different
intervals than the ones you receive.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla --
www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda>--
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding:
https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
--
Daniel-Constantin Mierla --
www.asipto.com
www.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding:
https://www.paypal.me/dcmierla