FAQ
Most frequent questions and answers
The RFCS is a specialized communication system designed for emergency situations. When a designated “master” phone goes off-hook (or a button is pressed in alerting mode), the system automatically initiates calls to a pre-defined list of endpoints (such as fire stations, police, and airport operations) and connects them all into a multi-party conference, enabling immediate and clear communication during critical events. This can also trigger other actions such as strobe lights, PA systems and gate openers.
The core of the RFCS system is built around a Cisco router (C8300) and contains a network interface module for analog, FXS, FXO or BRI connections as well as a service module where the XOP Linux-based software resides. This hardware and software supports analog, IP, or a combination of both types of phones, along with loop extenders. The RFCS has the ability to connect to a SIP trunk to connect off-net users. Redundant systems are often deployed for high availability, where a secondary RFCS will activate when the primary fails.
To ensure high availability, XOP Networks often deploys redundant RFCS systems. In a redundant configuration, a primary and secondary server located in different physical locations are connected, usually with a fiber optic cable. If the primary system fails due to network, power, or other issues, the connected phones automatically re-home to the secondary system, maintaining seamless functionality without interruption. All user functionality and configuration is exactly the same between primary and secondary.
The RFCS offers a web-based administration portal for system configuration, management, and monitoring. This includes:
- RealView: A screen showing the status of all phones in the system, including on/off hook status and caller ID. The screen will indicate who is speaking in a conference.
- Network Settings: Configuration of network parameters, email relay servers, time zones, and NTP servers.
- System Settings: Adjusting system parameters, including software updates, logging, and user authentication.
- Circuit Groups: Defining external network connections such as TDM, SIP trunks, and SIP extensions.
- Service Selection: Implementing rules to automatically invoke services based on incoming call source/destination numbers.
- Diagnostics and Backups: Tools to generate diagnostic files, create database backups, and restore from backups.
- Licensing: A section to view current licenses, upload new license files, and display the system hardware address required for licensing.
- SNMP: Using Simple Network Management Protocol to monitor system health such as CPU, memory, and hard drive utilization.
- LDAP Directory: Integration with corporate directory servers for remote authentication and user/group importing.
- Enhanced Security: Providing intrusion prevention features such as password policies, IP freezing on login failures, and X-Option sessions.
The sources provide information about T1 and E1 in the context of network interface modules for the XOP Networks system.
- T1 is mentioned as a type of circuit group, which allows the system to connect to external networks for inbound and outbound calls. The system allows for four types of circuit groups: TDM, SIP trunk, SIP extensions, and attached users. The parameters that need to be set depend on the type of circuit group.
- E1 is mentioned alongside T1 as part of the network interface modules in the Cisco 4000 router. The network interface modules allow for analog connections such as FXS, FXG, BRI, and also digital connections like T1 and E1.
These network interface modules are part of the core system. The system is based on a Cisco router, which includes two modules: the network interface modules and a service module. The service module is where the XOP software resides.
T1 and E1 refer to telephone trunks that carry digitized voice in Time Domain Multiplexed (TDM) channels. T1 based interfaces are pre-dominantly used in USA. Each T1 has 24 voice ports.
E1 based interfaces are pre-dominantly used in Europe, Asia and Latin America. Each E1 has 30 voice ports.
One voice port equates to one phone call.
The sources discuss VoIP and SIP trunk in the context of the XOP Networks system.
VoIP (Voice over Internet Protocol):
- The system supports both analog and IP phones. The system can support 2500 series analog sets, IP phones, or a combination of both.
- The system can connect with a SIP trunk to the airport PBX, which allows the system to call off-net users, such as cell phones, and join them into a conference.
- The system uses WebRTC technology to allow users to communicate with the conference bridge using a browser instead of a phone. This is used for the “click to call” service, which allows a user to enter a conference room with a single click of a button, without having to enter an access code.
- The network switches feature allows the system to scan a set of ethernet switches for attached SIP phones. If the phones are moved to a new switch, a remote PBX can be updated with the new physical location of the phone.
- The system also has a PBX synchronization feature that allows an administrator to configure connection location and credentials for a remote PBX, which would likely be relevant for integrating with a VoIP system.
SIP Trunk:
- A SIP trunk is one of the four types of circuit groups that the system can use to connect to external networks for inbound and outbound calls.
- The system can connect with a SIP trunk to the airport PBX.
- When setting up a circuit group, one of the options is a SIP trunk, which has its own set of parameters that need to be configured.
- The system can connect to external networks using SIP trunks for inbound and outbound calls.
- When using a SIP trunk, the system can call off-net users and join them into a conference.
Voice over IP refers to carriage of voice calls over the Internet. Session Initiation Protocol (SIP) is a signaling protocol that is used for setting up VoIP connections. The VoIP/SIP trunk operates over a standard Ethernet interface.
The capacity of the Universal Service Node (USN) in several areas:
- Connectivity: The Cisco router platform supports different types of network connectivity:
- Dedicated LAN: The system can operate on a dedicated LAN, such as an AirPort VLAN, to prevent conflicts and ensure reliable operation of the crash phone network.
- Fiber Network: For redundant systems, multiple RFCS units can be connected via a fiber network.
- SIP Trunk: The router can connect with a SIP trunk to the airport PBX, allowing the system to call off-net users, such as cell phones, and include them in the conference.
- Network Interface: The system’s core is a Cisco 4000 router, which has two network interface modules. These modules support analog (FXS, FXG) and digital (BRI, T1, E1) connections.
- Conference calls: The USN is capable of handling multiple audio conferences simultaneously. The Command and Control service allows monitoring of multiple audio conferences at the same time. A command and control station can be set up to manage and interact with multiple conference rooms.
- Mass notifications: The mass notification service is designed to send messages to a large group of people using different media. The system can send voice messages, emails, text messages, and SMS or pager texts. The system can be set to attempt multiple retries to contact members.
- System monitoring: The USN can be monitored remotely using SNMP (Simple Network Management Protocol). This allows for monitoring of system parameters such as CPU, memory, and hard drive utilization.
- User roles: The system has three user roles: administrator, moderator, and user. The administrator creates moderators by setting up accounts. The administrator can set up companies and associate accounts with a company. Users can be defined by the administrator and the moderator.
- System performance: The USN system allows administrators to monitor and analyze platform and application performance using real-time monitoring and reports. The system status report shows the status of the voice application, memory and disk usage, software services and network port status.
- Scalability: The system can connect with a SIP trunk to the airport PBX, which allows the system to call off-net users and join them into conferences.
- Redundancy: The system can be configured with a redundant RFCS (Ringdown Firebar Conference Server). If the primary system fails, the phones will automatically re-home to the secondary system.
It is important to note that the system’s capacity may be influenced by the specific configuration and the types of services being used. For example, a system configured for a large number of simultaneous mass notification messages may have a different capacity profile than a system primarily used for audio conferencing.
A USN can handle up to 16 T1 or E1 trunks per chassis. That equates to 384/480 voice channels. The available voice channels can enter/exit the system either over T1/E1 lines or over VoIP Ethernet interface or shared between the two. For example, following configurations are possible:
- 384 T1 TDM ports and 0 VoIP ports
- 480 E1 TDM ports and 0 VoIP ports
- 0 TDM ports and 480 VoIP ports
- 240 E1TDM ports and 240 VoIP ports.
- Limitations: Although the system is scalable, it is still constrained by the capacity of the Cisco router and the software. The system will deny any additional calls if the licensed port capacity is reached.
In short, you will need to equip the PBX with additional T1/E1 CAS or ISDN cards to connect one or more T1/E1s between the PBX and the USN.
If users have a legacy TDM (Time Division Multiplexing) based PBX (Private Branch Exchange) and need to interface with the XOP Universal Service Node (USN), they will require specific interfaces and configurations to bridge the technologies. Here are necessary components:
- Circuit Groups: The USN system uses circuit groups to connect to external networks for inbound and outbound calls. For a TDM-based PBX, the system needs to be configured with a TDM circuit group.
- Network Interface Modules (NIMs): The Cisco router, which is the heart of the USN system, includes Network Interface Modules (NIMs) that support various types of connections. For TDM, the NIMs can handle:
- Analog FXS and FXO connections
- BRI (Basic Rate Interface)
- TDM Gateway: The system also supports the use of analog gateways. These are typically used to interface with loudspeaker systems. These gateways can also have relays that can trigger devices like fire station doors, alarms, or other external equipment.
- Configuration: When setting up a TDM circuit group in the USN system, specific parameters will need to be configured. These parameters are dependent on the type of TDM connection being used, whether it is FXS, FXO or BRI.
- Service Selection: The USN system allows for automatic service invocation based on source and destination numbers. This feature, called service selection, can be configured so that calls coming from the TDM PBX are automatically routed to the appropriate service or conference within the USN.
- Gradual Transition: The system supports a phase transition to an IP-based environment. The USN’s multiple interfaces allow for a gradual migration from TDM to IP, which might involve using both TDM and IP simultaneously until the legacy PBX is fully phased out. This capability helps to protect the investment in existing TDM systems while providing a path to modern IP-based infrastructure.
- PBX Synchronization: The USN system has a PBX synchronization feature. This feature can be used to configure connection locations and credentials for the remote PBX, which might include a legacy TDM system. This synchronization can be used for data extraction, error reporting, and to help manage the transition to a fully IP based environment.
In summary, to interface a legacy TDM-based PBX with the XOP USN, users will require a TDM circuit groupconfigured on the USN, using appropriate NIMs for analog or BRI connectivity on the Cisco router. An analog gateway can also be used, particularly when needing to integrate with speaker systems and other devices. The service selection feature allows for automatic routing of calls to the correct USN services, and the PBX synchronization feature can help to manage connections to the legacy PBX during the transition. These steps ensure seamless communication between the legacy TDM system and the modern IP-based USN platform.
The default configuration is: E&M, Wink Start, DTMF, DNIS and No ANI.
Universal Service Node (USN) interfaces with IP PBX systems, primarily through SIP trunking and network switch integration.
Here are the key aspects of these interfaces:
SIP Trunking:
- The USN can connect to an airport’s PBX via a SIP trunk. This allows the USN to extend its reach beyond the local network and include off-net users, such as cell phone users, in conference calls.
- A SIP trunk is one of four types of circuit groups that the USN uses to connect to external networks for both inbound and outbound calls.
- When setting up a circuit group in the USN, one of the options is a SIP trunk, which has its own specific parameters that need to be configured.
Network Switch Integration:
- The USN can scan Ethernet switches for attached SIP phones.
- If a SIP phone is moved to a new switch, the USN can update the remote PBX with the new physical location of the phone. This automatic detection of moving phones is supported in combination with NEC’s Univerge 3C communication server.
- The network switches feature within the USN allows administrators to define switch names, IP addresses, authentication details, and port ranges for connected switches.
PBX Synchronization:
- The USN has a PBX synchronization feature that allows administrators to configure the connection location and credentials for a remote PBX.
- This synchronization also allows for the configuration of master relay servers for phone texting applications.
- The system allows for data extraction and data synchronization parameters from the PBX, as well as error reporting mechanisms.
VoIP Support:
- The USN supports IP phones, with analog or IP phones, or a combination of both.
In summary, the USN interfaces with IP PBX systems primarily through SIP trunking to connect to external networks and include off-net users, and network switch integration to manage SIP phones and update their locations. The system supports both SIP and traditional phone systems, facilitating integration within various communication infrastructures.
System’s behavior during a power outage, focusing on the redundancy features of the Ringdown Firebar Conference Server (RFCS) and how it ensures continued operation.
- Redundant Systems: The system is designed with primary and secondary RFCS units. These systems are located in different buildings within the airport and are connected via a fiber network.
- Automatic Failover: In the event of a power outage, fiber cut, or disconnection of the primary system, the phones will automatically re-home to the secondary system.
- Seamless Transition: The transition from the primary to the secondary system is intended to be seamless, with users not noticing any difference in functionality or which system is active. The secondary system will carry on functioning.
- Demonstration of Failover: The system’s failover capability is demonstrated by simulating a network or server failure by disconnecting the primary system. The phones will then re-home to the secondary system within a few seconds. The system also demonstrates re-homing back to the primary system when it comes back online.
- High Availability: The redundant setup ensures high availability of the system, making it suitable for critical applications such as emergency communications at airports or nuclear facilities.
In summary, the XOP Networks system is designed to maintain functionality during a power outage by using redundant RFCS units that automatically take over if the primary system fails. This ensures uninterrupted communication during critical events.
XOP Networks recommends that the equipment be deployed with a minimum of 1000 VA UPS. That will keep the unit running for 1 hour in case of loss of power.
In case of mission critical applications, our customers deploy two geographically redundant systems. The system’s software keeps both sides synchronized 100% of the times using real time data base replication. In case of extended power outage, the surviving system can be used for handing emergency situations.
As a further back up, XOP Networks can keep a copy of customer’s database on its customer care servers and allow use of that server during emergency situations. Please contact XOP Networks Customer Support department if that is required.
XOP Networks system allows for the customization of the sign-in page with a company logo. Here are the details:
- Customizable Sign-in Page: The system allows for the sign-in page to be customized with a company logo. This can be done by an administrator through the administration portal.
- Branding: This customization allows organizations to brand the system with their own visual identity. The company logo is highlighted and shown on the sign-in page.
- Web Page Banner: In addition to the sign-in page, the text that appears on the banner of each web page can also be customized, allowing consistent branding across the platform.
- Welcome Greeting: A company-specific welcome greeting can also be uploaded for the conferencing application.
These customization features are part of the broader system administration settings which allows for the tailoring of the user experience and the maintenance of a consistent look and feel for the XOP Networks system, while also promoting brand recognition.
A customer can upload their own logo in place of XOP Networks logo via the System Configuration page on the admin interface.
There are various reporting features available within the XOP Networks system, accessible through the administrator portal, that provide insights into system performance, usage, and service-specific activities.
Key aspects of the reporting system:
- Types of Reports: The system offers a range of reports accessible from the “Reports” menu. These reports include:
- Service-Specific Reports: These reports provide details on specific service instances, giving insights into the usage and performance of individual services.
- Conference Recordings: This report lists recordings associated with different conferences and provides links to access the recorded files.
- System Status Report: This report gives an overview of the system’s performance and resource utilization. It includes:
- System version numbers for the web and voice applications.
- Status of the voice application (running or stopped).
- Number of invalid web login attempts and locked web accounts.
- Status of system resources like memory, disk usage, and software services.
- Details of hard drive and network port status.
- System Events Report: Provides a detailed log of events that have occurred within the system. This includes:
- Event ID
- Date and time of the event
- Source IP address
- Moderator ID
- Event description
- Event details
- Current Logins Report: Shows the accounts that are currently signed into the web portal. Details include:
- Company name of the account holder.
- Name of the logged-in user.
- IP address of the browser used to log in.
- Time of sign-in.
- Time of the last action performed by the logged-in user.
- Access: Most reports are explained in detail in the moderator training modules, however, the system status report, system events report, and current logins report are only available to the administrator.
- Filtering: The reports can be filtered using various criteria to focus on specific information. For example, the system events report can be filtered by specifying a search criteria. The real-time view can be filtered by using various options including time and subject of the conference.
- Purpose: These reports provide details on system performance and usage, helping administrators to monitor the system’s health, troubleshoot issues, and analyze trends. They also help to keep track of the activity on the system.
- Customization: The real view can be customized using settings options, including sorting members by name or joining time and toggling between usernames and caller IDs.
In summary, the XOP Networks system provides a robust reporting suite, with both real time and logged data, that allows administrators to track system performance, monitor usage of various services, and identify any issues.
While versatile, the RFCS is particularly valuable in environments requiring rapid emergency response, and is primarily used by:
- Airports: Facilitating communication between air traffic control, fire services, airport operations, and other relevant personnel during incidents.
- Utilities, especially Nuclear Power Plants: Enabling communication between plant personnel, city, and state officials in case of emergencies.
- Government and Military: Providing secure and reliable emergency communication networks.
- Emergency Services: Connecting first responders such as fire, rescue, and medical personnel.
A ‘crash phone’ system is initiated when a phone is taken off the hook which triggers calls to multiple destinations and places them on an audio bridge. An ‘alerting network’ is a more basic system typically triggered by a button, and calls endpoints while also triggering other actions such as strobes and PA announcements. XOP Systems can combine these two systems into one solution so the system acts both as a crash phone as well as an alerting network.
In a tower environment, RFCS tower phones feature a sidecar, which is an additional display and button module that visually indicates who has answered the call. This allows the air traffic controller to see immediately which stations (e.g. fire, police) are actively participating in the conference. This provides immediate visual feedback and eliminates the need to ask which personnel are on the line.
XOP’s click-to-call feature enables users to initiate calls to the RFCS via a web browser (rather than a phone), providing a more versatile and flexible approach to emergency communication. It uses WebRTC technology to place a call button on the browser, which connects the user to the RFCS conference. This feature can be used in combination with service selection to enable one-click access to emergency conferences by utilizing special URLs or home screen icons. This can also be used to start scheduled or on-demand conferences. The system can be set to dial out to specific members when the CTC function is triggered. In these scenarios, CTC is used in place of a traditional phone for simplified access to the RFCS conference.
Here are some information regarding ISDN PRI (Integrated Services Digital Network Primary Rate Interface) in the context of the XOP Networks system:
- Network Interface Modules: The XOP system uses a Cisco router as its core, which is equipped with network interface modules. These modules provide connectivity to various types of networks. One of the module types is PRI, which is a form of ISDN.
- TDM Circuit Groups: The system allows for four types of circuit groups, one of which is TDM (Time Division Multiplexing). TDM circuits can be used for ISDN PRI connections. When configuring a circuit group of type TDM, specific parameters applicable to TDM circuits would need to be set.
- External Network Connectivity: The system uses these circuit groups to connect to external networks for both inbound and outbound calls. Therefore, ISDN PRI can be a method used to connect the XOP system to the external telephone network.
- Transition to IP: The system also supports a phase transition to an IP-based environment. This suggests that while traditional technologies like ISDN PRI are supported, the system is designed to integrate with and transition towards modern IP-based communication systems, such as SIP trunking, which is also supported.
In summary, although the sources do not explicitly detail the full specifications of ISDN PRI support, it indicates that the XOP Networks system, through its network interface modules and TDM circuit group capabilities, can connect to external networks using ISDN PRI. The system’s design also accommodates a transition towards IP-based communication infrastructure.
Notes: T1 ISDN PRI refers to a T1 based trunk that uses 23 bearer time slots and 1 signaling time slot. It is also popularly referred to as 23B + D.
E1 ISDN PRI refers to an E1 based trunk that uses 30 bearer time slots and 1 signaling time slot. It is also popularly referred to as 30B + D.
The Universal Service Node (USN) supports a wide range of interfaces to connect with various communication systems and devices. These interfaces can be broadly categorized as network interfaces, user interfaces, and service interfaces.
Network Interfaces:
- Analog Interfaces: The USN supports analog connections through FXS (Foreign Exchange Subscriber) and FXO (Foreign Exchange Office) interfaces. These interfaces allow the connection of traditional analog phones and devices.
- TDM Circuits: The system supports TDM (Time Division Multiplexing) circuits, which can include technologies like T1 and ISDN PRI.
- SIP Trunking: The USN supports SIP (Session Initiation Protocol) trunking, enabling connections to IP-based PBXs and other VoIP systems. This allows the system to communicate with off-net users and integrate with modern VoIP systems.
- SIP Extensions: The system supports SIP extensions which enable the system to register SIP devices.
- Ethernet Switches: The system can scan ethernet switches for attached SIP phones and update a remote PBX with the new location of a phone if it is moved.
- Network Time Protocol (NTP): The USN can synchronize its local clock with an official time source using NTP.
- Simple Network Management Protocol (SNMP): The system supports SNMP versions V1 and V3, allowing the monitoring of system health using a remote network management system.
User Interfaces:
- Web Portal: The system is administered and accessed through a web portal. This portal uses WebRTC technology and can be customized with a company logo.
- RealView: This provides a real-time view of active conferences and mass notification services, allowing administrators and moderators to monitor and control sessions.
- Command and Control Station: A specialized web page that allows a user to monitor and manage multiple conferences simultaneously.
- Click-to-Call: This web based interface allows users to join a conference with a single click without needing an access code.
Service Interfaces:
- Audio Conferencing: The USN provides audio conferencing services, supporting MeetMe, dial-out, and web conferencing. The system supports features such as access codes, audio messages, and recording options.
- Web Conferencing: The USN supports web conferencing with collaboration tools such as screen sharing and whiteboards.
- Mass Notification: This service enables the sending of multimodal messages to large groups of people via voice, email, text, SMS, and pager.
- Remote Control: The system offers remote control services, allowing a moderator to take control of a participant’s computer for diagnostics and support.
- PBX Synchronization: The system can synchronize with a remote PBX to update phone locations or other data.
- LDAP Directory Interface: The system can use LDAP to integrate with corporate directory servers for remote authentication and to import users and groups.
Other Interfaces:
- Email Relay: The system can be configured with an email relay server to send outbound emails.
- Relays: The system can trigger relays for actions such as opening fire station doors or switching off equipment.
- Loop Extenders: The system can use loop extenders to increase the reach of connections up to 30,000 feet.
In summary, the USN supports a wide variety of interfaces enabling it to integrate with different types of communication systems, networks, and devices. The system’s adaptability and flexibility are a result of the broad range of interfaces it supports and this helps it to function in different environments and meet diverse user requirements.
The Universal Service Node (USN) is designed with several features that contribute to its scalability, allowing it to adapt to different organizational sizes and communication needs. Here’s a breakdown of the USN’s scalability aspects, as described in the sources:
Capacity for Endpoints: The system can support to analog or IP phone sets that are up to Cisco router capability, or a combination of both. This provides a substantial capacity for organizations of various sizes.
Geographical Reach: The USN’s reach can be extended with loop extenders, which allow connections up to 30,000 feet away. This is particularly useful for large facilities or campuses, allowing for the extension of service to distant endpoints.
Redundancy: The system can be configured with redundant RFCS (Ringdown Firebar Conference Server) systems. This means having a primary and secondary system in different locations, connected by a fiber network, to provide high availability. If the primary system fails, the secondary system automatically takes over, ensuring continuous operation without any noticeable disruption.
Network Scalability:
- The USN can connect to external networks using different types of circuit groups, including TDM, SIP trunk, SIP extensions and attached users, allowing integration with different types of networks and systems.
- The system supports both traditional and modern interfaces, including analog, FXS, FXO, BRI, and SIP, which allows for seamless integration with a variety of systems.
- The system’s ability to connect to a PBX via a SIP trunk allows for integrating off-net users, like cell phones, further extending the system’s communication reach.
Service Scalability: The USN is designed to handle multiple services concurrently, including:
- Audio Conferencing: The system supports MeetMe, dial-out, and web conferencing, and can handle multiple concurrent conferences.
- Mass Notification: The USN supports sending messages to large groups of people through multiple modes of communication (voice, email, text, SMS, pager). The system has parameters to manage concurrent calls and retries for uncontacted members.
- Click to Call: The system supports click to call to join conferences, or trigger dial-out conferences and mass notification sessions as well.
- Command and Control: The system provides a command and control interface to manage multiple conferences simultaneously.
Software and Licensing: The system’s software architecture is built to accommodate the addition of various platform extensions and value added services. The system also provides the ability to manage software updates, and upload new licenses, to support the scalability of the system over time. The licensing system also controls the maximum number of ports available for web and audio services.
User Roles: The system has multiple roles such as administrator, moderator and user. An administrator can create multiple moderators and users to support more users of the system and enable the management of resources.
Centralized Management: The system provides a centralized web portal for administration. This portal allows for managing users, services, and system properties, which is critical for scaling operations and provides flexibility and control over the entire system.
Integration Capabilities: The USN can integrate with other systems through LDAP (Lightweight Directory Access Protocol) for directory services and PBX synchronization, which enables the automatic detection of moving phones. This capability ensures that the system can adapt to changes in network infrastructure and user locations.
In summary, the USN’s scalability is multifaceted, encompassing user capacity, geographical reach, redundancy, network flexibility, service concurrency and centralized management. These features allow the USN to handle a wide variety of communication needs and grow with the organization. The ability to integrate with legacy systems, while also supporting modern IP-based technology, means the system can scale and transition at the required pace.
Notes: A USN can handle up to 16 T1 or E1 trunks per chassis. That equates to 384/480 voice channels. The available voice channels can enter/exit the system either over T1/E1 lines or over VoIP Ethernet interface or shared between the two. For example, following configurations are possible:
- 384 T1 TDM ports and 0 VoIP ports
- 480 E1 TDM ports and 0 VoIP ports
- 0 TDM ports and 480 VoIP ports
- 240 E1TDM ports and 240 VoIP ports
The Universal Service Node (USN) supports trunking interfaces to connect to external networks, using both traditional and modern communication methods. The primary methods for trunking are SIP trunking and TDM circuits.
Here’s a breakdown of the USN’s trunking interface support:
SIP Trunking:
- The USN can connect to a PBX via a SIP trunk, enabling communication with off-net users (e.g., cell phones) and integrating with modern VoIP systems.
- SIP trunk is one of four types of circuit groups that the USN uses to connect to external networks for both inbound and outbound calls.
- When a circuit group is configured, SIP trunk is an available option with specific parameters that must be set.
- A SIP trunk can be used to connect with an airport’s PBX.
TDM Circuits:
- The USN supports TDM (Time Division Multiplexing) circuits for connecting to external networks.
- The system’s network interface modules support analog, FXS, FXO, and BRI (Basic Rate Interface), which are compatible with TDM circuits.
- TDM is one of the four circuit group types that the USN can use, and has its own configuration parameters.
Circuit Groups:
- The USN uses circuit groups to manage connections to external networks for inbound and outbound calls.
- There are four types of circuit groups: TDM, SIP trunk, SIP extensions, and attached users.
- The circuit group type dictates the parameters that need to be configured.
Integration with Various Systems:
- The USN is designed to integrate with both traditional and modern systems, supporting both analog and IP phones. The system can support up to 2,500 analog or IP sets, or a combination of both.
- By connecting to a PBX using SIP trunks, the USN allows for a transition to an IP-based communication environment while maintaining compatibility with legacy systems.
Flexibility and Scalability:
- The system supports loop extenders to extend connections up to 30,000 feet.
- The USN’s multiple interfaces enable a phase transition to an IP-based environment, providing investment protection and reducing maintenance costs.
In summary, the USN provides versatile trunk interface support through SIP trunking for modern IP-based systems and TDM circuits for legacy systems. This allows it to integrate with diverse communication infrastructures and facilitates a transition to modern IP-based environments. The system’s support for different types of circuit groups enables it to effectively manage various types of connections.
You will need a bi-directional Tie trunk between the PBX and the USN.
Based on common industry practices and the information available about the USN’s trunking capabilities, here’s how these concepts can be understood and potentially applied:
NI-2 (National ISDN-2): The sources mention BRI (Basic Rate Interface), which is a type of ISDN (Integrated Services Digital Network) interface commonly used in TDM (Time Division Multiplexing) circuits. While not directly addressing NI-2, which is another ISDN standard, it can be inferred that if a PBX uses NI-2 it is likely that the USN would connect through its TDM interfaces. However, the focus of the sources is on SIP, so this is not the preferred method. It is important to note that NI-2 is a less common interface, with SIP being the current standard for PBX trunking.
User Side: In the context of ISDN, “User Side” refers to the interface on the customer’s premises, in this case the PBX. The USN could present either a user-side or network-side interface depending on the specific connection with a PBX using TDM circuits. However, with the focus on SIP trunking, this distinction becomes less relevant, as SIP is a peer-to-peer protocol.
DNIS (Dialed Number Identification Service): DNIS refers to the number that a caller dials to reach a specific service or department within the PBX. The sources do not explicitly mention how DNIS is handled. With a SIP connection, the dialed number is typically included in the SIP signaling as the “To” header or the Request-URI. The USN can use service selection rules, which are configured by the administrator, to route incoming calls based on source and/or destination numbers. This means that the USN could use the DNIS information to direct a call to a particular conference or service, as configured by the service selection rules. The service selection feature can automatically invoke a service without needing the caller to enter a service access code. The USN can also invoke different services by using source or destination numbers.
ANI (Automatic Number Identification): ANI refers to the caller’s phone number. The sources do not directly address ANI. With a SIP trunk, the calling party’s number is conveyed in the SIP signaling, usually in the “From” header. This allows the USN to identify the caller. The USN can use the ANI for multiple purposes, including:
- Caller ID Display: The system can display the caller’s number or name on phones equipped with a sidecar, helping identify who has joined a conference call.
- Access Control: The system can use the ANI to identify authorized users and allow access to specific services.
- Call Routing: The USN can use service selection rules based on the source number (ANI) to route incoming calls to different services, conferences or departments as needed.
- When setting up a dial-out conference, the moderator can set the caller ID to be the source number or to use the incoming call number.
Recommended Configuration: Given the emphasis on ISDN and T1, the recommended configuration for integrating with a PBX is:
- Service Selection Rules: Use the USN’s service selection rules to map incoming calls with specific destination numbers to appropriate services or conferences.
- ANI Utilization: Utilize the caller ID information (ANI) for identification, access control, and proper routing of calls within the USN system.
In summary, if ISDN and T1 trunking as the primary way to connect to a PBX. DNIS and ANI can be used in conjunction with the service selection rules for routing calls to specific conferences or services.
Voice over Internet Protocol (VoIP) interfaces for the Universal Service Node (USN) is primarily focusing on Session Initiation Protocol (SIP). Here’s how to configure VoIP interfaces for USN integration:
Prioritize SIP Trunking:
- The primary method for integrating the USN with modern telephony systems and PBXs is through SIP trunks. This is the preferred method as it offers flexibility, scalability, and integration with modern IP-based systems.
- A SIP trunk is a direct connection between the USN and a PBX or a service provider over an IP network.
- The USN can also connect with a SIP trunk to an airport PBX, which allows the system to call off-net users.
SIP Extensions:
- The USN supports SIP extensions for connecting IP phones.
- This allows for integration of modern IP phones with the system.
- The USN can scan a set of Ethernet switches for attached SIP phones.
Configuration of VoIP Interfaces:
- For SIP trunks, the USN will require configuration parameters that include:
- The IP address or hostname of the SIP server (e.g., PBX or service provider).
- The port number for SIP signaling.
- Authentication credentials (username and password).
- Codec settings.
- For SIP extensions, the USN will need to be configured to register the IP phones and manage their connections.
- The network settings of the USN must be configured correctly, including the hostname, IP addresses, domain name servers and time zone.
- An NTP server can be configured to synchronize the system clock.
- For SIP trunks, the USN will require configuration parameters that include:
Circuit Groups:
- The USN uses circuit groups to manage connections to external networks.
- When configuring a circuit group for VoIP, you must select either SIP trunk or SIP extensions as the circuit group type.
- Each circuit group type has its own specific parameters that need to be set.
Service Selection Rules:
- Service selection rules are used to route incoming calls to specific services based on the dialed number (DNIS) or calling number (ANI).
- These rules are set by the administrator.
- With VoIP interfaces, the DNIS information is typically found in the SIP signaling (To header or Request-URI).
- The ANI is conveyed in the From header.
- These rules can be set to automatically invoke a service without requiring the caller to enter an access code.
Integration with PBX:
- When integrating with a PBX, a SIP trunk connection is recommended.
- This allows the USN to leverage the PBX for routing, dial plan management, and off-net calling.
Redundancy:
- For critical systems, implement a redundant RFCS (Ringdown Firebar Conference Server).
- A secondary system will take over if the primary system fails.
- Both primary and secondary systems can be connected to the VoIP network.
WebRTC Technology:
- The system uses WebRTC technology, which allows users to communicate with the conference bridge using a browser rather than a phone.
- Click-to-call services utilize WebRTC to allow users to join conferences with a single click, without having to enter an access code.
Security:
- Implement enhanced security measures to protect the VoIP interfaces and the system.
- This may include using PINs for authentication, implementing strong password policies, and restricting administrative access.
Testing:
- After setting up the VoIP interfaces, conduct thorough testing to ensure proper connectivity and call quality.
- The system has a test phone capability that can be used to verify connections to individual extensions.
In summary, the recommended approach for configuring VoIP interfaces on the USN is to prioritize SIP trunking for integration with modern systems and PBXs. You should configure the necessary parameters for both SIP trunks and extensions; utilize service selection rules to route calls, and implement appropriate security and redundancy. The system can also use WebRTC technology to allow users to join the system using a browser, rather than a phone.
Notes: You will need a bi-directional SIP based Tie trunk between the PBX and the USN.
Inbound to USN: Set up a hunt group with number of channels equal to number of VoIP ports on the USN. For example, for a 48 VoIP port system set up a hunt group with 48 channels.
Outbound from USN: Calls originating from USN will be received by the IP PBX which in turn will route them to either internal extensions or to external PSTN numbers. The external connectivity to the PSTN can be via a TDM based T1 trunk or via a VoIP carrier.
To ensure the Universal Service Node (USN) is functioning correctly, several basic tests can be performed:
- Network Connectivity:
- Verify that the USN has the correct network settings, including IP addresses, domain name servers, and time zone.
- Ensure the USN is connected to the network and can communicate with other devices, like phones and computers.
- If an NTP server is configured, verify that the system clock is synchronized.
- System Status:
- Use the system status report to check the version numbers for the web and voice applications.
- The voice processor status field indicates if the voice application is running or stopped.
- Check the status of system resources, such as memory and disk usage.
- Phone Connectivity and Functionality:
- Analog Phone Test: For analog phones, verify that a call from the master phone triggers the system to call out to the different endpoints. Make sure that as endpoints answer the call, they are joined onto a multi-party conference.
- IP Phone Test: For IP Phones, use the RealView feature to observe if the phones register to the system. Verify that a call from the master phone triggers the system to call out to the different endpoints. Make sure that as endpoints answer the call, they are joined onto a multi-party conference.
- Sidecar Functionality: For phones with a sidecar, verify that the sidecar lights correctly indicate which stations have answered the call.
- Test Call: Use the test phone capability to call individual extensions and verify that two stations can talk to each other.
- Redundancy Test:
- For redundant systems, simulate a failure of the primary system by disconnecting it from the network or cutting its power.
- Verify that the system automatically re-homes all phones to the secondary system and that the system continues to function without any disruption.
- Once the primary system comes back online, check that the system re-homes all the phones back to the primary system.
- Conference Call Functionality:
- Initiate a conference call by having a user go off-hook on the master phone.
- Confirm that all stations are called and added to the conference as they answer.
- Verify that all participants can hear each other.
- Use the RealView to see the active conferences and participants.
- Check the quality of voice calls, mute/unmute participants, and disconnect users, using RealView.
- Alerting Network Functionality:
- For an alerting network, verify that pressing the mushroom button in the air traffic controller’s tower calls all stations and triggers strobes and PA systems.
- RealView Monitoring:
- Use the RealView function to monitor the status of phones, see which stations are being called and who is speaking.
- Verify that the RealView screen accurately displays the status of each phone (on-hook or off-hook) and the current conference.
- Confirm that the RealView display changes when a user goes off-hook to initiate a call.
- Audio Quality:
- During a conference call, evaluate the audio quality to ensure it is clear and without excessive echo or noise.
- The system has a function that allows the user to test their laptop or mobile audio and video services.
- Click-to-Call Functionality:
- Test the Click-to-Call service by clicking on the call button, and verify that an audio call is made to the bridge. Confirm that the user is placed in the conference based on the predefined parameters.
- Ensure that the audio quality status is visible.
- Emergency Phone Functionality:
- Verify that the emergency phone cannot be used as a regular phone by picking it up and listening to the message, “This is an emergency phone only. Please hang up immediately”.
- System Administration Portal:
- Access the administrator portal using the assigned URL.
- Verify that the administrator can manage system properties, set up user profiles, and define services.
- Confirm that the administrator can monitor platform and application performance through real-time monitoring and reports.
- Email Relay:
- Verify the email relay server by sending a test email from the email relay configuration page.
By performing these basic tests, you can ensure that the USN is functioning correctly and ready for use. These tests should verify that the core functions of the USN are working correctly.
Notes: If you dial the main bridge number and hear a prompt requesting you to enter a PIN, the system’s voice application is in operational state.
If you can log into the system that means all networking aspects between your computer and the USN server are operational.
The USN system automatically generates several reports that provide details on service instances, system performance, and usage. These reports are accessible through the web portal and can be used to monitor and manage the system effectively. Here are some of the specific reports that are generated automatically:
- Service Specific Reports: These reports offer detailed information about individual service instances. For example, a report might provide details on a specific conference, such as its duration, the participants involved, and any recordings made. These reports can help in understanding the usage patterns of different services and provide insights into how they can be optimized.
- Conference Recording Reports: This report lists recordings associated with different conferences and provides links to the recording files. This report is useful for accessing and managing conference recordings.
- System Status Report: This report provides a snapshot of the current system health and performance. Key elements of this report include:
- System Version: This displays the version numbers for both the web application and the voice application. This can be helpful in ensuring that all components of the system are up-to-date.
- Voice Processor Status: This shows whether the voice application is currently running or stopped. If the voice application is not running, the system will not perform as expected.
- Web Login Attempts: This shows the number of invalid web login attempts and locked web accounts. This information is useful for identifying and mitigating security risks.
- Resource Usage: The report details the status of various system resources, such as memory usage (including swap space and memory oversubscription), and disk usage (showing the usage level of various disk partitions). Monitoring resource usage is critical for preventing performance issues.
- Software Services State: This indicates whether each service is running or not. If a service shows a failed state, customer support should be contacted.
- Hard Drive Details: This section shows the drive details of the system.
- Network Port Status: This section shows the speed and state of each network port.
- System Events Report: This report provides a log of system events that have occurred. Each entry includes:
- ID: A system-generated number to identify the event.
- Date and Time: When the event occurred.
- Source: The IP address of the device where the event originated.
- Account: The moderator ID of the user associated with the event.
- Event Description and Details: A textual explanation of what occurred.
- The events can be filtered by specifying a search criteria.
- Current Logins Report: This report displays all the accounts that are currently logged into the web portal. It includes the following details for each logged-in user:
- Company Name: The name of the company associated with the account holder.
- User Name: The name of the logged-in user.
- IP Address: The IP address of the browser used to log in.
- Sign-in Time: The time at which the user signed into the web portal.
- Last Action Time: The last time the user performed an action within the system.
These reports are valuable tools for administrators and moderators to manage, monitor, and troubleshoot the system. They provide insights into usage patterns, system performance, and potential issues, enabling timely and effective management.
Notes: The system automatically generates a usage and system health report every midnight. It captures previous day’s usage data. The report also tabulates month to date and year to date reports. These reports give sufficient information to the administrator so that he/she can determine if additional capacity is needed. In addition to the usage report, data is provided on the status of various components of the system such as Hard disk drives, Operating system etc.
When the USN system reaches its maximum license capacity, it will deny additional calls or service requests. This situation can arise when the system’s resources, particularly the number of available ports for audio and web services, are fully utilized. Here’s a breakdown of what happens and how to manage it:
Denial of Service: When the system’s licensed capacity is reached, any new call attempts or service requests that would exceed the limit will be denied. This means users trying to join a conference or initiate a mass notification may not be able to connect. This could affect a range of services, including:
- Audio Conferences: New participants might be unable to join an ongoing conference.
- Dial-out Conferences: The system might fail to dial out to all intended recipients.
- Mass Notifications: The system may not be able to send notifications to all intended recipients.
- Click-to-Call: Users attempting to connect via click to call may be unable to reach the conference.
- Remote Control Sessions: New remote control requests may be rejected.
Impact on Users: The immediate impact is that users will not be able to access the services they require. This could mean:
- Missed Meetings: Participants unable to join conferences.
- Delayed Communication: Emergency alerts or notifications may not reach recipients.
- Disrupted Workflow: Users may be unable to use the system for tasks that require its conferencing or notification services.
Monitoring and Identification:
- RealView: The administrator can see in real-time active conferences and mass notification services. This visual assessment can help the administrator identify when the system is close to capacity and if new services cannot be started.
- Licensing Page: This page shows the maximum number of ports for web and audio services. If the system is frequently hitting this limit, it’s an indicator that more licenses are needed.
- System Events Report: This report shows details of system events that can help identify issues when the system is unable to cope with the load due to reaching capacity.
- Service Specific Reports: These reports provide details of service instances and can help identify if the number of service instances are frequently reaching licensed limits.
Managing the Situation:
- Immediate Action: If the system denies new calls due to reaching the license limit, the administrator can take immediate steps to mitigate the problem. This may include:
- Terminating unnecessary conferences: The administrator can use the real view feature to terminate ongoing conferences, freeing up ports to accommodate new calls.
- Prioritizing essential services: If certain services are more critical, the administrator may need to prioritize these over other less essential services.
- Long Term Solution
- Add Licenses: The most effective solution is to add more licenses to increase the system’s capacity. This will allow the system to handle a larger number of concurrent calls and service requests.
- Optimize Usage Patterns: The administrator may also investigate ways to optimize how the system is being used. For example, adjusting call durations, scheduling conferences during off-peak hours, and optimizing notification settings can help to reduce the load on the system.
- Immediate Action: If the system denies new calls due to reaching the license limit, the administrator can take immediate steps to mitigate the problem. This may include:
Licensing and System Capacity: The licensing page displays the maximum number of ports for web and audio services. When the system denies additional calls because it has reached its maximum capacity, it indicates that the current licensing agreement does not allow for additional services. The system is designed to enforce these limits and will reject requests that exceed them.
Communication: If the system has denied calls, the administrator will need to communicate with end-users to let them know that the system was at capacity.
In summary, when the USN system reaches its licensed maximum, it will deny new service requests, potentially disrupting communication and workflows. The administrator should monitor the system using tools such as RealView, system status reports, and licensing information to anticipate when to add more licenses to prevent service denial, and implement operational strategies to minimize downtime and maintain service quality.
Note: Different businesses have peaks at different times. The administrator can watch all calls on the Real View link. Visually, he/she will be able to tell if the system is running close to its maximum capacity or not. With Release 5.0, the USN will also provide a histogram that displays number of ports in use by the hour.