[OpenSIPS-Users] NAT & RTPProxy
iiagavin at aim.com
Wed Apr 19 14:01:05 UTC 2023
yes, I do have rtpproxy set up in bridged mode. It is run using the following command (public IPs changed):
rtpproxy -F -s udp:127.0.0.1:7722 -l 192.168.2.251/192.168.2.251 -A 220.127.116.11/18.104.22.168 -m 10000 -M 10100
The client source IP seen by opensips is 22.214.171.124, and the SDP has a connection IP of 192.0.0.2.
In opensips' route configuration, when the incoming request is determined to be an INVITE, I call rtpproxy_offer(). I've tried passing no flags as well as every combination of "i" and "e". In each case the SDP's connection IP that is passed to the internal server is rtpproxy's advertised address (126.96.36.199), as it seems to think that the 192.0.0.2 is an internal address that needs to be converted to the advertised address, even when the "ei" flags are passed in rtpproxy_offer(). I've also tried passing the "s", "c", and "o" flags, with the same fundamental issue each time.
On the SDP answer, I am calling rtpproxy_answer("ie"), and that seems to result in no update to the SDP. The same IP (from the application server) that comes in is the one that is sent back to the client. It should be the public IP address (188.8.131.52).
On Wednesday, April 19, 2023 at 07:06:54 AM ADT, Callum Guy <callum.guy at x-on.co.uk> wrote:
Using an RTP proxy is a good approach, you'll need to set it up in
bridge mode so that it is aware of the internal and external addresses
so that it can present the public IP to the client and private to the
You probably don't need fix_nated_sdp as rtpproxy/rtpengine will do
that for you, you'll just need to tell it which address to use which
differs for each product.
On Wed, 19 Apr 2023 at 06:39, Gavin Murphy via Users
<users at lists.opensips.org> wrote:
> I'm trying to set up an instance of opensips to support a testing SIP phone calling into my simulated network. The client is running from a mobile phone. The connection from the client comes in from the public network, but the client sees its own IP as private (192.0.0.2). My test network is running on virtual machines on my laptop, and is behind a NATed home router, so all of the VMs are in private IP space (192.168.x.x). It looks something like this:
> client -> mobile network (NAT) -> home router (NAT) -> opensips -> application server
> I am having trouble relaying the media from the network to the client. I have made various attempts of using the rtpproxy and the matmodule, but nothing has been successful so far. When using rtpproxy it writes the SDP going back to the client in the 183 with the internal IP. But if I just use fix_nated_sdp() the media doesn't go through the proxy server. If I try to use both (fix_nated_sdp() followed by rtpproxy_answer()), rtpproxy doesn't properly re-write the SDP (it ends up with a concatenation of the the private and the public advertised address.
> Anyone have any advice or experience with this kind of setup?
> Users mailing list
> Users at lists.opensips.org
*0333 332 0000 | x-on.co.uk <https://www.x-on.co.uk> | **
<https://twitter.com/xonuk> ** | **Practice Index Reviews
*Our new office address: 22 Riduna
Park, Melton IP12 1QT.*
is a trading name of Storacall Technology Ltd
a limited company registered in
England and Wales.
Registered Office :
Glebe Farm, Down Street, Dummer, Basingstoke, Hampshire, England RG25 2AD.
Company Registration No. 2578478.
The information in this e-mail is
confidential and for use by the addressee(s)
only. If you are not the
intended recipient, please notify X-on immediately on +44(0)333 332 0000
and delete the
message from your computer. If you are not a named addressee
you must not use,
disclose, disseminate, distribute, copy, print or reply
to this email. Views
or opinions expressed by an individual
email may not necessarily
reflect the views of X-on or its associated
companies. Although X-on routinely
screens for viruses, addressees should
scan this email and any attachments
viruses. X-on makes no
representation or warranty as to the absence of viruses
in this email or
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users