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.frhttps://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.
Hey David,
No, the uac module really doesn’t do what you want based on how I understand your request.
You really want to do what I call “Pass-Thru” auth with a cache. This is where your phones register thru Kamailio. But, you want Kamailio to act as a cache and invalidate the cache every hour for a particular extension. Hence, phones register/re-register to Kamailio using the cache, but Kamailio only passes thru the auth every hour.
Kamailio doesn’t have a module like this that I know off. OpenSIP’s has a module that does this. I’ve been thinking about porting it over, but I can’t stay focused enough :-)
On Oct 12, 2020, at 9:02 AM, David VILLAUME david.villaume@sewan.fr 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@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
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.com Sent: Monday, October 12, 2020 3:20 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; David VILLAUME david.villaume@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.frhttps://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@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
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@gmail.com *Sent:* Monday, October 12, 2020 3:20 PM *To:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; David VILLAUME david.villaume@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@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
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.
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.com Sent: Monday, October 12, 2020 3:59 PM To: David VILLAUME david.villaume@sewan.fr; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Local cache registration
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
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.commailto:miconda@gmail.com Sent: Monday, October 12, 2020 3:20 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org; David VILLAUME david.villaume@sewan.frmailto:david.villaume@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.frhttps://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@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
somehow I haven't approached un-registrations in the previous email ... but it doesn't add that much.
If the expires is 0 (variable $expires(...) can be useful here) in REGISTER and comes from a trusted security token, you can call save() with the flag for no-reply and forward to the main registrar (or do it on reply with unregister). I would also lower the expires for htable item using $shtex(...) with same key (security token) to a few seconds to cope with retransmissions, rather than just deleting it.
However, if it expires because the user didn't sent any new registration, then you have to handle that when traffic (INVITE, etc.) comes from main registrar and return 404, 408 or 484. While there are event callbacks for both htable and usrloc records expiration, triggering a register towards main registrar is useless if main registrar asks for authentication (as it should do in most of the cases), because I understood you want to cover the case when kamailio doesn't know (cannot access) the user password. It would be a similar case like when the user is suddenly disconnected, before doing unregister (e.g., no more internet access, power off, ...) If kamailio has access to user password, the uac module becomes also an alternative.
Cheers, Daniel
On 12.10.20 16:11, David VILLAUME wrote:
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.
Regards,
David
*From:*Daniel-Constantin Mierla miconda@gmail.com *Sent:* Monday, October 12, 2020 3:59 PM *To:* David VILLAUME david.villaume@sewan.fr; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] Local cache registration
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@gmail.com> <mailto:miconda@gmail.com> *Sent:* Monday, October 12, 2020 3:20 PM *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org>; David VILLAUME <david.villaume@sewan.fr> <mailto:david.villaume@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@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 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
Thanks you so much for these helpful guidelines.
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.com Sent: Monday, October 12, 2020 4:56 PM To: David VILLAUME david.villaume@sewan.fr; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Local cache registration
Hello,
somehow I haven't approached un-registrations in the previous email ... but it doesn't add that much.
If the expires is 0 (variable $expires(...) can be useful here) in REGISTER and comes from a trusted security token, you can call save() with the flag for no-reply and forward to the main registrar (or do it on reply with unregister). I would also lower the expires for htable item using $shtex(...) with same key (security token) to a few seconds to cope with retransmissions, rather than just deleting it.
However, if it expires because the user didn't sent any new registration, then you have to handle that when traffic (INVITE, etc.) comes from main registrar and return 404, 408 or 484. While there are event callbacks for both htable and usrloc records expiration, triggering a register towards main registrar is useless if main registrar asks for authentication (as it should do in most of the cases), because I understood you want to cover the case when kamailio doesn't know (cannot access) the user password. It would be a similar case like when the user is suddenly disconnected, before doing unregister (e.g., no more internet access, power off, ...) If kamailio has access to user password, the uac module becomes also an alternative.
Cheers, Daniel On 12.10.20 16:11, David VILLAUME wrote: 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.
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.commailto:miconda@gmail.com Sent: Monday, October 12, 2020 3:59 PM To: David VILLAUME david.villaume@sewan.frmailto:david.villaume@sewan.fr; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: Re: [SR-Users] Local cache registration
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
Regards, David
From: Daniel-Constantin Mierla miconda@gmail.commailto:miconda@gmail.com Sent: Monday, October 12, 2020 3:20 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org; David VILLAUME david.villaume@sewan.frmailto:david.villaume@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.frhttps://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@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
have a look e.g. at this thread (also the replies) to get some ideas: https://puck.nether.net/pipermail/voiceops/2018-June/007716.html
Cheers,
Henning
-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of David VILLAUME Sent: Monday, October 12, 2020 3:03 PM To: sr-users@lists.kamailio.org Subject: Re: [SR-Users] Local cache registration
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.frhttps://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.
Hello,
just to add that the examples given in that old discussion with jsonrpc commands are now available with module functions, e.g.:
- https://www.kamailio.org/docs/modules/stable/modules/uac.html#uac.f.uac_reg_...
So it is more simpler config these days and many more related features in the uac module.
Cheers, Daniel
On 12.10.20 15:21, Henning Westerholt wrote:
Hello,
have a look e.g. at this thread (also the replies) to get some ideas:
https://puck.nether.net/pipermail/voiceops/2018-June/007716.html https://puck.nether.net/pipermail/voiceops/2018-June/007716.html
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/ https://skalatan.de/blog/
Kamailio services – https://gilawa.com https://gilawa.com/
*From:*sr-users sr-users-bounces@lists.kamailio.org *On Behalf Of *David VILLAUME *Sent:* Monday, October 12, 2020 3:03 PM *To:* sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] Local cache registration
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
David VILLAUME -
Henning Westerholt -
Mack Hendricks