I have an OpenSIPS server which listens on multiple IPs. If I route the calls back out to the next point, I want to ensure all signalling and media come from the IP the call originally landed on (I don't want the caller and callee to know each other's IP addresses).
I believe what I need for this something like RTPProxy.
My question is do I need one RTPProxy server per IP address, or can I route multiple IPs through a single server? Is there a better solution?
I'm going to try this myself, but I'm struggling to get the RTPProxy server running correctly (my ignorance rather than necessarily any issues with RTPProxy). I asked ahead of time just to see if anyone knew if I was wasting my time setting it up or not.
[UPDATE]
For anyone interested, this is how I got it working, though I'm not sure I want to run with this as the final solution. Needs more testing. For 2 IPs, with topology hiding and RTP proxying. Along with the answer below, I hope it helps someone.
Load the rtpproxy processes -
rtpproxy -l _your_public_ip_1_ -s udp:localhost:7722
rtpproxy -l _your_public_ip_2_ -s udp:localhost:7723
Then mod the kamailio.cfg file -
loadmodule "/usr/local/lib64/kamailio/modules/topoh.so"
modparam("topoh", "mask_key", "Your_key_here")
modparam("topoh", "mask_ip", "10.0.0.1")
The next bit creates two groups for RTP proxy - 1 & 2 -
#!ifdef WITH_NAT
# ----- rtpproxy params -----
modparam("rtpproxy", "rtpproxy_sock", "1 == udp:127.0.0.1:7722")
modparam("rtpproxy", "rtpproxy_sock", "2 == udp:127.0.0.1:7723")
then in the NAT section of the standard (shipped) config, you select which group to use in the proxying based on the IP the inbound call landed on. rtp_proxy_manage is a very high level version of the force_ and unforce_ commands. Basically it just fires up and does everything for you -
route[NATMANAGE] {
#!ifdef WITH_NAT
....
if($Ri=="X.X.X.1")
set_rtp_proxy_set("1");
if($Ri=="X.X.X.2")
set_rtp_proxy_set("2");
rtpproxy_manage("",$Ri);
If you use RTPProxy, you would need one RTPProxy server per IP address. You can specify the IP to listen on with the '-l' parameter:
# /usr/sbin/rtpproxy -l 10.10.10.10 -s unix:/var/run/rtpproxy/rtpproxy1.sock -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy1.pid &
# /usr/sbin/rtpproxy -l 10.10.10.11 -s unix:/var/run/rtpproxy/rtpproxy2.sock -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy2.pid &
You would need to match that up with independant opensips/openser/kamailio instances:
listen=udp:10.10.10.10:5060
...
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy/rtpproxy1.sock")
...
unforce_rtp_proxy();
...
force_rtp_proxy();
and
listen=udp:10.10.10.11:5060
...
loadmodule "rtpproxy.so"
modparam("rtpproxy", "rtpproxy_sock", "unix:/var/run/rtpproxy/rtpproxy2.sock")
...
unforce_rtp_proxy();
...
force_rtp_proxy();
If you have some experience with C, you could conceivably modify the rtpproxy module to be aware of multiple rtpproxy instances.
Also, if the thought of relaying RTP through userspace bothers you, MediaProxy is an alternative.
Rather than a userspace daemon relaying the RTP traffic, your openser/opensips/kamailio tells a python MediaDispatcher through a JSON web post to contact an available MediaRelay to setup a linux kernel level conntrack traffic forwarding entry.
The downside to this approach is that the current python media-dispatcher and media-relay read /etc/mediaproxy/config.ini - you would need to hack the python to take a configuration parameter so you could conceivably have multiple config.ini files, one for each instance to setup the correct redirect.
An example /etc/mediaproxy/config.ini might look like:
[Relay]
dispatchers = 10.10.10.10:25060
[Dispatcher]
socket_path = /var/run/mediaproxy/dispatcher.sock
listen = 10.10.10.10:25060
listen_management = 10.10.10.10:25061
[OpenSIPS]
socket_path = '/var/run/opensips/socket'
And in your opensips config file:
modparam("mi_datagram", "socket_name", "/var/run/opensips/socket")
...
loadmodule "mediaproxy.so"
# ----- mediaproxy params -----
modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy/dispatcher.sock")
#modparam("mediaproxy", "disable", 1)
#modparam("mediaproxy", "natping_interval", 60)
...
engage_media_proxy();
...
end_media_session();
It sounds like you may have better luck with rtpproxy for your particular needs.