That depends. Start with a more basic question: why do you need RTP relay in the middle at all? On May 9, 2018 1:54:55 PM EDT, KamDev Essa <kamdevessa(a)yahoo.com> wrote: -- Alex -- Sent via mobile, please forgive typos and brevity.

Correct. So remove all semblance of any RTP proxy and the resulting behaviour will be exactly what you expect. On May 9, 2018 2:13:22 PM EDT, KamDev Essa <kamdevessa(a)yahoo.com> wrote: -- Alex -- Sent via mobile, please forgive typos and brevity.

You'll want to not load the rtpproxy module, and lose any rtpproxy_*() calls in the actual script. On May 9, 2018 3:26:43 PM EDT, KamDev Essa <kamdevessa(a)yahoo.com> wrote: -- Alex -- Sent via mobile, please forgive typos and brevity.

Oh, the UAs are NAT'd? Yeah, you're going to need something clever in the middle that can do the RTP latching, then. -- Alex -- Sent via mobile, please forgive typos and brevity.

Re-read the piece of the article related to "RTP latching": http://blog.csrpswitch.com/server-side-nat-traversal-with-kamailio-the-defi… In order for RTP to reach a NAT'd endpoint, all other things being equal, the other party has to do RTP latching. This is true of both inbound and outbound calls. Failure to do it will result in one-way audio where the NAT'd party can transmit but cannot receive. As far as identifying who is doing that latching, that's not clear from your description. Some carrier media gateways do it, in which case you can get away with not having an RTP relay in the middle. Most carrier media gateways are designed for wholesale-ish peering and don't, as a matter of policy, but some do. Or you could have some near-end solutions at work of which you're not aware. It's also not clear whether you've definitively removed all rtpproxy invocation from your Kamailio config, in both directions. But if you haven't, I'd start there, and given your statement that you don't really want to be in series to the RTP path, figure out what exactly doesn't work. Then add rtpproxy as necessary. Beware the distinction between inbound and outbound call flows. -- Alex On Wed, May 09, 2018 at 09:15:48PM +0000, KamDev Essa wrote: -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

Update : I piggy backed Freeswitch to Kamailio and have resolved the issue. No media touching us now. Pros and Cons for doing that I know. But we have it working. Thanks for the dialog.  KD On Wednesday, May 9, 2018, 8:57:49 PM EDT, KamDev Essa <kamdevessa(a)yahoo.com> wrote: 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. 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 ? H  On Wednesday, May 9, 2018, 5:53:55 PM EDT, Alex Balashov <abalashov(a)evaristesys.com> wrote: Re-read the piece of the article related to "RTP latching": http://blog.csrpswitch.com/server-side-nat-traversal-with-kamailio-the-defi… In order for RTP to reach a NAT'd endpoint, all other things being equal, the other party has to do RTP latching. This is true of both inbound and outbound calls. Failure to do it will result in one-way audio where the NAT'd party can transmit but cannot receive. As far as identifying who is doing that latching, that's not clear from your description. Some carrier media gateways do it, in which case you can get away with not having an RTP relay in the middle. Most carrier media gateways are designed for wholesale-ish peering and don't, as a matter of policy, but some do. Or you could have some near-end solutions at work of which you're not aware. It's also not clear whether you've definitively removed all rtpproxy invocation from your Kamailio config, in both directions. But if you haven't, I'd start there, and given your statement that you don't really want to be in series to the RTP path, figure out what exactly doesn't work. Then add rtpproxy as necessary. Beware the distinction between inbound and outbound call flows. -- Alex On Wed, May 09, 2018 at 09:15:48PM +0000, KamDev Essa wrote: -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/