e work. If voice quality or connectivity problems existed, this demarcation point was an easy place to conduct testing and isolate whether the problem existed within your enter- prise network or whether it was the service provider's problem. TDM loop testing is com- mon, enabling the service provider to test the TDM loop to the edge of your network determine if the problem exists on that part of the connection. Bringing a SIP trunk into the enterprise removes this demarcation point and, therefore, also the problem isolation techniques that existed for TDM interconnection. If voice- quality problems occur, it can be difficult to isolate whether they are caused by some- thing in the service provider's network or by an element in your enterprise network. Using a CUBE as an IP demarcation point restores this troubleshooting capability, enabling testing within the enterprise network up to the CUBE and testing from the service provider's side to the CUBE to determine where a fault might exist. The IP loop can be tested in the same conceptual manner (RTP loopback capability and Service Assurance Agent [SAA] responder support) as the TDM loop to allow the service provider to determine if the service is causing a problem or whether the problem exists in the enterprise. Statistics Metrics, such as delay, jitter, and voice quality scoring, help enterprises and providers monitor and control the voice quality on their networks. These metrics can typically be derived only at the endpoint (DSP) of a VoIP call and not in the middle of it. (No DSP is involved in the middle of the call.) For calls on SIP trunks, it is necessary to calculate, or estimate, some of these metrics at the border element to reflect the quality of the call on the enterprise side of the network, separate from the metrics of the call leg on the service provider side of the network. Chapter 7: Design and Implementation Considerations 111 You can use different features to derive a reading of the metrics at the network border. One is to use transcoding on the 