Hi,

after reviewing "modules_s/usrloc" i could merge the reg-avps into "modules_k/usrloc". The functionality is as follows:

in module-parameters: modparam("usrloc", "reg_avp_flag", "name_of_avp_flag")

in Routing logic: In order to save a param into usrloc:

$test = "Something"; setvarflag($test, "name_of_avp_flag"); save("location");

Restore the parameters: lookup("location"); read_reg_avps("location", "$fU") (where $fU is user, for which the parameters will be loaded. It will then take the modified URI of the current message, to get the contact, for which the parameters will be loaded).

It took a little while to understand the functionality of the modules_s/usrloc, since it is not documented.

The variables of SER ($test = "something") and the setvarflag()/getvarflag() are disabled in Kamailio; so probably i should think of something else here.

Any comments?

Carsten

2011/2/8 Carsten Bock lists@bock.info:

Hi,

thanks for the hint. I was always about to say, it does not exist but it is simply not documented. I will take a look at it; thanks!

Thanks, Carsten

2011/2/8 Daniel-Constantin Mierla miconda@gmail.com:

...

Hello,

On 2/8/11 11:59 AM, Carsten Bock wrote:

...

Hi everyone,

just a short request for comments: Similar to the dialog-variables, which i implemented in my IMS branch recently, i need something similar for usrloc. Basically, i need to store additional data to a registration; which i can access after "lookup()" or upon a "is_registered()" call. Basically:

$reg_var(test) = "some value"; save();

---

lookup(); xlog("reg_var(test) is $reg_var(test)\n");

Now there are different approaches:

1. implement this funtionality in usrloc/registrar directly (similar

to my dialog-pvar-implementation). The performance when doing this impact should be minor if not used, since simply an empty pointer would be carried along every registration. This would be the cleanest way to do this; but however since many people are using usrloc i have a little respect doing changes on such core-module. Maybe it could be implemented as a change in usrloc and a dedicated module just for getting and setting the values. 2) another way would be to implement this in a dedicated module. This would mean, that i would not touch usrloc module and it would of course have no impact on "regular" usrloc usage at all if not used. I would have to add a second list of in-memory values, which would have to be synched with db, a second timer to do so. The list would be dependent on the usrloc callbacks. There is always the danger data-inconsistency. 3) is there any way, to do this with some event-routes, shared-variables or something similar?

Any thoughts? Comments very welcome!

I think that modules_s/usrloc has something like this, maybe looking at it can help somehow to get it in k version.

Cheers, Daniel

...

Kind regards, Carsten

P.S.: If i do not receive any comments, i would implement the first approach (directly in usrloc/registrar) in my IMS-branch for later merging into master.

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- Daniel-Constantin Mierla http://www.asipto.com

-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany

Mobile +49 179 2021244 Home +49 40 34927217 Büro (Verl) +49 5246 801427 Fax +49 40 34927218 mailto:carsten@bock.info

Hi Klaus,

the current implementation of modules_s/usrloc does not require any additional DB-Lookup. The data is simply kept with all the other data of a contact. The stored AVP's are serialized to a string and stored in an extra column together with all the other data.... I thought about this implicit loading as well, but you should consider the following point (which at least applies for my usecase): I need to access those values for both originating (from the CPE to server) and terminating (from the server to the CPE) case. So probably the implicit loading of the AVP's might be a good thing... I think it is not a good idea to store all AVP's automatically. In some setups we used to make quite a lot use of the AVPs with about having 40 AVP's for a dialog....

Carsten

2011/2/8 Klaus Darilion klaus.mailinglists@pernau.at:

Carsten Bock wrote:

...

In order to save a param into usrloc:

$test = "Something"; setvarflag($test, "name_of_avp_flag"); save("location");

Restore the parameters: lookup("location"); read_reg_avps("location", "$fU") (where $fU is user, for which the parameters will be loaded. It will then take the modified URI of the current message, to get the contact, for which the parameters will be loaded).

Does this require additional database lookups on write and read (DB-mode 3)?

I wonder why the AVP need to be loaded explicitly? IMO either the stored/restored AVPs should be configured as module parameter, or if done dynamically, all the stored AVPs should be restored automatically.

regards klaus