5 Oct
2009
5 Oct
'09
10:27 a.m.
Hello,
On 02.10.2009 6:31 Uhr, Alex Balashov wrote:
Henning Westerholt wrote:
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
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)"));
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.
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
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?