<div>Just in case my diagram got bungled:</div>
<div>The use case is: Freeswitch in the public network, with a SIP UA in a private network talking to Freeswitch across a NAT Server. <br></div>
<div>--naren<br></div>
<div class="gmail_quote">On Tue, Jul 26, 2011 at 5:51 AM, Narendra Sirugudi <span dir="ltr"><<a href="mailto:nsirugudi@gmail.com">nsirugudi@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>__________________________</div>
<div>| |</div>
<div>|________ ____|_____ ___________</div>
<div>|| | | | 74.1.1.1 74.1.1.2 | |</div>
<div>|| SIP UA |---------------------| NAT Server|------------------------------------------| Freeswitch |</div>
<div>||________|10.10.10.10 |__________| Public Network |___________|</div>
<div>| | 74.1.1.0</div>
<div>| Private Network 10.10.10.0 |</div>
<div>|__________________________|</div>
<div> </div>
<div>Hi,</div>
<div> </div>
<div>In the above topology, the typical issue one faces is that the SDP(rtp) IP&port in SIP invite sent from the SIP UA to Freeswitch will contain the private Ip address of the SIP UA. </div>
<div> </div>
<div>Assuming source NAT, the typical solution is to use a STUN server in the public network, which will help the SIP UA to discover the public IP&port (for its private IP&port). The UA then sends the Invite with the SDP(RTP) IP&port set to the discovered public IP&port. (I believe Freeswitch does not have a STUN server within itself.)</div>
<div> </div>
<div>But suppose that we do not want to use the STUN solution. Does Freeswitch itself offer any solutions in this case ? </div>
<div> </div>
<div>thanks,</div>
<div>--naren</div>
<div> </div></blockquote></div><br>