<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Hi Yuri,<br>
<br>
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.<br>
<br>
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/21/2017 02:15 PM, Yury Kirsanov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAD1_sevZkdW5W3WW5Ae_mfTOaBEACHmUr6evQWk1bPC2ROHW0A@mail.gmail.com">
<div dir="ltr">Hi Bogdan,
<div>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!</div>
<div><br>
</div>
<div>Best regards,</div>
<div>Yury.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2017-11-21 20:34 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>
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 -> <a href="http://3.3.3.4/5"
target="_blank" moz-do-not-send="true">3.3.3.4/5</a>
. 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><span class="">
<pre class="m_-113732287570044015moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_-113732287570044015moz-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_-113732287570044015moz-cite-prefix">On
11/16/2017 10:25 PM, Yury Kirsanov wrote:<br>
</div>
<blockquote type="cite">
<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>
<pre class="m_-113732287570044015m_6804738889772527769moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_-113732287570044015m_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="m_-113732287570044015h5">
<div
class="m_-113732287570044015m_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_-113732287570044015m_6804738889772527769m_-8757144276291194569moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_-113732287570044015m_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_-113732287570044015m_6804738889772527769h5">
<div
class="m_-113732287570044015m_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_-113732287570044015m_6804738889772527769m_-8757144276291194569m_2204025998222299265moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="m_-113732287570044015m_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_-113732287570044015m_6804738889772527769m_-8757144276291194569h5">
<div
class="m_-113732287570044015m_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_-113732287570044015m_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_-113732287570044015m_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_-113732287570044015m_6804738889772527769m_-8757144276291194569m_2204025998222299265mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Users mailing list
<a class="m_-113732287570044015m_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_-113732287570044015m_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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>