[OpenSIPS-Users] fix_nated_sdp and rtpproxy

Bogdan-Andrei Iancu bogdan at opensips.org
Thu Nov 23 04:59:43 EST 2017


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 <bogdan at opensips.org 
> <mailto:bogdan at opensips.org>>:
>
>     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 <http://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 <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
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>>:
>>
>>         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
>>         <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
>>>         <bogdan at opensips.org <mailto:bogdan at opensips.org>>:
>>>
>>>             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
>>>             <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
>>>>             <bogdan at opensips.org <mailto:bogdan at opensips.org>>:
>>>>
>>>>                 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
>>>>                 <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
>>>>>                 Users at lists.opensips.org
>>>>>                 <mailto:Users at lists.opensips.org>
>>>>>                 http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>                 <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171123/88110ff7/attachment-0001.html>


More information about the Users mailing list