[OpenSIPS-Users] NAT & RTPProxy
Callum Guy
callum.guy at x-on.co.uk
Wed Apr 19 19:11:56 UTC 2023
Excellent, glad you're up and running. Note that you need to manually
implement any late sdp dialogue and handle any calls originating from the
application server using the reverse logic.
Best,
Callum
On Wed, 19 Apr 2023, 19:53 Gavin Murphy, <iiagavin at aim.com> wrote:
> I have fixed most of the issues I had. I think that in the process of
> testing I mixed up an ie<->ei. Things are set up properly now and audio is
> flowing to the client on my mobile phone.
>
> Thanks for the help.
>
> Gavin
>
> On Wednesday, April 19, 2023 at 02:19:44 PM ADT, Gavin Murphy <
> iiagavin at aim.com> wrote:
>
>
> So I did remember that the rtpproxy_offer and rtpproxy_answer functions
> can take an IP address as a second parameter. That was able to address the
> SDP issue in the 183.
>
> However, I am still not getting audio flowing to the client. I have a
> suspicion that it's related to the SDP on the incoming INVITE having a
> connection address of 192.0.0.2, and rtpproxy being unable to route to that
> address. I though that I could call fix_nated_sdp(2) ahead of the call to
> rtpproxy_offer() in order to adjust the SDP before rtpproxy got hold of it,
> but that results in a mangled connection line with the client address and
> the private address getting concatenated in the resulting SDP (e.g. c: IN
> IP4 72.1.2.3.4192.168.2.251).
>
> Is there any way to address this? I was hoping that the client I'm using
> (ZoiPer) might support STUN/TURN/ICE, but it doesn't appear that it does.
>
> Thanks,
>
> Gavin
>
> On Wednesday, April 19, 2023 at 02:09:13 PM ADT, Gavin Murphy via Users <
> users at lists.opensips.org> wrote:
>
>
> Yes. I am assuming the rtpproxy_offer("ei") should be used when the INVITE
> comes in from the external network, and rtpproxy_answer("ie") should be
> used in the onreply_route to handle the 183 and 200.
>
> Gavin
>
>
>
> Sent via BlackBerry Hub+ Inbox for Android
>
>
> Original Message
>
>
> From: callum.guy at x-on.co.uk
> Sent: April 19, 2023 1:12 p.m.
> To: iiagavin at aim.com
> Cc: users at lists.opensips.org
> Subject: Re: [OpenSIPS-Users] NAT & RTPProxy
>
>
> Just to confirm, for a call from the client to the application server
> you should be running rtp_offer("ei") in the main route for a non-LR
> INVITE and rtp_answer("ie") in the on reply route (when handling the
> 183 response).
>
> Is that what you're doing?
>
> On Wed, 19 Apr 2023 at 17:08, Gavin Murphy <iiagavin at aim.com> wrote:
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
>
>
>
>
>
>
> *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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230419/28b4c648/attachment-0001.html>
More information about the Users
mailing list