Paging – Snom PA1 – Lockdown Internal and External Calls – v15

[Brian Buell]

Across installations we have had an issue with Incoming Calls to the Paging Systems both Internally and Externally. Our goal was to limit what Extensions internally can call the Paging Extension and to lockdown external calls to that extension from the Automated Attendant (IVR).

We have found that this could be accomplished in the following way but had to attack Internal Calls and External Calls separately. Please Note: All Examples assume you use 3-digit extensions numbers, you may have to adjust ranges and entries if your extensions differ.

Limit Internal Calls to Paging Extension

• In the Extension for your Paging System (We use Snom PA1 Devices) Go to > Forwarding Rules
• By Default, you will be on the “Available” Status
• Scroll down to the Exceptions Area and click Add Rule button
• In the Field “Calls from Caller ID” Enter the range you wish to block
  
  
• Example: If you only allow Ext 188 to call the Paging Extension, Enter 001-187, 189-999
• Set Receive During to “All Hours”
• Set Forward to “End Call”
• Option: You could choose to send the call somewhere else, like an IVR with a prerecorded message.
• Scroll Back to the top and click the OK Button

Limit External Calls Paging Extension

• There are (2) options in Settings > Parameters that limit calls from the Auto Attendant (IVR)
  
  
• IVRDONOTCALL (Does not currently work as of 15.5 SP4)
• IVR_DIRECT_DIALING_GRAMMAR – Works Great
  
  
• In the Value field enter: The Extension number(s) you with to block.
• Example 1 Snom ((?!501)[0-9]{3})
• Example Multiple Snoms ((?!501|502)[0-9]{3})
• Option: You can enter as many extension numbers as you want to limit

We have had good luck locking down our paging devices with the following method.
We have not found a way to disable the ability to transfer a call to the paging extension which is still a problem from time to time.
If you have other ideas we would love to hear them.

 

[CentrexJ]

We use Multicast paging and we configure the Yealink phones that are allowed to make pages with a custom template. The custom template adds a BLF key (typically key 3 after the first two line keys) where the Yealink phone makes the Multicast Page directly. We then don't have to use a ring group and therefor don't have to resort to blocking calls to that ring group number from internal and/or external calls.

There are two additional advantages of this method. One is that people can't put the page on hold or park it. If you use the ring group method the can can be placed on hold or parked which results in music playing over the speakers. The other is that if you use a cloud hosted 3CX server multicast paging won't work with the ring group method. Multicast Paging as far as I'm concerned is far superior to intercom paging.

The code to add to make BLF key 3 on a Yealink phone template to produce a Multicast page is as follows. You can alter the 3 to whatever BLF key you want to assign it to and change the IP/Port to match whatever you use for Multicast. This needs to be placed in the BLF section of the 3CX template in place of the existing linekey.3 entries.

linekey.3.label = Paging
linekey.3.line = 0
linekey.3.type = 24
linekey.3.value = 224.0.1.75:50001

There is a request in the ideas forum already (by someone else) for 3CX to be able to provision these Multicast buttons through 3CX BLF provisioning so that you don't have to use a custom template. That would be amazing. 3CX has gone a long way towards reducing the requirements for custom templates.

 

[Brian Buell]

I agree, Multicast Paging is a great option. We are really trying to get away from having to manage custom templates, but find that it is still required more often than we would like. The other option that affects our installs for Multicast is we are unable to use PNP as our servers are never on the same subnet, again which would force us to support more custom.templates. Thanks for the input.

 

[CentrexJ]

You can overcome the lack of PNP by using DHCP66 and pre-configuring the extension with the model # and MAC of the phone. No need for custom templates to accomplish that.

With v15/v15.5 though you can no longer use PNP for custom templates directly (although you can PNP provision to the 3cx template and then go to the extension and delete/add the model and mac to the custom template and re-provision the phone after). More work but it gets the job done and with the latest templates the phone doesn't even reboot on the re-provision.

 

[YiannisH_3CX]

Great ideas and thank you for sharing. Please note that in the latest service pack you have the ability to provision a multicast paging group without the need of a custom template for the phones that support this function.

 

[Brian Buell]

Thanks YiannisH_3CX for the tip.

Yes we were awaiting the update and hope of not having to build and manage custom templates to use Multicast. However, the bulk of our installations are hosted in a data center accessed onsite via VPNs. Int hat environment Multicast relies on PNP for connectivity and is not on the same subnet.

It there a way to pass PNP across the VPN so we don't have to build and mange custom templates?

 

[YiannisH_3CX]

It there a way to pass PNP across the VPN so we don't have to build and mange custom templates?

Technically there is a way, however that depends on the network administrator and the way the network is setup.

 

[Brian Buell]

So I will go back to my original statement, How can you achieve Multicast paging across a VPN without customizing templates?