[sr-dev] Implementation question / usrloc / registrar

Daniel-Constantin Mierla miconda at gmail.com
Tue Feb 8 12:24:38 CET 2011


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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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




More information about the sr-dev mailing list