[OpenSIPS-Users] fix_nated_sdp and rtpproxy
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Nov 21 04:34:09 EST 2017
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 <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/20171121/5da808d5/attachment-0001.html>
More information about the Users
mailing list