Michael,
You should probably turn on SIP debugging and look at the messages being
sent. I suspect what is happening is that a redirect is being sent to each
external node telling them to send their RTP packets directly to each other
rather than flow through your asterisk box. If this is the case then
something is going wrong there (either the external nodes do not accept
media redirects, or asterisk is passing the wrong IP address to redirect to
(which may be a consequence of NAT).
Another thing to do is run 'iftop' on your astlinx box... look at the rate
of traffic to/from the VoIP trunk. For a single ULAW/ALAW conversation it
should be about 78kbs each way. If it doubles when you do the transfer
back out to an external node then the media traffic is flowing through your
astlinux box. If it drops to nothing then a redirect was sent asking both
end points to talk directly to each other. If it stays at 78kbs then the
incoming node ignored the redirect request.
Given your description I think media is flowing through your astlinux box
when you answer the call then forward (because media link has already been
established and some VoIP trunk suppliers don't permit a redirect after you
have answered) but if you forward without answering then no media link is
established yet so the media redirects are then expected to work, but don't.
If you are okay with all media flowing through your box, then force an
answer of the incoming call before forwarding it (e.g. play a message
"please wait while I connect your call". This is not the ideal situation
but I can tell you that I have myself given up on trying to do call
forwarding (e.g. with a follow-me type scenario to forward calls to my
mobile phone if I am not at home) without forcing the media stream through
my astlinux box. I just couldn't get it to work reliably. Sometimes it
did, sometimes not. And my Astlinux is at the edge, not behind NAT.
David
On Mon, Mar 13, 2017 at 5:32 AM, Michael Knill <
michael.kn...@ipcsolutions.com.au> wrote:
> Ok my initial NAT testing is exhibiting the following issue which I
> remember previously occurred.
> Calls to and from extensions to external are fine with the below
> configuration.
> The failure scenario however is an incoming call forwarding out to an
> external call (hair pin) where there is no audio both ways.
>
> I spend ages trying to troubleshoot the issue to no avail. I looked though
> all the SIP SDP trying to work out what is happening. What I don't quite
> understand, and I am hoping all the SIP experts can help, is that I don't
> have any ALG’s set up so how does the external proxy know what media port
> to connect to? I understand that rport is sent in the Via header which
> gives the external address but this seems like its only for signalling!
>
> What is interesting is that I do a packet sniff on the router external
> interface (Mikrotik) and I don't see ANY RTP packets hitting or exiting.
> What is also interesting is that when I answer the incoming call from an
> extension and transfer it externally, the media works fine.
> I suspect it has something to do with this which I cant seem to find any
> info on:
> -- Local/0400113919@DialPlan1-00000025;2 requested media update control
> 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- SIP/gwy2-00000037 is making progress passing it to
> Local/0400113919@DialPlan1-00000025;2
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
> -- Local/0400113919@DialPlan1-00000025;2 requested media update
> control 20, passing it to SIP/gwy2-00000037
>
> Any ideas? No NAT for me currently until I can fix this.
>
> Regards
> Michael Knill
>
> -----Original Message-----
> From: Lonnie Abelbeck <li...@lonnie.abelbeck.com>
> Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Date: Thursday, 9 March 2017 at 1:22 am
> To: AstLinux List <astlinux-users@lists.sourceforge.net>
> Subject: Re: [Astlinux-users] Astlinux on the edge
>
> Michael,
>
> If you place AstLinux behind a NAT firewall as a PBX ...
>
> -- No NAT port forwarding to AstLinux (except for possible OpenVPN for
> remote IP Phones) and disable any upstream SIP ALG's.
>
> -- Set "directmedia=no" for all phones and the trunk, all media goes
> through Asterisk
>
> -- Set "qualify=yes" on trunk SIP peer to keep the upstream firewall state
> active
>
> -- Set "nat=force_rport,comedia" on the trunk SIP peer to force NAT
> handling, the only peer that does NAT to Asterisk
>
> -- Set "localnet=192.168.0.0/255.255.0.0' and "localnet=10.0.0.0/255.0.0.0"
> to cover any LAN and OpenVPN networks which are not NAT'ed to Asterisk.
>
> -- When using remote IP Phones over OpenVPN, since asterisk will bind to
> the openvpn server tun interface, use the openvpn network (possibly
> 10.8.0.0/24) for tunneled SIP endpoints.
>
> (Readers, if I have missed or mangled any of the above, please correct.)
>
> Bottom line, an AstLinux PBX behind NAT should be workable for production.
>
> Lonnie
>
>
> On Mar 7, 2017, at 8:01 PM, Michael Knill <michael.knill@ipcsolutions.
> com.au> wrote:
>
> > Hi thanks Lonnie. Sorry this went into my junk for some reason.
> >
> > 1) Yes this is certainly a problem but I have also experienced problems
> with no media on calls being hairpinned through Asterisk from the external
> trunk. This may be solvable with port forwarding however. Maybe I should do
> some testing on this and specify some known and working router/firewall
> configurations.
> > 2) I use Open VPN for my external phones so it could be solved this way.
> >
> > I am currently negotiating with the partner and it looks like they will
> take option 3 below which I think is the best compromise.
> >
> > Regards
> > Michael Knill
> >
> > -----Original Message-----
> > From: Lonnie Abelbeck <li...@lonnie.abelbeck.com>
> > Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
> > Date: Saturday, 4 March 2017 at 2:54 pm
> > To: AstLinux List <astlinux-users@lists.sourceforge.net>
> > Subject: Re: [Astlinux-users] Astlinux on the edge
> >
> > Hi Michael,
> >
> > My guess is "it depends" ... your IT partners go into a auto repair shop
> with a 5 year old residential-grade router, etc. (ie. a mess) then making
> AstLinux the edge device would be a major upgrade, not to mention the added
> voice functionality.
> >
> > Then again your IT partners go into a dentist's office which were
> previously sold more router than they needed, it may not seem right to put
> AstLinux in front of it.
> >
> > My guess is you need to plan for both situations.
> >
> > A couple comments ...
> >
> > 1) If AstLinux will only serve SIP endpoints on the private side, no
> roaming public endpoints, then being behind NAT is workable, only the trunk
> is effected by NAT. Always disable any upstream SIP ALG's, almost always
> bad news. Keep in mind no upstream port-forwarding is needed for this
> scenario, and always keep the AstLinux firewall enabled for the Adaptive
> Ban and other protections to be kept in place.
> >
> > 2) Else if roaming public endpoints need to be supported, placing
> AstLinux at the edge will make SIP easier. AstLinux comes with a dmz-dnat
> plugin, the idea is to move a pre-existing router from the WAN to
> AstLinux's LAN with a static IP address and configure the plugin which
> internally performs a " -j DNAT --to-destination $DMZ_IP " *all* traffic
> not allowed directly into AstLinux. WARNING - this plugin was written many
> years ago and has not been tested as thoroughly as I would like to see for
> production purposes. Though if there are issues with the dmz-dnat plugin
> they could be remedied.
> >
> > Lonnie
> >
> >
> > On Mar 3, 2017, at 4:50 PM, Michael Knill <michael.knill@ipcsolutions.
> com.au> wrote:
> >
> >> Hi all
> >>
> >> Im looking to push my Astlinux business this year and this will rely
> heavily on partners. These partners will usually be IT Service providers
> that have a number of small business customers and that they want to add
> voice as a value add product.
> >>
> >> Now here is where the problem lies. Most of these providers would
> currently be maintaining the site firewall but as Astlinux is designed to
> be on the edge, its an issue. So what do you do?
> >> 1) Put Astlinux in front of their firewall and open up the
> necessary ports and protocols. The problem here is that they lose
> flexibility in what they can do and there is another provider in the mix.
> Its also a problem if they are retailing the broadband connection for the
> site with too many dependencies.
> >> 2) Put their firewall on an Astlinux DMZ with a public IP
> Address. They now have more flexibility and I can control Qos. Still issues
> with being reliant on another provider and additional IP Addresses can be
> expensive or unobtainable. I assume I can actually do this with Astlinux!
> >> 3) Put Astlinux as a DMZ in their firewall with a public IP
> Address. They now have complete control however QoS would need to be
> configured on the firewall and additional IP Addresses can be expensive or
> unobtainable. PS this is the model I have with one of my partners
> >> 4) Sit behind the firewall and rely on port forwarding and/or
> ALG’s. Inviting trouble but possible if you have a known working
> configuration
> >>
> >> Im interested to know what others are doing in this space.
> >>
> >> Regards
> >> Michael Knill
> >
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Announcing the Oxford Dictionaries API! The API offers world-renowned
> > dictionary content that is easy and intuitive to access. Sign up for an
> > account today to start using our lexical data to power your apps and
> > projects. Get started today and enter our developer competition.
> > http://sdm.link/oxford
> > _______________________________________________
> > Astlinux-users mailing list
> > Astlinux-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
> ------------------------------------------------------------
> ------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
>
>
> ------------------------------------------------------------
> ------------------
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> _______________________________________________
> Astlinux-users mailing list
> Astlinux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pay...@krisk.org.
------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Astlinux-users mailing list
Astlinux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
pay...@krisk.org.
