<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Hi Yury,<br>
<br>
OK, so SIP goes like 192.168.1.1 / 1.1.1.1 -> 2.2.2.2 ->
3.3.3.3 , while RTP </tt><tt><tt>192.168.1.1 / 1.1.1.1 ->
3.3.3.4/5 . or ? what is the full path for SIP and RTP ?<br>
<br>
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) <br>
<br>
</tt>Regards,<br>
</tt>
<pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a>
</pre>
<div class="moz-cite-prefix">On 11/16/2017 10:25 PM, Yury Kirsanov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD1_sev8v2RpDsZAQDXzdxEcfK6Fu1W-9HNs9GHk6BmnZETpsA@mail.gmail.com">
<div dir="ltr">Bogdan,
<div>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:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks and best regards,</div>
<div>Yury.</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-11-17 3:26 GMT+11:00 Bogdan-Andrei
Iancu <span dir="ltr"><<a
href="mailto:bogdan@opensips.org" target="_blank"
moz-do-not-send="true">bogdan@opensips.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <tt>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.<br>
<br>
Regards,<br>
</tt><span class="">
<pre class="m_6804738889772527769moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_6804738889772527769moz-txt-link-freetext" href="http://www.opensips-solutions.com" target="_blank" moz-do-not-send="true">http://www.opensips-solutions.<wbr>com</a>
</pre>
</span>
<div>
<div class="h5">
<div class="m_6804738889772527769moz-cite-prefix">On
11/16/2017 03:07 PM, Yury Kirsanov wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Bogdan,
<div>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.</div>
<div> </div>
<div>Regards,</div>
<div>Yury.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-11-17 0:01 GMT+11:00
Bogdan-Andrei Iancu <span dir="ltr"><<a
href="mailto:bogdan@opensips.org"
target="_blank" moz-do-not-send="true">bogdan@opensips.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <tt>Hi
Yury,<br>
<br>
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.<br>
<br>
Just be sure you do not use the "a" and
"r" flags when calling rtpproxy engage.<br>
<br>
Regards,<br>
</tt><span>
<pre class="m_6804738889772527769m_-8757144276291194569moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_6804738889772527769m_-8757144276291194569moz-txt-link-freetext" href="http://www.opensips-solutions.com" target="_blank" moz-do-not-send="true">http://www.opensips-solutions.<wbr>com</a>
</pre>
</span>
<div>
<div class="m_6804738889772527769h5">
<div
class="m_6804738889772527769m_-8757144276291194569moz-cite-prefix">On
11/16/2017 02:48 PM, Yury Kirsanov
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Bogdan,
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Yury.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-11-16
23:32 GMT+11:00 Bogdan-Andrei
Iancu <span dir="ltr"><<a
href="mailto:bogdan@opensips.org"
target="_blank"
moz-do-not-send="true">bogdan@opensips.org</a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF"
text="#000000"> <tt>Hi Yury,<br>
<br>
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. <br>
<br>
Regards,<br>
</tt>
<pre class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-txt-link-freetext" href="http://www.opensips-solutions.com" target="_blank" moz-do-not-send="true">http://www.opensips-solutions.<wbr>com</a>
</pre>
<div>
<div
class="m_6804738889772527769m_-8757144276291194569h5">
<div
class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-cite-prefix">On
11/14/2017 04:05 AM,
Yury Kirsanov wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div
class="m_6804738889772527769m_-8757144276291194569h5">
<div dir="ltr">Hi,
<div>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:</div>
<div><br>
</div>
<div><Client>
----- <NAT
router> -------
<RTP Proxy>
----------
<OpenSIPS>
-------- <NAT>
-----------
<PBX></div>
<div><br>
</div>
<div>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:<br>
<br>
</div>
<div>
<div
class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265gmail-WordSection1">
<p
class="MsoNormal"
style="margin-bottom:0.0001pt;line-height:normal"><span>100.11.100.200192.168.20.200</span></p>
<p
class="MsoNormal"
style="margin-bottom:0.0001pt;line-height:normal"><span><br>
</span></p>
<p
class="MsoNormal"
style="margin-bottom:0.0001pt;line-height:normal"><span>Is there any way
to update SDP
of client's
packet and
then command
RTP Proxy to
use updated
IP? Thanks!</span></p>
</div>
</div>
</div>
<br>
<fieldset
class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Users mailing list
<a class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org" target="_blank" moz-do-not-send="true">Users@lists.opensips.org</a>
<a class="m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank" moz-do-not-send="true">http://lists.opensips.org/cgi-<wbr>bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>