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