<div dir="ltr">Hello,<div><br></div><div>I have Mediaproxy 2.6.1 and OpenSIPS 1.10 on Debian wheezy with a bit of an unusual configuration.</div><div><br></div><div>The box has a LAN-facing interface (&#39;lan&#39;) and a WAN-facing interface (&#39;wan&#39;).  The lan has a private IP and the wan has a public IP.  Each interface has a separate OpenSIPS instance bound to it for communication with SIP entities on its respective network.  The two OpenSIPS instances exchange SIP traffic with each other across localhost.</div><div><br></div><div>I had rtpproxy bridging media across the interfaces but it has a problem I can&#39;t work around at the moment.  So, I&#39;m attempting to creatively configure an RTP bridge with Mediaproxy.  I&#39;ve done this by running a separate relay/dispatcher pair on each OpenSIPS instance.  Each pair has its own config with the correct lan or wan IP address.  Since two interfaces on a single linux system can send traffic directly to each other without concern for subnets and traditional routing rules, I figure if I can get each relay to send traffic to the other one and then out thenI&#39;ve created a bridge.</div><div><br></div><div>The cool thing is it (almost) works.  On the relays I&#39;ve configured different port ranges to make it more obvious which relay I&#39;m observing, with 16384:24572 on the wan instance and 24576:32768 on the lan instance.  All the SDPs look good through the system with proper port selection.  The relay debugs and dispatcher stats agree with the SDPs.  RTP flows look just about right, with the exception that traffic leaving the relay always has source port 1024.  </div><div><br></div><div>Any thoughts on what might cause a relay&#39;s traffic always to source from 1024 rather than the port it has chosen?  This is the case for both the lan and wan relays sending traffic to its respective host on its own network.</div><div><br></div><div><br></div><div><br></div><div>Regards,</div><div>Jeff</div><div><br></div></div>