[sr-dev] [Kamailio-Users] Functions that don't accept pvars.

[Daniel-Constantin Mierla]

Hello,

On 02.10.2009 6:31 Uhr, Alex Balashov wrote:
> Henning Westerholt wrote:
>
>> Ah, you mean something like a "pv_printf()" exported to the 
>> configuration
>> file? This would be indeed a nice workaround, but not sure if its 
>> possible
>> on a first glance. Perhaps Daniel can comment on this? 
>
> Yeah, exactly.  :)  A container that defers binding of the string or 
> numerical scalar value to runtime and whose return value would be 
> evaluated by the config lexer exactly the same as if it were a string 
> literal in the file, i.e.
>
>   rtpproxy_offer("", make_str_from_pv("$var(src_ip)"));
the problem is the fixup function. The string given as parameter is 
further replaced with a compiled version (e.g., to integer or other more 
complex structures). This causes the issues with the perl module. The 
solution is that for each fixup function to be a free fixup function 
that would free the memory used after fixup. Then these operations can 
be done at runtime, not causing memory leaks.

We started to add free fixup functions, but the task is not yet 
completed. So this would be available in a future release.

Cheers,
Daniel

>
> This would provide a bridge to solve a lot of compatibility problems 
> that presently exist between PV-enabled and legacy pre-PV core and 
> module functions.
>
>> Another thing, it
>> should be not that hard to update rtpproxy to be able to use PVs, the
>> fixup function and the evaluation functions are available in the core 
>> and
>> more or less just needs to be called.
>
> Yeah, I think I don't have a choice and that is what I'm going to have 
> to try.  But it's all for nothing if rtpproxy can't bridge traffic 
> from 5 network interfaces by binding to them all simultaneously.  Do 
> you know if this is possible?
>

-- 
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/