Hi,
I am trying to have RTPproxy works with Kamailio behind a NAT. As it seems RTPproxy cannot handle NAT natively, I installed RTPproxy 1.2.1 by miconda: https://github.com/miconda/rtpproxy
Now I am able to make calls, but neither the video nor the audio are present. Wireshark showed that the RTP packets were sent to wrong IPs (private IPs). And this was because of the SDP which contained the wrong IP (fields o= and c=). Then I tried to play with rtpproxy_manage(), and Kamailio replaced the IP in o= and c= by its advertising IP (i.e. its public IP), so the packets from the client behind the NAT were sent to the public address of Kamailio (and then dropped).
My question here is what should be the addresses in the SDP when redirected from Kamailio to the client ?
Here is the topology when receiving an ACK with SDP: Client <--(2)-- Kamailio <--(1)-- Router (NAT) <--(1)-- Public Internet <--(1)-- Third party router (21.24.12.24)
(1): SDP o= 21.24.12.24, c= 21.24.12.24 (2): SDP o= ??, c= ?? (Should it be Kamailio public IP (actually Router IP), or Kamailio private IP, or third party SIP server public IP ?)
Cheer,
On 08/18/2015 08:36 AM, Jean-Marie Baran wrote:
Hi,
I am trying to have RTPproxy works with Kamailio behind a NAT. As it seems RTPproxy cannot handle NAT natively, I installed RTPproxy 1.2.1 by miconda: https://github.com/miconda/rtpproxy
This one is good or the new 2.0 version also supports the -A flag. You may want to run in debug or info mode to see if you're passing packets.
Something like:
rtpproxy -A PUBLICIP -F -l PRIVATEIP -m 10000 -M 20000 -s udp:127.0.0.1:7722 -d INFO
Making sure that the m (minimum) and M (maximum) ports match what you have opened/forwarded on your firewall.
My question here is what should be the addresses in the SDP when redirected from Kamailio to the client ?
Cheer,
*Jean-Marie Baran*
The address should be your public ip (for outside connections), which should also be in the advertised statement within kamailio.
--fred
On 18/08/2015 14:43, Fred Posner wrote:
On 08/18/2015 08:36 AM, Jean-Marie Baran wrote:
Hi,
I am trying to have RTPproxy works with Kamailio behind a NAT. As it seems RTPproxy cannot handle NAT natively, I installed RTPproxy 1.2.1 by miconda: https://github.com/miconda/rtpproxy
This one is good or the new 2.0 version also supports the -A flag. You may want to run in debug or info mode to see if you're passing packets.
Ok, that's good to know that version 2 also handle it. I did not pay attention.
Something like:
rtpproxy -A PUBLICIP -F -l PRIVATEIP -m 10000 -M 20000 -s udp:127.0.0.1:7722 -d INFO
Making sure that the m (minimum) and M (maximum) ports match what you have opened/forwarded on your firewall.
My question here is what should be the addresses in the SDP when redirected from Kamailio to the client ?
Cheer,
*Jean-Marie Baran*
The address should be your public ip (for outside connections), which should also be in the advertised statement within kamailio.
Okay, so now Kamailio receives an ACK with SDP, and replace the c=/o= fields with its public IP. Then it transmits the ACK to the client which in turn send its RTP packets to the public IP of Kamailio (that is, the router in front of Kamailio). However there is no trace of the RTP packets on the machine running Kamailio.
Because I like graphics:
Client Kamailio Router Third party SIP Server | | | | | | |<------ACK (SDP)------| | |<---ACK (SDP)---| | |<---ACK (SDP)---| | | | | | | |-------RTP---------------------->|? | | | | |
{________Private network________} {______Internet______}
The question mark denotes the fact that I lose trace of RTP packets here. Any idea why the packets are not relayed ?
--fred
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 18/08/2015 15:19, Fred Posner wrote:
On 08/18/2015 09:06 AM, Jean-Marie Baran wrote:
The question mark denotes the fact that I lose trace of RTP packets here. Any idea why the packets are not relayed ?
What ports do you have opened and forwarded on your firewall/router?
I forwarded the ports 29980 to 30000. The third party SIP server knows that, and my client is configured to use only ports in this range as well.
Should I understand that the router should send the packet back to Kamailio which then send them to the SIP server ? If it's the case I should investigate on the router side.
On a side note, as for Wireshark, RTPproxy does not see the RTP packets: INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped
Thank you,
On 18/08/2015 15:44, Fred Posner wrote:
On 08/18/2015 09:39 AM, Jean-Marie Baran wrote:
Should I understand that the router should send the packet back to Kamailio which then send them to the SIP server ?
RTP packets will flow from client to client or with rtpproxy, from client <-> rtpproxy <-> client.
Err, I meant RTPproxy, not Kamailio, but yes. In the SDP, is it maybe smarter to put the Kamailio (RTPproxy) private IP address in the c= field, so that the client contact directly RTPproxy without passing through the router first (which does not make much sense to me).
I hate NATs :'(
On 18/08/2015 16:00, Jean-Marie Baran wrote:
On 18/08/2015 15:44, Fred Posner wrote:
On 08/18/2015 09:39 AM, Jean-Marie Baran wrote:
Should I understand that the router should send the packet back to Kamailio which then send them to the SIP server ?
RTP packets will flow from client to client or with rtpproxy, from client <-> rtpproxy <-> client.
Err, I meant RTPproxy, not Kamailio, but yes. In the SDP, is it maybe smarter to put the Kamailio (RTPproxy) private IP address in the c= field, so that the client contact directly RTPproxy without passing through the router first (which does not make much sense to me).
Okay, I did not replaced the public address of RTPproxy (ip_public) in the SDP by its private address (ip_private), but I simply redirected all the traffic that was going from my computer to ip_public, to ip_private. Now RTPproxy actually receives the RTP packets, and relays them to the right IP afterwards ! However there is still no audio/video, but now it's another problem.
Thank you for your help Fred.
-
Fred Posner -
Jean-Marie Baran