Basics for Trunk Testing
In the PSTN, trunk testing is used to validate that a bearer circuit is properly set up as the SS7, ISDN, and other call signaling information is routed through the network. Trunk testing became more important in the PSTN when call signaling was disassociated from the bearer circuits. When signaling was placed in a different circuit, and ultimately in a whole different network, from the trunk circuits carrying the voice, it became possible to establish a call via the signaling but then find out that a bearer circuit had not been connected because of provisioning errors, wiring issues, or other problems.
Trunk testing also provides the carrier with the opportunity to test echo cancellation devices and other equipment designed to maintain voice quality in the PSTN.
Considerations for a Converging Network
The concept of trunk testing is still valid at the PSTN/packet network boundary and in a network model that has a packet core.
At the PSTN/packet network boundary, trunk testing is an easy way to validate that the digital signal processors (DSPs) in the media gateway are functioning correctly and that PSTN trunks and packet connections are properly terminated. It also allows the carrier to ensure correct provisioning of the softswitch or call agent so that calls are routed to the right TDM circuits or packet streams.
On a network level, use of trunk testing in a packet environment serves the same function as it does in today's PSTN. Given the ability of a signaling packet to go in a "different" direction than a voice packet or given that a carrier might establish a "signaling only" packet network for security purposes, signaling and voice are still disassociated from one another. Trunk testing allows a carrier to validate that all circuits are functional and all switching elements, either circuit- or packet-based, are properly provisioned.
Practical Testing Schemes
- Local: This approach, shown in Figure 5, has the advantage of being able to characterize a media gateway's performance independent of the network.

Figure 5
- Remote Loopback: This technique (see Figure 6) relies on a single piece of test equipment to measure the QoS across a network. While cost-effective, it does not give an accurate view of the VoIP network's performance, as there is no way to accurately compute the delay or packet loss across the network. It is impossible to determine whether transmission problems occur in the transmit path or whether they are incurred in the receive path. At best, an average of the network's performance can be determined using this method.

Figure 6
- End-to-End: This is the ideal approach (see Figure 7) for verifying voice QoS across a network, as it allows QoS characteristics to be determined for each transmit and receive path.

Figure 7


