Configuring Transparent Common Channel Signaling

When multiple PBXs exist in a private network, they are often connected using leased-line circuits from the PSTN as tie trunks between the PBXs. Many vendors have implemented proprietary protocols to carry features such as number display, name display, and networked voice mail across these tie trunks. This method makes the multiple PBXs appear to end users as a single, virtual PBX with a common dial plan and common features across all locations.

A disadvantage of this design is that dedicated pointto-point circuits are required between the PBX locations. If several locations exist, it might be necessary to implement a mesh design for the tie trunks. This can be a costly design, because there is a monthly recurring cost to each of these circuits. Further, you cannot use these circuits for any other purpose, even when call volume is low. Standard PRI or CAS circuit implementations on voice gateways do not work because of the proprietary protocols in use.

T-CCS allows the connection of two PBXs that use a proprietary or unsupported common channel signaling (CCS) protocol without the need for interpretation of CCS for call processing. The signaling is passed through transparently to the other side.

Using a T-CCS implementation, the PBX voice channels are nailed up (made permanent) and compressed between sites. You can transmit the accompanying signaling channel or channels transparently across the data network between the locations. Thus, the voice gateway does not route the calls from the PBXs on a call-by-call basis; instead, it follows a preconfigured, permanent route to the destination.

You can implement T-CCS in two primary ways:

• Frame forwarding mode You can only use frame forwarding T-CCS to support PBX proprietary protocols where the signaling channel or channels are HDLC-framed and the desired VoX technology is Voice over Frame Relay (VoFR) or Voice over ATM (VoATM). In this solution, the high-level data link control (HDLC) signaling frames are encapsulated and forwarded through a channel group that is configured for the signaling on the controller. The HDLC framing is interpreted and understood, although the signaling messages are not looked at or acted upon. Idle frames are suppressed, and only real data is propagated across the signaling channel.
• Clear-channel mode Clear-channel T-CCS is used to support PBX proprietary protocols in which the signaling channel(s) are ABCD-bit based or HDLC, or where the voice transport technology is Voice over IP (VoIP). In this solution, the signaling channel and voice channels are configured as DS0 groups, and all are treated as voice calls.

The voice-bearer channels are permanent trunk connections and can be compressed if desired using the voice coder/decoder (codec) of your choice. The signaling channel is also permanently connected using the clear-channel codec. The clear-channel codec passes the signaling transparently to the other side.

Use of frame forwarding mode has declined in recent years as networks have moved to an IP infrastructure and VoIP has gained popularity. When T-CCS is implemented today, it is almost always done using clear-channel mode. With clear-channel T-CCS, there is no intelligence in the software to know which channels are voice channels and which are signaling channels. You must configure the timeslots that you know carry signaling traffic to match a dial peer that assigns the clear-channel codec. The voice channels must match a dial peer that can encode voice using a compression codec scheme, such as G.729.

Figure 7-6 shows the flow of the traffic between Site A and Site B. Note that the signaling channel passes through transparently, whereas the voice channels are compressed before being sent over the network. This optimizes the use of the data network bandwidth while keeping the signaling intact.

Figure 7-6. T-CCS Clear Channel Signaling Flow

The channels on the proprietary digital trunk from the PBX at Site A are disassembled in the voice gateway. The signaling channel is passed through transparently. The voice gateway does not see or act on any of the signaling information on the channel. The voice-bearer channels are sent individually on permanent connections between the voice gateways. You can compress voice channels by using a compression algorithm, such as G.729. At Site B, you can reassemble the channels and pass them across the digital trunk in their original form to the PBX.

To configure T-CCS, you need to begin by creating a DS0 group for each channel on the controller that you want to transport. Each DS0 group contains a single timeslot. The type is defined as external signaling using the ext-sig parameter of the ds0-group command, as shown in Example 7-18.

Each DS0 group that is defined creates an associated voice port. After the voice ports are created, you must set them up as trunk connections using the connection trunk word command. In this case, word is the telephone number of the corresponding trunk on the far end of the connection. You can assign these numbers arbitrarily as long as they do not conflict with any other number used in the system. When you are configuring the trunk connections, configure one side to answer the call. You can do this by using the connection trunk word answer-mode command. Only use the answer-mode subcommand on one side of the trunk connection.

After you have configured the trunk information, you need to add a POTS dial peer for each voice port. The number on the destination pattern must match the telephone number of the trunk on the far end of the connection and is defined using the destination-pattern number command. The port must be the local voice port that connects to the far-end trunk.

You also need to set up VoIP dial peers to make the connection to the remote side. Be sure you create a separate dial peer for the bearer and signaling channels. The bearer channels can use whatever codec is appropriate, but G.729 is the default. The signaling channel must use the clear channel codec to function properly. You configure this by using the codec clear-channel command.

A complete sample configuration for Site A and Site B is shown in Example 7-19.

When the configuration is complete on both ends, the trunks should become active. These trunks are permanently connected between the two voice gateways.

You can use the show voice port summary command to verify that the trunks are connected correctly, as shown in Example 7-20.

You can also use the show voice call summary command. This command shows you the codec in use for each connected trunk, as demonstrated in Example 7-21. Note that in this example, timeslot 24 is the signaling channel and is using the clear channel codec.