Hi David
Thanks for the info and yes sorry all I do realise that this is a little off
topic for this forum (just a little!).
I have done heaps of SIP debugging actually and I don't think I can see any
redirects which is also what I suspected could be happening also. I actually
did an Asterisk RTP debug and a packet sniff on the Mikrotik router and did not
see ANY RTP packets in both cases. Even with a Reinvite, you see some RTP
packets initially traversing the box from memory.
However you do make a very good point in your last paragraph. I followed my
dial plan and realise that I never Answer the call. That's the obvious
difference between answering on phone and performing a transfer. I don't
understand why its works ok for me when on the edge but if answering works then
problem solved. I guess I have always been against answering an incoming call
before you have actually determined that the call can be routed e.g. if the
number is busy (rare with voicemail) or rings out, the caller should not be
charged for the call. Maybe I will just set it when I am behind NAT.
More testing required. Ultimately though SIP + NAT = BAD
Regards
Michael Knill
From: David Kerr <da...@kerr.net>
Reply-To: AstLinux List <astlinux-users@lists.sourceforge.net>
Date: Tuesday, 14 March 2017 at 12:39 am
To: AstLinux List <astlinux-users@lists.sourceforge.net>
Subject: Re: [Astlinux-users] Astlinux on the edge
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<mailto: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<mailto:li...@lonnie.abelbeck.com>>
Reply-To: AstLinux List
<astlinux-users@lists.sourceforge.net<mailto:astlinux-users@lists.sourceforge.net>>
Date: Thursday, 9 March 2017 at 1:22 am
To: AstLinux List
<astlinux-users@lists.sourceforge.net<mailto: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<http://192.168.0.0/255.255.0.0>' and
"localnet=10.0.0.0/255.0.0.0<http://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<http://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.kn...@ipcsolutions.com.au<mailto:michael.kn...@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<mailto:li...@lonnie.abelbeck.com>>
> Reply-To: AstLinux List
> <astlinux-users@lists.sourceforge.net<mailto:astlinux-users@lists.sourceforge.net>>
> Date: Saturday, 4 March 2017 at 2:54 pm
> To: AstLinux List
> <astlinux-users@lists.sourceforge.net<mailto: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.kn...@ipcsolutions.com.au<mailto:michael.kn...@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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:pay...@krisk.org>.
------------------------------------------------------------------------------
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.
