[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