Spirent Test Methodology IP Telephony Edition
Spirent Communications is a worldwide provider
of integrated performance analysis and service
assurance systems for next-generation network
technologies. Our solutions accelerate the profitable
development and deployment of network equipment
and services by emulating real-world conditions in
the lab and assuring end-to-end performance of large-
scale networks.
Spirent performance analysis solutions include
instruments and systems that measure and analyze
the performance of network equipment, particularly
the devices that route voice and data messages to
their destination. Our service assurance solutions
include remote test, fault and performance
management systems that let network service
providers quickly identify network faults and
monitor real-time performance.
Spirent’s integrated performance analysis and service
assurance solutions enable our customers to more
rapidly develop and certify new devices, lowering the
cost of widespread deployment and operation of new
network services.
Spirent Communications is a wholly owned
subsidiary of Spirent plc, an international network
technology company.
15200 Omega Drive
Rockville, MD USA
20850-3240
Tel: +1 301.417.1224
info@spirentcom.com
Americas
Tel: +1 800.927.2660
productinfo@spirentcom.com
Europe, Middle East, Africa
Tel: +33 1 6137.2250
salesemea@spirentcom.com
Asia Pacific
Tel: +852.2166.8382
spirentasia@spirentcom.com
http://scdn.spirentcom.com
Spirent Communications
Sales and Information
Spirent Communications Developers Network
www.spirentcom.com
IP Telephony Edition
© 2005 Spirent Communications Inc. All rights reserved. “Spirent” and “Analyze, Assure, Accelerate” are exclusive trademarks of
Spirent plc and its subsidiaries. All other names are trademarks of their respective owners and hereby acknowledged. Specifications
subject to change without notice.
P/N 340-5071-001 Rev A, 2/05
Spirent Communications
Test Methodologies
Spirent Communications Test Methodologies • IP Telephony Edition
Introduction
Welcome to the IP Telephony Edition of the Spirent Communications Test Methodologies resource book
series.
This volume contains four test methodologies that address common challenges in migrating circuit-
switched telephony networks to VoIP networks, with converged voice and data services.
The first test, Media Gateway: Signaling Protocols Functionality and Capacity, verifies interoperability of
a media gateway with existing PSTN signaling protocols and the translation into IP signaling.
Trunking Gateway: Media Gateway Control verifies the capacity, functionality and quality of voice pro-
cessing of a trunking gateway in two common scenarios.
The Signaling Gateway: SIGTRAN and SIP-T test analyzes the functionality and performance of a signal-
ing gateway when processing incoming messages from an SS7 or IP network, when using SIGTRAN and
SIP-T.
The fourth test, Converged Networks: Voice Quality Measurement in the Presence of Data, measures
voice quality in a converged voice and data network.
The fifth test is a three test case series: Fax Testing
These tests continue the subject of quality evaluation of converged voice and data networks. While fax
uses voice signaling to establish a call, the digital data is transmitted. These test methodologies pres-
ent fax testing options for PSTN and IP networks.
We hope these test methodologies help engineers and technical staff in their task of migrating legacy
voice networks into VoIP networks.
Spirent Communications
www.spirentcom.com
Spirent Communications Test Methodologies • IP Telephony Edition
Table of Contents
IP Telephony Edition
Media Gateway: Signaling Protocols Functionality and Capacity (TM-0179) . . . . . . . . . . . .1
Trunking Gateway: Media Gateway Control (TM-0184) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Signaling Gateway: SIGTRAN and SIP-T (TM-0181) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Converged Networks: Voice Quality Measurement in the Presence of Data (TM-0180) . . .11
Fax Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Spirent Communications Test Methodologies Information . . . . . . . . . . . . . . . . . . . . . . . . .22
1 Spirent Communications Test Methodologies • IP Telephony Edition
TM-0179
Media Gateway:
Signaling Protocols Functionality and Capacity
a73
ISDN PRI Q.931
a73
SS7 ITU-T Group of Standards
a73
DLC TR-NWT-000057 Telcordia
a73
SIP IETF RFC3261
a73
H.323 ITU-T Ver 5
a73
MGCP IETF RFC3425 Rev 1
a73
H.248 ITU-T Release 5
Objective
This test will demonstrate interoperability of a media gateway (MG) under test with in-band and out-of-band
PSTN signaling protocols and translate them into IP signaling. The test will determine the capability of the
gateway to process signaling protocols and communicate to the media gateway controller. The functionality
specified is employed in a converged voice network segment, where a signaling gateway and/or softswitch
are not used to process common channel signaling protocols such as SS7 and Q.931.
Overview
A media gateway is a network element residing at border points of PSTN and IP voice networks. MGs provide
in-band signaling and media interfaces between PSTN and IP networks. Media processing includes transla-
tions of TDM media and signaling information into RTP/RTCP and IP call control data. Media processed can
include voice, video, fax and sometimes modem streams translation and encapsulation. The network configu-
ration is shown below:
An alog
Phone
Modem
Fa x
PBX
Cl a ss 5
Sw it ch
An alog
Phone
IP Phone
IP
MG
MC G
TD M
TD M
Vo i ce , S i gn alin g
Vo i ce , S i gn alin g,
Dat a
An alog Vo i ce
An alog Dat a
Me d ia
Ca l l C ontr o l
Si gn alin g
Fa x
Spirent Communications Test Methodologies • IP Telephony Edition 2
To increase bandwidth efficiency, the MG can provide additional compression of voice and video streams by
using more efficient codecs, silence suppression and voice activity detection algorithms. Additional function-
ality can be added to support IVR, billing, conferencing, call hold and call transfer.
A test unit should emulate all interfaces, media and signaling protocols supported by the MG under the test.
The test unit should provide a call generator functionality to emulate IP phones, analog phones, fax and PBX.
Also, test unit should emulate MGC signaling interfaces for call setup, tear down and load profile. The call
generator will also send voice media in TDM and RTP stream formats for voice quality testing. The test will ver-
ify the proper operation and identify errors, signaling delays and voice quality. When errors, delays or voice
quality degradations occur, the test set will identify them, store and report so the operator
can determine whether the gateway functionality or capacity specifications were not met.
Test Setup
Two test scenarios must be performed to achieve the test objectives:
a73
Signaling protocols only, no voice.
a73
Voice quality measurements.
Test steps below cover both scenarios. The test unit should not be configured for voice quality measurements
when performing signaling only protocol testing.
Test Steps
Signaling Only
1. Verify the physical interfaces. Connect cables and make sure the correct interfaces are used:
10/100 Ethernet, Gigabit Ethernet, T1/T3, E1/E3 or Fibre.
2. Setup corresponding signaling protocols for test unit and SUT to signaling only.
3. Configure test unit to act as PSTN call generator, MGC call control unit and IP phone emulator.
4. Configure SUT and test unit capacity to correspond to each other. Start with a lower number
of channels.
This number should be enough to enable all signaling protocols for up to 10 pairs.
5. Start with generating calls from the TDM side and terminating at the IP side. Compare a number of calls
generated to a number of calls terminated.
6. Configure all originating calls from the IP side and terminating them at the PSTN side. You will want to
compare a number of originated and terminated channels.
7. Configure IP and PSTN sides for alternating originate and terminate calls. A number of terminating and
originating channels should be the same.
8. Gradually increase the number of channels until a reported number of terminated channels is not equal
to a reported number of originated channels, or when errors reported by test unit exceed thresholds.
TD M C al l
Gener ation
An alog C al l
Gener at or
MGC
Emu l at or
IP Phone C al l
Gener at or
Te s t Unit SUT
CAS, GR -303, S S7, ISDN, V .5
T1/E1, E1/E3, PRI, G747
Me d ia
Ga te wa y
DT M F, MFR
An alog
SIP , H.323
RT P /R T CP
MGCP , ME GA C O
3 Spirent Communications Test Methodologies • IP Telephony Edition
9. Analyze the traces and specific error events to identify the source of the errors.
Signaling and Voice
1. Setup the test unit configuration parameters to voice testing modes.
2. Verify a correspondence of codecs configured for each test.
3. Configure test unit and SUT for signaling protocols.
4. Choose a voice file to be used for path confirmation and specify which path confirmation algorithm will be
used to verify the voice path quality. The choice of a voice file depends on requirements to support silence
suppression, voice activity detection and call lengths. PESQ, PSQM and tones should be used with differ-
ent voice files. The test set should be able to measure voice quality on the TDM and VoIP ports.
5. Start by setting the call load at only a few calls to verify the signaling and media paths are configured cor-
rectly. At this point, take a baseline measurement of all parameters. These will be compared with measure-
ments at higher loads.
6. Once you are certain the signaling and media can transcend the network and complete a call, verify the
proper operation of the implemented features. Create various call configurations to verify that all features
operate as designed.
7. Use different codecs and packet payloads setting to load SUT.
8. Once the call completion and feature set have been verified, increase the call load to just under the
expected value at which the gateway might reach capacity. This can be done with a variety of distributions
including smooth ramp, stepped ramp, Gaussian or immediate.
9. Check for delays and other test parameters listed below. If there are no malfunctions, significant delays
or voice quality degradation, then increase the call setup rate and retest.
10. When you see errors, delays or malfunctions, you may have reached the capacity of that gateway. The
type of problem or delay can identify the component that limits the capacity. Decreasing a buffer or
increasing the processor speed can sometimes increase the capacity of the gateway.
Measurable Results
a73
BHCA.
a73
Call duration.
a73
Call set up time.
a73
Call tear down time.
a73
Call attempts.
a73
Call completions.
a73
Percentage of call completions.
a73
Call attempts per hour.
a73
Script attempts (number of tests).
a73
Percentage of script attempts.
a73
Errors received for active channels.
a73
Channels stopped with maximum allowable number of errors.
a73
Clipping.
a73
Ring duration.
a73
Bit error rate.
a73
PESQ value.
a73
PSQM value.
a73
MOS value.
a73
RTP packet loss rate.
a73
RTP packets out of order.
a73
RTP packets late arrival.
a73
RTP jitter.
a73
One way delay.
a73
Round trip delay.
Test Outcome
Attempted, Successful, Failed and Sessions Up at completion of test.
Expert Tip
Changes to the configuration may change the results significantly. Test with multiple SUT configurations
and with various ramp times.
Spirent Communications Test Methodologies • IP Telephony Edition 4
TM-0184
Trunking Gateway: Media Gateway Control
a73
RFC 2705 Media Gateway Control Protocol (MGCP)
a73
RFC 3015 MEGACO Protocol Version 1.0/2.0
This test methodology consists of two separate trunking gateway tests. Test Case 1 covers the most used
configuration in which a trunking gateway has a PSTN trunk on one side and an IP trunk on the other side.
Test Case 2, on the next page, covers testing for two or more trunking gateways connected to a network.
TEST CASE 1
Objective
This test will verify functionality and determine the capacity and quality of voice processing of a trunk-
ing gateway.
Overview
In this test case, we test the most used widely configuration in which a trunking gateway has a PSTN
trunk on one side and an IP trunk on the other side. The media gateway controller (MGC) provides a call
control. A test unit should emulate the PSTN and IP trunks as well as the media gateway controller.
Setup
Test Steps
1. Configure the media gateway (MG) to accept the test set as its MGC and provision the MG to open the
media path between the TDM side and IP side when needed.
2. Set the test set to use all the channels for which the MG is provisioned.
3. Determine the maximum CPS (calls per second) the MG can sustain without dropping calls.
4. Configure the test set to establish 75 percent of that CPS rate.
5. Start the test.
6. If test completes without errors, increase the CPS using the binary search* algorithm and repeat
Step 5.
7. If test completes with errors, decrease the CPS using the binary search algorithm and repeat
Step 5.
* For more information on binary searches, see D. E. Knuth. The Art of Computer Programming, Volume 3:
Sorting and Searching. Addison-Wesley, Reading, Mass., 1973.
5 Spirent Communications Test Methodologies • IP Telephony Edition
8. Record the last CPS rate where the test set did not generate an error.
a. Generate report.
b. Capture all results for every channel tested.
Test Parameters
None.
Test Outcome
a73
Maximum CPS the MG can sustain.
a73
Voice quality measurements.
a73
Call setup time.
TEST CASE 2
Objective
Test two or more trunking gateways for quality of voice processing, capacity, and functionality under
a heavy load.
Overview
It is useful to review a test case where two or more trunking gateways are connected in a network. In
this test case, the test set emulates two PSTN trunks connected to TGs, while the two TGs exchange
media traffic over ATM. This test case can be extended to any configuration where two or more TGs are
connected back-to-back and use any standard or proprietary media transmission protocols between
them. Both sides can be IP trunks; or, the sides can be either PSTN, or IP on one side and PSTN on the
other side.
Setup
Test Steps
1. Configure the TGs to accept the test set as its MGC and provision the TGs to open the media path
between the TDM side and IP side when needed.
2. Set the test set to use all the channels for which the TGs are provisioned.
3. Determine the maximum CPS (calls per second) the TGs can sustain without dropping calls.
4. Configure the test set to establish 75 percent of that CPS rate.
5. Start test.
6. If test completes without errors, increase the CPS using the binary search algorithm and repeat
Step 5.
7. If test completes with errors, decrease the CPS using the binary search algorithm and repeat
Step 5.
Spirent Communications Test Methodologies • IP Telephony Edition 6
8. Record the last CPS rate where the test set did not generate an error.
a. Generate report.
b. Capture all results for every channel tested.
Test Parameters
None.
Test Outcome
a73
Maximum CPS the MG can sustain.
a73
Voice quality measurements.
a73
Call setup time.
a73
Capacity of DUT.
7 Spirent Communications Test Methodologies • IP Telephony Edition
TM-0181
Signaling Gateway: SIGTRAN and SIP-T
a73
RFC 2719 Framework Architecture for Signaling Transport
a73
RFC 2960 Stream Control Transmission Protocol
a73
RFC 3332 SS7 MTP3 User Adaptation Layer (M3UA)
a73
RFC 3261 SIP
a73
RFC 2372 SIP-T
TEST CASE 1: SS7 Signaling Translation to IP with SIGTRAN
Objective
This test will determine the busy hour call attempts that a signaling gateway can handle. The test will
determine the capability of the softswitch to receive, process and manage the call setup messages
coming from the SS7 or IP side.
Overview
The SIGTRAN protocol provides transport of ISDN, SS7 ISUP messages between IP nodes and signaling
gateway (SG), media gateway controller (MGC), media gateway (MG) or IP-based database. Three main
components are the IP layer, SCTP transport layer and Adaptation layer. The IP layer is used for address-
ing, the SCTP transport layer is for reliable transfer of information between two nodes and the Adapta-
tion layer transport MTP3 user signaling (ISUP) over the IP link. The Adaptation layer runs independently
of the lower transport layers, but in this scenario it will use IP and SCTP.
The test set should emulate two devices in the telephone network: an STP in the SS7 network and the
softswitch (also known as the MGC) on the IP network. Call setup will be initiated on both sides (SS7
and IP). The call setup messages will flow through the signaling gateway and the test set will verify that
the transmission of the message is received correctly on the other side. For this scenario, the voice path
will not be set up nor tested.
Setup
Spirent Communications Test Methodologies • IP Telephony Edition 8
Test Steps
1. Connect the cabling for the signaling links (SL) to be in the test between the test set and
signaling gateway (DUT), using T1 or E1 and an Ethernet cable.
2. Provision and associate the SS7 SL:
a. Configure the test set to act as a minimum of one end points (SSP).
b. Configure the signaling point codes (SPC) on the test set and DUT.
c. Configure the circuit identification codes (CIC), to be controlled, on the test set.
d. Configure the desired number of link sets (SLS) with associated SLs on the test set and DUT.
e. Select the SS7 protocol variant(s), to be run across the network, on the test set and DUT.
f. Configure the test set to generate “signaling only” calls without any real voice traffic.
3. Initiate unblocking of SLs on the test set towards the DUT.
4. Provision the SIGTRAN SL:
a. Configure the test set and DUT to use SCTP as the Layer 4 protocol.
b. Configure test set and DUT with the IP address they will use to communicate.
c. Select the SS7 protocol variant(s), to be run across the network, on the test set and DUT.
d. Configure the route table and context on the test set.
5. Perform a test run to ensure the DUT and test set are configured correctly. Configure the test set to
initiate a low amount of calls across the DUT and verify the calls are being established.
6. Once it is certain that the signaling messages are traversing through the DUT correctly, increase the
number of calls being made by the test set to just under the expected value at which the DUT might
reach its capacity.
7. Check for delays and other test parameters listed below. If there are no malfunctions or significant
delays, increase the call setup rate and retest.
8. When the test set reports errors, significant delays or malfunctions, the DUT’s capacity may have
been reached. Altering configuration on the DUT may give different performance numbers. Turning
off unused services may relieve the DUT of some processing and memory usage leading to higher
performance numbers on the next run.
9. Record the last CPS rate where the test set did not generate an error.
a. Generate report.
b. Capture all results for every channel tested.
Test Parameters
a73
Utilize different SS7 protocols.
Test Outcome
a73
Maximum CPS the signaling gateway can sustain.
a73
Performance of the signaling gateway.
a73
Capabilities of the signaling gateway to handling different variances of SS7.
9 Spirent Communications Test Methodologies • IP Telephony Edition
TEST CASE 2: SIP-T
Objective
Test the signaling gateway’s abilities to transition SS7 ISUP messages to the IP network and vice versa with
SIP-T.
Overview
RFC 3372 states that SIP-T is not a new protocol. Rather, it is a set of mechanisms for interfacing traditional
telephone signaling with SIP.
SIP-T (SIP for telephones) provides extensions to the SIP protocol to carry legacy telephony signaling in the
SIP messages. Three requirements with interworking with the legacy telephony signaling network are trans-
parency, routability and transfer of mid-call signaling. SS7 ISUP messages are translated into corresponding
SIP headers for the messages to be routed correctly in the IP network. Encapsulation of the SS7 ISUP mes-
sage in the SIP payload makes the message available in its entirety without loss of information to the end
device for which it was intended. The final requirement makes use of the INFO [A1] messages for transferring
mid-call signaling.
Setup
Test Steps
1. Connect the cabling for the signaling links (SL) to be used in the test between the test set and
signaling gateway (DUT), using T1 or E1 and an Ethernet cable.
2. Provision and associate the SS7 SL:
a. Configure the test set to act as a minimum of one end points (SSP).
a. Configure the test set to act as a minimum of one end points (SSP).
b. Configure the signaling point codes (SPC) on the test set and DUT.
c. Configure the circuit identification codes (CIC), to be controlled, on the test set.
d. Configure the desired number of link sets (SLS) with associated SLs on the test set and DUT.
e. Select the SS7 protocol variant(s), to be run across the network, on the test set and DUT.
f. Configure the test set to generate “signaling only” calls without any real voice traffic.
3. Initiate unblocking of SLs on the test set towards the DUT.
4. Provision the SIP-T SL:
a. Configure the IP address for the test set and DUT so they will communicate.
b. Select the SS7 protocol variant(s), to be run across the network, on the test set and DUT.
c. Modify the ISUP signaling messages on the test set to match the DUT if necessary.
Spirent Communications Test Methodologies • IP Telephony Edition 10
5. Perform a test run to ensure that the DUT and the test set are configured correctly. Configure
the test set to initiate a low amount of calls across the DUT and verify the calls are being
established.
6. Once it is certain that the signaling messages are traversing through the DUT correctly, increase the
number of calls being made by the test set to just under the expected value at which the
DUT might reach its capacity.
7. Check for delays and other test parameters listed below. If there are no malfunctions or significant
delays, then increase the call set up rate and retest.
8. When the test set reports errors, significant delays, or malfunctions, the capacity of the DUT may
have been reached. Altering configuration on the DUT may give different performance numbers.
Turning off not used services may relieve the DUT of some processing and memory usage leading to
higher performance numbers on the next run.
10. Record the last CPS rate where the test set did not generate an error.
a. Generate report.
b. Capture all results for every channel tested.
Test Parameters
a73
Utilize different ISUP protocols.
Test Outcome
a73
Maximum CPS the signaling gateway can sustain.
a73
Test ISUP encapsulation in SIP payload.
a73
Test ISUP to SIP message translation.
a73
Decode ISUP messages in the SIP payload [A2].
11 Spirent Communications Test Methodologies • IP Telephony Edition
TM-0180
Converged Networks: Voice Quality
Measurement in the Presence of Data
a73
ITU-T G.1020 Performance Parameter Definitions for Quality of Speech and Other Voiceband
Applications Utilizing IP Networks
a73
ITU-T Y.1541 Network Performance Objectives for IP-Based Networks
a73
IETF RFC 1242 Benchmarking Terminology for Network Interconnect Devices
a73
IETF RFC 2544 Benchmarking Methodology for Network Interconnect Devices
Objective
The test evaluates functionality and capacity of IP converged networks' elements, where voice and data
streams are processed simultaneously. This element group includes but is not limited to multiservices (MS)
edge devices, edge routers, session border controllers and Class 5 softswitches with integrated support for
data transmission. The test can be performed for one network element, a device under test (DUT) or for a set
of devices interconnected into network as in a system under test (SUT). This test verifies voice quality devia-
tions depending on features, capacity and throughput enabled in a DUT or SUT.
The test determines the ability of a DUT/SUT to sustain the predefined quality of voice and quality of service
by varying voice and data stream configuration parameters. Changing of data traffic parameters such as
throughput, traffic pattern and packet size will be combined with voice call generation and voice media path
confirmation. Multitudes of QoS, signaling and voice transmission protocols will be configured to verify the
functionality and capacity of the DUT/SUT.
The interconnection of multiple services network elements into a converged network is shown below.
Vo i ce , Dat a LAN
Vo i ce
Me d ia
Ga te wa y
Me d ia
Ga te wa y
Co n tr o ll e r
Fir ew al l
Ed ge R out er PC
PST N Netw ork
Vo i ce
Dat a
Cl a ss 5
Sof tSw it c h
IP Netw ork
Fir ew al l
Ed ge
Ro u te r
MS Ed ge
De v ic e
An alog
Phone
LAN
Vo i ce , Dat a
IP Phone
PC
PC
PC
PC
IP Phone
IP Phone
IP PBX
Ser v er
Ed ge
Ro u te r
Fir ew al l
LAN
Vo i ce , Dat a
Spirent Communications Test Methodologies • IP Telephony Edition 12
Overview
In this test, the DUT/SUT’s network elements combine voice and data traffic into IP traffic toward IP converged
networks. The test units should provide TDM, analog, and IP voice and data streams on LAN ports of the
DUT/SUT, and IP voice and data streams on WAN side ports. The test configuration should support the follow-
ing DUT/SUT interfaces:
a73
TDM, analog and IP. Voice streams can be combined with data streams on these interfaces. Only voice or
only data stream can be configured per each TDM or analog channel simultaneously. Voice and data
streams can be combined on the IP interface and identified by IP.
a73
IP only. LAN and WAN ports of test units should emulate a permutation of voice and data streams.
For the test to determine DUT/SUT throughput and functionality, configuration parameters of data traffic
should be correlated with the voice quality measurements.
Data Traffic
To provide data traffic parameters configuration, at least two ports should be present: data port transmitter
and data port receiver. A number of ports is not limited to two; rather, it is defined by the DUT/SUT specifica-
tion. For each pair of LAN and WAN ports of the DUT/SUT, a pair of test data ports should be provided. The
DUT/SUT must be configured such that data traffic offered by data transmitters will be forwarded toward the
data receivers.
Data traffic is generated from the data port transmitter or transmitters, which offer a pre-defined number of
packets to the DUT/SUT. The packets are forwarded by the DUT/SUT to the data port receiver. Data port trans-
mitters generate packet traffic with variable packet rates, packet length distributions and load time profiles.
Data traffic should be generated to provide sufficient means to verify data path functionality and capacity of
the DUT/SUT. Data traffic load variations should be configured to accommodate DUT/SUT data processing
specifications. Security, quality of service support and throughput parameters should be taken into account
when configuring data traffic.
Voice Traffic
To obtain voice quality measurements, voice traffic signaling and speech voice paths should be established
and passed through the DUT/SUT. Configuration of signaling protocols, voice reference files and path confir-
mation methods ensure compatibility with DUT/SUT specifications. To provide TDM, analog and IP interfaces,
the test units emulate PBX trunks, analog phones and IP phones. Voice quality measurements such as PESQ
and R-Factor evaluate the effects on DUT/SUT performance of data traffic. PESQ measurements represent a
better picture when no bursts are generated in data traffic emulation. R-Factor values represent better evalua-
tion when packet bursts are included in the data traffic pattern.
The call generator creates the voice traffic by establishing a voice path through the DUT/SUT. Call generator
emulates the subscriber origination and termination endpoints of the voice path. DUT/SUT accepts signaling
and voice traffic from an originate endpoint, processes them and outputs them to a terminate endpoint. The
endpoint can be either terminate or originate endpoint(s) to provide full duplex communication links and
alternation of the call initiation side. The call origination can be emulated from both WAN and LAN sides of
the DUT/SUT. When a call path (or channel) is established, the originating endpoint(s) send prerecorded
voice files. Originate and terminate endpoints are synchronized by the test units.
Dat a P or t
Tr a ns m itt er
IP Phone C al l
Gener at or
An alog C al l
Gener at or
TD M C al l
Gener ation
LAN
Dat a P or t
Re c eiv er
IP Phone C al l
Gener at or
DUT/SUT
WA N
Dat a P ac k ets
Dat a P ac k ets
13 Spirent Communications Test Methodologies • IP Telephony Edition
Setup
The test configuration is presented in the test setup diagram below. This configuration is applicable to any
DUT/SUT shown in the IP converged network diagram on the front page. Data port transmitter and receiver
should be present in all tests. IP phone call generator, analog call generator and TDM call generator are used
in the tests according to the interfaces and functions supported by the DUT/SUT or as required by the test
objectives.
The maximum theoretical packet rate should be calculated. The maximum theoretical data rate is a sum of the
maximum data traffic rate specified for the DUT/SUT and the voice traffic maximum data rate. The voice traffic
maximum data rate calculation is based on G.711 codec and the maximum number of voice channels support-
ed by the DUT/SUT.
Test Steps
General
1. It is a good practice to first configure the workload test to discover the compatibility, connectivity issues,
syntax errors and other problems before performing the variable load tests. The workload tests include a
minimum number of configured channels acceptable by DUT/SUT and test units. The test should be set
for one direction of traffic only and support the simplest protocols.
2. When you are sure that test units and the DUT/SUT are connected properly and can be configured to per-
form the tests specified in the objectives, the data traffic setup should be carried out.
3. Data traffic tests should define the maximum throughput and functionality supported by the DUT/SUT.
4. Tests with voice traffic load should then be added to the data load of DUT/SUT. The voice traffic should
be configured for the maximum load of DUT/SUT voice processing capacity.
5. If there is no deterioration in DUT/SUT functionality nor capacity during tests with combined data and
voice traffics, go to Step 8.
6. If degradations of voice traffic are presented in measurable parameters, the data traffic setup should be
changed to lower the throughput. A DUT/SUT with QoS, NAT or firewall support should be configured to
provide the highest priority to voice traffic.
7. These steps should be repeated until there are no errors shown for voice quality measurements.
8. When the maximum values of voice traffic parameters are defined, the following voice traffic recovery
test steps should be carried out:
a. Configure the voice traffic to the maximum values found.
b. Configure the data traffic parameters to exceed the maximum value in Step 3. Voice traffic quality should
degrade.
c. Decrease the data traffic load of the DUT/SUT. Voice traffic should recover; no errors should be shown.
Workload Tests
1. Connect and verify the connectivity of cables needed for the test. In some cases the connectivity can be
verified during physical port connections.
2. Configure appropriate IP addresses and networks.
3. Configure the data test ports to the direction from transmitter to receiver.
4. Configure the DUT/SUT so that voice and data traffic are accepted and forwarded, if needed.
5. Configure packet traffic to a fixed packet size, uniform minimum load and constant inter-packet time. Set
the data traffic bandwidth to a value less than 4 Mbps for combined voice and data streams.
6. Configure the voice protocols and test parameters to the direction from originate to terminate for two
voice channels only.
7. If the DUT/SUT supports more than one voice interface and protocol, start with one interface and then
add one more. Repeat all steps of the workload test until all voice interfaces and protocols are config-
ured. Configure only one protocol for each interface.
8. Choose a voice reference file, set path confirmation to PESQ method and set call duration value to
30 sec.
9. Perform the test and observe. Check for any errors or if a PESQ value is less than 3.5 as reported by GUI.
10. If there are errors, check the connections and setup. Simplify the workload tests and repeat the steps
above until there are no errors.
Spirent Communications Test Methodologies • IP Telephony Edition 14
Data Traffic Generation
1. Configure the following parameters:
a. Packet size. While any frame size can be used, start with the IPv4 tests with frame sizes from 64 bytes
to 1518 bytes. For IPv6 tests, the minimum frame size should be set to 76 bytes.
b. IP addresses.
c. Routing. The primary route’s setup provides proper forwarding to specify the throughput.
d. Initial packet rate.
e. Run time.
2. Specify the data traffic pattern.
3. Send traffic from the data port transmitter. Start with the maximum packet rate. Measure the number of
packets offered at the transmitter port and the number of packets accepted at the receiver port.
4. If no packet loss occurs, continue with voice traffic setup. If packet loss occurs, decrease the packet rate
and repeat the test.
Voice Quality
1. Configure PESQ or R-Factor voice quality measurement method.
2. Verify a correspondence of codecs configured for each test.
3. Choose a voice file for the voice quality measurement. The choice of a voice file depends on requirements
to support silence suppression, voice activity detection and call lengths. Also, the data traffic setup
defines the choice of PESQ or R-Factor. The test set should be able to measure voice quality on the TDM
and IP ports.
4. Use different codecs and packet payloads setting to load the DUT/SUT.
Voice Traffic Generation
1. Keep the same signaling and voice protocols as in the workload test above.
2. Configure the number of channels for 30 percent lower than the maximum number of channels specified
for the DUT/SUT.
3. Start with generating calls from the LAN side and terminating at the WAN side. Compare a number of calls
generated to a number of calls terminated.
4. Configure all originating calls from the WAN side and terminating at the LAN side. Compare a number of
originated and terminated channels.
5. Configure LAN and WAN sides for alternating originate and terminate calls. A number of terminating and
originating channels should be the same.
6. Check for delays and other test results listed below. Analyze the traces and specific error events to
identify the source of errors.
7. Gradually increase number of channels until a reported number of terminated channels are not equal to
a reported number of originated channels, or when errors reported by the test unit exceed thresholds.
The maximum configured number of channels that passed the tests without voice-quality degradation is
the maximum capacity of the DUT/SUT.
15 Spirent Communications Test Methodologies • IP Telephony Edition
Measurable Results
a73
Call attempts.
a73
Call completions.
a73
Percentage of call completions.
a73
Call attempts per hour.
a73
Script attempts (number of tests).
a73
Percentage of script attempts.
a73
Errors received for active channels.
a73
Channels stopped with maximum allowable number of errors.
a73
Call duration.
a73
Call set up time.
a73
Call tear down time.
a73
Clipping.
a73
Ring duration
a73
Bit error rate.
a73
PESQ value.
a73
PSQM value.
a73
MOS value.
a73
RTP packet loss rate.
a73
RTP packets out of order.
a73
RTP packets late arrival.
a73
RTP jitter.
a73
One way delay.
a73
Round trip delay.
a73
Packet rate.
a73
Resolution rate for pattern search.
a73
Packet loss.
a73
Latency.
a73
Rate increment/decrement resolution.
Test Outcome
When there is a significant change in any of these measured results, record the call attempts, call comple-
tions and call attempts-per-hour numbers. Print and analyze the reported error log and events. When per-
formed with the test steps, collected data is sufficient to identify the failure points and configuration. These
are the results of the functionality and capacity tests. Feature performance is measured by degradation of
ability to perform the functions.
Spirent Communications Test Methodologies • IP Telephony Edition 16
TM-0182
Fax Testing
a73
ITU-T T.30. Procedures for document facsimile transmission in the general switched telephone network
a73
ITU_T T.38. Procedures for real-time Group 3 facsimile communication over IP networks
a73
ITU-T T.4. Standardization of Group 3 facsimile terminals for document transmission
a73
ITU-T T.6. Facsimile coding schemes and coding control functions for group 4 facsimile apparatus
a73
IETF RFC 3261 SIP
a73
ITU-T H.323
a73
IETF RFC 3435 MGCP
a73
IETF RFC 3015 MEGACO
a73
IETF RFC 3550 RTP/RTCP
Objective
To test fax transmissions functionality and capacity of the SUT (System Under Test) and measure fax
transmission quality over the IP or PSTN telephony network.
Overview
Overview of Fax signaling protocols and modems
The following signaling fax protocols are used for tests:
a73
T.4 (G3 fax) and T.6 (G4 fax) specify image encoding, format, and page layout.
a73
T.30 specifies the session-management procedures that control the establishment, maintenance, and
closing of a fax transaction.
a73
T.38 defines the protocol for relaying a fax across an IP network in real time.
T.30 allows the two end terminals to agree on transmission speed, encoding format, and page size, among
other parameters. It is important to note that a fax transaction is defined as two corresponding endpoint ter-
minals that utilize the ITU T.30 protocol to exchange information. A protocol specifies how two entities com-
municate. There is a sender and a receiver of information. This means there must be a T.30 entity at each
facsimile endpoint. T.38 is a relay protocol and cannot be an endpoint. Its role is to transparently relay T.30-
driven signals across an IP network. So, T.38 cannot originate or terminate a fax transaction. See the illustra-
tion below.
Rea l -T i me P ac k et - Ba s ed Fa x
IP
Netw o rk
Fa x T . 30 Fa x T . 30T. 3 8- C ap a bl e
Ga te wa y
T. 3 8- C ap a bl e
Ga te wa y
T. 3 8
T. 3 0
17 Spirent Communications Test Methodologies • IP Telephony Edition
The T.38 gateway, in addition to its pure relay function, should accomplish the following:
a73
Reduce bandwidth utilization in the packet network by sending lengthy analog signals, such as 1.5
seconds of HDLC flags, as an IP message that simply says it occurred.
a73
Eliminate the effects of packet loss through forward error-correction techniques.
a73
Eliminate data overruns and under-runs caused by non-synchronized endpoint clocks.
a73
De-jitter IP packets, removing five seconds or more of inter-arrival irregularities.
Since G3 is specified for the PSTN, and it is an all-digital procedure, it requires the use of modems for the
PSTN analog leg of a transaction. These modems are specified in ITU standards:
a73
For the T.30 procedures: V.21 (300 bps).
a73
For image transfer: V.27ter (4800 bps), V.29 (7200/9600 bps), and V.17 (7200, 9600, 12,200,
and 14,400 bps).
The test cases shown outline the possible SUT with test scenarios likely expected by the Abacus/ICG system.
VoIP signaling can be any of the available: SIP, H.323, MGCP or Megaco/H.248. PSTN call setup is outside of
the scope of this document.
TEST CASE 1
Objective
This methodology tests the T.38 Gateway.
Overview
The IP Test Card (ICG) will emulate the T.38 Gateway on the IP network. The PSTN Test Card (PCG) will emulate
the T.30 fax endpoint. Fax transmission will be bi-directional with faxes being transmitted from IP to PSTN and
vice versa.
Set Up
Set up the IP Test Card to transmit a fax to the PSTN Test Card and have the PSTN Test Card wait for the fax
transmission. Then have the PSTN Test Card transmit the fax to the IP Test Card and ensure that card receives
the fax transmission. If the tester desires, they can increase the volume of fax transmissions through the SUT.
Test Parameters
Configure the IP test card to emulate a T.38 Gateway.
Configure the PSTN to emulate a T.30 fax endpoint.
T. 3 8 C ap ab l e
Ga te wa y
IC G
(O/T)
IC G
(O/T)
Vo L P S ig n al i ng PS T N S ig n al i ng
VRG
(O/T)
T. 3 8 C ontr o l
T. 4 /T .6 M edi a
V. 2 1, V .17
T. 3 8 C ontr o l
T. 4 /T .6 M edi a
V. 2 1, V .17, V . 27 , V .29
IP PST N
SUT
Me d ia Ga t ew a y wi th T .38 Ca p ab i li t y
Spirent Communications Test Methodologies 18
TEST CASE 2
Objective
This methodology sends faxes through the SUT from IP to PSTN and vice versa without a T.38 Gateway (Fax
Bypass mode).
Overview
The IP Test Card will emulate fax traffic on the IP network. The PSTN Test Card will emulate the T.30 fax end-
point. Fax transmission will be bi-directional with faxes being transmitted from IP to PSTN and vice versa.
Set Up
Set up the IP Test Card to transmit a fax to the PSTN Test Card and have the PSTN Test Card wait for the fax
transmission. Then have the PSTN Test Card transmit the fax to the IP Test Card and ensure that the card
receives the fax transmission. If the tester desires, they can increase the volume of fax transmissions through
the SUT.
Test Parameters
Configure the IP test card for fax bypass mode
Configure the PSTN to emulate a T.30 fax endpoint.
Fa x -B yp ass
Ca p ab l e
Ga te wa y
IC G
(O/T)
IC G
(O/T)
Vo L P S ig n al i ng PS T N S ig n al i ng
VRG
(O/T)
RIP M edi a
(V .17 b as e d G.711 P a ylo a d)
V. 2 1, V .17
T. 3 8 C ontr o l
T. 4 /T .6 M edi a
V. 2 1, V .17, V . 27 , V .29
IP PST N
SUT
Me d ia Ga t ew a y wi th out T . 38 C a pa b il i ty
V. 2 1, V .17, V . 27 , V .29
TEST CASE 3
Objective
This methodology tests a pure IP network with no PSTN, with fax transmissions between two T.38 Gateways.
Overview
The IP Test Cards emulate T.38 Gateways across the IP network. Fax transmission will be bi-directional with
faxes being transmitted between IP Gateways.
Set Up
Set up the first IP Test Card A to transmit a fax to IP Test Card B and have IP Test Card B wait for the fax trans-
mission. Then have IP Test Card B transmit the fax to IP Test Card A and ensure that Test Card A receives the
fax transmission. If the tester desires, they can increase the volume of fax transmissions through the SUT.
Test Parameters
Configure both IP test card to emulate T.38 Gateways.
Test Cases 1 through 3 Outcomes
a73
Fax connection speed in bits per second.
a73
Fax throughput in bits per second.
a73
Fax line error rate.
a73
Received fax pages per call.
a73
Sent/received T.38 packets per call.
a73
T.38 Session length average transmission rate and reception rates in bits per second.
a73
Visual fax reports via TIFF file captures.
Netw ork
Fir ew al l
IC G
(O/T)
IC G
(O/T)
Vo L P S ig n al i ng Vo L P S ig n al i ng
T. 3 8 C ontr o l
T. 4 /T .6 M edi a
V. 2 1, V .17
T. 3 8 C ontr o l
T. 4 /T .6 M edi a
IP
IP
SUT
Ne t wo r k F ir e wa l l
19 Spirent Communications Test Methodologies • IP Telephony Edition
Spirent Communications Test Methodologies • IP Telephony Edition 20
Acronyms
BHCA — Busy Hour Call Attempts
CAS — Channel Associated Signaling
CCS — Common Channel Signaling
CIC — Circuit Identification Code
CPS — Calls Per Second
DTMF — Dual Tone Multi-Frequency
DUT — Device Under Test
ISDN — Integrated Services Digital Network
ISUP — ISDN User Part
MEGACO — Media Gateway Control
MG — Media Gateway
MGC — Media Gateway Controller
MGCP — Media Gateway Control Protocol
MOS — Mean Opinion Score
MTP3 — Message Transfer Part 3
PBX — Private Branch Exchange
PESQ — Perceptual Evaluation of Speech Quality
PRI — Primary Rate Interface
PSQM — Perceptual Speech Quality Measurement
PSTN — Packet-Switched Telephone Network
RTCP — Real-Time Control Protocol
RTP — Real-Time Transport Protocol
SCTP — Stream Control Transmission Protocol
SG — Signaling Gateway
SIGTRAN — Signaling Transport
SIP — Session Initiation Protocol
SIP-T — Session Initiation Protocol for Telephones
SL — Signaling Link
SLS — Signaling Link Sets
SPC — Signaling Point Codes
SS7 — Signaling System Number 7
SSP — Service Switching Point
STP — Signal Transfer Point
SUT — System Under Test
TDM — Time Division Multiplex
TG — Trunking Gateway
VoIP — Voice over Internet Protocol
21 Spirent Communications Test Methodologies • IP Telephony Edition
Glossary
E-model — An International Telecommunication Union (ITU) model used to estimate the impairment of
voice quality and to plan for network capacity. The R-value is the result.
H.323 — An international multimedia communications protocol standard that supports the convergence
of voice, video and data. Used with IP networks and VoIP.
Mean Opinion Score (MOS) — A measurement of audio quality heard on a phone. Defined in ITU-T
P.800. The result is a score range from 1 to 5, with 1 being “bad” and 5 meaning “excellent.”
Media Gateway (MG) — A network element that converts audio signals in telephone circuits into Internet
data packets (or for other packet networks) and vice versa.
Media Gateway Control (MEGACO) — The name given to the ITU-T H.248 protocol standard recommenda-
tion by the Internet Engineering Task Force. The protocol is used when connecting calls between the
PSTN and the LAN.
Media Gateway Controller (MGC) — A device that controls one or more media gateways. The MGC can
control most aspects of each media gateway.
Media Gateway Control Protocol (MGCP) — A protocol that allows a media gateway controller to control
media gateways when bridging between the circuit-switched PSTN (Public Switched Telephone Network)
and the Internet Protocol packet-switched networks.
Perceptual Evaluation of Speech Quality (PESQ) — An objective measurement tool for predicting the
results of subjective listening tests on telephony systems. Large databases of subjective tests are used
for calibrating the scores.
Perceptual Speech Quality Measurement (PSQM) — An ITU standard used for the end-to-end assess-
ment of speech quality (ITU P.862).
R-value — The result of an E-model calculation. Derived from factors such as delays and equipment
impairment. Once obtained, the R-value is mapped to the MOS.
Session Initiation Protocol (SIP) — A protocol related to Layer 7 (Application layer of the OSI Reference
Model). The protocol establishes, modifies and terminates conferencing and telephony sessions over
an IP-based network.
Session Initiation Protocol for Telephones (SIP-T) — A framework for interfacing traditional telephone
signaling with SIP and intended for use where a VoIP network interfaces with the PSTN.
Signaling Gateway — A device that resolves issues for interfacing between packet-switched networks
and circuit-switched networks. It routes calls between an IP network and a circuit-switched network.
Softswitch — A type of switch that replaces central office circuit switches used by PSTNs. The softswitch
typically supports IP and ATM. (Softswitch is also known as a media gateway controller.)
Signaling Transport (SIGTRAN) — A telephony protocol used for transporting Signaling System 7 (SS7)
over the Internet. SS7 signals originated by a telephone company are sent to a signaling gateway. The
gateway then converts the signals into SIGTRAN for IP transmission.
Trunk — The communication line that connects two switching systems. An aggregation of several lines
to increase bandwidth.
33 Spirent Communications Test Methodologies • Layer 2 Testing with RFC 2889
Spirent Communications
Test Methodologies Journals
_______________________________
Spirent Communications at <www.spirentcom.com> has a library of test methodology journals that
offer you insight into testing a variety of technologies. The journals were developed to make net-
work and equipment testing easier.
Spirent provides the following series of generic and informative test methodology journals. They
can be downloaded at <www.spirentcom.com/tmj>:
• Router Performance Edition
• Volume II - Wireless, Edge Router,
Metro Optical, VoIP, SS7, QoS and IPv6
• Edge Router Edition
• Layer 4-7 Edition
• Multicast Edition
• Optical Edition
• PPPoX Edition
• MPLS Edition
• IPSec Edition
• IPv6 Edition
Spirent also offers customers platform-specific journals at the Customers Service Center (CSC).
These Spirent Communications Step-by-Step Test Methodologies
TM
journals require use of the
TeraRouting Tester (TRT) on the SmartBits platform. The publications can be downloaded at
<http://support.spirentcom.com>. Registration is required.
• TRT Edition: High Availability Routing
• TRT Edition: BGP Functionality Testing
• TRT Edition: Multicast Registration Protocols
IGMP/MLD Functional Testing
• TRT Edition: Protocol Independent Multicast (PIM)
Sales and information phone numbers are listed on the back cover of this journal in case you
would like to contact us.
Spirent Communications is a worldwide provider
of integrated performance analysis and service
assurance systems for next-generation network
technologies. Our solutions accelerate the profitable
development and deployment of network equipment
and services by emulating real-world conditions in
the lab and assuring end-to-end performance of large-
scale networks.
Spirent performance analysis solutions include
instruments and systems that measure and analyze
the performance of network equipment, particularly
the devices that route voice and data messages to
their destination. Our service assurance solutions
include remote test, fault and performance
management systems that let network service
providers quickly identify network faults and
monitor real-time performance.
Spirent’s integrated performance analysis and service
assurance solutions enable our customers to more
rapidly develop and certify new devices, lowering the
cost of widespread deployment and operation of new
network services.
Spirent Communications is a wholly owned
subsidiary of Spirent plc, an international network
technology company.
15200 Omega Drive
Rockville, MD USA
20850-3240
Tel: +1 301.417.1224
info@spirentcom.com
Americas
Tel: +1 800.927.2660
productinfo@spirentcom.com
Europe, Middle East, Africa
Tel: +33 1 6137.2250
salesemea@spirentcom.com
Asia Pacific
Tel: +852.2166.8382
spirentasia@spirentcom.com
http://scdn.spirentcom.com
Spirent Communications
Sales and Information
Spirent Communications Developers Network
www.spirentcom.com
© 2005 Spirent Communications Inc. All rights reserved. “Spirent” and “Analyze, Assure, Accelerate” are exclusive trademarks of
Spirent plc and its subsidiaries. All other names are trademarks of their respective owners and hereby acknowledged. Specifications
subject to change without notice.
P/N 79-000007 Rev A, 3/05
