Vì sao Asterisk không thể xử lý số lượng Concurrent Calls rất lớn?

Asterisk không phải là hệ thống không chạy được concurrent calls lớn, mà đúng hơn là kiến trúc của Asterisk không được thiết kế để scale lên hàng chục nghìn cuộc gọi đồng thời như các Softswitch hoặc SIP Proxy chuyên dụng (Kamailio, OpenSIPS, SBC thương mại).

Các nguyên nhân chính được trình bày dưới đây.

1. Kiến trúc B2BUA (Back-to-Back User Agent)

Đây là nguyên nhân quan trọng nhất.

Asterisk hoạt động như một B2BUA, nghĩa là nó chấm dứt (terminate) một phiên SIP và tạo ra một phiên SIP mới.

UA A <-- SIP Dialog 1 --> Asterisk <-- SIP Dialog 2 --> UA B

Asterisk phải xử lý:

• SIP Session
• SDP Negotiation
• RTP
• Dialplan
• AGI/FastAGI
• IVR
• Recording
• CDR/CEL

Nói cách khác, toàn bộ trạng thái của cuộc gọi đều nằm trong Asterisk.

Trong khi đó Kamailio hoặc OpenSIPS chỉ hoạt động như SIP Proxy:

UA A -------- SIP --------> UA B

Proxy chỉ:

• Parse SIP message
• Lookup Location
• Forward SIP message

Không xử lý media nên tiêu tốn CPU rất ít.

2. Mỗi cuộc gọi tạo nhiều Thread

Asterisk sử dụng mô hình đa luồng (multi-thread).

Một cuộc gọi thường sinh ra nhiều thread:

Call

├── SIP Thread
├── RTP Thread
├── PBX Thread
└── Bridge Thread

Nếu có:

10.000 concurrent calls

có thể tồn tại:

20.000 ~ 40.000 thread

Số lượng thread lớn dẫn đến:

• Context Switching
• Scheduler Overhead
• Cache Miss
• Memory Overhead

Đây là giới hạn lớn của kiến trúc dựa trên thread.

3. Dialplan Interpreter

Mỗi cuộc gọi đều chạy Dialplan.

Ví dụ:

same => n,Answer()
same => n,Playback(...)
same => n,AGI(...)
same => n,Dial(...)

Dialplan Engine phải:

• Parse Extension
• Evaluate Expression
• Lookup Context
• Thực thi Application

Nếu lưu lượng lớn, CPU sẽ dành đáng kể thời gian chỉ để xử lý dialplan.

4. RTP đi qua Asterisk

Nếu RTP không được Direct Media:

Phone A

   RTP

Asterisk

   RTP

Phone B

Asterisk phải:

• Nhận RTP Packet
• Parse Header
• Bridge RTP
• Forward RTP

Ví dụ:

1000 Calls

↓

2000 RTP Streams

↓

100 Packet/s mỗi stream

↓

200.000 RTP Packet/s

CPU sẽ tăng rất nhanh.

5. Transcoding

Đây là tác vụ tiêu tốn CPU nhất.

Ví dụ:

Caller

G.729

↓

Asterisk

↓

Opus

Asterisk phải:

Decode

↓

PCM

↓

Encode

Nếu sử dụng codec nặng như:

• Opus
• G.729
• G.722

thì CPU tiêu thụ có thể tăng gấp nhiều lần so với chỉ chuyển tiếp RTP.

6. Bridge Engine

Asterisk sử dụng Bridge Engine để kết nối các kênh.

Ví dụ:

• Conference
• Queue
• Call Transfer
• Call Park
• MixMonitor
• Whisper

Bridge phải:

• Đồng bộ Audio
• Mix Audio
• Tạo Audio Frame mới

Đây là tác vụ tính toán rất nặng khi số lượng cuộc gọi lớn.

7. Lock Contention

Asterisk sử dụng rất nhiều đối tượng chia sẻ:

• Channel
• Bridge
• Codec
• Endpoint
• AO2 Object

Nhiều thread cùng truy cập:

lock()

unlock()

lock()

unlock()

Khi có hàng nghìn cuộc gọi đồng thời, Lock Contention trở thành một nút thắt hiệu năng.

8. Memory Allocation

Mỗi cuộc gọi tạo nhiều object:

• Channel
• Frame
• RTP Buffer
• Codec Buffer
• Bridge
• CDR
• CEL

Số lượng object lớn dẫn đến:

• malloc/free liên tục
• Fragmentation
• Cache Miss
• Memory Pressure

9. Nhiều Module cùng hoạt động

Một cuộc gọi có thể đi qua:

• res_pjsip
• chan_pjsip
• bridge
• app_queue
• app_mixmonitor
• func_callerid
• res_odbc
• CDR
• CEL
• Logger

CPU không chỉ xử lý SIP mà còn phải xử lý nhiều module khác.

10. Logging và Database

Nếu hệ thống ghi:

• CDR
• CEL
• SQL
• File Log

thì I/O có thể trở thành nút thắt.

Ví dụ:

5000 CPS

↓

5000 INSERT/s

↓

Database Bottleneck

11. Call Per Second (CPS)

Concurrent Calls và CPS là hai khái niệm khác nhau.

Ví dụ:

Concurrent Calls

10.000

không có nghĩa hệ thống xử lý được:

1000 CPS

Mỗi cuộc gọi mới cần:

• INVITE
• Authentication
• SDP Negotiation
• Dialplan
• Channel Creation

Đây là giai đoạn tiêu tốn CPU nhất.

Vì sao Kamailio/OpenSIPS xử lý được nhiều hơn?

Quy trình xử lý:

Incoming INVITE

↓

Parse SIP

↓

Lookup Location

↓

Forward

↓

Done

Không thực hiện:

• RTP
• IVR
• Queue
• Conference
• Recording
• Dialplan
• Playback

Do đó CPU sử dụng rất thấp.

So sánh

Lưu ý: Các con số chỉ mang tính tham khảo. Khả năng thực tế phụ thuộc vào:

• CPU
• RAM
• NIC
• Codec
• Transcoding
• Direct Media
• CPS
• Dialplan
• Database
• Logging

Kiến trúc thường dùng trong hệ thống Carrier

                    +----------------------+
                    | Kamailio/OpenSIPS    |
                    | SIP Proxy            |
                    +----------+-----------+
                               |
                   Routing / Load Balancer
                               |
        +----------------------+----------------------+
        |                      |                      |
+---------------+     +---------------+     +---------------+
| Asterisk #1   |     | Asterisk #2   |     | Asterisk #3   |
| IVR           |     | Queue         |     | Recording     |
+---------------+     +---------------+     +---------------+

Trong mô hình này:

• Kamailio/OpenSIPS xử lý SIP Signaling.
• Asterisk chỉ xử lý Media và Business Logic.
• RTP có thể được Direct Media hoặc chuyển qua RTP Engine chuyên dụng.
• Hệ thống dễ mở rộng theo chiều ngang (Horizontal Scaling).

Kết luận

Asterisk không yếu, nhưng được thiết kế như một Media Application Server (B2BUA) chứ không phải một High Performance SIP Proxy.

Các giới hạn chính khi số lượng concurrent calls tăng cao gồm:

1. Kiến trúc B2BUA phải giữ toàn bộ trạng thái cuộc gọi.
2. Mỗi cuộc gọi tạo nhiều thread.
3. Dialplan Interpreter tiêu tốn CPU.
4. RTP Bridging và Media Processing.
5. Transcoding rất nặng.
6. Bridge Engine xử lý Conference/Queue.
7. Lock Contention.
8. Memory Allocation.
9. Nhiều Module chạy đồng thời.
10. Logging và Database I/O.
11. CPS cao làm tăng tải khi thiết lập cuộc gọi.

Vì vậy, trong các hệ thống VoIP quy mô Carrier, Asterisk thường chỉ đảm nhiệm các dịch vụ Media (IVR, Queue, Conference, Recording…), còn việc xử lý SIP Signaling được giao cho Kamailio, OpenSIPS hoặc SBC chuyên dụng để đạt khả năng mở rộng lên hàng chục hoặc hàng trăm nghìn cuộc gọi đồng thời.