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

[Alex Balashov]

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:
> 
>> 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