Hi,
okay, so I really misunderstood the IP parameter. Thanks for your solution,
from the first look it does work. Is there anything I should consider or
watch specifically when using msg_apply_changes() in the middle of
processing the request?
Best Regards,
Sebastian
On Fri, Aug 29, 2014 at 1:52 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
Hello,
the second parameter is to give the IP to appear in sdp, instead of the
rtpproxy ip.
What you can try is to update the sdp with fix_natted_sdp() with the
source IP as seen by the LB, then do msg_apply_changes() and pass the flag
to trust the ip in sdp -- not sure it is going to work, by worth giving a
try.
Perhaps a flag to overwrite the source IP would be good.
Cheers,
Daniel
On 29/08/14 11:44, Sebastian Damm wrote:
Hi,
I have the following setup:
UAC ---> LB ---> Proxy ---> GW
In NAT scenarios the loadbalancer detects it, but the proxy communicates
with the RTP proxy. I want to send the original caller IP as detected by
the loadbalancer (and transported to the proxy) to the RTP proxy.
As far as I understand the documentation of the rtpproxy module, I could
call rtpproxy_manage with a second parameter, indicating which IP address
should be sent to the RTP proxy. I tried sending a pseudovariable, both
within quotes or not, or even a static string. But when I look at those
messages sent to the RTP proxy, there's always the IP from where the SIP
packet was received (the loadbalancer IP) in the request.
Previously we used the "r" parameter, sending the original IP from the SDP
to the proxy. But due to strange behavior of some UACs, we want to get rid
of that.
Do I misunderstand the second parameter?
This is what the documentation says:
* ip_address* - new SDP IP address.
Unfortunately, I couldn't find any example using this.
Best Regards,
Sebastian