<html><head></head><body><div style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div>Response from the carrier matches your description. Looks like their Inbound carrier is latching but the outbound carrier is not and yes they recommended handling the NAT on my end.</div><div><br></div><div>That said, whats my options here. Is the native rtpproxy scalable? or is it better to go with a Freeswitch farm to handle media proxying. We are looking @ holding in upwards of 10K UAs on one instance of Kamailio. So whats the best architecture or that ?</div><div><br></div><div>H </div><div><br></div>
<div id="yahoo_quoted_6637399138" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Wednesday, May 9, 2018, 5:53:55 PM EDT, Alex Balashov <abalashov@evaristesys.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div>Re-read the piece of the article related to "RTP latching":<br clear="none"><br clear="none"><a shape="rect" href="http://blog.csrpswitch.com/server-side-nat-traversal-with-kamailio-the-definitive-guide/" target="_blank">http://blog.csrpswitch.com/server-side-nat-traversal-with-kamailio-the-definitive-guide/</a><br clear="none"><br clear="none">In order for RTP to reach a NAT'd endpoint, all other things being<br clear="none">equal, the other party has to do RTP latching. This is true of both<br clear="none">inbound and outbound calls. Failure to do it will result in one-way<br clear="none">audio where the NAT'd party can transmit but cannot receive. <br clear="none"><br clear="none">As far as identifying who is doing that latching, that's not clear from<br clear="none">your description. Some carrier media gateways do it, in which case you<br clear="none">can get away with not having an RTP relay in the middle. Most carrier<br clear="none">media gateways are designed for wholesale-ish peering and don't, as a<br clear="none">matter of policy, but some do. Or you could have some near-end solutions<br clear="none">at work of which you're not aware. <br clear="none"><br clear="none">It's also not clear whether you've definitively removed all rtpproxy<br clear="none">invocation from your Kamailio config, in both directions. But if you<br clear="none">haven't, I'd start there, and given your statement that you don't really<br clear="none">want to be in series to the RTP path, figure out what exactly doesn't<br clear="none">work. Then add rtpproxy as necessary. Beware the distinction between<br clear="none">inbound and outbound call flows.<br clear="none"><br clear="none">-- Alex<br clear="none"><div class="yqt6065865606" id="yqtfd76223"><br clear="none">On Wed, May 09, 2018 at 09:15:48PM +0000, KamDev Essa wrote:<br clear="none"><br clear="none">> Well then why does Inbound (from carrier to NATed UA) call work. Kam is doing something clever there. Why not when sending the call out. <br clear="none">> KD <br clear="none">> On Wednesday, May 9, 2018, 4:34:55 PM EDT, Alex Balashov <<a shape="rect" ymailto="mailto:abalashov@evaristesys.com" href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote: <br clear="none">> <br clear="none">> Oh, the UAs are NAT'd? Yeah, you're going to need something clever in the middle that can do the RTP latching, then. <br clear="none">> <br clear="none">> -- Alex<br clear="none">> <br clear="none">> --<br clear="none">> Sent via mobile, please forgive typos and brevity. </div><br clear="none"><br clear="none">-- <br clear="none">Alex Balashov | Principal | Evariste Systems LLC<br clear="none"><br clear="none">Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br clear="none">Web: <a shape="rect" href="http://www.evaristesys.com/, " target="_blank">http://www.evaristesys.com/, </a><a shape="rect" href="http://www.csrpswitch.com/" target="_blank">http://www.csrpswitch.com/</a><div class="yqt6065865606" id="yqtfd41471"><br clear="none"></div></div>
</div>
</div></div></body></html>