Báo Cáo Phân Tích Kỹ Thuật: So Sánh RTPEngine & SEMS

I. So Sánh Hiệu Năng: RTPEngine vs SEMS Server khi Xử Lý RTP Relay

Khi so sánh hiệu năng giữa RTPEngine và SEMS (SIP Express Media Server) trong bài toán chuyển tiếp/phát lại gói tin RTP (RTP Relay / Proxy), RTPEngine vượt trội hoàn toàn về băng thông, khả năng chịu tải đồng thời (concurrency) và mức độ sử dụng tài nguyên CPU/Memory.

1. Bảng So Sánh Tổng Quan

2. Phân Tích Kỹ Thuật Chuyên Sâu

A. Cơ chế chuyển tiếp gói tin (Packet Forwarding Architecture)

• RTPEngine (Kernel-space Acceleration):

  • RTPEngine tích hợp module kernel Linux (xt_RTPENGINE thông qua iptables/nftables).
  • Khi luồng RTP được thiết lập, quy tắc chuyển tiếp gói tin sẽ được nạp trực tiếp vào Kernel. Gói tin RTP đi vào card mạng sẽ được nhận, sửa header (IP/Port) và gửi đi ngay tại Kernel space.
  • Kết quả: Triệt tiêu hoàn toàn chi phí Context Switching (chuyển đổi giữa User space và Kernel space) và bộ đệm bộ nhớ (Buffer Copy).

• SEMS (User-space Processing):

  • SEMS hoạt động hoàn toàn ở User space. Mỗi gói tin RTP đi vào phải đi qua Stack mạng Linux Kernel → Socket API → SEMS Process → Socket API → Linux Kernel → Card mạng.
  • Kết quả: Khi lưu lượng RTP tăng cao (hàng trăm ngàn pps - packets per second), CPU sẽ phải dành rất nhiều thời gian để context switch và đọc/ghi socket, dẫn đến nghẽn cổ chai nhanh chóng.

B. Định hướng kiến trúc & Sử dụng thực tế

• RTPEngine: Được thiết kế riêng biệt cho bài toán RTP Proxy / Media Relay / WebRTC Gateway. Thường kết hợp với các SIP Proxy siêu nhẹ như Kamailio hoặc OpenSIPS để xử lý hàng chục nghìn cuộc gọi đồng thời.
• SEMS: Bản chất là một SIP Application Server tích hợp Media Server. Thích hợp hơn khi cần phát file âm thanh (Announcement), làm tổng đài IVR, phòng họp hội nghị (Conference), hoặc B2BUA logic phức tạp hơn là chỉ chuyển tiếp thuần túy gói tin RTP.

II. Khả Năng Xử Lý File Âm Thanh (.wav, .mp3)

Cả SEMS và RTPEngine đều có thể đọc hoặc ghi/đóng gói được file âm thanh (.wav, .mp3), tuy nhiên mục đích và cơ chế hoàn toàn khác nhau:

1. SEMS (SIP Express Media Server)

SEMS được thiết kế chính cho mục đích làm Media Server / Application Server, nên việc đọc và đóng file âm thanh là tính năng cốt lõi.

• Định dạng file:
  • Hỗ trợ rất tốt file .wav (với các codec chuẩn như Uncompressed PCM 8kHz/16kHz, G.711a, G.711u, GSM…).
  • Có thể đọc/ghi .mp3 (thông qua các thư viện/plugin mã hóa đi kèm).
• Mục đích sử dụng:
  • Phát file âm thanh (Playback): Phát đoạn chào IVR, thông báo (“Số máy quý khách…”, “Vui lòng chờ…”), nhạc chờ (Music on Hold).
  • Ghi âm (Recording): Ghi âm cuộc gọi, lời nhắn hộp thư thoại (Voicemail) trực tiếp ra file .wav hoặc .mp3.

2. RTPEngine

RTPEngine được thiết kế cho mục đích Proxy / Forwarding, việc đóng/đọc file chỉ là tính năng bổ trợ.

• Định dạng file:
  • Hỗ trợ đóng file .wav hoặc file raw/PCAP (thông qua công cụ ghi âm đi kèm là rtpengine-recording).
  • Việc xuất ra .mp3 trực tiếp không phải là thế mạnh chính của RTPEngine (thường phải qua công cụ chuyển đổi hoặc cấu hình ffmpeg đi kèm tùy phiên bản).
• Mục đích sử dụng:
  • Ghi âm cuộc gọi (Call Recording): RTPEngine có thể “nhái” (mirror) các luồng RTP đang truyền qua nó và ghi lại thành file .wav ở dạng tệp âm thanh đơn (Mono) hoặc đôi (Stereo/2 kênh tách biệt người nói - người nghe).
  • Phát file (Inject Audio): RTPEngine hỗ trợ phát/tiêm (inject) file âm thanh vào luồng cuộc gọi (thường dùng cho thông báo ngắt cuộc gọi, hết tiền, hoặc chặn cuộc gọi).

3. Tóm Tắt Lựa Chọn

III. Khả Năng Thực Hiện Tính Năng ChanSpy / Whisper / Barge-in

1. RTPEngine có tạo được ChanSpy như Asterisk không?

Không, RTPEngine không thể tự tạo tính năng ChanSpy (nghe lén/xen vào cuộc gọi) hoàn chỉnh theo cơ chế native/built-in sẵn như Asterisk.

• Nguyên nhân:

  1. Bản chất B2BUA / Media Server vs. RTP Proxy: Asterisk quản lý trực tiếp State, Bridge, SIP Session và luồng RTP, có khả năng mix (trộn) nhiều kênh âm thanh lại với nhau. RTPEngine chỉ nhận gói tin RTP ở điểm A và đổi IP/Port để forward sang điểm B (xử lý ở tầng Kernel), không có logic quản lý kênh thoại PBX.
  2. Khả năng trộn âm thanh (Audio Mixing): RTPEngine không hỗ trợ Audio Mixing / Conference Engine để trộn giọng nói của Supervisor vào luồng RTP hiện tại giữa Agent và Customer.

• Giải pháp thay thế nếu dùng RTPEngine:

  • Cách 1 (Sử dụng RTP Mirroring): RTPEngine gửi một bản sao (mirror) các gói tin RTP (2 chiều) đến một IP/Port chỉ định (UDP/PCAP stream) tới một Media Server phụ (Asterisk/FreeSWITCH) để phát cho Supervisor nghe. (Chỉ làm được chế độ Listen - Nghe 1 chiều).
  • Cách 2 (Định tuyến qua Media Server): Định tuyến cuộc gọi của Supervisor vào Asterisk/FreeSWITCH để thực hiện ChanSpy() / Eavesdrop().

2. Định Nghĩa Các Chế Độ Giám Sát Cuộc Gọi (Whisper & Barge-in)

Trong ngành viễn thông và Call Center, Whisper và Barge-in là các tính năng giám sát cuộc gọi nâng cao dành cho Quản lý / Giám sát viên (Supervisor):

A. Whisper (Nhắc lời / Nói thầm)

• Cơ chế: Cho phép Giám sát viên (Supervisor) nói chuyện trực tiếp với Nhân viên (Agent) trong lúc cuộc gọi đang diễn ra.
• Đặc điểm:
  • Chỉ Agent nghe thấy lời nói của Supervisor.
  • Khách hàng hoàn toàn KHÔNG nghe thấy những gì Supervisor đang nói.
• Kịch bản sử dụng: Đào tạo nhân viên mới (Onboarding/Coaching) theo thời gian thực; Nhắc bài/hướng dẫn xử lý khi Agent gặp tình huống khó.

B. Barge-in (Xen vào / Nói 3 bên)

• Cơ chế: Cho phép Giám sát viên nhảy trực tiếp vào cuộc gọi và biến nó thành một cuộc hội thoại 3 bên (Conference Call).
• Đặc điểm:
  • Cả Agent và Khách hàng đều nghe thấy giọng nói của Supervisor.
  • Supervisor có thể giao tiếp song phương với cả hai bên.
• Kịch bản sử dụng: Xử lý sự cố / khiếu nại gắt gao khi Agent không đủ thẩm quyền hoặc cần cấp quản lý nhảy vào giải quyết bế tắc ngay lập tức.

C. Bảng So Sánh Các Chế Độ Giám Sát