SERVICE ASSURANCE

Kiểm thử SIP/RTP: call scale, chất lượng thoại và failover

5/8/2026 · 16 phút

SIP user agents gọi qua SBC và call server trong khi RTP đi qua mạng được chèn impairment
Mục lục bài viết 9 phần

Một hệ thống VoIP có thể thiết lập đủ cuộc gọi nhưng media một chiều, jitter cao hoặc failover làm rơi phiên. Test plan cần tách SIP signaling, RTP media và trải nghiệm thoại, đồng thời giữ topology và codec nhất quán giữa các lượt.

ĐỌC NHANH

Bài viết giúp bạn

  • Vì sao call connected chưa đủ?
  • Topology và điểm đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Vì sao call connected chưa đủ?

#

SIP thiết lập, sửa đổi và kết thúc session; RTP vận chuyển media. Trạng thái 200 OK không chứng minh RTP đi hai chiều, codec đúng, DTMF hoạt động hoặc jitter buffer giữ chất lượng. NAT, firewall, SDP và routing có thể làm signaling thành công nhưng media lỗi.

Capacity cũng có nhiều trục: calls per second (CPS), concurrent calls, registration rate, transaction rate và media bandwidth. Một con số “hỗ trợ N cuộc gọi” thiếu call model, codec, encryption và duration không đủ dùng cho sizing.

02

Topology và điểm đo

#

Topology gồm user-agent/load generator hai phía, SBC/firewall, call server/registrar, DNS và network emulator trên media/signaling path. Capture SIP ở các trust zone và thu RTP/RTCP statistic tại endpoint; tránh lưu nội dung thoại thật.

Gắn Call-ID/correlation ID để nối log. Đồng bộ thời gian và ghi rõ RTP direct media hay anchored qua SBC. Nếu HA có virtual IP, đánh dấu node active/standby và state replication path.

Topology kiểm thử phân tách SIP signaling và RTP media
Topology kiểm thử phân tách SIP signaling và RTP media
03

Biến số phải kiểm soát

#

Khóa codec, packetization interval, SRTP/TLS, call duration, hold/resume, early media, retransmission timer, registration expiry, NAT binding, session timer và media anchoring. Ghi rõ call mix nội bộ, PSTN trunk giả lập, inbound/outbound và tỷ lệ answer/busy/no-answer.

  • Biến: CPS · Giá trị cần ghi: ramp/step/burst · Ảnh hưởng: Signaling CPU/queue
  • Biến: Concurrent calls · Giá trị cần ghi: mức giữ · Ảnh hưởng: Memory/session table
  • Biến: Codec/ptime · Giá trị cần ghi: theo profile · Ảnh hưởng: Bandwidth/PPS/QoE
  • Biến: TLS/SRTP · Giá trị cần ghi: bật/tắt · Ảnh hưởng: CPU, handshake, overhead
  • Biến: Impairment · Giá trị cần ghi: latency/jitter/loss · Ảnh hưởng: RTP quality
  • Biến: Call duration · Giá trị cần ghi: ngắn/dài · Ảnh hưởng: Churn và state
04

KPI signaling, media và trải nghiệm

#

Signaling KPI gồm registration/call success, CPS thành công, setup latency, SIP response code, retransmission và teardown completeness. Media KPI gồm RTP packet loss, discard, jitter, one-way latency, out-of-order, duplicate và RTCP report.

QoE có thể dùng MOS ước tính hoặc phép đo theo phương pháp phù hợp, nhưng phải ghi thuật toán, codec và điều kiện. MOS không thay thế packet-level evidence; hai cuộc gọi cùng MOS tổng hợp có thể có burst loss rất khác nhau.

05

Ma trận kịch bản quyết định

#
  • Kịch bản: Baseline 1 call · Điều cần chứng minh: SIP/RTP hai chiều đúng · Bằng chứng: pcap + audio test pattern
  • Kịch bản: CPS ramp · Điều cần chứng minh: Ngưỡng setup ổn định · Bằng chứng: success + setup p99
  • Kịch bản: Concurrent hold · Điều cần chứng minh: State không rò · Bằng chứng: session/memory counter
  • Kịch bản: WAN impairment · Điều cần chứng minh: QoE theo SLO · Bằng chứng: loss/jitter/MOS
  • Kịch bản: SBC active fail · Điều cần chứng minh: Hành vi phiên mới/cũ rõ · Bằng chứng: loss window + logs
  • Kịch bản: Registration storm · Điều cần chứng minh: Registrar phục hồi · Bằng chứng: queue/error/recovery
  • Kịch bản: NAT timeout · Điều cần chứng minh: Keepalive/reconnect đúng · Bằng chứng: mapping + SIP trace
06

Test plan theo từng pha

#

Pha A xác minh chức năng một cuộc gọi và media hai chiều. Pha B tăng CPS. Pha C giữ concurrent calls. Pha D chèn impairment theo bậc. Pha E gây lỗi node/link và registration storm. Pha F recovery và kiểm tra stale state.

  • Đồng bộ thời gian, lưu cấu hình và call model.
  • Chạy 1–10 cuộc gọi, kiểm SIP/SDP/RTP.
  • Tăng CPS theo bậc, giữ duration ổn định.
  • Giữ concurrent calls đủ lâu để bắt leak.
  • Chèn latency, jitter, loss riêng rồi kết hợp.
  • Kiểm DTMF, hold/resume, transfer nếu trong scope.
  • Fail active SBC/call server dưới tải.
  • Tạo registration/reconnect storm có giới hạn.
  • Phục hồi; đo time-to-baseline và stale session.
  • Xuất pcap chọn lọc, log, counter và pass/fail.
Tương quan lỗi signaling và media trong failover VoIP
Tương quan lỗi signaling và media trong failover VoIP
07

Checklist nghiệm thu

#
  • Call model, codec, ptime và encryption đã ghi.
  • Đã xác nhận RTP hai chiều, không chỉ SIP 200 OK.
  • CPS và concurrent calls được đo riêng.
  • SIP code/retransmission được phân loại.
  • Latency, jitter, loss được chèn và xác minh.
  • Failover thử với call mới và call đang hoạt động.
  • Registration storm có ngưỡng dừng.
  • Không thu/lưu nội dung thoại production.
  • Counter SBC, server và generator đối soát.
  • Recovery không để stale session hoặc route sai.
08

Giới hạn kết luận

#

Kết quả phụ thuộc codec, call flow, TLS/SRTP, transcoding, recording và license. Traffic generator có thể không tái tạo đầy đủ hành vi handset, carrier hoặc NAT thực. Không suy rộng con số capacity nếu call model khác.

MOS là phép ước tính hoặc đo theo phương pháp cụ thể, không phải sự thật tuyệt đối về cảm nhận. Cần ghi thuật toán, phiên bản và input; phân biệt KPI mạng với đánh giá người dùng.

09

Khái niệm cần nhớ

#
  • *SIP: Giao thức signaling tạo và quản lý session.
  • *RTP/RTCP: Vận chuyển media và báo cáo chất lượng.
  • *CPS: Số cuộc gọi được thiết lập mỗi giây.
  • *Concurrent calls: Số cuộc gọi đồng thời.
  • *MOS: Điểm chất lượng thoại ước tính/đánh giá.
  • *SBC: Session Border Controller kiểm soát biên thoại.
  • *One-way audio: Chỉ một chiều RTP hoạt động.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Baseline
Dải giá trị bình thường được thu đủ lâu để làm mốc so sánh và đặt ngưỡng.
SLA
Cam kết chất lượng dịch vụ gắn với KPI, phạm vi, thời gian và cách đo cụ thể.
Active test
Phép đo dùng traffic tổng hợp được tạo có chủ đích giữa các điểm kiểm tra.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo5 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật