I am replacing a customer's current Asterix system with a UC500. The Asterix system has a page all function which, when pressed, will activate speakerphones on all phones AND trigger their PA system (which is connected with a Linksys PAP2T) for a true global page. On the UC500, I can configure this to work with all IP phones (via paging-dn) OR just the PA system (by dialing the extension of the FXS port). The paging group on the UC500 will not allow me to include the FXS-connected PA system.
I really need to deliver this functionality and am willing to purchase any ATAs I might need.
Can someone please provide advice on how to accomplish a paging feature that will activate all phones AND the FXS-connected PA system?
Although, I would be tempted to tell the customer, "sorry, but no" I can think of a few ways to address this. Probably, only the first one would be considered a 'supported' solution.
1. Offer to install some additional page speakers to cover the areas that were previously handled by paging on the phones.
2. If UC500 has a background music feature where you can play music on hold through the phone speakers then split page amp output between speakers and MOH input. Then turn on BG music on phones. When you page overhead the page will also go through the phone speakers. I have done this on Nortel and NEC phone systems in the past successfully.
3. Crack open a spare Cisco phone and wire the speaker output into the page amp input. I have also done this on a couple of occasions. You may need an impedance matcher or a device like a Bogen TAMB between the phone and the page amp.
Thank you so much for that information! I will say that option 3 (crack open a spare phone) is the most attractive option. I just looked and it appears the current setup (using a PAP2T) is actually going into the "Phone System" punch-down on a Bogen TAMB.
So, I can just wire the single-pair speaker output to this input on the Bogen and I should be good to go?
Also, do you have any information or links that would help me open the Cisco phone and perform the wiring properly?
Yes you should be able to connect the speaker leads to an input on the TAMB without anything else.
I never did this with a Cisco phone, but other models. Phones aren't usually too hard to take apart. Look for screws on the bottom sometimes hidden under stickers and go from there. It is putting them back together that is the challenge ;)
Can someone please provide advice on how to accomplish a paging feature
that will activate all phones AND the FXS-connected PA system?
I know this is not what you want to hear, but this not really an option, other then doing some really ugly hacks, even going as far as butchering physical hardware.
You could look at the option of a second hand Cisco Cordless phone which should allow paging, i am not sure if this is an option for you.
A Video on demand (VOD) on Overhead paging for the UC500, which is also relevant to the SPA9000 system can be found in this community at the following location;
But since your customer had an existing FXS connected overhead paging system, you can continue to ring an extension to activate the existing overhead paging system. Details of this can be found in the VOD.
The built in multicast paging system, as you are aware, uses the speaker phone capabilities and a Pilot number to activate the speaker on the IP phones. It's pre-configured in the UC500, as per the script example below.
number 101 no-reg primary
description paging group
name paging group
paging ip 126.96.36.199 port 2000
Manufacturers like Valcom, cyberdata and others have overhead paging systems that also work with Multicast paging, so your customer has a choices.
Zone 1 using pilot number 101 for multicast paging and
Zone 2 Using an FXS port extension number, and built in or external multiport FXS device such as a SPA8000 for amplified overhead paging.
If your customer is really insistent that they have one number for both multicast and amplified overhead paging, buy some Cyberdata, Valcom or other multicast based overhead paging system. This will allow one pilot number to page both IP phones and multicast based Overhead paging system.
Since your customer were most likely used to FXS based paging in the past, they can still have this status quo, but just connecting the existing paging system to the built in FXS port on the UC500, and not use built in multicast paging.
Other folks tested ideas on how to achieve what you want would be most welcome.
I know this thread is almost 2 years old, but we have a couple of customers with new UC500 installs who would like the functionality described by the original poster. The solutions in the thread were from 2 years ago, are there any better solutions available now?
I can see us encountering more customers with non-IP based paging systems where we will need this functionality. It would be nice if Cisco could make it easy and allow us to add the FXS port to the paging-dn.
I can honestly tell you, save yourself the headache and see if you can sell them another paging system, preferrably a SIP based one so it can be placed into a calling group.
You could try though with an FXS based setup to add the FXS station ID into a blast group, this may work for you and you speed dial it onto one of the button phones or leave it as being diallable. But with FXS solutions you may encouter other issues such as locked ports because the call to that station has not cleared down.
I know wht you are saying as we see this on about 6 out of 10 installs, but you need to try hard to up-sell them to a more modern paging system where possible, it will save you many agonising hours of fault finding or configuring the system to place nice.
A paging group in general sends out one way audio to a multicast group not a FXS interface and maybe someone smarter than me can how we connect a FXS interface to a paging group. I can't see how that can work.. By the time the overhead auto answered the FXS call, all the other IP phones are receiving the page, but the FXS connected overhead pageing system may still be ringing or get some clipped audio.
yep more input needed on the thread.
David Trad brings up a interesting point.