<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.800000190734863px;background-color:rgb(255,255,255)">configuring endpoints to use a particular port for RTP and<br>
</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.800000190734863px;background-color:rgb(255,255,255)">then forwarding a range of ports for each endpoint</span></blockquote><div><br></div>
<div>
Guessing this is how you're working around the fact the external RTP port won't be the same as the internal one through most NAT implementations.</div><div><br></div>Seems an awful lot of work to go to when it'd be easier to configure a client correctly (assuming they support NAT correctly). A lot of work for you to setup and maintain, and that won't scale well.<div>
<br></div>If the clients can't support NAT correctly you could try using the SIP ALG on the NAT router (if available) which should rewrite the RTP IP/port automatically. Usually the advice is to disable that and let FS & the client handle the NAT (because generally it just causes more problems if you're handling the NAT twice). But in the bypass_media case it might help. Does mean you can't use TLS though (since the router can't see inside the encrypted packets), and it'll probably only spot SIP on port 5060.<div>
<br></div><div>-Steve</div><div><br></div><div><br></div><div><br></div><div> </div><br><div class="gmail_quote">On 21 November 2012 20:11, PhilQ <span dir="ltr"><<a href="mailto:philq@qsystemsengineering.com" target="_blank">philq@qsystemsengineering.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":y9">configuring endpoints to use a particular port for RTP and<br>
then forwarding a range of ports for each endpoint</div></blockquote></div><br>