fix_nated_sdp and rtpproxy

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

fix_nated_sdp and rtpproxy

Lt_Flash
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu-2
Hi Yury,

Why do you need to update the incoming SDP before engaging RTPproxy ? Just pass to it whatever you get into SDP (even if private) and let rtpproxy to "learn" the correct IP:port of the media end points based on the incoming traffic.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/14/2017 04:05 AM, Yury Kirsanov wrote:
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu-2
Hi Yury,

RTPproxy learns not only from SDP, but based on the incoming RTP traffic. Your Client will send RTP to RTPproxy (as the Client will receive back a valid IP in the SDP) and RTPproxy will see where the RTP traffic comes from and starts sending back RTP to that IP:port.

Just be sure you do not use the "a" and "r" flags when calling rtpproxy engage.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 02:48 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for your answer and support! But the issue is that there is a private IP address in SDP coming from the client so if I just pass it via RTP proxy - it would learn that incorrect IP and would try to forward packets to it causing one-way audio. That's why I first wanted to overstamp that incorrect IP with received IP and then pass it to the RTP Proxy. Hope this makes my idea clear.

Regards,
Yury.

2017-11-16 23:32 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

Why do you need to update the incoming SDP before engaging RTPproxy ? Just pass to it whatever you get into SDP (even if private) and let rtpproxy to "learn" the correct IP:port of the media end points based on the incoming traffic.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/14/2017 04:05 AM, Yury Kirsanov wrote:
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu-2
Using the "i" and "e" flags to control the RTP interfaces does not affect the "learning" mode. You should you "r" flag only if the received IP in SDP is public. Otherwise do not use it.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 03:07 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for clarification, I didn't know that RTP Proxy learns from source packets, it's quite hard to find documentation on it. The problem here is that I'm using RTP Proxy in bridge mode, connecting public interface with internal LAN and my upstream providers are using sets of their own proxies too, besides customers connecting to this OpenSIPS server. So I have to use flag "r" (and, of course, flags of direction - "i" and "e") or else there would be no audio on calls when SDP in provider's answer is different from SIP packet source IP. Of course, I can analyze where the initial INVITE packet is coming from and enable different options but that would be more complex rather than just have SDP modified before passing it to RTP Proxy.
 
Regards,
Yury.

2017-11-17 0:01 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

RTPproxy learns not only from SDP, but based on the incoming RTP traffic. Your Client will send RTP to RTPproxy (as the Client will receive back a valid IP in the SDP) and RTPproxy will see where the RTP traffic comes from and starts sending back RTP to that IP:port.

Just be sure you do not use the "a" and "r" flags when calling rtpproxy engage.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 02:48 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for your answer and support! But the issue is that there is a private IP address in SDP coming from the client so if I just pass it via RTP proxy - it would learn that incorrect IP and would try to forward packets to it causing one-way audio. That's why I first wanted to overstamp that incorrect IP with received IP and then pass it to the RTP Proxy. Hope this makes my idea clear.

Regards,
Yury.

2017-11-16 23:32 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

Why do you need to update the incoming SDP before engaging RTPproxy ? Just pass to it whatever you get into SDP (even if private) and let rtpproxy to "learn" the correct IP:port of the media end points based on the incoming traffic.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/14/2017 04:05 AM, Yury Kirsanov wrote:
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users






_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu-2
Hi Yury,

OK, so SIP goes like 192.168.1.1 / 1.1.1.1 -> 2.2.2.2 -> 3.3.3.3 , while RTP
192.168.1.1 / 1.1.1.1 -> 3.3.3.4/5 . or ? what is the full path for SIP and RTP ?

Without the "r" flag, rtpproxy will stay and listen for incoming traffic in order to learn the end points, it will not use the SIP signaling IP for anything (rtpproxy makes no assumptions based on the SIP ips)

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 10:25 PM, Yury Kirsanov wrote:
Bogdan,
But in SIP packets from upstream carriers there's a public IP address in SDP header, pointing to different IP than SIP packet is coming from. Both of these IP addresses are public. But customers who connect via public Internet to OpenSIPS server sitting on public interface are actually behind NAT and that's why packets from them contain private IP address in SDP header. Example, to clarify things up:

Client has a PBX behind a router that's doing NAT. Internal IP of PBX is 192.168.1.1, public IP of client is 1.1.1.1, router is doing just NAT without SIP ALG. Customer connects over the Internet to OpenSIPS at 2.2.2.2, so packets are reaching OpenSIPS. But in SDP of customer's SIP packets there's c=192.168.1.1 and all the rest of descriptors are with the same IP.

Now, provider is at IP of 3.3.3.3 having RTP proxies at 3.3.3.4 and 3.3.3.5. So, packets from provider are reaching OpenSIPS at 2.2.2.2 via the Internet and contain different IP address in SDP from SIP packet (3.3.3.4 or 3.3.3.5 in SDP, SIP has 3.3.3.3)

RTP Proxy at my side is operating in bridge mode, one side is connected to public interface with IP of 4.4.4.4 and 4.4.4.5 (two proxies), and another side is connected to DMZ internal LAN, IPs 10.0.0.4 and 10.0.0.5.

So, in order to use fix_nated_sdp() AND engage RTP proxy when the call is coming from customer - I should NOT use flag "r". But if the call is coming from provider - I must be using that flag or otherwise RTP Proxy would be expecting packets to be coming from 3.3.3.3 rather than 3.3.3.4 or 3.3.3.5. That's why my idea was first to update customer's part of SDP from 192.168.1.1 to 1.1.1.1 (where packets from customer are coming from) and then pass this modified SIP packet with new SDP to RTP proxy, so it would have flag "r" enabled and start sending packets to IP of 1.1.1.1 straight away.

Thanks and best regards,
Yury.


2017-11-17 3:26 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Using the "i" and "e" flags to control the RTP interfaces does not affect the "learning" mode. You should you "r" flag only if the received IP in SDP is public. Otherwise do not use it.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 03:07 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for clarification, I didn't know that RTP Proxy learns from source packets, it's quite hard to find documentation on it. The problem here is that I'm using RTP Proxy in bridge mode, connecting public interface with internal LAN and my upstream providers are using sets of their own proxies too, besides customers connecting to this OpenSIPS server. So I have to use flag "r" (and, of course, flags of direction - "i" and "e") or else there would be no audio on calls when SDP in provider's answer is different from SIP packet source IP. Of course, I can analyze where the initial INVITE packet is coming from and enable different options but that would be more complex rather than just have SDP modified before passing it to RTP Proxy.
 
Regards,
Yury.

2017-11-17 0:01 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

RTPproxy learns not only from SDP, but based on the incoming RTP traffic. Your Client will send RTP to RTPproxy (as the Client will receive back a valid IP in the SDP) and RTPproxy will see where the RTP traffic comes from and starts sending back RTP to that IP:port.

Just be sure you do not use the "a" and "r" flags when calling rtpproxy engage.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 02:48 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for your answer and support! But the issue is that there is a private IP address in SDP coming from the client so if I just pass it via RTP proxy - it would learn that incorrect IP and would try to forward packets to it causing one-way audio. That's why I first wanted to overstamp that incorrect IP with received IP and then pass it to the RTP Proxy. Hope this makes my idea clear.

Regards,
Yury.

2017-11-16 23:32 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

Why do you need to update the incoming SDP before engaging RTPproxy ? Just pass to it whatever you get into SDP (even if private) and let rtpproxy to "learn" the correct IP:port of the media end points based on the incoming traffic.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/14/2017 04:05 AM, Yury Kirsanov wrote:
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users








_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu-2
Hi Yuri,

No, in the answer() you need to use a separate set of flags, reflecting your intentions in regards to the SDP you received from the callee side.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/21/2017 02:15 PM, Yury Kirsanov wrote:
Hi Bogdan,
Yes, you're correct, I should try to analyze if initial INVITE packet coming from outside (Internet) contains a private IP in SDP and in that case just not use "r" flag in rtpproxy_offer(). Thanks a lot for clarifying this! Just one more question - do I need to specify same flags in rtpproxy_answer() or is it sufficient just to call it without parameters? Thanks!

Best regards,
Yury.

2017-11-21 20:34 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

OK, so SIP goes like 192.168.1.1 / 1.1.1.1 -> 2.2.2.2 -> 3.3.3.3 , while RTP
192.168.1.1 / 1.1.1.1 -> 3.3.3.4/5 . or ? what is the full path for SIP and RTP ?

Without the "r" flag, rtpproxy will stay and listen for incoming traffic in order to learn the end points, it will not use the SIP signaling IP for anything (rtpproxy makes no assumptions based on the SIP ips)

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 10:25 PM, Yury Kirsanov wrote:
Bogdan,
But in SIP packets from upstream carriers there's a public IP address in SDP header, pointing to different IP than SIP packet is coming from. Both of these IP addresses are public. But customers who connect via public Internet to OpenSIPS server sitting on public interface are actually behind NAT and that's why packets from them contain private IP address in SDP header. Example, to clarify things up:

Client has a PBX behind a router that's doing NAT. Internal IP of PBX is 192.168.1.1, public IP of client is 1.1.1.1, router is doing just NAT without SIP ALG. Customer connects over the Internet to OpenSIPS at 2.2.2.2, so packets are reaching OpenSIPS. But in SDP of customer's SIP packets there's c=192.168.1.1 and all the rest of descriptors are with the same IP.

Now, provider is at IP of 3.3.3.3 having RTP proxies at 3.3.3.4 and 3.3.3.5. So, packets from provider are reaching OpenSIPS at 2.2.2.2 via the Internet and contain different IP address in SDP from SIP packet (3.3.3.4 or 3.3.3.5 in SDP, SIP has 3.3.3.3)

RTP Proxy at my side is operating in bridge mode, one side is connected to public interface with IP of 4.4.4.4 and 4.4.4.5 (two proxies), and another side is connected to DMZ internal LAN, IPs 10.0.0.4 and 10.0.0.5.

So, in order to use fix_nated_sdp() AND engage RTP proxy when the call is coming from customer - I should NOT use flag "r". But if the call is coming from provider - I must be using that flag or otherwise RTP Proxy would be expecting packets to be coming from 3.3.3.3 rather than 3.3.3.4 or 3.3.3.5. That's why my idea was first to update customer's part of SDP from 192.168.1.1 to 1.1.1.1 (where packets from customer are coming from) and then pass this modified SIP packet with new SDP to RTP proxy, so it would have flag "r" enabled and start sending packets to IP of 1.1.1.1 straight away.

Thanks and best regards,
Yury.


2017-11-17 3:26 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Using the "i" and "e" flags to control the RTP interfaces does not affect the "learning" mode. You should you "r" flag only if the received IP in SDP is public. Otherwise do not use it.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 03:07 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for clarification, I didn't know that RTP Proxy learns from source packets, it's quite hard to find documentation on it. The problem here is that I'm using RTP Proxy in bridge mode, connecting public interface with internal LAN and my upstream providers are using sets of their own proxies too, besides customers connecting to this OpenSIPS server. So I have to use flag "r" (and, of course, flags of direction - "i" and "e") or else there would be no audio on calls when SDP in provider's answer is different from SIP packet source IP. Of course, I can analyze where the initial INVITE packet is coming from and enable different options but that would be more complex rather than just have SDP modified before passing it to RTP Proxy.
 
Regards,
Yury.

2017-11-17 0:01 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

RTPproxy learns not only from SDP, but based on the incoming RTP traffic. Your Client will send RTP to RTPproxy (as the Client will receive back a valid IP in the SDP) and RTPproxy will see where the RTP traffic comes from and starts sending back RTP to that IP:port.

Just be sure you do not use the "a" and "r" flags when calling rtpproxy engage.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/16/2017 02:48 PM, Yury Kirsanov wrote:
Hi Bogdan,
Thanks for your answer and support! But the issue is that there is a private IP address in SDP coming from the client so if I just pass it via RTP proxy - it would learn that incorrect IP and would try to forward packets to it causing one-way audio. That's why I first wanted to overstamp that incorrect IP with received IP and then pass it to the RTP Proxy. Hope this makes my idea clear.

Regards,
Yury.

2017-11-16 23:32 GMT+11:00 Bogdan-Andrei Iancu <[hidden email]>:
Hi Yury,

Why do you need to update the incoming SDP before engaging RTPproxy ? Just pass to it whatever you get into SDP (even if private) and let rtpproxy to "learn" the correct IP:port of the media end points based on the incoming traffic.

Regards,
Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com
On 11/14/2017 04:05 AM, Yury Kirsanov wrote:
Hi,
I have a problem with remote client who can't properly configure NAT and is sending private IP in all SDP and SIP packets. I've resolved issues with registration but can't resolve the issue with SDP. My topology is as following:

<Client> ----- <NAT router> ------- <RTP Proxy> ---------- <OpenSIPS> -------- <NAT> ----------- <PBX>

So, I need to simultaneously engage RTP Proxy to bridge external Internet and our local LAN and need to rewrite SDP body of original Client's packet with received IP address. If I'm doing fix_nated_sdp and then rtpproxy_offer - I'm getting doubled IPs in SDP message, like this:

100.11.100.200192.168.20.200


Is there any way to update SDP of client's packet and then command RTP Proxy to use updated IP? Thanks!



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users










_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users