> Am 13.03.2017 um 18:01 schrieb Lonnie Abelbeck <[email protected]>:
>
> Michael,
>
> Keeping Asterisk in the path is key, and calling Answer() is required at some
> point to do that.
>
> I always call Answer() before calling local phones, of course any IVR
> requires calling Answer() first.
>
> Though it may be possible, depending on your SIP trunk provider and enabling
> "directmedia=yes" for the trunk only, to selectively re-invice inbound calls
> back to the SIP trunk and not calling Answer(). Since this depends on your
> SIP trunk provider, it may work one day and stop working another day.
>
> If these kind of "hair-pin" calls are not common, play it safe and answer the
> call and dial back out, keeping Asterisk in the path.
>
> Lonnie
I never had to any of these "answer tricks" yet.
BTW: If you are working with local channels and forwarding, it can help a lot
to add "/n" to NOT optimizing out the local channels.
That way they stay active until hangup. E.g.
[globals]
FORWARD_CONTEXT=forwarded
[forwarded]
exten => _X.,1,NoOp(Forward to Ext. ${EXTEN})
; same => n,DumpChan()
same => n,Dial(local/${EXTEN}@forward-context/n)
> On Mar 13, 2017, at 11:33 AM, Michael Knill
> <[email protected]> wrote:
>
>> Yes thanks Lonnie
>>
>> No the call never gets to the IP Phone. I manage all my forwarding within
>> the Asterisk dial plan. And yes Im always keeping Asterisk in the path but
>> as prompted by David, I suspect now that Asterisk is not bridging the call
>> as I never actually Answer it in my dial plan.
>>
>> We will see.
>>
>> Regards
>> Michael Knill
>>
>> -----Original Message-----
>> From: Lonnie Abelbeck <[email protected]>
>> Reply-To: AstLinux List <[email protected]>
>> Date: Tuesday, 14 March 2017 at 12:51 am
>> To: AstLinux List <[email protected]>
>> Subject: Re: [Astlinux-users] Astlinux on the edge
>>
>> Michael,
>>
>> I hope others here will offer their SIP experiences, but can you define in
>> more detail what the failure mode is. I'll guess a little ...
>>
>> A call comes in via your SIP trunk provider, dials a local extension, either
>> the extensions is busy (or DND set) or no answer then the Asterisk dialplan
>> does what ?
>>
>> Or are you using a "feature" of the IP Phone to initiate the outbound call
>> when DND or other is set ? Using Asterisk as the server or directly to the
>> SIP trunk provider ?
>>
>> Explain exactly who does what and when.
>>
>> Bottom line, when behind NAT keep Asterisk in the path at all times.
>> Possibly in your failure case your IP Phone is re-inviting around Asterisk ?
>>
>> Lonnie
>>
>>
>> On Mar 13, 2017, at 4:32 AM, Michael Knill
>> <[email protected]> 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 <[email protected]>
>>> Reply-To: AstLinux List <[email protected]>
>>> Date: Thursday, 9 March 2017 at 1:22 am
>>> To: AstLinux List <[email protected]>
>>> 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
>>> <[email protected]> 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 <[email protected]>
>>>> Reply-To: AstLinux List <[email protected]>
>>>> Date: Saturday, 4 March 2017 at 2:54 pm
>>>> To: AstLinux List <[email protected]>
>>>> 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
>>>> <[email protected]> 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
Michael
http://www.mksolutions.info
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
