[OpenSIPS-Users] NAT & RTPProxy

Wed Apr 19 16:08:20 UTC 2023

 Hi Callum,
   thanks for the additional info. I removed the -A option from the rtpproxy command line but am essentially getting the same result. The INVITE does get the address translated correctly, such that it's the rtpproxy's internal IP address when the INVITE is forwarded on to the application server.
However when a 183 comes back from the application server, the IP is updated to the internal address, regardless of which i/e combination I use. I can't seem to get it to populate the external IP.
Thoughts?
Gavin

    On Wednesday, April 19, 2023 at 12:52:04 PM ADT, Callum Guy <callum.guy at x-on.co.uk> wrote:  

 Hi Gavin,

Its been a while since i used rtpproxy (favouring RTPEngine these
days) however I believe the main issue may be the listen option - this
should be "-l [internal]/[external]"

-l 192.168.2.251/142.1.2.3

Once implemented you do indeed need to set ei/ie/ee etc in the offer
options to specify which address you wish to present for each scenario
you are handling.

This also applies to -A however you should only need that if running
those addresses behind NAT.

Hope that helps to move you forward!

Callum

On Wed, 19 Apr 2023 at 15:01, Gavin Murphy <iiagavin at aim.com> wrote:
>
> 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.guy at 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 at 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 at 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.
>
>
>
>
>
>
>
>

-- 

*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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230419/887c5e26/attachment-0001.html>