Hi all, I'd like to simulate in kamailio 1.4.4, the loading of a global setting (like a parameter that is loaded only at startup), using AVPs. So, I want to load some AVP only at proxy startup. Probably it is not possible because, if I'm not wrong, AVPs are transaction persistent. The problem is that I don't need to load those AVPs for every transaction. There is a why to implement such configuration?
Thanks. Best regards.
Hello,
On 1/11/10 12:09 PM, Antonio Reale wrote:
Hi all, I'd like to simulate in kamailio 1.4.4, the loading of a global setting (like a parameter that is loaded only at startup), using AVPs. So, I want to load some AVP only at proxy startup. Probably it is not possible because, if I'm not wrong, AVPs are transaction persistent. The problem is that I don't need to load those AVPs for every transaction. There is a why to implement such configuration?
you should upgrade for such features: - in 1.5.x you can use htable to cache value in shared memory and perhaps offers what you need - in 3.0.0 you still have htable, but you have also the global avps, you can set/get them with $avp(g.name). You can load at startup within route event_route[htable:mod-init] { ... } via sqlops
Cheers, Daniel
2010/1/13 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
Hi Daniel.
you should upgrade for such features:
- in 1.5.x you can use htable to cache value in shared memory and perhaps
offers what you need
- in 3.0.0 you still have htable, but you have also the global avps, you can
set/get them with $avp(g.name). You can load at startup within route event_route[htable:mod-init] { ... } via sqlops
Perfect. I'll evaluate your suggestions. Probably global AVPs is what I need, because I can use them without change the script logic.
Cheers, Daniel
Thanks for your support. Regards.
2010/1/13 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
you should upgrade for such features:
- in 1.5.x you can use htable to cache value in shared memory and perhaps
offers what you need
- in 3.0.0 you still have htable, but you have also the global avps, you can
set/get them with $avp(g.name). You can load at startup within route event_route[htable:mod-init] { ... } via sqlops
I migrated to kamailio 3.0 and I used custom cfg file parameters as explained here: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#custom_cfg_f... just simple and clear solution. At this point there are three possible solution (probably four, using cfg_db module): htable, global AVPs and custom cfg file parameters. Can someone give a very brief comparison between the three implementations? Is one better than the others? Thanks.
Cheers, Daniel
Best regards, Antonio
On Monday 25 January 2010, Antonio Reale wrote:
you should upgrade for such features:
- in 1.5.x you can use htable to cache value in shared memory and perhaps
offers what you need
- in 3.0.0 you still have htable, but you have also the global avps, you
can set/get them with $avp(g.name). You can load at startup within route event_route[htable:mod-init] { ... } via sqlops
I migrated to kamailio 3.0 and I used custom cfg file parameters as explained here: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#custom_cfg_ file_parameters just simple and clear solution. At this point there are three possible solution (probably four, using cfg_db module): htable, global AVPs and custom cfg file parameters. Can someone give a very brief comparison between the three implementations? Is one better than the others? Thanks.
Hi Antonio,
from the performance POV this three ways make probably not that much a difference, but i'd differ them over the intendent use case:
1. global AVPs
This is the oldest mechanism, i think they were implemented as a list in the core. In kamailio we moved them to the pseudo-variables, but they still have certain core parts. I'd use them if you've a smaller set of values to store, like one or two values you set during startup.
2. htable
This is a mechanism coming from the kamailio side, they implement a hash table like you probably know from other languages as perl or java. As this implement a key-value storage which is basically arbitrary large (depending on the memory) i'd use them to store certain attributes, like the number of failed authentification per user (as described in the mod docs).
3. custom cfg params
This is a mechanism coming from the SER side, i think. If I understand the docs correctly i'd use them if i have certain attributes which belong to a bigger group or class, like a hostname or simliar. Its probably easier to add structure to your values as if you use the (global) AVPs.
Hope that helps,
Henning
2010/1/25 Henning Westerholt henning.westerholt@1und1.de:
from the performance POV this three ways make probably not that much a difference, but i'd differ them over the intendent use case:
- global AVPs
This is the oldest mechanism, i think they were implemented as a list in the core. In kamailio we moved them to the pseudo-variables, but they still have certain core parts. I'd use them if you've a smaller set of values to store, like one or two values you set during startup.
- htable
This is a mechanism coming from the kamailio side, they implement a hash table like you probably know from other languages as perl or java. As this implement a key-value storage which is basically arbitrary large (depending on the memory) i'd use them to store certain attributes, like the number of failed authentification per user (as described in the mod docs).
- custom cfg params
This is a mechanism coming from the SER side, i think. If I understand the docs correctly i'd use them if i have certain attributes which belong to a bigger group or class, like a hostname or simliar. Its probably easier to add structure to your values as if you use the (global) AVPs.
Hope that helps,
Henning
Hi Henning, thanks for the clarification. It is exactly what I needed.
Regards,
-
Antonio Reale -
Daniel-Constantin Mierla -
Henning Westerholt