One of our campus customers initially needed several door phones with openers and call boxes with camera coverage. Then the school principal wants a few other items addressed. In the end discussion, they asked us for a "unified" solution. Remember back to Cabling the Campus, I outlined a plan of one of our customers to develop a best practice blueprint to acquire and implement technology and communications.
Since that post in 2008, the school has been recognized as a Blue Ribbon School. They currently have the ADTRAN 1534 WiFi, Cat5E structured wiring, managed ADTRAN 1524 ST switches and a 1Gig fiber backbone with spare fiber pairs. The existing camera solution is questionable and the telephone system is no longer supported. The PA wiring is decrepit while the PA system is too limited for the school’s needs. The LAN is flat and without VLANs because there aren’t any…yet. The PA, network cameras and phone system are serviced by three separate vendors, a fourth vendor services the servers and immediate IT support while we (the fifth vendor) service the infrastructure and WiFi.
We brought in a couple of network cameras and started testing with our Panasonic Communications Assistant Pro (CA Pro) clients. Our NCP1000 has onboard door phone and door opener relays. Each door phone presents station Caller-ID *3101 (door 1) *3102 (door 2) etc. The door phone and opener functions are programmed to ring different extensions including soft phones and cell phones and at different times and on different days. The screen pop is a simple URL setting or PATH statement for accessing applications. Once we set up a guest viewing only URL on each network camera, the screen pop was easy. The guest viewing URL is entered for the first entry for each door phone extension number. When visitors press the call button at door phone 1, the assigned extensions ring and the user’s CA Pro will screen pop showing the extension and then launch a webpage to the corresponding camera’s URL for guest viewing. The network cameras we used have multiple screen-refresh rates so we opted for the lowest setting of 3 seconds. Since there are two additional entries in the client, I decided to have a little fun and entered a PATH statement to sound archives on our Mac Mini Server--and directed the desktop to play a sound file that follows the web page launch to view the camera at the door phone. The user answering the door phone call has the option to press a soft key on their desk phone or their soft phone to open the door.
Of course we need to address policy of challenging and then buzzing someone in remotely but the immediate concerns are how fast desktops can connect to the local URLs and/or PATH statements we define in our UC clients and how consistently they will work under traffic loads on campus. Granting access is another thing, and then deciding what we should or shouldn’t pop to a user screen needs more discussion.
Several weeks ago I had lengthy discussions with Paul McMillan, Director UC Technical Vision & Strategy over at Siemens, and Paul reminded me of the complexity and security concerns in and around UC, and be sure to read Gary Audin’s post on Identity Issues in UC. Still, converging the PA, phones and cameras onto one wired infrastructure along with all the "bells and whistles" found in a campus environment is challenging due to physical wire distances to and from relays and sensors. Mapping out the distances of physical wire to ensure that adequate power is delivered to devices over the distance is necessary. Otherwise, doors won't open and cameras won't function properly. Thus, adding a new set of reasons of why I argue to Shorten the Cable Drops. Of course there are options to use Ethernet devices and adapters for every bell or whistle in a campus setting, because Valcom offers Classroom Connection, a dynamic range of products including adapters to extend conventional signal wire connections over to IP to increase distances. Each IP-PBX manufacturer is different and we’re working with 22AWG at 590 feet for door phones (call boxes) and door openers. In the campus environment, the IP-PBX is a communications server; so mandating that all the "IT gear" must remain in the computer room/data center isn't always practical. Vendors, customers and architects don’t always have the luxury of designing in centrally located closets, MDFs and IDFs. It's an age-old problem that Valcom has elegantly designed around with their Classroom Connection solutions.
So in a good day's work we emulated in our offices what the customer wanted without using separate video monitors connected to camera controllers. Another screen pop that on the surface seems pretty simple but will lead us into numerous challenges. Campus communications is a good proving ground to reduce vendors, converge infrastructure, encourage integration/convergence and reduce costs; but it won’t happen without planning, investment of skin in the game and working out acceptable methods to minimize the risks.
CONCERNS
* Using separate available fiber pairs for campus-wide paging may be more resilient but more hardware intensive
* Routing between VLANs
* Desktops using UC client must be well maintained
* Security--who uses the desktop and how much or which data should be screen popped
* Is PoE sufficient for network cameras and features that require more power such as pan, tilt, zoom? 802.3af or 802.3at? Centralized power from a protected LAN switch (PoE) is better than local power and costs less to install
* Remote door opening, call boxes and video to other buildings connected via fiber
* Single point of failure within campus
* Call boxes, cameras vandal/weather proof/resistant?
* Minimizing equipment clutter
* Protecting equipment clusters with dual conversion UPS and AC TVSS protectors
* Solution(s) must remain practical, functional, manageable and cost effective
* Placement of the IP-PBX does matter--central locations may be better for home run wiring for signal cables (relays/openers) but may be too difficult
