Failure Analysis of Internet Protocol Terminal Equipment

Abstract

This article describes a fault that occurred in the transmission of voice signals in a customer’s Internet protocol telecommunication system and the analysis carried out to identify the problem. This is the forty-second article in a series on telecommunication technologies. This contribution is from the Network Interface Engineering Group, Technical Assistance and Support Center, Maintenance and Service Operations Department, Network Business Headquarters, NTT EAST.

Keywords: IP phone, PBX, VoIP gateway

1. Introduction

The Network Interface Engineering Group investigates the causes of puzzling and troublesome phenomena in Internet protocol (IP) network services such as the FLET’S HIKARI NEXT fiber-optic broadband service and also considers countermeasures. We do this by capturing and collecting IP packets in the Ethernet section dividing terminal equipment and telecommunication equipment and analyzing the data in those packets.

A typical customer premises network is configured with a voice over Internet protocol (VoIP) gateway for converting IP signals to analog or integrated services digital network (ISDN) signals for accommodation by terminal equipment. If a problem should occur in voice or facsimile (fax) communications on these circuits, it becomes necessary to analyze the data collected by measurement equipment.

We introduce here a case study in which we applied our analysis methods to the occasional occurrence of a one-way-voice problem in extension calls between two hubs on a private branch exchange (PBX)-accommodated extension telephone. A one-way-voice problem is when a voice signal is transmitted in only one direction.

2. Case study overview and investigation method

The customer had installed a PBX in hub A and a VoIP gateway in hub B and was making extension calls between these hubs via the FLET’S VPN WIDE virtual private network service. In this configuration, a one-way-voice problem was periodically occurring in extension calls between these two hubs.

The extension telephone on which the one-way-voice problem occurred was not a specific telephone, and it is known that the problem did not reoccur after remaking the call directly after the problem occurrence. The measures usually taken by maintenance personnel in the field to identify problems were to exchange telephones, exchange the PBX package, or collect data through packet capture at the time of problem occurrence and perform primary analysis. These measures, however, failed to find the cause of the problem, so the Technical Assistance and Support Center was called upon to conduct an investigation.

To collect and analyze data at the time of problem occurrence, we captured packets in the Ethernet section at the point marked with “” in Fig. 1.

Fig. 1. Connection configuration and data collection point.

3. Analysis of collected data

The results of analyzing Real-time Transport Protocol (RTP) packets at the time of problem occurrence are shown in Fig. 2.

Fig. 2. Results of RTP packet analysis.

3.1 Analysis results 1: Change in payload type

The analysis of captured data revealed that the payload type (PT)^*1 of RTP packets suddenly switched to “103” (Dynamic RTP-103) at the time of problem occurrence.

The customer’s system applies PT “0” indicating G.711PCMU—a pulse code modulation standard for voice communications—to voice calls, but at the time of problem occurrence in a certain voice call, the PT of RTP packets in both directions suddenly switched to “103” beginning at 9:07:34. Later, however, the PT of RTP packets only in the direction from hub A to the VoIP gateway returned to “0,” at which time the one-way-voice problem occurred.

To identify the purpose of PT “103,” we checked with personnel in charge of PBX development and learned that it is a PT used in fax communications. We were told that the PBX switches the PT to “103” on receiving a fax signal from a lower-level terminal.

3.2 Analysis results 2: Frequency components included in hold tone

We decoded the captured data collected in the Ethernet section into analog audio and analyzed the result using open source audio analysis software (WaveSurfer). We found that a frequency component of 1100 Hz, namely, a calling (CNG) signal (Fig. 3) used in fax communications, appeared in the audio signal directly before the problem occurred (Fig. 4).

Fig. 3. Format of CNG signal.

Fig. 4. Results of analyzing audio components.

This frequency component was included in the hold tone (tune: “Let It Be”) output by the extension telephone (stand-alone phone) accommodated by the PBX. An actual CNG signal is specified as the transmission of a 1100-Hz tone for a period of 0.5 s ±15% (0.425–0.575 s), but the analyzed audio included the transmission of a 1100-Hz tone for a period of 0.7 s, which was outside the CNG specified value. Nevertheless, we still considered the possibility that the PBX erroneously recognized the audio signal as a fax CNG signal and switched the PT to “103” accordingly, so we continued with our analysis.

Although the VoIP-gateway side also switched to PT “103” in step with the PBX side, no CED signal (called station identification: reply signal to CNG) arrived at the PBX, so the PBX switched back to PT “0.” However, the VoIP-gateway side did not subsequently switch back^*2 the PT, which seems to be the reason why voice transmission occurred only in the direction from the PBX to the gateway (one-way-voice state).

*1	Payload type (PT) in RTP indicates the digital encoding method applied to audio.
*2	No-switch-back operation is a PBX specification (confirmed by PBX development personnel).

4. Countermeasures

We proposed the following three countermeasures to suppress PT switching in the PBX:

Countermeasure 1: Set the PBX so as not to switch to PT “103” used for fax communications.

Countermeasure 2: Change the source of the hold tone.

Countermeasure 3: Exchange the PBX package to one with no function for switching to PT “103” for fax communications.

Of these countermeasures, we considered that countermeasure 1 would be the least burdensome for the customer and therefore implemented it to check its effectiveness. We did this by connecting the stand-alone phone actually used by the customer to a test PBX and noted that no one-way-voice problem occurred when transmitting the above hold tone during a call. On the basis of this result, we were able to confirm that the problem occurred because of the switch to PT “103” for fax communications even when the PBX was not conducting fax communications and that countermeasure 1 was effective in solving the problem.

5. Summary

The one-way-voice problem described in this report occurred for the following reason. On observing the transmission of an 1100-Hz audio component for 0.7 s closely resembling the CNG signal used in fax communications within the audio of the customer’s extension call, the PBX erroneously recognized that frequency component as a CNG signal and switched the PT of the RTP packets to “103” used in fax communications.

This problem was solved by setting the PBX so that it would not switch the PT to “103” for fax communications.

6. Conclusion

In IP network services, a system configuration that includes VoIP gateways and PBXs may use equipment with analog and ISDN interfaces. Solving problems that arise in such a system requires measurement equipment and analysis skills appropriate for each type of interface.

The case study presented here showed how analyzing both analog signals and Ethernet data led to a solution. Going forward, the team at the Technical Assistance and Support Center aims to contribute to solving troublesome problems in network services by analyzing signals and data in various types of interfaces using diverse tools and techniques.

↑ TOP