MITEL MIVOICE BUSINESS ENGINEERING GUIDELINES MITEL MIVOICE BUSINESS RELEASE 7.
NOTICE The information contained in this document is believed to be accurate in all respects but is not warranted by Mitel Networks™ Corporation (MITEL®). The information is subject to change without notice and should not be construed in any way as a commitment by Mitel or any of its affiliates or subsidiaries. Mitel and its affiliates and subsidiaries assume no responsibility for any errors or omissions in this document.
Table of Contents Chapter 1: About This Document Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 About Mitel MiVoice Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 What’s New in this Release? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Engineering Guidelines AX Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 AX Controller ONS port limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 CX/CXi Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 CX II/CXi II Controller . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents Cordless (DECT) Handset and Headset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Installation Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Coverage and Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Engineering Guidelines Options for IP Phone Powering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 AC Power adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 In-Line Ethernet AC power adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 In-Line Gigabit Ethernet AC power adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents Chapter 8: Emergency Services Emergency Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Location Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Teleworker devices . . . . . . . . . . . . . . . . . . . .
Engineering Guidelines Chapter 10: Licensing System Licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Device Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Licensing Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Licensing Example . . . . . . . . . . .
Table of Contents Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Echo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Engineering Guidelines Chapter 13: Network Configuration Specifics Network Configuration Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Start-Up Sequence and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Startup Sequence for Phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 NetBIOS and PC Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Wireless Phone Performance on the 3300 ICP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 SpectraLink wireless phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Engineering Guidelines IP Address Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 Cables and Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Cable types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Ethernet cable distances . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table of Contents Appendix C: LLDP and LLDP-MED Configuration Examples LLDP, LLDP-MED Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 LLDP-MED advertising information determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Quick Start – Getting LLDP-MED Running Quickly . . . . . . .
Engineering Guidelines Dual Port Phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Devices that support 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Worm and virus protection . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHAPTER 1 ABOUT THIS DOCUMENT
About This Document Overview These guidelines will assist you in planning an installation of a 3300 IP Communications Platform. The guidelines describe specific areas of the product that need to be considered before installation. Also, field experience highlights specific areas that might not have previously been covered. These guidelines should not be considered as a comprehensive list, but as useful reminders or pointers that should be considered before installation.
Engineering Guidelines • Updated IP port usage (Table 80 on page 272) • Clarified bandwidth requirements for SRTP encrypted voice streams (page 339). Engineering Guidelines for older releases can be found in the Legacy/Older Products section on the Note: Information specific to Releases prior to MCD 6.0 that has been superceded by changes in the current release, or that is no longer relevant for other reasons, has been removed from this document.
About This Document • Current Product Briefs: Notes on current releases • White Papers: Reliability (MTTF and MTBF) and Availability information 5
Engineering Guidelines System Management Tools The System Administration Tool, the Group Administration Tool and the Desktop Tool are GUI based tools for configuring and administering MiVoice Business and MiVoice IP Phones. The System Management Tools are accessed via an internet browser. For MCD Release 6.0 Internet Explorer (IE) Version 8.0 is supported, other web browsers (such as Firefox, Navigator, Google Chrome) are not supported. For MiVoice Business Release 7.
CHAPTER 2 SYSTEM OVERVIEW
System Overview System Architecture The 3300 ICP is built upon Mitel’s Data Integrated Voice Applications™ architecture delivering sophisticated call management, applications and desktop solutions to businesses. Mitel delivers a highly scalable, resilient, and robust call control that fully utilizes the power of IP while fully supporting the traditional TDM-based telephony for legacy devices and PSTN connectivity.
Engineering Guidelines MiVoice Business Controller The MiVoice Business controller provides the voice, signalling, central processing, and communications resources for the system. There are several controller configurations supported for release MiVoice Business 7.
System Overview Supported Countries During the installation process the MiVoice Business system can be configured for operation in a particular country or region. The Embedded System Management interface (ESM) allows the installer to choose the most appropriate country or region from a list of supported countries and regions.
Engineering Guidelines 12
CHAPTER 3 TYPICAL CONFIGURATIONS
Typical Configurations System Configurations The MiVoice Business product line includes a number of platforms, IP phones, and applications. Each platform is designed for a different business segment and size, but each contains a number of common components. The main difference between the units is the quantity of components contained in each.
Engineering Guidelines Typical Installation Configurations The MiVoice Business platorm can be designed into different network configurations to suit the organization of the enterprise.
Typical Configurations possesses the group controller and local phones, but the PSTN access is in a separate secure building. A different scenario is a large enterprise with corporate headquarters in different cities. Each would have distributed trunk units and could be considered multiple copies of the campus scenario.
Engineering Guidelines Hybrid System A Hybrid system combines both of the previous scenarios and involves a distributed system for a headquarters and combined units for remote branch offices. The branch office has access to corporate PSTN access as well as local access through the local group controller. In the event the WAN link is lost, the separate sites can still operate as independent units.
Typical Configurations Sample 3300 ICP Configurations The sections below describe sample configurations: • “The 3300 ICP as a Trunk Gateway” on page 19 • “The 3300 ICP as a Trunk Tandem” on page 20 • “MiVoice Business, 3300 ICP and ACD” on page 20 • “The 3300 ICP as a Dedicated Voice Mail Server” on page 29 The 3300 ICP as a Trunk Gateway If the 3300 ICP is used as a trunk gateway, the unit will act purely as a TDM-to-IP gateway. It will not have IP phones registered.
Engineering Guidelines The 3300 ICP as a Trunk Tandem When the 3300 ICP acts as a Trunk Tandem, it functions similar to that described for the gateway unit. Typically, this configuration is applied where there is already an established (TDM) PBX network where the ICP units are being used for toll-bypass, or as an alternative route to the PSTN. As with the gateway unit, the 3300 ICP does not have end users directly connected.
Typical Configurations RAD sources may be embedded (using the voice mail and/or music ports) or off-board (for example, Mitel Contact Center Intelligent Queue). In the networked configurations, the RAD playback and distribution should be located on the trunk gateway. • • • • Embedded RAD in 3300 ICP (TDM source) - RAD plays directly into the TDM switch fabric (no E2T channels used). - RAD stream is connected directly to n output channels for TDM trunks (no E2T).
Engineering Guidelines The MiVoice Business systems do NOT support: • Traditional agents and Hot Desk agents active on the same system • Traditional agents and Hot Desk agents directly or natively logged into SIP or Analog endpoints (directly connected to the system, or via a MiVoice Border Gateway) Standalone ACD Controller Smaller ACD installations will use a single controller with all trunks, agents, groups and paths on it.
Typical Configurations Network ACD Controllers For large installations, splitting the system into multiple nodes allows a higher capacity in terms of both agents and trunks. This also allows for resiliency between two (or more) agent controllers. This configuration is shown in Figure 7. Here the calls enter from the PSTN on the trunk gateway(s), are routed to the IVR system, and are queued to paths on those gateways which in turn queue to groups on the agent controllers.
Engineering Guidelines Basic Call Center • Trunk to agent ratio is 1.5 (lower trunk ratios will allow increased system capacity, at the expense of more rejected (busy tone) calls). • Traffic per agent is at 27 CCS and 120 sec call handling time, i.e. 30 CPH per agent. • No Mitel Contact Center Solutions used to provide call handling and reporting. • There is no IVR system handling incoming calls, thus calls will ring directly to the path(s).
Typical Configurations Advanced Call Center • Trunk to agent ratio is 1.5 (lower trunk ratios will allow increased system capacity, at the expense of more rejected (busy tone) calls). • Traffic per agent is at 27 CCS and 120 sec call handling time, i.e. 30 CPH per agent. • Mitel Contact Center Solutions 6.0 is used to provide call handling and reporting. • There is an IVR system handling incoming calls.
Engineering Guidelines In the standalone configuration, adding more groups for the agents or allowing overflow on the paths will both add a processing load for each call, and will therefore reduce the capacity of the system. In the networked configuration, the agent controller has been relieved of the processing load for the IVR, so the nominal call capacity increases significantly from that of a standalone system. Multiple agent groups and path overflows still affect this node and reduce its capacity.
Typical Configurations Active agents vs. traffic The maximum number of agents shown in the above tables is based on each agent handling an average of 30 CPH, corresponding to an average total call handling time (CHT) of 120 seconds, including work timer. If the call traffic is a different rate, the number of active agents that can be supported on a controller will change. The following tables show typical numbers for several representative configurations.
Engineering Guidelines Table 6: Active Agents on MXe-III Agent Controller Agents CHT (sec) CPH CPH/agent 100 120 3000 30 150 180 3000 20 200 240 3000 15 250 300 3000 12 300 360 3000 10 Local agents vs. EHD agents As stated previously, when EHDA is used for some or all of the agents, the total number of agents that can be supported on a controller is reduced.
Typical Configurations Figure 8: Example of Local vs. EHD Agents on ISS Agent Controller The 3300 ICP as a Dedicated Voice Mail Server The 3300 ICP can be used as a dedicated voice mail server with or without additional end devices attached. When used as a dedicated voice mail server, the ICP provides up to 30 channels for continuous use. Connections to voice mail can be made with or without using compression. This is selectable during configuration.
Engineering Guidelines When determining network bandwidth, consider voice mail sessions as being active 100% of the time. The number of voice mail sessions determines the bandwidth required. With G.711 voice streams and 30 active sessions, a minimum of 4.0 Mbps must be provided: (30 x 96.8 kbps + 10% (signalling)) / 80% = 4.0 Mbps Where the unit is used as a dedicated voice mail server, consider the number of other functions provided on the box.
Typical Configurations MXe Server, Virtual MiVoice Business, MiVoice Business for ISS, and MiVoice Business Multi-instance Note: Other limits besides those in the following table may apply to Virtual MiVoice Business and MiVoice Business for ISS depending on the deployment. Consult the Virtual MiVoice Business and MiVoice Business for ISS Engineering Guidelines for more information.
Engineering Guidelines Table 8: Maximum MXe Server / Virtual MiVoice Business / MiVoice Business for ISS / MiVoice Business Multi-instance configuration (continued) Feature / Resource Value / Quantity Notes Voice Mail 0 Voice mail must be an external application on MXe Server and MiVoice Business for ISS. Compression channels 256 G.729a compression is not a standard offering on base systems. Additional DSP resources are needed to achieve the value shown in the MXe Server.
Typical Configurations AX Controller Table 9: Maximum AX configuration Feature / Resource Value / Quantity RTC processor 450 MHz E2T processor N/A Memory (RAM) 512MB IP Users and Devices (including SIP users) 100/300 Maximum IP devices or users. The lower number of devices/users can be supported on any system at normal office traffic. The larger number can be supported on a system with 512MB of memory and only at reduced traffic (2-3 CCS) in hospitality applications.
Engineering Guidelines Table 9: Maximum AX configuration (continued) Feature / Resource Value / Quantity Notes MMC modules (installed slots) Quad DSP (int, ext) Echo Canceller (int, ext) Dual T1/E1 (ext) T1/E1 Combo (ext) Quad BRI (ext) Dual FIM (ext) DSP II (int, ext) Modules may be installed in the internal or external locations as shown. Digital links 2 Peripheral cabinet 0 Not supported. R2 NSU 2 Up to two R2 NSUs. Other types of NSUs are not supported.
Typical Configurations CX/CXi Controller Table 10: Maximum CX/CXi configuration Feature/ Resource Value/Quantity Notes RTC processor 266 MHz This processor is listed as 300 MHz in the Engineering Tool. Memory (RAM) 512 MB IP Users and Devices (Including SIP Users) 100 Up to 16 IP devices may be connected directly to the powered Ethernet ports on the front of the CXi cabinet. Maximum 100 IP users. TDM Devices 150 ONS devices only. DNIC devices are not supported on the CX.
Engineering Guidelines Table 10: Maximum CX/CXi configuration (continued) Feature/ Resource Value/Quantity Notes MMC modules (installed slots) Dual DSP (3) Quad DSP (3) The CX is the only member of the 3300 ICP family that uses the Dual DSP module. DSP II (2,3) T1/E1 Combo (1,2) Quad BRI (1,2) Quad CIM (1,2) Note that the Dual FIM and the Dual T1/E1 modules are NOT supported on the CX.
Typical Configurations CX II/CXi II Controller Table 11: Maximum CX II/CXi II configuration Feature/ Resource Value/Quantity Notes RTC processor 400 MHz This processor is listed as 450 MHz in the Engineering Tool. E2T processor N/A The CX II uses a single processor for both RTC and E2T functions. Memory (RAM) 512 MB Expandable to 1024 MB IP Users and Devices (Including SIP Users) 150 Up to 16 IP devices may be connected directly to the powered Ethernet ports on the front of the CXi cabinet.
Engineering Guidelines MXe Controller Table 12: Maximum MXe configuration Value/Quantity Feature/Resource Notes Base MXe RTC processor 450 MHz E2T processor Memory (RAM) Expanded 450 MHz The base MXe uses a single processor for both RTC and E2T functions. See Note, below. 450 MHz Optional, to increase capacity. The two processors operate independently, one as RTC and the second as E2T.See Note 1 512 MB IP Users and Devices (Including SIP Users) 300 1400 Maximum 300/1400 IP users or devices.
Typical Configurations Table 12: Maximum MXe configuration (continued) Value/Quantity Feature/Resource Notes Base MXe Compression channels Expanded 64 192 G.729a compression is not a standard offering on base systems. Additional DSP resources are needed to achieve the values shown. Compression is added in block of 8 bi-directional channels on Quad DSP modules and DSP II modules only. T.
Engineering Guidelines Note: The MXe III has an improved processor card in both positions (533 MHz CPU with DDR2 memory). This does not increase any of the allowed maximum values on the controller, but does permit more features to be combined at higher performance levels. Refer to the System Engineering Tool for detailed performance evaluations on this (or any other) controller.
Typical Configurations LX Controller Table 13: Maximum LX configuration Feature/ Resource Value/Quantity Notes RTC processor 450 MHz E2T processor 450 MHz Memory (RAM) 256 MB / 512 MB Prior to release 6.0, all LX systems used 450 MHz processors with 256 MB of memory. From release 6.0 the RTC module uses 512 MB of memory. Memory and core speed are displayed in the Hardware Compute Cards form in the System Administration Tool. Minimum of 512MB RAM and 450MHz is required.
Engineering Guidelines Table 13: Maximum LX configuration (continued) Feature/ Resource Value/Quantity Notes CIM ports 4 These ports may be used to connect ASU cabinets only. ASU supported 4 LS trunks (in ASU) 16 (32) Up to four Universal ASUs may be added with 4 LS trunks each. Four ASU II cabinets can support 8 ONS/LS cards for a total of 32 LS trunks. Additional LS trunk cards may be added in peripheral cabinets.
Typical Configurations Other Maximum Limits Table 14: Feature/ Resource Value/Quantity Other Maximum Limits Notes 5230/5235/5320/5330/53 1000 40/5360/Navigator IP 3000 (MXe Server) phones These devices may be configured up to the maximum of the value shown or the number of IP devices allowed on the system, whichever is less. The 5230 is not supported on the MXe Server. 5140/5240 IP Appliances 100 The maximum number of IP appliances is limited by the internal web server.
Engineering Guidelines Table 14: Other Maximum Limits (continued) Feature/ Resource Value/Quantity Device Campons per system 172 Group Campons per system 84 Hard Holds per system 312 Notes 480 (MXe Server) 240 (MXe Server) 870 (MXe Server) Wake-up Calls in 1 minute 100 Wake-up Calls in 5 minutes 400 213 (MXe Server) 852 (MXe Server) Page 2 of 2 SIP Phones and use of TLS (SIP-TLS) The use of TLS (Transport Layer Security) places additional requirements on the MiVoice Business systems (MiV
Typical Configurations For deployments with more than 100 nodes in a cluster where SIP-TLS will be deployed, it is highly recommended that Professional Services be contacted to get a more specific value on location and quantity of SIP-TLS devices per node. Use of SRTP SRTP allows voice encryption between Mitel and supported third party devices.
Engineering Guidelines Table 16: Music and Paging Limits Controller Type Music or Paging Limit MXe expanded, LX, and MXe Server 64 MiVoice Business for ISS, MiVoice Business Multi-instance, Virtual MiVoice Business 100 Note: In the CX/CXi and AX systems the number of available echo cancellers might be less than the numbers shown here, depending on the specific combination of modules installed.
Typical Configurations Table 17: Device and User Limits Active System Type Limits CX/CXi CX II/CXi II AX MXe Base MXe Exp MXe Server Total Devices 150 150 575 350 1500 5000 IP Devices (Note 1) 100 150 300 300 1400 5000 53xx Display Sets (Note 2) 100 150 300 300 1000 5000 (Note 4) SIP Sets (Note 3) 100 150 300 300 1000 3000 ONS (licensed) 150 150 288 192 576 0 ONS (peripheral cab) 0 0 0 768 1152 0 ONS (extended per) 0 0 0 1536 2304 0 Analog Trunks 3
Engineering Guidelines HTML Applications on Sets Certain MiVoice IP Phones use the Switch Application Communications (SAC) protocol which is a protocol that is used by IP phones to support graphics-based software applications. Phones that employ SAC present more of a processing load to the ICP or MiVoice Business than phones that do not use the SAC protocol.
Typical Configurations Upgrading the System There are two reasons to upgrade a system – to increase the line size or to improve performance. With Mitel the network is the system, so it can also be expanded (and resiliency added) by adding more controllers into a clustered "virtual system". Individual controllers can be upgraded as shown below, or new controllers can be added into a cluster to create a larger virtual system.
Engineering Guidelines Provisioning System Resources The table below shows the capacity of each system in its factory default configuration, with no additional MMC modules or other upgrades purchased. Notes: 1. No compression is possible in the base configurations. 2. The AX must have a 4GB flash card installed to support Voice Mail.
Typical Configurations CX Hardware Configurations In addition to the two devices installed on the main board, DSP resources may be added to a CX system using the Dual DSP Module (2 devices), the Quad DSP Module (4 devices), or the T1/E1 Combo Module (1 device). The Combo module also adds a 32-channel hardware echo canceller. On system start-up, the system assigns the various DSP resources configured on the system as illustrated in Table 20 above.
Engineering Guidelines . Table 20: Maximum CX Feature Availability Without DSP II Lines Trunks DSP Usage # System Hardware Configuration1 IP ONS LS T1/E 1 0 Base 24 8 12 Base + 1 T1/E1 Combo 64 8 12 40 24 64 D S 1 P 3 4 5 6 7 E C H O G.
Typical Configurations Table 21: Maximum CX Feature Availability With DSP II Lines Trunks DSP Usage # System Hardware Configuration IP ONS LS T1/E 1 0 Base + Dual DSP + DSP II + Quad CIM 100 150 28 Base + Quad DSP + T1/E1 Combo + Quad CIM 100 150 28 Base + DSP II + 2 T1/E1 Combo 100 8 D S 1 P 3 4 5 E C H O G. 7 2 9 T.
Engineering Guidelines Programmable Keys Each phone (or hot desk user) has a number of pre-allocated programmable keys associated with them. When these devices, or users, are made resilient to other nodes, data for these keys has to be shared. Before MiVoice Business 7.0 there was a limit of 150,000 keys that could be synchronized from an SDS sync master to its slave(s). For example, a 5330 phone has 24 keys allocated to it.
Typical Configurations Table 22: Programmable Key Capacity by Device Type Phone Type Programmable Keys 5330e IP 24 5340 IP 48 5340e IP 48 5360 IP 48 5401 IP N/A 5505 SIP 6 5560 IPT 96, or 192 (See Note below) 5603 SIP 2 5604 SIP 2 5607 SIP 2 5610 SIP 2 5624 SIP 2 Generic SIP 96 Navigator 24 NetVision N/A UC Endpoint 8 Superset 4001 N/A Superset 401 N/A Superset 4015 7 Superset 4025 14 Superset 410 6 Superset 4125 14 Superset 4150 14 Superset 420 12 Superset
Engineering Guidelines Table 22: Programmable Key Capacity by Device Type Phone Type Programmable Keys OpenPhone 26/27 14 SpectraLink NetLink 14 Telematrix 3000IP 12 Page 3 of 3 Note: The default number of programmable keys on the 5560IPT is 96 keys. This can be increased to 192 keys with a license selection. This can only be applied to a system that is configured with up to 700 users. Provisioning for Traffic All 3300 ICP controllers contain an internal TDM switching fabric.
Typical Configurations • Call volume is typically split in thirds, with 33% incoming from trunks, 33% outgoing to trunks, and 33% handling internal calls (50% is making calls and 50% receiving calls). • For normal users, typically one voice mail session is needed for 20 users. Modify this number accordingly if you expect heavier or lighter voice mail traffic per user. • Typically, ACD workers are busy 75% to 100% of the time.
Engineering Guidelines 58
CHAPTER 4 PHONES AND VOICE APPLICATIONS
Phones and Voice Applications MiVoice IP Phones The 3300 ICP supports the following MiVoice IP Phones: • the 50xx, the 52xx, and the 53xx range of IP phones • the 5330 and 5340 display phones, the 5312 and 5324 IP Phones, the 5302 IP Phone, the 5304 IP Phone, the Navigator, the TeleMatrix IP3000, and the 5540 and 5550 IP consoles • the 5560 IPT, which is only supported on the MXe ICP, the CX/CXi II ICP, the MXe Server and all other server variants Note: The MXe Server and other MiVoice Business server
Engineering Guidelines 5560 IPT Limits The 5560 IPT is supported on three platform types, the CX/CXi II, the MXe (both the MXe II and MXe III expanded versions), and the MXe Server (and all commercial servers, including MiVoice Business for ISS and Virtual MiVoice Business). Because of the typical use of this device, in an extremely high traffic environment, there are restrictions on the number of these appliances which can be deployed on the various systems.
Phones and Voice Applications Table 23: Impact of Shared Line Appearances and Traffic Rates on Number of 5560 IPT Supported Controller Type Number of sets (users) Shared Line Appearances CPH per user Equivalent Call hold time (sec) 8 16 50 72 8 4 100 36 8 0 150 24 CX II Phones Supported on the AX All phone sets are supported on the AX platform; there are no software restrictions on provisioning sets on the AX.
Engineering Guidelines The Micro Firewall will filter the packets and allow bursts up to the “credit” limit shown above. After a protocol type has exhausted its credits with a burst that reached the prescribed limit, the credits are added back at prescribed rates. For instance, the Micro Firewall may allow up to 50 ICMP packets in a burst, then discard any additional ones that arrive before the Micro Firewall will begin adding credits at the rate of 5 a second.
Phones and Voice Applications Accuracy can be achieved using a Stratum 3 clock source (± 4.6 ppm), which is standard on all 3300 controllers. DECT RFP units with IP connection use their own internal reference clocks. Because local synchronization takes place between these units directly, the requirements on the ICP are not as critical. Refer to “RFC 3942, reclassifying DHCP options: DeTeWe and Spectralink Phones” on page 239 for information regarding DECT phones and DHCP.
Engineering Guidelines Table 25: Phone Stand Support (continued) Phone Gigabit Ethernet Stand Support WLAN Stand Support IP DECT Stand Support 5212 Yes Yes No 5215 No No No 5220 Dual Mode Yes Yes No 5215 Dual Mode Yes Yes No 5220 No No No 5224 Yes Yes No 5230 No No No 5235 Yes Yes No 5302 No No No 5304 No No No 5312 Yes Yes Yes 5324 Yes Yes Yes 5320 Yes Yes Yes 5320e Not Applicable Yes Yes 5330 Yes Yes Yes 5330e Not Applicable Yes Yes 5340
Phones and Voice Applications Gigabit Ethernet Phone Stand The Gigabit Ethernet Phone Stand allows a 5200/5300 series IP phone to be interfaced to a Gigabit Ethernet LAN. Details on the Gigabit Ethernet Phone Stand can be found in the Gigabit Ethernet Stand Installation Guide and in the Mitel Wireless LAN Stand Configuration and Engineering Guidelines on Mitel Online. 1000 Base-T or Gigabit Ethernet must be run on Category 5 or better cabling plant.
Engineering Guidelines Cordless (DECT) Handset and Headset The Cordless (DECT) Handset and Headset are supported on the 5330, 5340 and 5360 IP phones. A Cordless Module must be installed in the back of the IP phone to allow operation with the Cordless Accessories. For details see the Cordless Module and Accessories Installation Guide for Mitel 5330, 5340 or 5360 IP Phones available at Mitel OnLine.
Phones and Voice Applications Table 26: Cordless Module and Accessory Part Numbers Description Mitel Part Number Part Marking Standard DECT Cordless Module 56008567B 56008567B DECT 6.0 Cordless Module 56008567A 56008567A Standard DECT Handset 56008564B 56008564B DECT 6.0 Handset 56008564A 56008564A Standard DECT Headset 57008904 100-79330049-00 DECT 6.0 Headset 57008905 100-79330059-00 See http://www.dect.org to determine which variant is appropriate for the country of operation.
Engineering Guidelines Note: RF energy will travel through floors and ceilings. This can affect deployment density and performance. When planning an installation across multiple floors, interference from adjacent floors must be taken into account. Typical operating range Based on the building material and the number and type of obstructions within the operating space, you can roughly calculate the coverage area for an individual Cordless Module.
Phones and Voice Applications RF Site Survey For installations that call for only a small quantity of cordless accessories a simple trial and error test with the actual cordless accessories might be sufficient to ensure satisfactory operation.
Engineering Guidelines MiCollab Client and MiCollab Client Softphone Access Connections MiCollab Client and MiCollab Client Softphone use a number of access connections to both the MiVoice Business (or ICP) controller and to a MiCollab Client server.
Phones and Voice Applications Networking Considerations for MiCollab Client The MiCollab Client Softphone is an application that runs on the PC on which it is installed. This means that the Mitel-only DHCP options (e.g. VLAN, DSCP) are not available to the application. UCA Version 3.1 (SDK Version 1.2) does not provide support for 3300 SIP trunking. MiCollab Client incorporates a MiAudio softphone.
Engineering Guidelines Networking Considerations for MiVoice Business Console The MiVoice Business Console is an application that runs on the PC on which it is installed. This means that the Mitel-only DHCP options (e.g. VLAN, DSCP) are not available to the application. The MiVoice Business Console incorporates a MiAudio softphone. For details regarding MiAudio refer to the document called Mitel Universal SDK, Installation and Maintenance Guide Release 1.2. As of SDK Version 1.
Phones and Voice Applications Some of the connection paths and limitations are shown in Figure 9 and tables below. In analyzing the resources used by the different telephones, they can be grouped into a limited number of categories. All single line and older multi-line sets can be treated the same as the 5220 (including 5215, 5212, and 5224). The 53xx display sets are all similar in their resource requirements (also includes 5230, 5235 and Navigator) and more than 52xx devices.
Engineering Guidelines Table 29: (continued)ICP Connections (continued) Resource Telephone or Application MiNET Sockets SAC Sockets MiTAI Sockets MiTAI Monitors MiVoice Business IP Connections 1 per device 1 per device 1 per system (via internal SAC server) 1 per device 2 per device (MiNET & SAC) 5304/5312/5324 (without attached application) 1 per device 1 per device None None 2 per device (MiNET & SAC) 5304/5312/5324 (with attached application) 1 per device 1 per device 1 per system (v
Phones and Voice Applications Most external applications emulate 5220 sets and require similar resources when they connect to the 3300 ICP. They will also use sockets and place monitors on the users’ sets, similar to the MiCollab Clients and server in the above tables. The UC Express application connects to the phone for access to call control. All of the UC Express supported phones have a SAC connection, but may not invoke a monitor.
Engineering Guidelines Table 30: ICP Connections to External Application Servers (continued) Resource Application Maximum ports per ICP Maximum ports per server 1 per server (Mitel OIG) Limited by Mitel OIG sockets and monitors Application specific 1 per hot desk phone per link, 1 per user per link, 4 in total 2 per application server (2 MiTAI) Limited by MiTAI sockets and monitors Application specific 1 per monitored device 1 per application server (MiTAI) Limited by MiTAI sockets and monitors
Phones and Voice Applications Table 30: ICP Connections to External Application Servers (continued) Resource Application Unified Communicator Mobile Server MiNET Sockets MiTAI Sockets MiTAI Monitors Total IP Sockets 1 per port (see Note) 1 per system 2.4 per port (see Note) 1.
Engineering Guidelines an additional 500 sockets for these internal services. The System Engineering Tool counts socket usage for internal and external devices, and it is recommended to use this tool, especially if the calculations from the tables plus overhead suggest that a limit will be reached.
Phones and Voice Applications Table 31: Application Socket Limits for Release MCD 5.
Engineering Guidelines Figure 10: Worked Example The configuration includes a number of hot desk users (200+200) as well as mix of applications for MiCollab Client (100+100) and also UC Express (50+50) on the non-hot desk user phones. In this example it is assumed that the MiCollab Client and UC Express applications are only monitoring themselves, and so the number of MiTAI monitors is equal to the number of applications.
Phones and Voice Applications Table 32: Worked Example - Standard and Resilient Operation Standard Operation Phone Total Hot Desk Quantity MiNET SAC MiTAI Sockets Sockets Sockets Total MiTAI IP Sockets Monitors Connections 400 200 5330 (Hot Desk) 100 phones 100 100 100 0 200 200 200 5312 (Hot Desk) 100 phones 100 100 100 0 200 0 200 MiCollab Client (Monitor 5330s) MiCollab Client Server 100 0 0 0 0 100 0 Standard fixed 200 5312 (Standard) without UC Express 200 200 2
Engineering Guidelines Table 32: Worked Example - Standard and Resilient Operation (continued) Standard Operation UC Express added 50 UC Express User Quantity 50 MiNET SAC MiTAI Sockets Sockets Sockets Total MiTAI IP Sockets Monitors Connections 0 0 0 0 50 0 400 Hot Desk (SAC) Hot desk users 200 0 0 0 200 0 0 Standard fixed included with phone 200 0 0 0 0 0 0 800 800 800 3 900 900 1602 Total Note: As can be seen from the calculations, some additional IP Sockets are ne
CHAPTER 5 POWER
Power Introduction This chapter discusses the following power requirements for the 3300 ICP: • “Installation Practices” on page 87 • “Controller Power Input” on page 87 • “MiVoice IP Phone Power” on page 88 • “Planning a Power Over Ethernet Installation” on page 95 • “Uninterruptible Power Supply (UPS)” on page 109 Installation Practices Data signals on an Ethernet or similar connection are low power and are susceptible to electromagnetic interference.
Engineering Guidelines are auto-sensing. NSU cabinets also have universal (auto-sensing) power inputs. Migrated SX 2000 DSU cabinets each have a switch on the power supply to select 120 VAC or 230 VAC power. The Peripheral Cabinets are available as either 120 VAC/60 Hz or 230 VAC/50 Hz. During a local power failure, data that is being written to a disk or FLASH module may not be completely stored and it can become corrupted.
Power To determine which standard(s) a particular phone supports refer to Table 33. Phones can be powered remotely with the following methods: • If the phone supports the IEEE 802.3af power over Ethernet standard, remote power to the phone can be supplied by an IEEE 802.3af compliant Ethernet switch. Alternately, if the phone and the powered Ethernet switch both support LLDP-MED, then the phone can advertise its power requirements to the IEEE 802.3ab compliant switch.
Engineering Guidelines Options for IP Phone Powering Table 33: IP Phone Power Options Phones In-Line Ethernet AC Power Adapter (48 VDC LAN) AC Power Adapter (24 VDC) Power Dongle (Cisco-Co mpliant) 802.3af 802.3af 802.3af Signal Mid-Span Spare Pair (Phantom) Power Hub Power Pair Power 802.
Power Table 33: IP Phone Power Options (continued) In-Line Ethernet AC Power Adapter (48 VDC LAN) AC Power Adapter (24 VDC) Power Dongle (Cisco-Co mpliant) Yes, but the only power supply approved for use is: Mitel Part # 51015131) No No 5505 Yes No No 5485 IP Pager No Yes 5540 Yes 5550-TKB (5550 IP Console) Phones 5360 802.3af 802.3af 802.
Engineering Guidelines Table 33: IP Phone Power Options (continued) In-Line Ethernet AC Power Adapter (48 VDC LAN) Phones AC Power Adapter (24 VDC) Power Dongle (Cisco-Co mpliant) 802.3af 802.3af 802.3af Signal Mid-Span Spare Pair (Phantom) Power Hub Power Pair Power 802.3ab (LLDP-MED Signalling) Support Note 1: Refer to TeleMatrix 3000IP Technical documentation for details. Note 2: For some IP Phone accessories or modules, the total power is not compatible with 802.3af LAN powering.
Power There are two methods of providing power in the standard: • “Phantom” power across existing Ethernet wires (RJ-45 pins 1, 2, 3 and 6). This is the method typically used by 802.3af compliant Ethernet switches. The 3300 CXi controller uses the phantom (signal pair) method for delivering power. • “Spare pair” power where power is supplied across RJ-45 pins 4, 5, 7 and 8. This is the method typically used by mid-span devices that sit between a non- 802.3af Ethernet switch and the end device.
Engineering Guidelines The CXi/CXi II controller’s Layer 2 switch can provide 100 Watts of power to 802.3af-compatible devices according to the following general rules: • Depending on the phone and option power requirements, up to 16 IP Phones could be supported. • Up to four PKMs (PKM12 or PKM48) are supported on Dual Mode IP Phones. Only one PKM can be attached to a set. Multiple PKMs on a set require an AC adapter. • Conference units require an AC adapter.
Power Note: Some of the older versions of 4000 and 6000 series are not IEEE 802.3af-compliant (check before using). The older 3524XL-PWR and 3550-PWR are not fully compliant and have been replaced by the newer 3560 series. For switches that are not IEEE 802.3af-compliant, use the Mitel 3300 Power Dongle. (See page 95.) Others As the IEEE 802.3af standard becomes more widely adopted, additional vendors are offering IEEE 802.3af compliant products.
Engineering Guidelines Cable Power Loss Some power loss will occur over the Ethernet cable used to connect the phone to the L2 switch or the mid-span powered hub. If you are using an IEEE 802.3af compliant L2 switch or mid-span power hub and the power required by the telephone does not exceed 8 W, the power loss in the cable will be approximately 10% of the power required by the phone. The IEEE 802.3af standard specifies that the PSE must provide at least 15.4 W and that the PD cannot draw more than 12.
Power • what size UPS would be required to maintain power to the phones in the event of a main power outage • if a L2 switch that uses a proprietary PoE (non-802.3af compliant) mechanism has sufficient power capabilities to power the desired combination of phones. Notes: 1. The phone power requirements shown in Table 34 do not include the 3300 Power Dongle power requirements. For example, a 5220 (Dual Mode) phone requires 4.7 watts of power and a 3300 Power Dongle requires 1.4 watts of power.
Engineering Guidelines Table 34: Actual Telephone Power Consumption (continued) Power consumption (W) (Worst Case Maximum) Device 5302 3.84 5304 3.45 5312 3.87 5324 3.87 5320 5.3 5320e 5.5 5330 with back light 5.8 5330e 6.1 5340 5.8 5340e 6.1 5360 (see Note 4) 9.2 5360 + Conference Unit (see Note 4) 12.8 5360 + Cordless OM Handset + Headset (see Note 4) 12.0 5360 + LIM (see Note 4) 9.9 5412 PKM (see Note 3) 1.3 5412 PKM + 5448 PKM (see Note 3) 3.0 5448 PKM (see Note 3) 1.
Power Table 34: Actual Telephone Power Consumption (continued) Power consumption (W) (Worst Case Maximum) Device 5560 IPT 12.9 Bluetooth Module for use with 5330, 5340 and 5360. 3.0 UC360 The UC360 can consume up to 25.5 Watts, however typical power consumption is less. For details refer to the UC360 Engineering Guidelines. Note 1: See “Power Restrictions” on page 67. for information about power restrictions related to the Gigabit Ethernet Phone Stand.
Engineering Guidelines Table 35: CDP Power Advertisements Device CDP Power Advertisements (see Note) 5001 IP Phone 4.5 W 5005 IP Phone 4.5 W 5010 IP Phone 6.3 W 5020 IP Phone 6.3 W 5020 IP Phone + 5310 Conference Unit (Conference unit is powered with AC adapter 24 VDC) 6.3 W 5020 IP Phone + PKM(s) (PKMs are powered with AC adapter 24 VDC) 6.3 W 5201 IP Phone 4.5 W 5205 IP Phone 4.5 W 5207 IP Phone 4.5 W 5212 IP Phone 6.1 W 5215 IP Phone 6.3 W 5215 IP Phone (Dual Mode) 6.
Power Table 35: CDP Power Advertisements (continued) CDP Power Advertisements (see Note) Device 5330 with 1 PKM 7.5 W 5330 with 2 PKMs 9.2 W 5330e 6.1 W 5340 6.1 W 5340e 6.1 W 5340 with 1 PKM 7.5 W 5340 with 2 PKMs 9.2 W 5360 9.5 W 5505 6.1 W 5540 6.1 W 5560 IPT 6.1 W Navigator 6.1 W TeleMatrix 3000 IP 5.0 W UC360 5.
Engineering Guidelines Table 36: 802.
Power Table 36: 802.
Engineering Guidelines Table 36: 802.3af Power Class Advertisements (continued) Device Class Advertised 5540 3 5560 IPT 0 UC360 See Note 2. Note 1: See “Power Restrictions” on page 67. for information about power restrictions related to the Gigabit Ethernet Phone Stand. Note 2: The UC360 is an IEEE 802.3at (Type 2) Class 4 device. IEEE 802.3at (Type 2) Class 4 devices draw from 12.95 Watts to 25.5 Watts.
Power Table 37: LLDP-MED Power Advertisements (continued) Device Power Value Advertised Power Consumption (Watts) 5201 IP Phone Not Supported n/a 5205 IP Phone Not Supported n/a 5207 IP Phone Not Supported n/a 5212 IP Phone 47 4.7 5215 IP Phone Not Supported n/a 5215 IP Phone (Dual Mode) 47 4.
Engineering Guidelines Table 37: LLDP-MED Power Advertisements (continued) Device Power Value Advertised Power Consumption (Watts) 5240 IP Appliance Not Supported n/a 5302 Not supported n/a 5304 IP Phone 37 3.7 5312 IP Phone 47 4.7 5320 35 3.5 5320e 55 5.5 5324 IP Phone 47 4.7 5324 IP Phone + 5412 PKM 64 6.4 5324 IP Phone + 5448 PKM 64 6.4 5324 IP Phone + 5412 PKM + 5448 PKM 81 8.1 5324 IP Phone + 5448 PKM + 5448 PKM 81 8.
Power Table 37: LLDP-MED Power Advertisements (continued) Device Power Value Advertised Power Consumption (Watts) 5360 + Conference Unit 128 12.8 5360 + Cordless OM/Handset + Headset 120 12.0 5360 + Bluetooth module 120 12.0 5360 + LIM 99 9.9 5505 39 3.9 Navigator 86 8.6 TeleMatrix 3000IP 37 3.7 Gigabit Ethernet Phone Stand Version 1 (Note 2) 53 + Phone 5.3 + Phone Gigabit Ethernet Phone Stand Version 2 (Note 2) 34 + Phone 3.4 + Phone 5540 53 5.3 5560 IPT 129 12.
Engineering Guidelines Power Requirements for 5220 IP Phone Optional Accessories The 5220 IP Phone and the 5220 IP Phone (Dual Mode) support optional accessories which are powered in different ways depending on the option and the phone: • 5220 IP Phone options are powered from a 24 VDC power unit only. • 5220 IP Phone (Dual Mode) options can be powered from either 24 VDC power unit or through the Ethernet.
Power Uninterruptible Power Supply (UPS) Use uninterruptible power supplies when phones, the associated controllers, PC-based consoles, and the LAN infrastructure need to continue to operate during a power failure. UPSs can range from simple local battery units to larger central installations that include backup generators.
Engineering Guidelines 110
CHAPTER 6 PERFORMANCE
Performance System Performance Index In order to calculate the performance limits of a system, different weighting values are assigned to various types of calls. Typically an ONS-to-ONS call is considered to have a loading factor of 1.0, and an IP phone-to-IP phone, a loading factor of 3.2. Other call types (ONS to PSTN trunk, IP phone to IP trunk, etc.) are assigned different values based on actual performance tests.
Engineering Guidelines attached, the maximum performance may only be obtained by using the ICP as a group controller in conjunction with other units providing functions such as TDM gateways and voice mail services. Normal operation is within the P.99 region. The system may be pushed into the P.95 region, for short duration, for example during a resilient failover condition. However, certain call parameters, such as delay to dial tone, may be extended beyond the normal expected timings. Operation beyond P.
Performance Figure 12: Performance Limitations for Mixed Office Traffic (MXe Server) Performance in an ACD Environment There are many features of an office telephone system which are always present and which individually use a large amount of CPU performance, but since they are rarely used in an office or hospitality environment, they are insignificant to the overall performance numbers of the system.
Engineering Guidelines internal calls (the IVR and the agent) and could easily be more than five calls, depending on how busy the call center is and how many callers are waiting in queues. When a system is sized such that the number of trunks is less than 1.5 times the number of agents, the overall call rate will typically be less than 2.5 times the incoming (trunk) call rate. When the number of trunks into the system is more than 1.
Performance type—for example, Voice, VoiceMail, RAD, etc.—also has performance implications, especially with respect to auto attendant and IVR operation. Hunt groups containing auto attendant or IVR ports should be configured as VoiceMail type groups to take advantage of automatic camp-on; otherwise, in a high traffic site, you may experience system slowdowns if calls are rejected by call control due to excessive processing.
Engineering Guidelines 118
CHAPTER 7 APPLICATIONS
Applications 3300 ICP Applications The 3300 ICP supports a number of applications. This includes applications that are embedded in the product, such as voice mail, through to providing DSP resource to allow connections to external devices, for example a remote central voice mail in another unit. Other interfaces include MiTAI for MiCollab Client Softphone operation.
Engineering Guidelines Voice Mail The 3300 ICP includes an integrated, fully featured voice mail system. Up to 30 ports are available for voice mail calls with support for a maximum of 750 mailboxes and 130 hours of storage time. Notes: 1. The AX only supports 20 voice mail ports, and only if Flash 1 is upgraded to 4 GB. 2. The CX has 4 or 16 voice mail ports depending on the DSPs installed. 3. The MXe Server does not support embedded voice mail.
Applications • EHLO – greeting that announces support for extended messaging options. • MAIL FROM – specifies the originating mailbox. • RCPT TO – identifies the recipient's mailbox. • DATA – start of data. • QUIT – connection is to be closed. The receiver will send an OK reply. • NOOP – no action. It can be used at any time during a connection session. • RSET – resets the connection.
Engineering Guidelines Table 41: Embedded Music On Hold Capabilities Total RAM Total Play Time Maximum Number of Embedded MOH Sources MXe Server LX with 512 MB (1400-user), MXe expanded 16 MB 32 minutes 64 MXe base 16 MB 32 minutes 16 MX, LX with 256 MB 8 MB 16 minutes 16 CX/CXi 4 MB 8 minutes 5 AX 2 MB 4 minutes 2 Platform Application Processor Card The Application Processor Card (APC) is an embedded PC card.
Applications The APC hosts the 6000 Managed Application Server (MAS).The MAS can run the following applications: • Unified Communicator Mobile - Enables 3300 ICP users to twin their cell phone (or other external telephone connected to the PSTN) with their office extension. Once twinned, calls to the office extension ring both devices simultaneously until one or the other is answered or, if unanswered, forwards the call to voice mail.
Engineering Guidelines 126
CHAPTER 8 EMERGENCY SERVICES
Emergency Services Emergency Services Emergency services such as 911 are available from most phone devices according to how the class of service and restrictions for the phone are set. The default is to enable 911 emergency service access.
Engineering Guidelines The IP phones determine the MAC addresses of the L2 ports to which they are connected by using Spanning Tree Protocol (STP)/Rapid Spanning Tree Protocol (RSTP), or Cisco Discovery Protocol (CDP). The IP phones then report to the ICP, sending the MAC address of the L2 switch port to which they are connected. Note: The network port MAC addresses and physical locations must be known before the IP phones are deployed.
Emergency Services Figure 13 contains three panels. For the configuration in the left panel (CDP), the administrator must set the preferred protocol to CDP in the CESID Assignment form; for the configuration in the middle panel (STP), the administrator must set the preferred protocol to STP, and for the configuration in the right panel, the preferred protocol is set to STP and CDP.
Engineering Guidelines CESID auto updates, unsupported cConfigurations Automatic updating of CESID when a phone moves to a new location will not work under the following circumstances: • If the IP phone is connected to an Ethernet hub • If the IP phone is connected to an L2 switch that does not have CDP or STP/RSTP enabled • If multiple IP phones report connectivity to the same L2 port. The system will detect this condition upon device registration.
Emergency Services Figure 15: Non-compatible Network Configuration - L2 Switch with both CDP and STP Disabled Figure 16: Non-compatible Network Configuration - Devices Connected to L2 via Hub Other considerations • The Spanning Tree Protocol allows multiple ethernet connections to be made between a device and the network without introducing a network loop.
Engineering Guidelines • Using RSTP reduces disconnection time to approximately 3 seconds, which has a much smaller effect on IP phone operation and is the preferred setting throughout the network. Note: More details on Rapid Spanning Tree configurations can be found in the 3300 ICP Resiliency Guide.
CHAPTER 9 IP NETWORKING
IP Networking IP Networking Considerations This chapter discusses how IP networking and IP trunks affect the 3300 ICP. The terms “IP networking” and “IP trunks” have become synonymous. However, “IP networking” covers the whole picture, while “IP trunks” refers to the individual call connections.
Engineering Guidelines Clustering Clustering and networking between units introduces additional performance overhead and limitations on the individual 3300 ICPs and MiVoice Business systems, but allows a much greater overall system to be deployed, over potentially a large geographic area. To determine the impact of such configurations and use with users and applications, it is highly recommended to use the System Engineering Tool to gauge the headroom and overall impact of such configurations.
IP Networking IP-Trunk Connection Limitations Prior to Release MCD 5.0 there were some IP-Trunk limitations to consider. These include: • The number of IP-Trunk channels per connection, or route - 200 per route • The total number of IP-Trunk channels on the node, gateway or controller is limited to a total 2000 provisioned channels • The number of IP-XNet Trunk Groups (321) Prior to Release MCD 5.
Engineering Guidelines IP trunking models Examples of fully-meshed and hierarchical network configuration networks are shown Figure 17 and Figure 18. Figure 17: Fully-meshed Network In a fully-meshed network, every node is connected to every other node. The benefit of a fully-meshed network arrangement is that one, or even more than one, link can go down, and nodes can still reach each other—there are many alternative routes.
IP Networking Figure 18: Hierarchical Network Further details on setting up a cluster can be found in the “3300 ICP Multi-Node Management Clustering” document under the 3300 product documentation on Mitel-on-Line. Call Handling, Routing, and Bandwidth A call consists of two parts: signalling and voice streaming. Using TDM, typically over the PSTN, the two parts of the call follow the same path and are closely linked in their routing.
Engineering Guidelines Figure 19: Signalling and Voice Path Example 1 In the tandem case, a virtual IP trunk is used from A to B and another virtual IP trunk is used from B to C. These trunks are counted against the routing limit. In certain networks, especially external WANs that use VPNs, the most direct path from A to C may actually be through the IP router at site B. However, the 3300 ICP at this site only handles the signalling and not the voice traffic.
IP Networking Variable RTP Packet Rates MCD 4.0 introduced capabilities to support the use of variable RTP packet rates between specific phones, applications and the 3300 ICP. Previously, RTP packet rates were fixed at 20 ms. Currently, the 3300 ICP has only one means of connecting to service providers via IP technology: over SIP Trunks. Some service providers of SIP trunks may require packet rates that are not 20 ms.
Engineering Guidelines The MiVoice Border Gateway (Release 6.0 onwards) can provide packet rate adaptation between the internal and external address interfaces. This can be used to provide a different packet rate to a carrier compared to a local packet rate, thus allowing internal devices and applications to run at a common rate that may be different from the carrier.
IP Networking When used in a cluster environment, the network ID must equal the Cluster Routing digits. When not in a cluster environment, the network ID must equal the Node ID. WARNING:IN A NETWORK CONSISTING OF A CLUSTER OF ICPS, ROUTE OPTIMIZATION SHOULD NOT BE ENABLED FOR ICP UNITS PRIOR TO RELEASE 4.2. ALSO, WITH ROUTE OPTIMIZATION ENABLED, IT IS NOT RECOMMENDED TO HAVE A NETWORK CONSISTING OF ICPS WITH MIXED SOFTWARE RELEASES (4.0, 4.1 AND 5.0) AS CALLS MAY BE DROPPED.
Engineering Guidelines IP Networking and Product Release Compatibility Product improvement is part of an important and ongoing process and it includes the need for new product releases. While every effort is made during the development process to ensure that the new release is compatible with earlier releases, there may be instances where this cannot be fully achieved. This may become apparent due to, but not limited to, differences in expected system operation and feature availability.
IP Networking Applications compatibility To ensure applications compatibility with an ICP that is using SIP trunking, the System Administrator needs to ensure that all applications that use MiAudio or emulate a MiNET phone are upgraded to versions that support RFC 4733. SDK version 2.0 supports RFC 4733. RFC 4733, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals is an IETF memo that describes how to carry DTMF signalling, other tone signals, and telephony events in RTP packets.
Engineering Guidelines For correct operation, ports that are used to connect to Fax machines must have the following COS option enabled: • Fax Capable (Set to “Yes”) In addition to the Fax Capable COS option, the Administrator is advised to set the following COS options as indicated. If some of these overrides are not set as indicated and a tone is generated on this port while a Fax transmission is in progress, then the Fax transmission will likely fail.
IP Networking Figure 21: Enterprise Site with SIP Aware Firewall The ingate SIP Firewall is interoperable with the 3300 ICP based SIP solution. You can obtain the Ingate product documentation at www.ingate.com. The Mitel SIP firewall product is the MiVoice Border Gateway. Information is available on Mitel OnLine.
Engineering Guidelines • The new MiTAI driver communicates with MiVoice Business using internal MiVoice Business component (Data Services) port 5320. • The Microsoft PC to Phone application uses ports 5060 and 5061 for communication between the Live Communication Server and the 3300 ICP. Resiliency Some service providers may offer service resiliency. There are two different mechanisms for making use of service provider resiliency; IP addressing or FQDNs (Fully Qualified Domain Names).
CHAPTER 10 LICENSING
Licensing System Licenses Release MCD 5.0 introduces two new switch packaging options (System Types) which are defined as follows: • Standalone • Enterprise In “Enterprise” systems users can be made Resilient, but in “Standalone” systems they cannot. “Enterprise” systems allow network or cluster programming, whereas “Standalone” systems do not. Licenses may also be shared among the nodes in a network of “Enterprise” systems.
Engineering Guidelines • IP Device license In MCD 4.0, an IP device license is needed for every IP phone that is, or could be, registered with the MiVoice Business system. Resiliency requires IP device licenses, but not necessarily IP user licenses, as these are registered on another system. In MCD 4.1 and later, the IP device license is replaced with the IP user license. The IP user license now applies to both users and devices.
Licensing • Multi-device Users license In MCD 5.0 it is possible to create Personal Ring Groups (PRGs) whose members are collectively licensed under a single Multi-Device License instead of being individually licensed as users. • Multi-device Suites license In MCD 5.0 it is possible to create suites whose members are collectively licensed under a single Multi-Device License instead of being individually licensed as users.
Engineering Guidelines commercial servers, compression resources are provided in software by the Media Server component (software blade). Compression licenses are available in increments of 8 sessions. • Fax over IP (T.38) A T.38 license is required to allow an ICP to originate or terminate Faxes over IP or SIP trunks from TDM ports. A field called ‘Fax over IP (T.38) licenses” can be found under purchasable option. The Wizard will validate that the value input is a multiple of 4.
Licensing • Embedded Voice Mail PMS license An embedded voice mail PMS (Property Management System) license is needed to enable access to hospitality/PMS services. • Tenanting license In Release MCD 4.1 and earlier, a licensable option is required to enable Tenanting on the MiVoice Business system. The Tenanting package allows the MiVoice Business system to be configured to look like a separate system to each participating tenant.
Engineering Guidelines Device Licensing The 3300 ICP requires a number of device licenses in order to operate. The following table lists these licenses. Table 43: Devices and licenses - MCD Release 4.
Licensing Table 43: Devices and licenses - MCD Release 4.0 and Earlier (continued) Device License Fax over IP (T.38) licenses A T.38 license is required to allow T.38 transmission or reception of Fax over an IP or SIP trunk. The T.38 licenses are instantiated in multiples of 4; the minimum value is 0 and the maximum value is 64. Compression (TDM/IP) A Compression license is needed for TDM to IP or IP to TDM calls that require the use of the DSP compression.
Engineering Guidelines Table 44: Devices and licenses - Release 4.
Licensing Table 44: Devices and licenses - Release 4.1 and later (continued) Device License Note 1: The licenses described are those applicable to the 3300 ICP. The Customer Interaction Solutions, Speech Server, and Messaging Server also require application licenses to enable their functions. Note 2: The number of voice mailboxes is not the same as the number of voice mail ports enabled.
Engineering Guidelines Table 45: License limits License type Maximum limit Hospitality / PMS license Y/N Voice Mail Networking license Y/N Tenanting license Y/N Note 1: Effective Release 10.1 (MCD 4.1), the IP device license and SIP user license are dropped, and their functionality is merged into the IP user license. Note 2: In MCD 4.0, the combined total of IP user licenses and SIP user licenses cannot exceed 5600.
Licensing Taking each of the licenses in turn, the above information results in the following calculations and resulting licenses: • IP device License MCD Release 4.0: IP device licenses apply to IP phones. HQ1 has 400 local IP users, 20 remote users and is secondary for 200 IP phones from HQ2. Thus 620 licenses are needed. HQ2 has 200 local IP users and is secondary for 400 IP phones from HQ1. Thus 600 licenses are needed. For the total site, 1220 licenses are needed. In MCD Release 4.
Engineering Guidelines needed for trunks. A further two channels are needed for internal calls, making a total of 26 IP trunks (200 X 2/36 X 15% (networking) X 1.1 (+ 10%)). • Voice Mail License At HQ1 there are 420 voice mailboxes. At HQ2 there are 200 voice mailboxes. For the site, a total of 620 licenses are needed. • Advanced Voice Mail License At HQ1 there are additional services: two Auto-Attendants and one Record-a-Call. Thus, a total of three licenses is needed.
CHAPTER 11 BANDWIDTH, CODECS AND COMPRESSION
Bandwidth, Codecs and Compression Bandwidth, Bandwidth Management, Codecs and Compression An IP packet carrying voice information has a number of additional “wrappers” (see graphic below) so that different network devices know how to route the information (IP address), how to forward information between physical devices (MAC address), and how to identify when a packet starts and finishes (Ethernet).
Engineering Guidelines Note: Some network analyzers will not monitor the full Ethernet frame, excluding checksums and synchronization data, and therefore they give a bandwidth somewhere between wire and IP bandwidth. For the example shown, this would typically be 87.2 kbps, including VLAN. What is the media bandwidth? Depending upon how this is measured, this could be simply the payload bandwidth, which is similar to TDM, or it could be the bandwidth of the packet carried across the network.
Bandwidth, Codecs and Compression time do not carry user information, they do consume bandwidth, which is unusable by any other connected device. Table 47: Ethernet/LAN IP and On-the-wire Bandwidth Codec: Payload: Link Type Packet Rate (ms) G. 711 G.729 G.722.1 64 kbits/s 8 kbits/s 32 kbits/s IP Wire IP Wire IP Wire Ethernet 10ms 96.0kbits/s 129.6kbits/s 40.0kbits/s 73.6kbits/s 64.0kbits/s 97.6kbits/s 20ms 80.0kbits/s 96.8kbits/s 24.0kbits/s 40.8kbits/s 48.0kbits/s 64.
Engineering Guidelines Table 48: Other Protocols: On-the-wire Bandwidth (continued) Codec: G.711 G.729 G.722.1 64kbits/ 8kbit/s 32kbit/s Wire (kbits/s) Wire (kbits/s) Wire (kbits/s) Payload: Link Type Packet Rate (ms) cPPP 10ms 72.0 48.0 40.0 20ms 68.0 28.0 36.0 30ms 66.7 21.3 34.7 40ms 66.0 10.0 34.0 10ms 127.2 84.8 84.8 20ms 106.0 42.4 63.6 30ms 98.9 28.3 56.5 40ms 84.8 21.2 53.0 10ms 169.6 84.8 127.2 20ms 106.0 63.6 84.8 30ms 98.9 42.4 70.
Bandwidth, Codecs and Compression Bandwidth availability The advertised rate for a particular link is the speed at which the data travels; it is not necessarily the available data rate. In practice, a percentage of this bandwidth is lost due to communications between end devices because the data is asynchronous and requires certain guard bands. In a synchronous telecom link, these issues are resolved through mechanisms such as framing data into fixed timeslots.
Engineering Guidelines The LAN connection guidelines table also shows the maximum capability of a LAN link assuming that the link is used purely for voice traffic. If the link is shared with other devices such as PCs, then some priority mechanism is required to ensure that the voice gets the available bandwidth when needed. Also, in a busy network with multiple broadcasts, the available bandwidth is reduced by this percentage.
Bandwidth, Codecs and Compression Bandwidth Management This section details the new bandwidth management solution. Bandwidth management and call admission control The terms “Bandwidth Management” and “Call Admission Control” are often used interchangeably to mean the management, and potential re-routing, of calls across an IP network between end devices. In reality these are two separate concepts.
Engineering Guidelines bandwidth is shared. You may need to specify alternative routes where multiple routes go through a common bottleneck, or where bandwidth is shared between a primary and secondary controller for resilient operation in the event of a controller failure. Call Admission Control and re-routing applies to normal calls. Emergency calls, certain priority calls and established calls being re-routed, for example, calls on hold, do not need to negotiate access.
Bandwidth, Codecs and Compression Figure 22: Fully Meshed WAN Connections - Deployment Example Table 52: Fully-meshed Network with WAN as the Root Zone Parent 1 Root (WAN) 2 Root (WAN) 3 Root (WAN) In a multi-node installation, it is also possible to link a single VPN back to headquarters at another site using a star configuration.
Engineering Guidelines Figure 23: Fully-meshed WAN Connections - Star Configuration Non-meshed WAN connections If all VPNs terminate at the HQ access router in a star configuration, then connections between remote nodes will use bandwidth twice on the access link to HQ, and this needs to be counted. An example of a business configuration like this is a franchise where internode traffic is either limited in volume or regulated by call control.
Bandwidth, Codecs and Compression Table 53: Non-meshed WAN Zone Parent 1 Root (1) 2 Root (1) 3 Root (1) This non-meshed configuration is a little different, as it requires that data be forced to travel back through the central control node. This configuration requires that the “Media Anchor” function be used, and that all outlying nodes be treated as independent units. This is similar to a large deployment, for example, a business with multiple corporate HQ in different countries.
Engineering Guidelines The configuration table will look similar to that in Table 54. Table 54: Non-meshed Configuration Zone Parent Perimeter Anchor Manager Bandwidth 1 none No Yes 2 none No 3 none No 11 1 Yes Unit A in Zone 1 1024 kbps 12 2 Yes Unit B in Zone 2 256 kbps 13 3 Yes Unit C in Zone 3 256 kbps Deployment boundaries There are limitations that apply to the current configuration of nodes and paths within the Call Admission Control tree. These are listed below.
Bandwidth, Codecs and Compression Redundant WAN links and load sharing The usable bandwidth to be counted on such links (by number of calls using the link) must be considered and may be set according to business requirements. A standby link may provide the same, or reduced, bandwidth as compared to the main link that has failed. In this case, the usable bandwidth is likely to drop when the backup link is activated.
Engineering Guidelines Inter-zone bandwidth settings As well as defining the zones and links between locations, the available bandwidth also needs to be defined. Generally the available bandwidth on these links is also determined by the WAN link protocol. This could be a dedicated link running cPPP, or may be a more general purpose connection such as MPLS, or xDSL. Although the payload (IP) is common to these WAN protocols, the bandwidth on the physical wire link may not be.
Bandwidth, Codecs and Compression Other coding laws also exist. One that gives good voice quality and is also efficient at coding is G.729. This also comes in different formats: • G.729 - original version—very processor intensive • G.729a - reduced processor effort and compatible with G.729 • G.729b - includes voice activity detection and ability to send background information. Compatible with G.729 and G.729a Wideband audio, up to 7kHz (50Hz to 7.0kHz) of voice bandwidth, is available with the G.
Engineering Guidelines • Network Zone Topology - Bandwidth Limits • ARS Routes - Compression On/Off/Auto. Compression 'On' may override zone settings (Auto setting is recommended) The endpoint CODEC to use is also influenced by: Can the end device support this CODEC? (Not all phones will support G.722.1, and some earlier phone models may not support G.729.
Bandwidth, Codecs and Compression Assuming that the end devices are capable of supporting the available CODECs, then the following table will highlight the operation from Release MCD 5.0 for calls within a common zone as well as calls between zones. Note that prior to Release MCD 5.0, there were only two CODEC selections and these were often referred to simply as non-compressed and compressed. At Release MCD 5.0 additional CODEC selections now need to be considered.
Engineering Guidelines Table 58: Codec Zone Interconnects Zone Interconnect IntraZone Compression InterZone Compression Route Compression Off On No* Auto* Zone 2 Yes** Off (Defined Setting) On Yes Auto* To Zone 1 To Zone 2 G.729 G.722.1 G.722.1 G.711 G.711 G.729 G.729 G.722.1 G.722.1 G.711 G.711 G.729 G.722.1 G.722.1 G.711 G.711 G.729 G.729 G.722.1 G.722.1 G.711 G.711 G.729 G.729 G.722.1 G.722.1 G.711 G.711 G.729 G.729 G.722.1 G.722.1 G.711 G.
Bandwidth, Codecs and Compression Figure 26: Codec Zone Interconnect Example Operation through MiVoice Border Gateway and SRC At Release MCD 5.0 and MBG 6.1, there is no transcoding support for the wideband G.722.1 CODEC via the MiVoice Border Gateway or SRC. As such, the MiVoice Border Gateway and SRC will default to only negotiate connections with G.711 and G.729 CODEC types. The SRC will ensure that the connected phones only negotiate to G.711 or G.729 and will provide G.729 to G.
Engineering Guidelines although there is a reduction in required bandwidth, the gain isn’t always as much as might be expected. Other forms of data compression also exist in the network. It is possible to do a level of header compression on certain fixed links, e.g. RFC 1993. Other data compression techniques include Compressed RTP (RFC 2508 or Enhanced CRTP-RFC 3545), or they may only compress up to the IP layer. Data and header compression is typically used for lower speed links, less than 1.
Bandwidth, Codecs and Compression 3300 ICP controllers and compression A single controller has the following limitations: • If the controller has one compression DSP module, the maximum number of compression sessions is 32. If the controller has two compression DSP modules, the maximum number of compression sessions is 64. • If the controller has DSP-II fitted, this is capable of up to 64 compression sessions per module.
Engineering Guidelines Trunking gateway working example In terms of considering network bandwidth, it should be based on the 120 channels and where they are being connected. Also consider the maximum number of compression channels (G.729a); they are limited to 64 within a single unit. Further IP trunks use standard non-compressed G.711 channels. Thus, in the example of toll-bypass, it is likely that trunks will go via the IP WAN. In this case, the connection bandwidth requirements will be 11.0 Mbps.
Bandwidth, Codecs and Compression Figure 27: IP Networking Compression Zones Example Although the network shown in the figure above is not a real network, it highlights some of the areas to consider in allocating bandwidth in different parts of the network: • Calls within Zone 1 of both controllers are not compressed. • Calls between controller A and controller B are sent over an IP networking route (IP trunk) and are compressed but can be set up as non-compressed.
Engineering Guidelines IP trunk routes and compression The IP trunk route is a virtual path from one 3300 ICP to another 3300 ICP. One of the parameters assigned to this route is compression. Assuming that the end devices are capable of compression, compression is enabled on the route, and there are sufficient available channels, or sessions, then the end devices stream using compression. Otherwise the call is blocked, rerouted, or streamed with G.711 (uncompressed).
CHAPTER 12 NETWORK CONFIGURATION CONCEPTS
Network Configuration Concepts Introduction This chapter provides a high-level overview of the network settings and configurations required for a Voice-over-IP (VoIP) installation with the 3300 ICP when used in a business or Enterprise environment. The concepts below will help you understand more about network configurations. Table 61 shows a list of the topics in this chapter and a description of what you will find in each one.
Engineering Guidelines Network Configuration Guidelines Table 62 contains a list of guidelines for network configuration. In brief, these guidelines are exactly that: guidelines. Because LANs are so diverse and equipment changes so quickly, review the following recommendations to provide the best operating conditions. For more information on the guidelines in the table below, click on the cross-reference link in the adjacent column, if provided. Also see “Network Configuration Specifics” on page 227.
Network Configuration Concepts Table 62: Network Configuration Guidelines (continued) Guideline For more information The controller should be located behind a network Layer 2 switch. “LAN architecture” on page 202 Ensure that the PPS rate of the routers and switches is adequate for the amount of voice traffic expected. “WAN layer 3 priority” on page 213 Wherever possible, provide the most bandwidth available. Use full duplex instead of half duplex.
Engineering Guidelines Table 62: Network Configuration Guidelines (continued) Guideline The controller uses some internal IP addresses in the range 169.254.10.0/15 to 169.254.30.0/15. Communication to the 3300 ICP using an IP address in these ranges will fail to get a response. For more information “IP Address Restrictions” on page 285 Note: None of these reserved addresses can be used by devices that need to communicate with the 3300 ICP (e.g. MITEL Phones, E2TVirtual MiVoice Business).
Network Configuration Concepts Voice-Over-IP Installation Requirements It is essential to assess and configure the network in order to maintain the voice quality and functionality for the user. This may require that an existing network be changed, or that equipment with certain capabilities be installed.
Engineering Guidelines 198 • Network address translation (NAT) and firewall: Although there are emerging standards to allow VoIP through firewalls and NAT devices, these are still in early development. To allow voice through a firewall, a number of ports need to be opened because one controller may use a range of ports that are dynamically assigned. Opening all possible ports negates the usefulness of the firewall.
Network Configuration Concepts General Guidelines for Quality of Service The main issues that affect system installation and user perceptions are • Quality of service (voice quality during the call) • Availability of the service (setting up and clearing voice connections or signalling) The challenge is to engineer the network to ensure that these quality requirements are met. With TDM, this is possible by providing dedicated connections to the desk.
Engineering Guidelines Extensive use of hubs rather than switches also introduces jitter. Hub use for larger networks and where connections are shared with data devices is not advised. Use of multiple WAN connections and load-sharing can also introduce jitter due to different path delays. Ideally, voice should pass down one path or another and may be configurable based on TOS/DiffServ values.
Network Configuration Concepts Some carriers may also offer an SLA that honours and provides queuing for incoming (download to the customer) data as well. There may be an additional charge, but this will provide the added queuing on the far end of the often bandwidth limited connection between the customer and the carrier.
Engineering Guidelines Wideband audio is not supported over the analogue PSTN. The G.722.1 CODEC is also not easily supported over the digital PSTN (BRI, PRI) and could nominally be used only for point to point connections. For these reasons the G.722.1 CODEC is only supported on IP end devices. The G.722.1 wideband codec is also supported by some 3rd party SIP products, so allowing for interoperability of this feature between different vendor end devices.
Network Configuration Concepts The IP phones are in constant communication with the 3300 ICP. All signalling traffic, as well as traffic to and from the PSTN, goes through the 3300 ICP. The controller should be placed higher up the physical network, at some central switch point (for example, where all the access Layer 2 switches connect, or where there is a router or Layer 3 device to other subnets).
Engineering Guidelines In smaller networks, the definitions of the boundaries may become a little blurred. However, even in these smaller networks, plan a tree-type structure between the 3300 ICP and the phones. Daisy-chaining a number of switches is not recommended since all switches become involved in connections from one end of the chain to the other. Layering will reduce unnecessary traffic. For more specific information on network configurations, see the 3300 ICP Technician’s Handbook.
Network Configuration Concepts Maintaining Voice Quality of Service As discussed in the previous section, the following issues affect voice quality of service over IP connections: • End-to-end delay • Jitter or delay variation • Packet loss - Due to link congestion resulting in discarded or out of sequence packets - Due to lack of or incorrectly configured QoS controls on LAN and WAN connections - Due to forced discard of packets caused by excessive jitter The following sections discuss tools, m
Engineering Guidelines Network Measurement Criteria Assuming that jitter and packet loss are not an issue, the one parameter left that affects the voice and conversation quality is end-to-end delay. From ITU-T recommendations (and practical experience), the end-to-end delay for a voice call should not exceed 150 ms. The characteristics of the end devices such as the gateway (Ethernet and TDM bridge in the 3300 ICP) and the IP phones are known.
Network Configuration Concepts Bandwidth management and call admission control can be used to ensure that voice quality is maintained in parts of the network where there may be bandwidth constraints. For details, refer to “Bandwidth, Bandwidth Management, Codecs and Compression” on page 167. Refer to the 3300 ICP Resiliency guide for detailed calculations and breakdown of signalling messages for different connections.
Engineering Guidelines By modifying the router MTU value to approximately 500, larger packets are divided up and sent in smaller chunks. The result of this is that there are three times as many opportunities to send the voice data. Thus the data rate link could be reduced to 300 kbps. Note: Some routers do not function with an MTU as low as 500. Internet specifications for a reduced packet suggest a lower value limit for MTU of 576.
Network Configuration Concepts Network Priority Mechanisms There are two areas where priority mechanisms operate in the network to ensure that voice traffic maintains high priority: • Layer 2 in the LAN through use of IEEE 802.
Engineering Guidelines IEEE 802.1p (Layer 2 priority) uses a field in the IEEE 802.1Q tag to provide eight levels of priority. IEEE 802.1Q is the open VLAN standard that extends the Ethernet header by adding an additional 4 bytes to tagged packets. Because the 802.1p priority is part of the VLAN header, ports that need to convey multiple VLANs/802.1p priorities must use tagging. This includes ports used between LAN switches and ports connected to dual-port phones.
Network Configuration Concepts • Use VLAN 1 to 999 with Cisco products. VLANS can be extended from 1000 upwards. Care in selection should be exercised in this case as some VLANs are already reserved for other network usage. • Set Priority for untagged VLAN/native VLAN/default_vlan to 0. • Hubs don’t support priority queuing, so use managed Layer 2 switches with 802.1p/Q support. • Do not use VLAN 4095 with HP products; this is reserved for inter-switch use.
Engineering Guidelines packets with that VLAN setting. • - The phone will obtain the necessary VLAN configuration in a number of ways, highlighted later, but essentially through one of the following: Static programming, DHCP, LLDP-MED, or CDP broadcasts. - While the IEEE specification allows for VLANs from 0 to 4095, not all vendors support this range. As a general rule, VLAN 0 is treated in different ways by different vendors. The recommendation is not to use VLAN 0.
Network Configuration Concepts The default_vlan is VLAN1. The VLAN numbers are assigned names to help follow which function is assigned to which VLAN. The voice_vlan is VLAN2, the video_vlan is VLAN3, and test4 is VLAN4. The default VLAN is used by the data devices and also by the IP phones when they first start up and look for their correct VLAN configuration. (See the section “Startup Sequence for Phones” on page 230.
Engineering Guidelines DSCP46. The alternative is to map DSCP44 to the EF queue, but then this needs to be programmed in all routers. Note that the DSCP value can still be programmed to 44 to maintain backward compatibility. Current releases of software (MCD 4.0 upwards) use a default DSCP value of 46, while the older IP sets and software may also use a default DSCP value of 44. An example of programming needed for a router is given in the appendix (see page 308 and page 311).
Network Configuration Concepts into the Expedited Forwarding class with DSCP value 46. Note also that a number of access Layer 2 switches can overwrite the DSCP value based on the incoming Layer 2 priority information. Ensure that such ports use a consistent DSCP value, in this case 46. With a Layer 3 device, such as a router, the packet-per-second (PPS) throughput is also important.
Engineering Guidelines Network topology with priority The following network diagram highlights the use of the dual-port phones and the configuration of a network including VLAN priority and also the use of DiffServ/TOS in the WAN connection. Figure 35: Network Topology with Priority In Figure 35, the network switch ports connected to the dual-port phones must be able to accept both untagged and tagged information. The untagged data is translated to a data VLAN (1).
Network Configuration Concepts In a Cisco based environment the recommended settings are: • Voice Packets: DSCP: 46, 802.1p:5 • Signalling Packets: DSCP: 26, 802.1p:3 • Other Packets: DSCP:0 802.1p:0 For Cisco based environments refer to “Network QoS settings in a Cisco Environment” on page 248. LAN QoS policies The 3300 can apply different LAN QoS policies to voice packets, signalling packets and other packets. The LAN Policy (QoS) form in ESM is used for setting the LAN QoS policy values.
Engineering Guidelines The COS values run from 0 to 7. Typically 7 is the highest value, 0 the lowest. However, newer standards and switches define a COS 2 as “best effort” with 0 and 1 as lower. Also, the default setting on some switches might place COS 5 into the expedite queue, potentially giving this higher priority than 6 and 7. Check these settings on the switch to ensure correct and expected operation.
Network Configuration Concepts Each LAN connection includes both a transmit pair of cables as well as a receive pair of cables. In a full duplex Ethernet connection, data can be sent and received at the same time. The transmit and receive pair of connections are not shared within the network device (typically a layer 2 switch). Thus, the local phone sends 100 kbps (G.711) on the transmit pair of cables. It also receives a similar transmission.
Engineering Guidelines Maintaining Availability of Connections The quality of service for signalling measures how long a user needs to wait before a service becomes available, or whether the user becomes blocked from using a function. For example, delays in receiving dial tone, or blocking that occurs if there are insufficient PSTN trunks degrade the quality of service. Quality of service can be ensured by proper provisioning.
Network Configuration Concepts WAN traffic working example In this example, assume the following configuration: • 50 IP phones at the corporate centre. • 10 IP phones over a T1 link at a remote site. • Trunk traffic is 65% of all traffic. • Traffic between remotely located IP phones stays local to the remote site (it does not traverse the WAN link).
Engineering Guidelines Solutions that come from this example can then be covered by: • Compression (G.729a) to the remote phones can be used to increase the voice channel capability. However, it also reduces voice quality, which may not be acceptable. • The WAN link bandwidth can be increased. • The blocking ratio can be changed to P.01, and such a link would handle 68.8 CCS. • The number of remote phones or the overall number of phones can be reduced.
Network Configuration Concepts exceeded, an alternative path is tried through ARS, either through a different node connected by IP trunks, or through the PSTN TDM network. The value of the IP trunk restriction is set for a particular connection. This setting relies very much on traffic and also the bandwidth available. Since the bandwidth is derived from the number of conversations, it is important to understand which CODEC is used across the link (G.729a, G.711, or a combination of both).
Engineering Guidelines Figure 37: IP trunk limit example Table 66: IP networking limit calculations Calculation Formula Result Traffic from IP sets Number of sets (250) x 6 CCS 1500 CCS Percentage networked Total traffic x 15% 225 CCS Percentage traffic intercom Networked traffic x 35% 79 CCS Percentage traffic trunk to PSTN Networked traffic – intercom traffic 146 CCS Total Number of IP trunk channels needed ErlangB on total IP trunk traffic (225 CCS) 13 channels (P.
Network Configuration Concepts Note: • Seven channels are needed for internal traffic and ten are needed for external traffic, but together the total is only 13. The reason is that a number of channels have shared use: in this case, it is 4 (10+7-13). The higher G.711 rate is used to ensure adequate bandwidth at all times. • This data rate is close to a T1 rate.
Engineering Guidelines 226
CHAPTER 13 NETWORK CONFIGURATION SPECIFICS
Network Configuration Specifics Network Configuration Specifics The previous chapter “Network Configuration Concepts” on page 191 covered a number of general guidelines that may be applicable depending on the network to be used. This chapter highlights a number of specific network guidelines. Table 67: Network Configuration Specifics Section Topic “Start-Up Sequence and DHCP” on page 230 Describes DHCP and how the various protocols (LLDP-MED and CDP) affect IP Phone network policy.
Engineering Guidelines Start-Up Sequence and DHCP The previous chapter “Network Configuration Concepts” on page 191 dealt with network conditions and call traffic. However, before any of this can occur, the system first needs to be installed and the phones need to obtain their operating software. Refer to Table 78 for VLAN priority information. “LAN Policy” consists of a set of three parameters that are used to control segregation and priority of voice traffic across the network.
Network Configuration Specifics Sources that can be used to obtain network policy information Table 68 indicates which LAN Policy parameters can be obtained from each of the different sources of information. Table 68: Sources of Network Policy Information Phone IP Address Default Gateway IP Address Subnet Mask Manual entry Yes Yes LLDP-MED N/A CDP Source of Information VLAN (802.1Q) Information L2 QOS Priority (802.
Engineering Guidelines Note: If a phone has obtained network configuration information via manual programming, this information will be held by the phone permanently, i.e. other methods cannot overwrite these values and the values will be maintained even if the phone is rebooted.
Network Configuration Specifics Table 70: Priority levels for the Various Sources of L2/L3 QoS Settings Source of L2 & L3 QoS Settings Priority Level Notes Manual Entry (Static) 5 Programmed by installer DHCP 4 The first time a phone receives DHCP information it must contain an IP address for the RTC and the TFTP server. This is also true for the double DHCP fetch mechanism. If the phone fetches DHCP information a second time, this information will over write the previous values.
Engineering Guidelines Since these values are non-user programmable they cannot be changed by the system administrator. These values do not provide the correct priority levels for voice media at either L2 or L3, therefore the use of these values will potentially cause severe voice quality issues. The Solutions: 1. If it is a requirement to keep LLDP-MED running on the Cisco switches: • Leave LLDP-MED running on the Cisco switches.
Network Configuration Specifics When it is desired to use separate voice and signalling priorities, Mitel recommends the following: • Voice DSCP 46, 802.1p '6' • Signalling DSCP 26, 802.1p '3' • Other DSCP 0, 802.1p ‘0’ The new Cisco LAN Policy defaults pre-defined in AutoQoS are: • Voice DSCP 46, 802.1p '5' • Signalling DSCP 24, 802.1p '3' • Other DSCP 0, 802.1p ‘0’ The legacy Cisco LAN policy settings are: • Voice DSCP 46, 802.1p '5' • Signalling DSCP 26, 802.1p '3' • Other DSCP 0, 802.
Engineering Guidelines The sequence above assumes that the phones get information from a DHCP server. The information can also be manually entered into a phone as it starts to boot up, to make sure the information is fixed and requires little DHCP intervention. This method is particularly useful if a phone is used on a remote WAN link and the router cannot forward DHCP requests, or if a local DHCP server does not exist. It is also useful on VPNs, for the same reasons.
Network Configuration Specifics LLDP-MED and using scopes In many situations, especially where part of the network uses different LAN policy from other parts, use of LLDP-MED may simplify network configuration. The appropriate LAN policy values can be applied directly to the L2 switching gear in each section of the LAN separately, rather than creating and managing multiple scopes in the DHCP server.
Engineering Guidelines Table 71: Phones and LLDP-MED Names (continued) Phone Model Name Reported in LLDP-MED 5220 Dual Mode "MITEL 5220 DM" 5224 Dual Mode "MITEL 5224 DM" 5235 Dual Mode "MITEL 5235 DM" Navigator "MITEL NVGT" 3000 IP "TELEMATRIX 3000IP" 5304 IP Phone "MITEL 5304 IP" 5312 IP Phone "MITEL 5312 IP" 5320 Dual Mode "MITEL 5320 DM" 5320e "MITEL 5320e IP" 5324 IP Phone "MITEL 5324 IP"; 5330 Dual Mode "MITEL 5330 DM" 5330e "MITEL 5330e IP" 5340 Dual Mode "MITEL 5340 DM"
Network Configuration Specifics Table 72: IP Phone and VLAN Programmability (continued) Device IEEE 802.
Engineering Guidelines 5302 Startup and DHCP DHCP options will be used to inform the 5302 of servers that can be contacted to register and retrieve the profiles. RFC 3925, Vendor-Identifying Option exchange (options 124/125) will be used as the primary mechanism for conveying the addresses of these servers. The 5302 will transmit a DHCP discover message containing the option 55 (Parameter Request List). Within the request list, each endpoint will include option 124 (Vendor Class Identifier).
Network Configuration Specifics DHCP Option Reclassification Mitel’s legacy IP device configuration approach, using DHCP options 128 – 135 is still supported, but the preferred methods based on either DHCP options 124/125 or 60/43 are recommended. The standards based options (124/125 and 60/43) will remove potential DHCP conflict with other devices and manufactures that may be using the same DHCP server for optional information.
Engineering Guidelines Table 73: Mitel-Internal current DHCP Option Usage (continued) DHCP option Field Type Description 132 long word 802.1Q Layer 2 VLAN ID 133 long word 802.1Q/D Layer 2 Priority 134 long word Diffserv Code Point (DSCP) 135 string HTTP Proxy for phone-specific applications Unused options MUST be left blank. Conflict may arise where a number of different devices exist within the same subnet or DHCP scope (e.g.
Network Configuration Specifics Vendor information data format (options 125 and 43) For vendor information returned in either options 125 or 43, the following common string encoded vendor identifier is used followed by one or more string encoded tag/value pairs: “id: ... “ where: is the Mitel discrimination string “ipphone.mitel.
Engineering Guidelines Table 74: Tag / Value Pair Definitions Type (old option) Tag Data Type Description SW load TFTP server IP address (128) sw_tftp IP Address list TFTP server IP address, to retrieve software loads Call Server (ICP) IP address (129) call_srv IP Address list 1 to 4 ICP IP addresses Remote Analysis Server IP (131) ipa_srv IP Address 1 IP address (port optional) Voice VLAN ID (132) Vlan Integer IEEE 802.
Network Configuration Specifics DHCP Lease Time To allow users to move off the local subnet, or to let new users join a subnet, a method is needed to give up an IP address and to obtain a new address. If a phone is disconnected, it obviously cannot talk to the DHCP server, so another method is needed to free up unused addresses. DHCP lease time clears out unused IP addresses and makes them available for new requests. The timer can be set from a few minutes to months.
Engineering Guidelines Block size is not user configurable on either the 3300 or the phone, however TFTP block size could be user configurable on some 3'rd party external TFTP servers. In situations where phones are accessing an external TFTP server over a very slow connection reduce, if possible, the transmitted block size from 4096 to a smaller number; 512 or 1024.
Network Configuration Specifics VMPS, CDP, and Location Change Indication (E911) The MiVoice IP Phones at Release MCD 4.0 and higher include: • Support of dual-port IP phone operation in the presence of Cisco VLAN Membership Policy Server (VMPS) security and dynamic VLAN configuration. • Voice VLAN configuration via CDP.
Engineering Guidelines • To use dual port phone functionality when using VMPS then CDPv2 with the auxiliary VLAN set must be used. • Location Change information can be collected by the IP phones using CDP. If this functionality is required using CDP then CDP must be enabled on the IP phone ports. STP • Redundant connections from the 3300 ICP to the network Layer2 switches are allowed when Spanning Tree functionality is enabled on the controller.
Network Configuration Specifics In a Cisco based environment the recommended settings are: • Voice Packets: DSCP: 46, 802.1p:5 • Signalling Packets: DSCP: 26, 802.1p:3 *(see note, below) • Other Packets: DSCP:0 802.1p:0 * Note: Newer Cisco installations will support DSCP 24 especially if Autqos is used. Older Cisco installations may be configured for DSCP 26. Check the network to determine which is active.
Engineering Guidelines be equally configured. The Ethernet switch ports must not be set to portfast because the 3300 ICP is an active device in this protocol. Table 77: Multiple Network Connections Product Release Multiple Network Connections Loop Handling in 3300 ICP Release MCD 4.0 and higher Yes Basic STP When multiple connections are made to the 3300 ICP, the ports should have: • No Portfast: that is, Portfast must be disabled • One of three Spanning Tree Protocols enabled: a.
Network Configuration Specifics MiVoice IP Phone The MiVoice IP Phones are compatible with CDP and are able to utilize this information for VLAN and location change discovery, when available. In order to ensure that these work as expected, it is recommended that ports connected to MiVoice IP Phones and using CDP have the cdp timer and cdp holdtime values left at their default values of 60 and 180 seconds respectively. If enabled, cdp advertise-v2 should be left in the default state.
Engineering Guidelines 1. Manual Entry at boot time 2. LLDP-MED 3. CDP 4. DHCP. The ability to provide partial information at each stage allows these modes to be used together to ease installation. For example, the IP phone’s IP address may be supplied manually, but the RTC address could be picked up via DHCP. Also, CDP does not provide priority (COS) information, so the VLAN could be picked up from CDP, but the priority (COS) provided by DHCP.
Network Configuration Specifics The commands required to change the network port settings are: Switch(config)# interface fastethernet0/1 Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan 100 Switch(config-if)# mls qos trust cos Switch(config-if)# mls qos cos 0 Switch(config-if)# wrr-queue cos-map 4 5 Switch(config-if)# priority-queue out Switch(config-if)# switchport voice vlan 2 Switch(config-if)# spanning-tree portfast Switch(config-if)# end Switch# The above set of comm
Engineering Guidelines messaging compatibility with CDP overcomes this limitation. Thus, an IP phone that is compatible with the Auxiliary_VLAN setting in CDP can be used with another attached device, such as a PC. An IP phone that cannot determine the Auxiliary_VLAN setting will be treated as a single end device, and require an entry in the VMPS database.
Network Configuration Specifics • Static secure ports cannot become dynamic ports. Security on the static, secure port must be turned off before it can become dynamic. • Trunk ports cannot become dynamic ports. Trunks must be turned into access ports before being changed from static to dynamic in order to work with VMPS. • A port that enters the “shutdown” state blocks all access. This includes a connected IP phone, if the attaching PC is not accepted.
Engineering Guidelines • It can specifically deny access to certain recognized devices, e.g. most unknown devices might go to a guest VLAN, but certain rogue devices will be specifically blocked. In this mode, the port may be set to simply deny access, or to shut the port down. Shutting down a port is a good way to restrict access, but it will also affect the operation of the phone, or any other device, attached to this port. CAUTION: Shutting down a port could be considered a form of denial of service.
Network Configuration Specifics Network Considerations This section describes a number of specific items to consider for the 3300 ICP network: • “NetBIOS and PC Settings” on page 257 • “Wireless Phone Performance on the 3300 ICP” on page 258 • “Fax and modem connections over IP using G.711 Pass Through” on page 261 • “DTMF Signalling over IP Networks” on page 263 • “T.38 FoIP Guidelines” on page 263 • “Bandwidth Management” on page 268 • “T.
Engineering Guidelines Wireless Phone Performance on the 3300 ICP SpectraLink wireless phones Mitel has partnered with SpectraLink to provide wireless IP phone connectivity to Mitel’s 3300 ICP. The SpectraLink e340 and i640 Wireless Telephones, which are IEEE 802.11b (WI-FI) compliant, support Mitel’s MiNET signalling protocol. The SpectraLink e340 and i640 phones do not use a unique device type. These phones register with the IPC as Mitel 5220 IP phones.
Network Configuration Specifics The DeTeWe DECT-IP, OPS27 wireless phones can be registered as resilient phones. The OPS27 phones register with the ICP as Mitel 5220 IP Phones and the Resiliency Guidelines for MiVoice IP Phones are also applicable to these DECT-IP phones.
Engineering Guidelines However, there are additional issues, unique to wireless LANs, that must be taken into consideration when designing a wireless LAN. These issues are best addressed by consulting the appropriate wireless phone documentation. Detailed information regarding SpectraLink equipment, network engineering guidelines and numerous discussion papers can be found on the Spectralink web site. The URL is http://support.spectralink.com/SpectralinkService/support/us/support/voice/index.html.
Network Configuration Specifics Other considerations Depending on the particular installation, the following issues may need to be considered: • E-911 is not supported on wireless phones. Users should not place 911 calls from these phones or the database entry should be entered manually to point to the default building entrance point. • Transmission of data and voice over an RF link presents potential security issues that system administrators and users should be aware of.
Engineering Guidelines G.711 Fax pass through performance guidelines Due to the many variables involved in sending Fax data over G.711 pass-through on IP trunks, there is no guarantee of reliable transport. However, practical experience has shown that, with some careful network considerations, such a link can be made to work. These considerations include: • The IP trunk link must use G.711 only. • The rate of packet loss on the link must be less than 0.1%. • The link delay must be below 200 ms.
Network Configuration Specifics • The rate of packet loss on the link must be less than 0.1%. • The link delay must be below 200 ms. • Jitter must be less than 30 ms (ideally less than 20 ms). Do not expect MODEM speeds to exceed 22.8 kbps. WARNING:MODEM SIGNALS REQUIRE A SPECIAL CONNECTION SETUP TO BE SENT OVER AN IP NETWORK; AS A RESULT, IT IS NOT RECOMMENDED TO SEND MODEM SIGNALS OVER AN IP NETWORK AT THE PRESENT TIME.
Engineering Guidelines T.38 is not supported on any of the server platforms, since it is a conversion between TDM and IP transmission, and these platforms do not have any TDM lines or trunks. T.38 is supported on the following platforms: • 3300 MXe • 3300 CX/CXi • 3300 CX/CXi II • 3300 AX DSP II The DSP II card contains eight DSP devices and is required to support T.38. An individual DSP device on the DSP II can be loaded with eight T.
Network Configuration Specifics • Placing a voice call and then switching to Fax will work as long as the Fax call is initiated within 60 seconds of the set going off-hook. • Switching to voice after a Fax transmission has completed is not recommended. • The T.38 solution supports V.17 Fax calls at 14,400 bps or lower. • Mitel's T.38 solution does not support V.34 (Super G3) Fax calls, however if a V.34 capable machine is set to operate in V.17 mode then the call can be handled as a T.38 call.
Engineering Guidelines Resources required • T.38 is a licensable option. Licenses can be purchased in increments of four. • A maximum of 56 T.38 sessions are supported on a DSP II card. • At the start of a fax call an echo canceller is used. Once the call switches to T.38 mode, the echo canceller is placed in by-pass mode but continues to be allocated for the duration of the call. • At the start of a call a Fax Tone/V.21 detector is used to determine if the call is a fax call.
Network Configuration Specifics • The SI Tool, AMC and the MiConfig Wizard can be used for T.38 license configuration. Inter-zone default profile • There is only one profile available for inter-zone Fax traffic. • This profile determines how Faxes will be handled when transmitted between devices located in different zones.
Engineering Guidelines • For most applications, the default values of 3 for the low speed portion of the Fax call and 1 for the high speed portion should be fine. • Error Correction Mode (ECM) should be enabled if this capability is supported and enabled on both Fax machines. • Non Standard Facilities (NSF) capabilities. Whether or not to enable this capability requires experimentation. What happens if there are insufficient DSP resources or T.
Network Configuration Specifics Voice Network Limits Packet Loss Jitter End-to-End Delay < 0.5% < 20 ms < 50 ms Green = Go < 2% < 60 ms < 80 ms Yellow = Caution > 2% > 60 ms > 80 ms Red = Stop Fax over G.711 pass Through Packet Loss Jitter End-to-End Delay < 0.1% < 20 ms < 300 ms Green = Go < 0.2% < 40 ms < 500 ms Yellow = Caution > 0.2% > 40 ms > 500 ms Red = Stop T.38 UDP, Low Speed Redundancy = 0, High Speed Redundancy = 0 Packet Loss Jitter End-to-End Delay < 0.
Engineering Guidelines T.38 UDP, Low Speed Redundancy = 8, High Speed Redundancy = 3 Packet Loss Jitter End-to-End Delay < 7% < 1000 ms < 6000 ms < 10% < 2000 ms > 10% > 2000 ms Green = Go Yellow = Caution > 6000 ms Red = Stop T.38 Alarms T.38 load alarm For Release MCD 5.0 SP2 a new alarm has been added called ‘T.38 Load Alarm’. The purpose of this alarm is to indicate if there is an issue with the T.38 software/hardware/configuration when the system starts up.
Network Configuration Specifics Q: What QoS settings are used for T.38 packets and signalling? A: T.38 packets are transmitted using the same QoS settings as voice. QoS for T.38 cannot be programmed independently of voice QoS settings, T.38 and E2T (Voice) traffic share the same global variable for the QoS setting. Q: How does the 'loopback' method used to allow T.38 to interoperate with NuPoint work? A: Because NuPoint does not support T.
Engineering Guidelines Although the list can be used to open access across a firewall, where a firewall and NAT are used (for example, at the Internet), there might be issues with simply opening up ports from a functional and security viewpoint.
Network Configuration Specifics Table 80: MiVoice Business and 3300 ICP port numbers (continued) IP port number Transport Function 5060 TCP SIP 5061 TCP/UDP SIP-TLS 5432 TCP MiVoice Business Console to SQL Server – Call History 5320 TCP Mitel OIG 2.0, SDK 6.0 (MiTAI Driver), LBG 3.
Engineering Guidelines connections on the first available port in the range from 49500 to 49549. (Usually 49500 unless other Data Services apps are running on the same PC.) Ports 9000 and 9002 are used by the legacy 5550 IP Console application only. The MiVoice Business Console uses ports in the 50000 to 50511 range. With extended capabilities of the E2T on certain 3300 ICP it is recommended that the full RTP port range of 50000-50511 now be opened up.
Network Configuration Specifics TCP / 20,21 (FTP) TCP / 20, 21 (FTP) TCP / 23 (Telnet) UDP / 67 (DHCP) TCP / 68 (DHCP) User Application/ PC TCP / 80 (HTTP) TCP / 443 (HTTPS) TCP / 22 (SSH) TCP / 53 (DNS) AMC (Licenses) DNS UDP / 67 (DHCP) UDP / 68 (DHCP) UDP / 69, 20001 (TFTP) TCP / 80 (HTTP) TCP / 443 (HTTPS) IP Phone TCP / 3998 (SACS) MiVB TCP / 3999 (SAC) TCP / 6800, 6801, 6802 (MiNET, SecureMiNET) UDP / 50000...50511 (Voice Media/RTP/SRTP) UDP / 50000...50511 (RTP/SRTP) UDP / 50000...
Engineering Guidelines TCP / 1752 (SMDR) 6110 Contact Center Management TCP / 15373 (ACD Real Time Events) 6115 Interactive Contact Center TCP / 8000, 80001 (MiTai, Secure MiTai) 6140 Agent Portal TCP / 8000, 80001 (MiTai, Secure MiTai) TCP / 6800, 6801, 6802, 6803 (MiNet, Secure MiNet) TCP / 8000, 8001 (MiTai, Secure MiTai) UDP / 50000...50511 (Voice Media/RTP/SRTP) UDP / Ephemeral (Voice Media/RTP/SRTP) UDP / Ephemeral (Voice Media/RTP/SRTP) 6160 Intelligent Queue UDP / 50000...
Network Configuration Specifics TCP / 80, 443 (HTTP, HTTPS – Web Services) TCP / 6800, 6801, 6802, 6803 (MiNet, Secure MiNet) TCP / 5500...12670 (MiNet) TCP / 8000, 80001 (MiTai, Secure MiTai) NuPoint UDP / 50000...50511 (Voice Media/RTP/SRTP) UDP / 50000...50479 (Voice Media) UDP / 50000...50479 (Voice Media) UDP / 50000...
Engineering Guidelines Voice First (VCON) TCP / 8000, 8001 (MiTai, Secure MiTai) TCP / 80 (HTTP) TCP /443 (HTTP) Web Services TCP / 20, 21 (FTP) TCP / 222 (FTPS) TCP / 443 (HTTPS) Software Installer TCP / 2002 (FTPS) TCP / 7011 (Data Services) TCP / 49500...49599 (Data Services) Port defined through port 7011 UDP / 161 (SNMP) UDP / 161 (SNMP) UDP / 162 (SNMP-Trap) Emergency Response Adviser TCP / 8000, 8001 (MiTai, Secure MiTai) TCP / 7011 (Data Services) TCP / 49500...
Network Configuration Specifics TCP / 80, 443 (MiXML, Secure MiXML) UCA Server TCP / 8000, 8001 (MiTai, Secure MiTai) TCP / 6800, 6801, 6802 (MiNet, Secure MiNet) UDP / 50000...50511 UDP / 50098...50508 (RTP, SRTP) UDP / 50098...50508 (RTP, SRTP) UCA Softphone (MiNet) UDP / 50000...50511 TCP / UDP / 5060, 5061 (SIP, SIP-TLS) UDP / 50000...50511 UDP / 50098...50508 (RTP, SRTP) UCA Softphone (SIP) UDP / 50098...50508 (RTP, SRTP) UDP / 50000...
Engineering Guidelines Internet Access TCP / 80, 443 (HTTP, HTTPS) TCP / 8080 (HTTP) Web Proxy DNS TCP / 6880 (HTTPS) UDP / 53 (DNS) UDP / 67 (DHCP) DHCP UDP / 68 (DHCP) TCP / UDP / 5060 (SIP) PC/UCX UDP / 67 (DHCP) UDP / 68 (DHCP) UDP / 69, 20001 (TFTP) TCP / 80 (HTTP) TCP / 443 (HTTPS) TCP / 3998 (SACS) MiVB TCP / 3999 (SAC) TCP / 6800, 6801, 6802 (MiNet, SecureMiNet) TCP / 6900...6999 (MiNet, SecureMiNet) UDP / 50000...50511 (Voice Media) UDP / 50000...50511 UDP / 50000...50511 UDP / 50000..
Network Configuration Specifics DNS UDP / 53 (DNS) UDP / 67 (DHCP) DHCP MS-LCS UDP / 68 (DHCP) TCP / 5060 (SIP/Presence) UDP / 67 (DHCP) UDP / 68 (DHCP) TCP / 1606 (CSMSG) TCP / 6800, 6801, 6802 (MiNet, Secure MiNet) TCP / 6900 (MiNet) IP Console (PC) TCP / 7011 (Data Services) TCP / 49500...49599 (Data Services) Port defined through port 7011 TCP / 7050 (SDS) TCP / 7050 (SDS) TCP / 443 (Secure MiXML) TCP / 10000, 10002 (MiNet, Secure MiNet) UDP / 50000...
Engineering Guidelines DNS UDP / 53 (DNS) UDP / 67 (DHCP) DHCP UDP / 68 (DHCP) TCP / 5060 (SIP/Presence) TCP / 6806 (SSL CSMSG) IP Console (PC) TCP / 6801, 6802 (MiNet, Secure MiNet) TCP / 6900...6999 (MiNet) TCP / 6807 (Secure MiXML) TCP / 10000, 10002 (MiNet, Secure MiNet) UDP / 50000...50511 (TX Recording) Teleworker MiVoice Border Gateway UDP / 50000...
Network Configuration Specifics UDP / 53 (DNS) DNS UDP / 67 (DHCP) DHCP MiCollab/ UCA SQL (Call History) MS Exchange UDP / 68 (DHCP) TCP / 18100 (SIP/Presence) TCP / 5432 (SQL DB) IP Console (PC) TCP / 443 (HTTPS/Calender) UDP / 67 (DHCP) UDP / 68 (DHCP) TCP / 1606 (CSMSG) TCP / 7011 (Data Services) TCP / 49500...49599 (Data Services) Port defined through port 7011 MiVB TCP / 6800, 6801, 6802 (MiNet, Secure MiNet) UDP / 50000...50511 (Voice Media) UDP / 50098...50508 UDP / 50098...
Engineering Guidelines UDP / 53 (DNS) DNS UDP / 67 (DHCP) UDP / 68 (DHCP) DHCP UDP/6806 (SSL CSMSG) IP Console (PC) UDP/1606 (CSMSG) MiVB TCP/6800, 6801, 6802 (MiNet, Secure MiNet) UDP/50000...50511 (Voice Media) MBG TCP/6801, 6802 (Secure MiNet) UDP/20000...30999 (Voice Media) UDP/50000...50511 UDP/20000...30999 (Voice Media) UDP/50000...50511 UDP/20000...30999 (Voice Media) IP End Device (IP Phone App) UDP/1024...65535 (Voice Media) UDP/20000...30999 (Voice Media) UDP / 50098...
Network Configuration Specifics Embedded firewalls The 3300ICP/MiVoice Business product and phones include micro-firewalls to protect against unexpected levels of activity and will restrict traffic and responses according to some built in rules. The 3300/MiVoice Business system will limit traffic based on current operating conditions and traffic expected to be handled. The phones use a “credit” system to limit unexpected packet rates and will discard if these limits are exceeded.
Engineering Guidelines Cables and Connections Although often hidden, the cable plant provides the connection between the end user and the data service (the IP phone and 3300 ICP). Because data is sent at high speed, there are requirements that need to be met in order to get the best performance.
Network Configuration Specifics wiring schemes are always preferred as they can be connected in star and ring configurations with little change within the building. Ethernet cable distances Cable runs for Ethernet are specified up to 100 m when the correct cable type is used. This includes the internal building wiring as well as patch leads at either end. The limitation on this distance is quite strict and operation is not guaranteed beyond a total length of 100 m.
Engineering Guidelines Straight and crossover cables Two types of cable connection are used to connect between network equipment devices and also from the network equipment to the end equipment: • Straight connection, used to connect end users to the network (for example, an IP phone to a switch) • Crossover connection, used to connect between network equipment (for example, between switches) The connections between devices contain pairs of wires to transmit data and to receive data.
Network Configuration Specifics Figure 51: Using Wire Color Order to Identify Connection Cables The cables shown are those expected in new installations, namely, a T568A connection to a T568A for a straight cable, and a T568B connection to a T568A for a crossover cable. It is also possible to get straight cables that have a T568B connection to a T568B, but these are more likely in older installations. International standards recommend that new installations conform to the T568A wiring format.
Engineering Guidelines Interconnection Summary The following illustrations provide a summary of the different interconnections between the ICP and associated peripheral cabinets. The analog interfaces both on the ASU and on the embedded Analog Main Board/Analog Option Board (AMB/AOB) have not been shown. These are standard telecom wiring, and likely use RJ-11 connections with a single pair.
APPENDIX A CAT 3 WIRING
CAT 3 Wiring CAT 3 Wiring Practices Category 3 (CAT 3) refers to a type of UTP copper cabling that meets specific transmission characteristics (see CAT3/EIA/TIA-568 wiring standards). CAT 3 also refers to the installation practices observed when routing these cables as well as the interconnection and end point termination methods used. The following sections detail further practical issues to be used in conjunction with the specification.
Engineering Guidelines 294 • It is highly recommended not to connect PCs to the phones, and to connect these on a separate LAN infrastructure. The second port on the IP Phones can be disabled in the SX-200 ICP through option 131 and COS setting 280. The second port on the IP Phones can be disabled in the 3300ICP/MiVoice Business Class of Service (COS) form, option 193, under the heading “PC Port On IP Device – Disable”.
CAT 3 Wiring Summary of CAT 3-specific Network Configurations There are a number of different installation combinations and devices that can run with CAT 3 cables. There are also many exceptions and variations that prevent this from working. The underlying principles in making the installation work are: • The devices connected via CAT 3 must be restricted to 10BaseT operation only. • Standard 10/100/1000 auto-negotiation will not guarantee to restrict to 10BaseT with CAT 3 cable and should be avoided.
Engineering Guidelines Figure 54: CXi/CXi II Minimum Cable Standard Note: Selection of the network port settings differs on the CXi/CXi II platform depending upon whether it is configured as an SX-200 ICP product or a 3300 ICP product. On the SX-200 ICP product a single port setting applies to all ports. On the 3300 ICP product the ports can be configured individually.
CAT 3 Wiring Figure 55: CX, MX, MXe, AX, and LX Minimum Cable Standard 297
Engineering Guidelines 298
APPENDIX B INSTALLATION EXAMPLES
Installation Examples Using Cisco Routers and Catalyst Switches The Cisco 2600 series routers tested were running Software (C2691-JS-M), Version 12.3(9) and the Catalyst C3550 Software (C3550-IfQ3L2-M), Version 12.0(20)EA1. Basic Rules • To segregate traffic, voice and data devices should be run on separate VLANs • To transmit VLAN information and Ethernet priority between switches, the inter-switch connections must be defined as VLAN Trunks. We recommend IEEE 802.1Q VLAN trunks.
Engineering Guidelines Note: MiVoice IP Phones set the 802.1q bits as they are using VLAN tagged traffic. However the ICP controller does not send VLAN tagged traffic and so cannot set Ethernet priority. The switch port the controller connects to should set the Ethernet priority. This also applies to other non-VLAN aware VoIP devices, such as NuPoint Unified Messenger Rel. 8.5. It is important that QoS be set up in the network end to end, not just in a few places.
Installation Examples MiVoice IP Phone Each MiVoice IP Phone must know (as a minimum) • its own IP address • its subnet mask • its default gateway • its VLAN (not required by a PC) • its controller (not required by a PC). Note: A PC will also have other settings such as DNS and WINS that the MiVoice IP Phone does not require. IP settings on a MiVoice IP Phone can be assigned: • Statically or • Dynamically using DHCP (the 3300 has an integrated DHCP server.
Engineering Guidelines The WAN link shown is a serial interface but could be any technology (Frame Relay, ATM, MPLS). Figure 56: Example Network Topology Ethernet Switch 1 configuration There are four physical connections in the example topology for Ethernet Switch 1. 1. Fa0/2 to the 3300 ICP 2. Fa0/4 to IP Phone extension 2001 3. Fa0/5 to Ethernet Switch 2 4. Fa0/24 to Router 1 port Fa0/0 In this example VLANs are being assigned to the IP phones using CDP.
Installation Examples These steps are to set up QoS on the Catalyst 3550 and create the Voice VLAN.
Engineering Guidelines Switch1(config-if)# switchport mode trunk [sends VLAN information across the link] Switch1(config-if)# priority-queue out [makes queue 4 a strict priority queue] Switch1(config-if)# exit Interface fa0/5 is the VLAN trunk connection between Switch 1 and Switch 2. For Ethernet priority information to be sent between the switches the VLAN trunk must be configured.
Installation Examples Interface fa0/2 is connected to a MiVoice IP Phone that is capable of sending VLAN tagged Ethernet frames. When learning the voice VLAN via CDP (as configured), an 802.1p value of 5 is initially assumed. However, if the Mitel proprietary DHCP option 133 is used then this will overwrite the initial value. Mitel recommends an 802.1p value of 6 (unless using Cisco auto-qos). By default 802.1p value 6 is a member of queue number 4.
Engineering Guidelines Interface fa0/2 is connected to a MiVoice IP Phone that is capable of sending VLAN tagged Ethernet frames. When learning the voice VLAN via CDP (as configured) an 802.1p value of 5 is initially assumed. However, if the Mitel proprietary DHCP option 133 is used then this will overwrite the initial value. Mitel recommends an 802.1p value of 6 (unless using Cisco auto-qos). By default 802.1p value 6 is a member of queue number 4.
Installation Examples Programming the IP addresses Router1# configure terminal Router1(config)# interface s0/0 Router1(config-if)# description "To Telco" Router1(config-if)# ip address 172.16.1.1 255.255.255.252 Router1(config-if) encapsulation ppp Router1(config-if)# no shutdown Router1(config)# interface fa0/0 Router1(config-if)# description "Default Gateway for 10.0.0.0/24 Network" Router1(config-if)# ip address 10.0.0.1 255.255.255.
Engineering Guidelines Create Class Maps Router1(config)# class-map match-all MitelClassMapIn Router1(config-cmap)# match access-group name Mitel [Matches the ACL created above] Router1(config)# class-map match-all MitelClassMapOut Router1(config-cmap)# match ip dscp ef [Matches the DSCP value of 46] Create the Policy Maps Router1(config)# policy-map MitelPolicyIn [Only required if default DSCP is being changed] Router1(config-pmap)# class MitelClassMapIn [Matches the class map looking for Mitel tra
Installation Examples Now place the policy maps on the interfaces Router1(config)# interface fa0/0 Router1(config-if)# service-policy input MitelPolicyIn [applying the inbound policy map] Router1(config)# interface fa0/0.
Engineering Guidelines Programming the IP addresses Router2# configure terminal Router2(config)# interface s0/0 Router2(config-if)# description "To Telco" Router2(config-if)# ip address 172.16.1.2 255.255.255.252 Router2(config-if) encapsulation ppp Router2(config-if)# no shutdown Router2(config)# interface fa0/0 Router2(config-if)# description "Default Gateway for 10.0.10.0/24 Network" Router2(config-if)# ip address 10.0.10.1 255.255.255.
Installation Examples Create Class Maps Router2(config)# class-map match-all MitelClassMapIn Router2(config-cmap)# match access-group name Mitel [Matches the ACL created above] Router2(config)# class-map match-all MitelClassMapOut Router2(config-cmap)# match ip dscp ef [Matches the DSCP value of 46] Create the Policy Maps Router2(config)# policy-map MitelPolicyIn [Only required if default DSCP is being changed] Router2(config-pmap)# class MitelClassMapIn [Matches the class map looking for Mitel traf
Engineering Guidelines Now place the policy maps on the interfaces Router2(config)# interface fa0/0 Router2(config-if)# service-policy input MitelPolicyIn [applying the inbound policy map] Router2(config)# interface fa0/0.
Installation Examples option 130 ascii "MITEL IP PHONE" [required for the Mitel phones to accept] option 132 hex 0000.0064 [VLAN 100 in hex] option 133 hex 0000.0006 [802.1p priority 6] lease 14 [lease length in days] Remember to save your configurations! Using the CXi/CXi II or MXe Internet Gateway By default, the System IP Gateway IP address is the same as the L2 Switch IP address.
Engineering Guidelines other networks. The PCs and IP phones use DHCP Option 3 (which equals the L2 Switch IP address) to reach known intranet, and unknown internet networks.
APPENDIX C LLDP AND LLDP-MED CONFIGURATION EXAMPLES
LLDP and LLDP-MED Configuration Examples LLDP, LLDP-MED Overview LLDP (Link Layer Discovery Protocol – IEEE 802.1AB) provides a standards-based Layer 2 protocol for enabling network switches to advertise themselves and learn about adjacent connected LLDP devices. LLDP-MED (LLDP Media specific – ANSI/TIA-1057) is an extension to LLDP to provide auto-configuration and exchange of media related information, such as Voice VLAN and QoS, and is designed to provide enhanced VoIP deployment and management.
Engineering Guidelines The information advertised by LLDP-MED is obtained from various switch settings. These settings need to be configured in order to get the correct information on the relevant port. Note that some of these commands are used for other functions, which includes the policy enforcement, some of which operate on a VLAN or switch level, not just at the port. These areas are highlighted in the diagram below, and described in more detail in the following sections.
LLDP and LLDP-MED Configuration Examples The information to be advertised can come from a number of sources, but follows the general flow outlined below: • Defaults for LLDP-MED for voice at the Access Port are: Priority = 6; DSCP = 46. Defaults are overwritten with other information, if available and configured. • The lowest value voice VLAN ID that is enabled at the port will be used. If a voice VLAN is not identified, LLDP-MED will not be advertised.
Engineering Guidelines To ensure that the correct settings are applied, use the following sequence of commands: • Define Voice VLAN and assigned ports. • Define DSCP to Priority Mapping (optional) or voice VLAN priority settings (optional). • Define QoS Policy Enforcement at the access port (optional). • Ensure that LLDP is enabled.
LLDP and LLDP-MED Configuration Examples Assigning a port, or range, to a particular VLAN: HP ProCurve Switch 5304XL(vlan-63)# vlan 63 tagged a1 HP ProCurve Switch 5304XL(vlan-63)# show vlan ports a1 Status and Counters - VLAN Information - for ports A1 802.
Engineering Guidelines First, determine the current DSCP mapping. HP ProCurve Switch 5304XL(config)# show qos dscp-map DSCP -> 802.p priority mappings DSCP policy ------------000000 000001 . . 101101 101110 . . 111111 802.1p tag ---------------No-override No-override Policy name ---------------- No-override 7 No-override The DSCP value of interest is 46, or 101110 in binary format.
LLDP and LLDP-MED Configuration Examples An example of such a connection could be a softphone on a PC. The PC will run multiple applications, but will not be able to provide VLAN tagging or Priority information. Currently, voice applications will have a user, or predetermined DSCP value. In the case of a Softphone being used on a PC, then DSCP information is provided by the voice application, but Priority information and VLAN assignment must be configured at the access port on the switch.
Engineering Guidelines LLDP/LLDP-MED will advertise DSCP, VLAN and Priority from an untagged access port, but the VLAN and Priority values are only provided for informational purposes, since the end device is sending untagged frames and as such, will only be able to make use of the DSCP information.
LLDP and LLDP-MED Configuration Examples To redefine these setting the full information must be entered: HP ProCurve Switch 5304XL(config)# lldp config a1-a4 medportlocation civic-addr CA 2 1 ON 3 Ottawa 4 Kanata 6 "Legget Drive" Note: Spaces are used to separate the different fields, and so a name with an intended space must be enclosed in “quotation marks”.
Engineering Guidelines 63 64 100 No-override DSCP DSCP | | | 011010 No-override 4 3 The remote device can also be interrogated to determine the settings it is using.
LLDP and LLDP-MED Configuration Examples TLVS Advertised: * port_descr * system_name * system_descr * system_cap * capabilities * network_policy * location_id * poe * macphy_config IpAddress Advertised: The capabilities option and network policy are both needed for auto configuration of the end devices. The different services can be enabled or disabled through the following commands.
Engineering Guidelines 330
APPENDIX D VOIP AND VLANS
VoIP and VLANs VoIP Installation and VLAN Configurations Although this section refers to VLAN configurations, it can also be used to consider whether or not VLANs are needed for a particular installation. There are, currently, six configurations that have been identified. These are not expected to cover all possible configurations, there will always be exceptions, but as a guideline for the more general installations.
Engineering Guidelines Standalone CXi, voice only This is a self-contained configuration, with only the CXi unit involved in the network. There are only voice devices connected to the CXi. There is only a single device at each egress point of the Layer 2 switch, and so there are no contention issues with data. There are also no data devices, so assigning priority to voice is meaningless, since all voice devices will have equal priority.
VoIP and VLANs Standalone CXi without expansion switch, dedicated voice and data ports In this configuration, the CXi controller becomes the network, albeit limited to 16 ports. There are no egress queuing issues since each device, either voice or data, has its own dedicated port. In this situation, the internal switching bandwidth of the internal Layer 2 switch exceeds that from the external ports. There is no need for priority mechanisms, hence no requirement for VLANs.
Engineering Guidelines For the controllers, or servers, VLAN and priority is also needed. However, this can be configured in different places. The VLAN, and priority, information can be added at the network access point. In this case all information will carry the voice VLAN, but will also carry equal priority for all services. It is also possible to differentiate services and overwrite the VLAN priority by mapping the type of service (Layer 3) priority field into the VLAN priority field.
APPENDIX E VOIP SECURITY
VoIP Security Security Support with Mitel VoIP A number of devices in the Mitel IP product range now include additional security measures. These include: • Encryption of voice and signalling payload data • Network Access Authentication (802.1X) Encryption is used to “hide” the information that is carried in the payload from unauthorized users and applications. Network access authentication is a method to restrict connections to the network, or guide the device to particular parts of the network.
Engineering Guidelines When the data is encrypted, it is simply replaced with a scrambled version. This is a 1 for 1 transformation, so there are no additional bytes. As a result, the bandwidth is the same for encrypted or non-encrypted information. This is NOT true for Secure RTP (SRTP) which appends either 4 or 10 bytes to the voice payload depending on the cipher mode used. See “Voice streaming security (SRTP)” on page 341.
VoIP Security phones on two controllers will require the establishment of three secure signalling channels, that is, a secure connection at each controller and one between the controllers. Figure 60: Media and Signaling Path Encryption The signalling paths with security do not take different network routes compared to those without security. The only difference is that the contents of the payload are encrypted.
Engineering Guidelines Mitel's Secure MiNET protocol uses the Advanced Encryption Standard (AES) to encrypt call control packets. Using secure MiNET ensures that call control signalling packets between the IP phones and the 3300 ICP are protected from eavesdropping. Using secure MiNET also protects the 3300 ICP from unauthorized control packets. Secure MiNET uses a predefined algorithm to encode the signalling messages.
VoIP Security Voice streaming to internal voice mail, Record-a-Call and conference Where there are internal features like voice mail, Record-a-Call or conference at the ICP, these are considered TDM devices. Encryption applies to the packet part of the connection, so the IP path to the gateway will be secure, where possible. The connection on the TDM devices will remain a dedicated connection to the requested service. A conference call with a number of users requires multiple connections to the IP gateway.
Engineering Guidelines Table 84: Security Support by Device (continued) Device Secure Signalling (SSL) Secure Signalling (Secure MiNET) Voice Encryption Phones 5001 No Yes Yes 5005 No Yes Yes 5010 No Yes Yes 5020 No Yes Yes 5201 No Yes Yes 5205 No Yes Yes 5207 No Yes Yes 5212 Yes Yes Yes 5215 No Yes Yes 5215 (Dual Mode) Yes Yes Yes 5220 No Yes Yes 5220 (Dual Mode) Yes Yes Yes 5224 Yes Yes Yes 5230 No Yes Yes 5235 (Dual Mode) Yes Yes Yes 5140
VoIP Security Table 84: Security Support by Device (continued) Device Secure Signalling (SSL) Secure Signalling (Secure MiNET) Voice Encryption 5550 IP Console No Yes N/A 5550-TKB Yes Yes Yes 5560 IPT Yes Yes Yes MiCollab Client Yes Yes N/A MiCollab Client Softphone Yes Yes Yes MiCollab Client Server Yes Yes N/A SpectraLink wireless No No No DECT wireless Yes (TLS) No Yes Teleworker Server Int Yes Yes Yes Teleworker Server Ext Yes Yes Yes Speak@Ease (6500) No N
Engineering Guidelines Authentication Protocol Support A number of networks now support a level of access restriction to the network ports. A device that connects to one of these ports needs to be authenticated as valid before connections can be established. There are a number of protocols that can do this, including: • Cisco VMPS • 802.1X The Cisco VMPS is described in “VMPS, CDP, and Location Change Indication (E911)” on page 247.
VoIP Security • the port could be opened to a guest VLAN • the port could be shut down. When a PC is connected to a port, it will be interrogated in the same manner as the phones, and user input will be required. The same results will likely occur. Typically, 802.1X will only allow a single device to be authenticated and connected to a port. This restricts how devices can be connected into the network infrastructure.
Engineering Guidelines Note: In some cases, network administrators may be running 802.1X to prevent unauthorized users from accessing the network. As an example, Ethernet drops in semi-public spaces such as reception areas would likely be protected with 802.1X. Use caution if deploying phones that do not support 802.1X in these situations, because the network administrator will not be able to enable 802.1X on this network port.
VoIP Security Table 85: 802.1X support by device Device 802.1X Support 5330e Yes 5340e Yes 5485 IP Pager No 5550 TKB No 5560 IPT Yes DECT wireless No Navigator Yes SpectraLink wireless No UC360 Yes MiCollab Client Server If on PC MiCollab Client Softphone If on PC Worm and virus protection The 3300 ICP uses an embedded real-time operating system.
Engineering Guidelines Secure management interfaces The 3300 ICP includes a fully integrated set of management tools designed to install, manage, and administer 3300 ICP systems. Three levels of access are provided in order to meet the needs of system technicians, group administrators, and the desktop telephony users themselves. All of these integral management tools use Secure Socket Layer (SSL) security for data encryption. User access to the management tools is controlled by a login and password.
Glossary Glossary ACD – Automatic Call Distribution. A package of advanced call processing features, relating to groups of agents who handle calls and agent supervisors. AMC – Applications Management Center. Used to activate new hardware and software licenses for Mitel products. ARP – Address Resolution Protocol. Used to identify a MAC address against an IP address. ARS – Automatic Route Selection.
Engineering Guidelines Controller. Control element of ICP (see also RTC). COS – Class of Service. This refers to the priority value in the Layer 2 part of an IP packet when IEEE 802.1p is used. CPH – Calls Per Hour. For example, 6 CPH means 6 calls per hour. CSM – Customer Service Manager. Former name for MiContact Center Office, an entry level contact center solution hosted on MiCollab for basic contact centers or workgroups with up to 100 agents. CSMA/CD – Carrier Sense Multiple Access Collision Detect.
Glossary routers at Layer 3 to direct the data to an appropriate queue. Value 46 is recommended for voice and will use the Expedited Forwarding queue or Class of Service. DSP – Digital Signal Processor. This is a programmable device that can manipulate signals, such as audio, to generate and detect a range of signals, e.g. DTMF signalling. DSU – Digital Service Unit. A peripheral which provides digital ports for the ICP. DTMF – Dual Tone Multi-Frequency.
Engineering Guidelines ICP – IP Communications Platform. Includes gateway function, call control, plus a number of other features, such as voice mail. IP Address – Internet protocol address. A 32-bit address assigned to hosts using TCP/IP. An IP address belongs to one of five classes (A, B, C, D, or E) and is written as 4 octets separated by periods (dotted decimal format). Each address consists of a network number, an optional subnetwork number, and a host number.
Glossary information such as Voice VLAN and QoS. It is designed to provide enhanced VoIP deployment and management. LS – Loop Start. This is a particular analog trunk protocol for signalling incoming and outgoing calls. MAC – Media Access Controller. This is the hardware interface that data (media) travels through. Typically this will be assigned a world-wide unique address. MAN – Metropolitan Area Network.
Engineering Guidelines NAT – Network Address Translation. A means of translating internal IP addresses to a defined limited range of internet IP addresses. The benefit is the ability to use a limited range of internet addresses and map these to a much larger internal range. NIC – Network Interface Card. Physical connection to the network. In a PC, this is often a plug-in card. NSU – Network Services Unit. This interface connects between the PSTN Primary Rate trunks and the ICP. ONS – On-Premise Line.
Glossary RAD – Recorded Announcement Device. RAID – Redundant Array of Independent Disks. Array of hard drives on which the information is duplicated. A controller manages the disks, switching automatically from the primary to the secondary in the event of the failure of the primary hard drive. RDN – Remote Directory Number. The Remote DN Table is used to identify alternate ICPs to check for availability of devices, and to determine if a device is located on the Primary or Secondary ICP.
Engineering Guidelines Subnet – A subnet (short for “subnetwork”) is an identifiably separate part of an organization's network. Typically, a subnet may represent all the machines at one geographic location, in one building, or on the same local area network (LAN). SWB – Mitel Sales Workbench. T.37 – Internet Protocol for FAX (Store and Forward). A means of taking a TDM FAX, converting it to data, passing it via IP and reconverting it back to TDM. T.38 – Internet Protocol for FAX (Real Time). Similar to T.
Glossary VM – Voice Mail. WAN – Wide Area Network. A network connection to a network that could be global, e.g. via Frame Relay. Wi-Fi – Wi-Fi Alliance technology for Wireless LAN based on IEEE 802.11. WLAN – Wireless LAN. WAV – WAVe file. Wav is an audio file format, created by Microsoft, that has become a standard PC audio file format for everything from system and game sounds to CD-quality audio. A Wave file is identified by a file name extension of .wav.
Engineering Guidelines 360
Index Index default configuration 50 flash card capacity 29 maximum configuration 33 voice mail server 29 NUMERICS 1400, performance 113 3300 ICP compression limitations 186 configuration table 30 IP ports 271 multiple network connections 249 overview 9 port numbers 272 power requirements 87 system capabilities 220 system configurations 15 3300 Software Applications 121 embedded music 123 emergency services 129 external hot desk users 121 voice mail 122 5220 IP phone options power requirements 108 5540 C
Engineering Guidelines codec selection 181 Commands for changing network port settings 253 Compression 167 3300 ICP controllers 187 CODEC 201 conference 187 device license requirements 190 E2T compression 187 guidelines 186 internal 3300 ICP devices 187 introduction 185 IP applications 187 IP networking routes 188 IP phones 186 IP trunk routes 190 license 155, 161 license availability 156 licenses, IP networking 190 music on hold 187 NuPoint Unified Messenger 187 operation factors 223 voice mail 187 zones
Index IEEE PoE power advertisements 101 In Line Ethernet AC power adapters 92 Installation examples Basic QoS 301 Basic rules 301 Catalyst switches 301 Cisco routers 301 Define the IP addressing 302 Define the VLAN 302 Ethernet switch 1 configuration 304 Ethernet switch 2 configuration 306 Ethernet switch 3 configuration 307 MiVoice IP Phones 303 Network topology 303 Router 1 configuration 308 Router 2 configuration 311 Installation planning, PoE 95 Installation practices 87 Inter-device traffic 200 IP dev
Engineering Guidelines LX 113 default configuration 50 maximum configuration 41 M Mailbox license 161 Maintaining availability of connections 220 Maximum configuration AX controller 33 CX II/CXi IIcontroller 37 CX/CXi controller 35 LX controller 41 MXe controller 38 other limits 43 Maximum ICP parameters 30 sizes 30 MCD IDS license 157 Minimizing interference 87 Mitel Open Integration Gateway 149 MiVoice Business Console access connections 73 maximum number suipported 61 MLPP license 157 MSPLogs Viewer 27
Index Options for IP phone powering 90 Other maximum limits 43 P Paging, limits on number of E2T channels available for 45 PC settings 257 Performance limitations 1400 LX 113 ACD environment 115 Hunt Groups 116 Ring Groups 116 Phone advertises Class 101 Phone power consumption local power 96 PoE 96 remote CDP 99 remote IEEE PoE 101 remote LLDP-MED 104 Planning installation guidelines 3 PMS (Property Management System) license 157, 162 PoE cable power loss 96 IEEE 802.
Engineering Guidelines calculating 113 multiple processors 113 processor load, factors 113 single processor 113 System upgrades 49 Uninterruptible power supply 108, 109 Upgrading the system 49 UPS 108, 109 advanced license 156, 161 capacities 122 encoding formats 123 license 161 network bandwidth 30 networked 122 networking license 156, 161 using ICP as dedicated voice mail server 29 Voice over IP installation requirements 197 voice quality 181 Voice quality of service bandwidth requirements 206 maintain
