Performance Testing of Ctrip Call Center Telephony System Using SIPp

Background

Ctrip, a global online travel leader, operates the world’s largest travel call center across self‑built and third‑party cloud platforms. The telephony system handles millions of daily calls and supports tens of thousands of agents, making its stability critical.

Performance Testing Execution

2.1 Reason

Travel demand spikes during holidays (e.g., May Day, National Day) dramatically increase call volume. To ensure the system can handle these peaks, the R&D team conducts periodic performance stress tests.

2.2 Tools

SIPp is used for SIP protocol performance testing. It supports SIP signaling and media flow simulation, allowing custom call‑flow scenarios via XML scripts, and can be combined with tools like LoadRunner for enhanced capabilities.

2.3 System Architecture Analysis

The test design references the system architecture (see Figure 2‑1) to create realistic load‑testing scenarios and scripts.

2.4 Test Script Design

The necessary SIPp files are:

uac.xml : UAC side SIP signaling flow.

uas.xml : UAS side SIP signaling flow.

data.csv : Input data such as extension numbers and called numbers.

uac.bat : Batch file to invoke SIPp for the caller side.

uas.bat : Batch file to invoke SIPp for the callee side.

2.5 Objectives

a) Verify that the call‑center supports the maximum concurrent call paths, triggers circuit‑breaker behavior when thresholds are exceeded, and maintains service stability. b) Ensure accurate high‑concurrency remote allocation.

2.6 Scenario Design

Two main stress‑test directions are defined:

IVR and PBX overflow protection scenarios, including PBX queue overflow to IVR, normal IVR overflow to backup IVR, and total saturation where calls cannot be accepted.

Remote allocation accuracy for PBX across regions, using Expected Wait Time (EWT) to route calls.

2.7 Test Execution

After preparing scripts and registering extensions, the load test is run (see Figure 2‑2 for results).

Key points during execution include starting the callee before the caller, monitoring exceptions, and capturing server CPU/memory metrics.

2.8 Result Analysis

Scenario outcomes:

PBX queue overflow to IVR behaved as expected.

Normal IVR saturation redirected calls to backup IVR, with appropriate voice prompts.

Full saturation of IVR and backup IVR prevented further call entry, confirming circuit‑breaker functionality.

Remote allocation tests showed correct routing based on EWT, with logs confirming accurate seat assignment.

Conclusion

Regular performance testing is essential before system releases. The tests demonstrated that Ctrip’s telephony platform has ample headroom beyond current peak loads, and the established limits and routing mechanisms effectively protect service stability during traffic surges.