Hello Daniel,
Thanks for your clear
and complete answer knowing I’ts nor part of a module your
approach seems totally comprehensible to me .
I imagine I can add a
second htable with the A-leg expiration interval and a
trigger on expire to perform an uac request to unregister on
the B-leg.
Thanks again for all
your work and quick answers.
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
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> 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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: 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