2 Oct
2009
2 Oct
'09
2 a.m.
It's very frustrating that some functions don't accept pseudovariables
and there's no workaround.
For example, in this case I need rtpproxy_offer() and rtpproxy_answer()
to accept an IP address argument that is retrieved from a database.
However, this won't work.
rtpproxy_offer("", $var(src_ip)); # Config compilation error
rtpproxy_offeR("", "$var(src_ip)"); # Results in $var(src_ip)
# literally being placed in the
# SDP body.
I understand it is difficult to go back and update all legacy functions
to accept PVs everywhere. But isn't it possible to provide a
wrapper/compatibility function in the core that will parse a PV and
generate as a result something that other functions can see as a string
literal?
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
2 Oct
2 Oct
6:13 a.m.
The reason I need to do this, by the way, is because I have a host
with 5 network interfaces and depending on where the media is going
the source IP of the media needs to be different. But there are too
many possible combinations for me to just put all of the possible
scenarios statically into the configuration, and it's not clean; I
need it to be dynamic and query a database so it can be changed on the
fly.
Any suggestions for workarounds that allow me to use rtpproxy are welcome!
Thanks,
Alex Balashov wrote:
It's very frustrating that some functions
don't accept pseudovariables
and there's no workaround.
For example, in this case I need rtpproxy_offer() and rtpproxy_answer()
to accept an IP address argument that is retrieved from a database.
However, this won't work.
rtpproxy_offer("", $var(src_ip)); # Config compilation error
rtpproxy_offeR("", "$var(src_ip)"); # Results in $var(src_ip)
# literally being placed in the
# SDP body.
I understand it is difficult to go back and update all legacy functions
to accept PVs everywhere. But isn't it possible to provide a
wrapper/compatibility function in the core that will parse a PV and
generate as a result something that other functions can see as a string
literal?
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
6:17 a.m.
New subject: [Kamailio-Users] Functions that don't accept pvars.
Come to think of it, I don't even know if this is entirely possible
with rtpproxy. In order to forward packets between interfaces it
appears that "bridging mode" is required, and in order to activate it
two listen addresses must be specified - but only two, and not more
than two.
I just figured I would try it with 5 by binding it to 0.0.0.0 and
seeing what happens.
Not sure how to get around this without using MediaProxy, which seems
both increasingly incompatible with Kamailio politically and also
requires a slew of Python dependencies that are difficult to install
on a CentOS host that I do not really administer. If this were a
Debian box like my systems, it would be easier.
Alex Balashov wrote:
The reason I need to do this, by the way, is because I
have a host with
5 network interfaces and depending on where the media is going the
source IP of the media needs to be different. But there are too many
possible combinations for me to just put all of the possible scenarios
statically into the configuration, and it's not clean; I need it to be
dynamic and query a database so it can be changed on the fly.
Any suggestions for workarounds that allow me to use rtpproxy are welcome!
Thanks,
Alex Balashov wrote:
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
It's very frustrating that some functions
don't accept pseudovariables
and there's no workaround.
For example, in this case I need rtpproxy_offer() and
rtpproxy_answer() to accept an IP address argument that is retrieved
from a database. However, this won't work.
rtpproxy_offer("", $var(src_ip)); # Config compilation error
rtpproxy_offeR("", "$var(src_ip)"); # Results in $var(src_ip)
# literally being placed in the
# SDP body.
I understand it is difficult to go back and update all legacy
functions to accept PVs everywhere. But isn't it possible to provide
a wrapper/compatibility function in the core that will parse a PV and
generate as a result something that other functions can see as a
string literal?
6:26 a.m.
New subject: [Kamailio-Users] Functions that don't accept pvars.
On Fri, October 2, 2009 6:17 am, Alex Balashov wrote:
Come to think of it, I don't even know if this is
entirely possible
with rtpproxy. In order to forward packets between interfaces it
appears that "bridging mode" is required, and in order to activate it
two listen addresses must be specified - but only two, and not more
than two.
Hello Alex,
I just figured I would try it with 5 by binding it to
0.0.0.0 and
seeing what happens.
Not sure how to get around this without using MediaProxy, which seems
both increasingly incompatible with Kamailio politically and also
requires a slew of Python dependencies that are difficult to install
on a CentOS host that I do not really administer. If this were a
Debian box like my systems, it would be easier.
Never used mediaproxy so far, but i also got this impressions.
> The reason I need to do this, by the way, is
because I have a host with
> 5 network interfaces and depending on where the media is going the
> source IP of the media needs to be different. But there are too many
> possible combinations for me to just put all of the possible scenarios
> statically into the configuration, and it's not clean; I need it to be
> dynamic and query a database so it can be changed on the fly.
>
> Any suggestions for workarounds that allow me to use rtpproxy are
> welcome!
>
>> It's very frustrating that some functions don't accept pseudovariables
>> and there's no workaround.
>> [..]
>> I understand it is difficult to go back and update all legacy
>> functions to accept PVs everywhere. But isn't it possible to provide
>> a wrapper/compatibility function in the core that will parse a PV and
>> generate as a result something that other functions can see as a
>> string literal?
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? 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.
Regards,
Henning
Henning
6:31 a.m.
New subject: [Kamailio-Users] Functions that don't accept pvars.
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)"));
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?
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
5 Oct
5 Oct
10:27 a.m.
New subject: [Kamailio-Users] Functions that don't accept pvars.
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?
5536
days inactive
5539
days old
5 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt