Hi Callum,
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
142.1.2.3/142.1.2.3 -m 10000 -M 10100
The client source IP seen by opensips is 72.1.2.3, 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 (142.1.2.3), 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 (142.1.2.3).
Thoughts?
Thanks,
Gavin
On Wednesday, April 19, 2023 at 07:06:54 AM ADT, Callum Guy
<callum....@x-on.co.uk> wrote:
Hi Gavin,
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
application server.
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.
Good luck!
Callum
On Wed, 19 Apr 2023 at 06:39, Gavin Murphy via Users
<users@lists.opensips.org> wrote:
>
> Hello,
>
> 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?
>
> Thanks,
>
> Gavin
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
*0333 332 0000 | x-on.co.uk <https://www.x-on.co.uk> | **
<https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel>
<https://twitter.com/xonuk> ** | **Practice Index Reviews
<https://practiceindex.co.uk/gp/x-on>*
*Our new office address: 22 Riduna
Park, Melton IP12 1QT.*
X-on
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
within this
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
for
viruses. X-on makes no
representation or warranty as to the absence of viruses
in this email or
any attachments.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
