<div>The expectation that the RTP will come from the same place as the signalling does exist in some sclerotic telco interconnects, since big brand SBCs would ordinarily meet this need and big brand SBCs are the only thing sclerotic telcos understand.<br/>
<br/>
But I agree that it's an exotic and uncommon requirement, certainly not applicable to anything like end-user UAs or ordinary business SIP devices. <br/>
<br/>
--<br/>
Sent from mobile. Apologies for brevity and errors.<br/><br/>-----Original Message-----<br/>From: Daniel Tryba <d.tryba@pocos.nl><br/>To: "Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org><br/>Sent: Thu, 23 Aug 2018 4:35 AM<br/>Subject: Re: [SR-Users] Struggling with RTPProxy and RTPEngine<br/><br/></div>On Wed, Aug 22, 2018 at 05:05:02PM +0000, Wilkins, Steve wrote: <br/>
> The SIP traffic is working this way for me but I still see RTP traffic going directly from Asterisk to the UAC, which means they need to whitelist asterisk IP.  Am I missing something? <br/>
<br/>
In what sense do they need whitelisting? In a common NATed solution <br/>
where is no white/blacklist needed. UA gets RTP endpoints from SDP, <br/>
starts sending packets to ip/port and the destination will send back <br/>
packets to the source ip/port, the router/firewall will just send this <br/>
to the actual UA. I have yet to find an UA that cares about where the <br/>
RTP stream is coming from with regards to the SIP traffic. <br/>
<br/>