I've seen a lot of discussions about running rtpproxy behind NAT. The fact is that standard vanilla rtpproxy can run behind NAT without any issues (no patches required). A few things must be addressed: - the proper ports must be forwarded from the public IP to the private IP; - when calling rtpproxy_offer/answer, the second parameter must be properly populated with the external public IP for streams from public network.
I hope this brings some light over this highly debated topic.
Regards, Ovidiu Sas
-- VoIP Embedded, Inc. http://www.voipembedded.com
Hello,
On 7/7/13 5:42 AM, Ovidiu Sas wrote:
I've seen a lot of discussions about running rtpproxy behind NAT. The fact is that standard vanilla rtpproxy can run behind NAT without any issues (no patches required). A few things must be addressed:
- the proper ports must be forwarded from the public IP to the private IP;
- when calling rtpproxy_offer/answer, the second parameter must be
properly populated with the external public IP for streams from public network.
I hope this brings some light over this highly debated topic.
the stock one works fine in the simple scenario of one rtpproxy. But not when needing to bridge between two interfaces as well as when working with a farm of (load balanced) rtpproxies.
Cheers, Daniel