<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
<div class="moz-cite-prefix">On 11/4/12 10:52 PM, Moacir Ferreira
wrote:<br>
</div>
<blockquote cite="mid:COL125-W12D0CF6CE05AE827D592DBC8650@phx.gbl"
type="cite">
<div dir="ltr">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr"><font face="Times New Roman" size="3">Daniel,</font><br>
<br>
<font face="Times New Roman"><font size="3">I am "reading" a
lot... However, I can’t still get the “logic” to overcome
my problem using
Kamailio routing logic. I was willing to have a dual-homed
Kamailo+RTPproxy on a
single server, where one interface goes to the Internet
and another one goes to
my private network. However, the private network is using
the RFC1918 address
space. Kamailio's NAT detection mechanism forces the
RTPproxy between two UAs if
they are using RFC1918 address space even if the 2 UAs are
at the IP subnet that the Kamailio server is.
So, if I have a “private” network using RFC1918 addresses,
made of several remote sites, all the RTP traffic
would have to go to the Kamailio/RTPproxy, causing a large
and undesirable traffic on
the WAN links. By other hand, should I don’t care about
getting all my RTP LAN/WAN traffic being sent to Kamailio
because I am using RFC1918 address space, I could not find
an "workable example" of configuring a
dual-homed Kamailio+RTPProxy that properly sets the
rtpproxy_manage flags to make it work.<!--?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /--><o:p></o:p></font></font><br>
</div>
</div>
</blockquote>
<br>
RTPProxy is engaged on demand, it does not do rtp relaying just
because it finds a RFC1918 address. It is up to you when you want to
call rtpproxy_manage() function. So if the call comes from and goes
to a rfc1918 address, then don't execute rtpproxy_manage().<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<blockquote cite="mid:COL125-W12D0CF6CE05AE827D592DBC8650@phx.gbl"
type="cite">
<div dir="ltr">
<div dir="ltr"><font face="Times New Roman" size="3">
</font><br>
<font face="Times New Roman" size="3">Looking at your
IPv4/IPv6 example, we can see that it could be possible to
tag a SIP transaction and decide latter if it were to go
from external to internal, internal to internal or external
to external. The example is quite easy to understand because
you can separate IPv6 from IPv4 transactions. However, what
about the private address space?</font><br>
<br>
<p style="margin: 0cm 0cm 10pt;" class="MsoNormal"><font
face="Times New Roman"><font size="3">Any help would be
really appreciated. If you can't help, what forum can I
post my questions and get some answers?</font></font></p>
<font face="Times New Roman" size="3">
</font><br>
<p style="margin: 0cm 0cm 10pt;" class="MsoNormal"><font
face="Times New Roman"><font size="3"><font face="Times
New Roman"><font size="3">Moacir</font></font></font></font></p>
<font face="Times New Roman" size="3">
<br>
</font> <br>
<div>> Date: Mon, 15 Oct 2012 09:10:30 +0200<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:miconda@gmail.com">miconda@gmail.com</a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
> CC: <a class="moz-txt-link-abbreviated" href="mailto:moacirferreira@hotmail.com">moacirferreira@hotmail.com</a><br>
> Subject: Re: [SR-Users] Another NAT question<br>
> <br>
> Hello,<br>
> <br>
> you can detect that the call is coming from
public/external interface <br>
> and goes to private/internal interface.<br>
> <br>
> There are couple of ways to do it, one is to set a
branch flag when they <br>
> register, saying it is from external or internal. Then
based on src ip <br>
> ($si) or rcv io ($Ri) of the invite and the branch flag
from location, <br>
> you decide to enforce the rtpproxy or not.<br>
> <br>
> Alternative is to look at the forced socket or
destination ip after <br>
> lookup location and get the info from there about the
message flow.<br>
> <br>
> Cheers,<br>
> Daniel<br>
> <br>
> On 10/13/12 11:43 PM, Moacir Ferreira wrote:<br>
> > Hi,<br>
> > <br>
> > I have a scenario where I got a firewall with 3
interfaces: internal, DMZ and external. All the traffic from
internal going to external is NATed. However, the traffic
between internal and DMZ is NOT NATed. The external and DMZ
are using public IP addresses. On the DMZ I have a Kamailio
server running with RTPProxy + NAT Helper.<br>
> > <br>
> > Everything works fine when public (from the
internet) users (UAs) are behind NAT as Kamailio will force
the RTP to go via RTPProxy. However, when the public user
has a public IP, it will fail to establish the RTP to a user
who registered on Kamailio coming from the internal firewall
interface.<br>
> > <br>
> > The reason is that, as I don't do NAT between
internal and DMZ firewall interfaces, Kamailio will not
RTPRroxy in between the UAs because, from the way Kamailio
detects NAT, they are not behind NAT. So the public user UA
tries to reach a private IP address. If the "inside" user
tries to call a public user (a user on the Internet with a
public IP), it works.<br>
> ><br>
> > Yes, I could do NAT in between the internal and
DMZ firewall interfaces. However, this would force all RTP
traffic of my UAs at the LAN go to Kamailio RTPProxy, an bad
effect that I would like to avoid.<br>
> ><br>
> > So my question is: what would be the best approach
to solve this issue using Kamailio and RTPProxy in such
scenario?<br>
> ><br>
> > Cheers!<br>
> > Moacir <br>
> > _______________________________________________<br>
> > SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
> > <a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
> >
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
> <br>
> -- <br>
> Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a><br>
> <a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> -
<a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a><br>
> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -
<a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a><br>
> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012
- <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a><br>
> <br>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kat">http://asipto.com/u/kat</a>
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a></pre>
</body>
</html>