[SR-Users] How to use the ip parameter in rtpproxy_manage()

[Sebastian Damm]

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 at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140829/aa951174/attachment.html>