Connecting to PBXs

Digital Trunks

Connecting the voice gateway to the PBX using digital trunks has many advantages. Among these advantages are higher capacity, more reliable signaling methods, and advanced features, such as caller number and name display.

Configuring E1/T1 Physical Layer Connections

Successful implementation of digital tie trunks between a PBX and a voice gateway begins with establishing correct physical connections. You must properly set line coding, framing, and clocking on each end of the link. When the PSTN service provider connects to a PSTN trunk, it establishes the parameters to use for the link. When you connect to a PBX, you typically have control over both ends of the link and can optimize the configuration for your particular application.

Line coding and framing configuration are discussed in detail in Chapter 6. Be sure that you configure these parameters in the voice gateway to match what is configured on the PBX.

Clocking

It is important that you understand how clocking will be set up on a digital trunk. Improper clocking configuration shows up as clock slips on the controller interface. Slips can cause a wide variety of voice problems, including poor voice quality, static, echo, and one-way audio. Understanding how to set up a stable clocking domain prevents these problems.

In addition to the trunks, Cisco voice gateways that have a built-in TDM bus must be clocked correctly for voice traffic to flow properly and to avoid problems. By default, the time-division multiplexing (TDM) bus uses the internal oscillator as a clock source. However, this causes problems with connected circuits that use a different clock source. You can use the show network-clocks command to see which of the available clock sources is currently being used to time the TDM bus. In Example 7-5, a primary and a secondary clock source are configured. The secondary source link is not active at the moment, and the primary is in use. The internal oscillator (called the Backplane in this output) is also listed as a "last ditch" clock source to be used if no better clock is available.

In Cisco Integrated Services Routers (ISR), you must synchronize the clock for the digital signal processor (DSP) resources on the motherboard with the circuit to be used. The DSP resources are clocked from the TDM bus.

When selecting a clock source to use, choose the best available one. PSTN circuits are generally the best clock sources available. Most PBX systems can pass the clock from a "master" source, such as a PSTN circuit, to other trunk ports. If the PBX has a PSTN circuit attached and can use that circuit as a master clock source, use the PBX timing on the tie trunk and set the voice gateway for loop timing, as shown in Figure 7-1.

Figure 7-1. Using PSTN Trunk to the PBX as Master Clock Source

With this configuration, you can also use the clock that you recovered from the PSTN (using the PBX) for the TDM bus within the gateway. Example 7-6 shows the configuration necessary. The network-clock-participate command enables the module on slot 1 to be a clock source for the TDM bus. The network-clock-select command sets clocking recovered on T1 1/0 to be used as the priority 1 clock for the TDM bus. If additional clock sources are available, you can add them as candidates using the network-clock-select command and different priorities. Only one clock is in use at any given time. In controller configuration mode, the clock source line command instructs the voice gateway to use the clock recovered from the bit stream received on that interface as a clock source, rather than the internal clock.

You can also reverse this configuration. If the PSTN trunk goes to the Cisco voice gateway instead of the PBX, the voice gateway can recover the clock from the PSTN circuit and use it to clock both the internal TDM bus and the tie trunk to the PBX, thus providing clocking for the PBX. Figure 7-2 shows an example of this scenario.

Figure 7-2. Using the PSTN Trunk to the Voice Gateway as the Master Clock Source

Example 7-7 shows the voice gateway configuration necessary. Notice that T1 1/1 goes to the PBX and uses the clock source internal command. That command gets clocking from the TDM bus, which is in turn being clocked by PSTN T1 1/0.

Another possibility is that two connections to the voice gateway exist and both are good clock sources. As an example, suppose that there is a PSTN trunk to the voice gateway, a PSTN trunk to the PBX, and a tie trunk from the PBX to the voice gateway. In this case, a viable clock source for the voice gateway exists on both ports. Figure 7-3 shows this scenario.

Figure 7-3. Multiple Usable Clock Sources

Example 7-8 shows the configuration of the voice gateway that is necessary to support this clocking scenario. The PSTN trunk uses the clock source line primary command, and the PBX trunk uses the clock source line command. The primary keyword indicates that, whenever possible, you should use the clock from the PSTN trunk to time the Phase-Locked Loop (PLL) on this controller.

When using a two-port network module, such as a VWIC2-2MFT-T1/E1 for two voice circuits, both ports must use the same clock source. The same DSP resources used for both ports and differences in clocking can cause sips and interface flaps. If multiple different clocks sources are present (such as circuits from different carriers), divide them across modules using different DSP resources. For example, one could use motherboard DSPs and another could use DSPs on a network module (NM), such as the NM-HDV2. In this case, you should not include the NM-HDV2 in the network-clock-participate list. Because the NM has a different clock than the other circuits in this example, it should not be a fallback candidate to clock the TDM bus.

For voice circuits, all interfaces that share a common pool of DSP resources must have synchronized clocks.

Verifying and Troubleshooting

You can verify the correct operation of the digital trunk at a physical level by using the show controller t1 | e1 slot/subunit/port command. The output shows a great deal of information about the current state of the link, in addition to historical information. This information can help you isolate problems with line coding, framing, and clocking of the link. In Example 7-9, you can see that numerous slips have been recorded, which indicates a clocking issue with the circuit. Notice in this example that the clock source is set to internal. This information can immediately lead you to investigate the clocking configuration as a starting point in troubleshooting.

Additional troubleshooting information, as well as a description of all the fields in the output of the show controller command, is covered in detail in Chapter 6.

Configuring ISDN PRI Trunks

Configuring a PRI trunk to a PBX and configuring one to the PSTN has two main differences:

• The need to determine the network versus user role Layer 2 communications are established on an ISDN link using a master-slave relationship. The master side is called the network side, and the slave side is called the user side. When connecting to the PSTN, the voice gateway is always the user side and the PSTN is always the network side. This is not necessarily the case when connecting a voice gateway to a PBX.

  PBX manufacturers typically assume that the PRI trunk ports will be connecting to the PSTN, so they default to user side. The Cisco voice gateway also defaults to user side. If a connection is made from user side to user side or network side to network side, Layer 2 communications are not established. You must decide which device will be the network side of the connection and configure it correctly. Many older or smaller PBX systems do not have the option of running the PRI trunk port as the network side.

  If this is the case, you need to configure the voice gateway to be the network side. You accomplish this by using the isdn protocol-emulate network command. You apply this command to the serial interface that is created when you define the pri-group.

• The need to determine the ISDN switch type to be used The ISDN switch type determines the format of the Layer 3 messages to be used on the ISDN D-channel. When you connect to the PSTN, the service provider specifies the ISDN switch type to use. When you connect to a PBX, it is important to select a switch type that is supported and provides the highest level of interoperability for supplementary services and information exchange.

  Many PBX vendors support "native" switch types that provide the highest level of capabilities for their systems. These include 5ESS for AT&T or Lucent, DMS-100 for Nortel PBX systems, and so on. Most PBX systems also support standard switch types such as NI2 for North America and NET5 for the UK, Europe, Asia, and Australia.

  The QSIG protocol was developed specifically to provide interoperability between PBXs and can be used if your PBX system supports it. Many PBX vendors have chosen to support QSIG only as an added cost upgrade. You can find more information about QSIG later in this chapter.

After you have the physical connection running and verified, have determined which side will be network and user, and have selected a switch type, you can begin to configure the PRI trunk.

Configuration begins by setting a global ISDN switch type for the voice gateway. You do this by using the isdn switch-type type command in global configuration mode. You can override this setting on a port-by-port basis later on if necessary. After you have defined the global switch type, enter controller configuration mode using the controller T1 | E1 slot/subunit/port command. Add the PRI group to the interface using the pri-group timeslots num command. The num parameter is 1-24 for T1 or 1-31 for E1. You can only create one PRI group on an interface. The Cisco IOS includes the D-channel automatically.

After you have defined the PRI group, IOS automatically creates a corresponding voice port and serial interface. You can manipulate parameters, such as locale, station name and number, and so on, on the voice port.

The serial interface is for controlling Layer 3 (and some Layer 2) functions. This is where you can override the switch type for an individual port, change the B-channel selection order, and configure network-side protocol emulation.

Example 7-10 shows a voice gateway connected to both the PSTN and a PBX. The PSTN is connected to T1 1/0, and the PBX is connected to T1 1/1. Twelve B-channels are available on the PSTN link, which is using the NI2 protocol. The PBX has all 23 B-channels available, and it is using the 5ESS protocol. The voice gateway is the network side of the PBX connection and the user side of the PSTN connection. It is deriving clock from the PSTN trunk and supplying clock to the PBX.

Verifying and Troubleshooting

For the PRI to be operating properly, the Layer 1, Layer 2, and Layer 3 protocols must be functioning correctly. Layer 1 is discussed in the earlier section "Configuring E1/T1 Physical Layer Connections." To verify Layer 2, use the show isdn status command. If Layer 2 is up and operating, you should see the status Multiple Frame Established, as shown in Example 7-11.

In Example 7-11, the ISDN switch type that is defined globally is primary-ni, whereas the switch type for this interface is primary-5ess. This interface is defined as network side, and Layer 2 is up. If Layer 2 was not up, the status would show TEI Assigned instead of Multiple Frame Established. If Layer 1 is active, indicating that the physical circuit is available, the Layer 2 failure might be caused by having both sides of the connection defined as either user or network. You can diagnose this using the debug isdn q921 command.

Example 7-12 shows the output from a debug isdn q921 trace in which Layer 2 has failed to come up properly. Notice that the Layer 2 status is shown as TEI Assigned. This output shows that this router is the user side and is receiving bad frames. That likely means that the remote end of the connection is set up as user side, too. To correct this error, configure one side of the trunk as the network side and the opposite side of the trunk as the user side.

Example 7-13 shows the same interface after you have configured isdn protocol-emulate network.

Troubleshooting Layer 3 problems on a PRI that is connected to a PBX can be more difficult. If you are having problems with call completion, you can trace the Layer 3 messages with the debug isdn q931 command. Example 7-14 shows the output of a debug isdn q931 trace. The lobby phone at 919-555-3456 called 911 on B-channel 1, and the call ended normally. This trace validates that both the calling and called numbers are being passed correctly, the calling name is being provided correctly, and the calls can complete normally.

Occasionally, slight differences in the implementation of the Layer 3 protocol can cause problems, even though calls complete properly. These problems can manifest themselves as missing or improperly displayed caller name or number display, call transfer failures, and so on. Use the debug isdn q931 trace information in conjunction with placing test calls to verify that everything is working correctly. If you encounter problems that are related to variations in protocol implementation, the debug isdn q931 information can help you determine whether the problem is with the PBX or the voice gateway. You might also be able to find a case study on Cisco.com that can help. Cisco has tested interoperability with many brands of PBX systems and published case studies that can provide insight into the correct configuration parameters to use on both the voice gateway and the PBX.

MGCP

The configuration process changes when you use MGCP to control the T1 or E1 PRI trunk. The configuration on the voice gateway sets up MGCP control. This begins when you specify on the controller configuration that you will use the MGCP protocol. You do this by using the pri-group timeslots num service mgcp configuration command. When you are configuring CallManager MGCP, all the parameters that control the trunk are defined on the CallManager, rather than on the gateway. Further, the Layer 3 Q.931 traffic is backhauled to CallManager for processing. The Layer 3 backhaul is configured using the isdn bind-l3 ccm-manager command on the serial interface configuration.

Example 7-15 shows the full configuration parameters that are necessary to set up a CallManager MGCP-controlled T1 PRI tie trunk on controller 1/0. The IP address of the CallManager is specified on the mgcp call-agent command. The configured dial peer associates call control for port 1/0:23 to the MGCP application.

Figure 7-4 is an excerpt of the CallManager configuration showing how both the physical line and ISDN signaling information are configured for an MGCP-controlled PRI trunk. In CallManager configuration, the Protocol Side drop-down box controls whether the ISDN trunk operates as network or user side. You also configure line coding, framing, and clocking here.

Figure 7-4. CallManager Configuration of MGCP PRI

Verifying and Troubleshooting

You can verify the operational status of an MGCP-controlled PRI trunk by using the show isdn status command. In Example 7-16, you can see that Layer 1 is active, and Layer 2 shows Multiple Frame Established and is operational. The display also indicates that Layer 3 is backhauled to CallManager.

For information about the ISDN Layer 3 backhaul, use the show ccm-manager command, as shown in Example 7-17. Example 7-17 shows that the voice gateway is registered to a CallManager at IP address 10.1.5.2, and the backhaul link is open. The PRI at slot 1, port 0 is being backhauled, and you can see that messages have flowed across the backhaul link with no receive or transmit failures.

To view the traffic on the backhaul link, you can use the debug ccm-manager packets trace command. Although this command does show the actual traffic on the backhaul link, it is typically not as useful in troubleshooting as the debug isdn q931 trace command discussed in the previous section.

Q Signaling

The QSIG protocol is a set of international standards that define services and signaling protocols for private integrated services networks (PISN). QSIG is based on ISDN Q.921 and Q.931 and is a worldwide standard for PBX interconnection. QSIG allows you to route calls from one private integrated services network exchange (PINX) to another PINX using Cisco voice gateways. A PINX can be a PBX, key system, or CallManager node that supports the QSIG protocol. Using the QSIG protocol, all of the features that are available as a PBX user operate transparently across the network.

It is important to note that although many PBX manufacturers provide support for QSIG, the support is frequently not included as a standard feature; instead, it is offered as an extra-cost option. If the connection to the PBX is being made as an interim measure during a conversion to an IP telephony system, it might not make financial sense to pay for the QSIG option. Verify the status of QSIG support on the PBX prior to planning a QSIG implementation.

The Cisco QSIG implementation supports basic calls, identification and message waiting indication services, call forwarding, and call transfer. QSIG can transparently route call services from a PBX to a voice gateway, across a WAN or virtual private network (VPN) connection to another voice gateway, and back to a PBX. A far more common topology is a T1 or E1 PRI connection to a CallManager-controlled voice gateway.

Cisco has tested CallManager QSIG feature interoperability with the following PBX vendors: Lucent/Avaya Definity G3R, Avaya MultiVantage and Communication Manager all using T1 or E1, Alcatel 4400 using E1 or T1, Ericsson MD110 using E1, Nortel Meridian using E1 or T1, Siemens Hicom 300 E CS using T1, Siemens Hicom 300 E and Siemens HiPath 4000 both using E1.

CallManager supports many call features with QSIG, including the following:

• Retry on busy When the number you are calling is busy, you can request that the call complete when the busy destination hangs up the phone and becomes available.
• Retry on no answer When your call is not answered, you can request that the call be retried after activity occurs on the phone of the called party.
• Identification service The ability to present or restrict the display of caller or called party number and name is configurable in CallManager.
• Message waiting services Turn on or turn off voice mail message waiting indicator (MWI) indications based on QSIG directives. When a call that has been forwarded is redirected to voice mail, the called number can be determined through supplementary services, and the message is placed in the correct voice mailbox.
• Call forwarding and call transfer Forwarding and transferring calls.

QSIG offers a high level of functionality and provides interoperability between equipment from different manufacturers, making its use desirable on an interconnect tie trunk between a PBX system and a voice gateway in an IP telephony environment.

Configuration of a CallManager-controlled QSIG trunk is done in the same way as an MGCP-controlled ISDN PRI trunk. The QSIG protocol is selected with the isdn switch-type primary-qsig command on the voice gateway or by selecting PRI QSIG T1 or PRI QSIG E1 on the PRI Protocol Type drop-down box in CallManager. An excerpt of the CallManager configuration page with QSIG selected is shown in Figure 7-5. Note that this also enables the Connected Line ID Presentation field, which allows you to control the display of the connected line number.

Figure 7-5. CallManager Configuration for a QSIG Trunk

Configuring E1 R2 or T1 CAS Trunks

When setting up tie trunks to a PBX, it is always preferable to use a PRI or QSIG trunk if you can. Some PBX systems do not have PRI capability, which might force you to use a channel-associated signaling (CAS) trunk. If you must use an E1 R2 or T1 CAS connection, be sure to select a supported signaling method that provides the highest level of reliability and functionality.

Configuration of the interface on the voice gateway is done in the same way that it is for a PSTN connection. For more information, see Chapter 6.