Amir Jabbari
اگر یک Asterisk دیگر جواب‌گوی رشد سامانه نیست، راه درست معمولاً خرید یک سرور خیلی بزرگ‌تر نیست؛ باید Signaling، Media و Application را از هم جدا کنید. در یک معماری VoIP مقیاس‌پذیر، Kamailio ورودی SIP و مسیریابی را مدیریت می‌کند، Asterisk منطق تماس و سرویس‌هایی مثل IVR و Queue را اجرا می‌کند و RTPengine مسیر RTP/SRTP، NAT و WebRTC را در لایه‌ای مستقل می‌گیرد.
در ۱۹ اکتبر ۲۰۲۶، نسخه پایدار Kamailio شاخه 6.1 برابر 6.1.5 است. آخرین نسخه LTS عمومی Asterisk برای Production برابر 22.11.0 است و شاخه Asterisk 22 تا اکتبر ۲۰۲۸ Full Support دارد. RTPengine نیز چند Release Train موازی دارد؛ بنابراین برای Production بهتر است شاخه LTS یا Release Train سازگار با ماژول Kamailio و Distribution خودتان انتخاب شود.
هدف این مقاله: یک معماری مرجع می‌سازیم که دو Kamailio، چند Asterisk و چند RTPengine داشته باشد؛ سپس DNS/VIP، Registrar، Load Balancing، Database، Health Check، Failure Scenario و روش تست آن را مرحله‌به‌مرحله بررسی می‌کنیم.
معماری VoIP مقیاس‌پذیر یعنی چه؟
در یک نصب کوچک، یک PBX ممکن است همه‌چیز را انجام دهد: REGISTER، SIP Routing، IVR، Queue، RTP، Recording و CDR. این مدل ساده است، اما با رشد تعداد Endpoint، تماس هم‌زمان و سرویس‌های WebRTC یا AI، همان سرور به نقطه تجمع همه بارها تبدیل می‌شود.
در معماری چندسروره، مسئولیت‌ها جدا می‌شوند:
🔹 Kamailio: SIP Edge، Registrar، Routing، ACL، Load Balancing و Health Check.
🔹 Asterisk: Dialplan، IVR، Queue، Conference، Application Logic و Integration.
🔹 RTPengine: Media Proxy، NAT، WebRTC، ICE، SRTP و Media Scaling.
🔹 Database: Configuration، Subscriber Data، Dispatcher List، CDR و در صورت نیاز Realtime Config.
🔹 DNS/VIP: ورود Redundant کاربران و Carrierها به Edge.
SIP Clients / Carriers
|
DNS SRV / VIP
/ \
v v
+-----------+ +-----------+
| Kamailio A| | Kamailio B|
+-----+-----+ +-----+-----+
\ /
\ /
Registrar / Routing
|
+------------+------------+
| | |
v v v
+---------+ +---------+ +---------+
|Asterisk1| |Asterisk2| |Asterisk3|
+---------+ +---------+ +---------+
Signaling Control Media
\ /
\ /
+------ RTPengine ---+
/ \
v v
RTPengine-1 RTPengine-2
DB / CDR / Config Clusterنسخه‌های مناسب مبنا در اکتبر ۲۰۲۶
| جزء | نسخه یا شاخه مبنا | نکته |
|---|---|---|
| Kamailio | 6.1.5 | آخرین نسخه پایدار شاخه 6.1 در زمان نگارش |
| Asterisk | 22.11.0 LTS | آخرین نسخه LTS عمومی Production در زمان نگارش |
| RTPengine | Release Train سازگار / LTS | چند شاخه موازی دارد؛ با ماژول Kamailio و OS تطبیق داده شود |
| Linux | Debian 12/13 یا توزیع پشتیبانی‌شده پروژه | نسخه دقیق با Repository و Packageهای موردنیاز تطبیق داده شود |
Kamailio 6.1.5 در ۱۵ اکتبر ۲۰۲۶ منتشر شده و طبق اعلام رسمی، Compatibility فایل پیکربندی و Database Schema شاخه 6.1 حفظ شده است. Asterisk 22 نیز شاخه LTS است و نسخه 22.11.0 در ۲۷ اوت ۲۰۲۶ منتشر شده است.
مرحله ۱: Signaling و Media را واقعاً از هم جدا کنید
یکی از مهم‌ترین اشتباه‌ها این است که Kamailio جلوی Asterisk قرار داده شود، اما RTP همچنان بدون طراحی مشخص از هر سمت به هر Node برود. این فقط Signaling را Scale می‌کند، نه Media را.
در معماری پیشنهادی:
🔹 تمام SIP Endpointها و Carrierها فقط Kamailio را می‌بینند.
🔹 Backendهای Asterisk از اینترنت عمومی SIP قبول نمی‌کنند.
🔹 SDP توسط Kamailio به RTPengine داده می‌شود.
🔹 RTP/SRTP روی Pool جداگانه RTPengine Anchor می‌شود.
🔹 Asterisk فقط به شبکه داخلی Signaling/Media موردنیاز دسترسی دارد.
این جداسازی باعث می‌شود ظرفیت Kamailio بر اساس SIP Message Rate و CPS سنجیده شود، ولی ظرفیت RTPengine بر اساس Packet Rate، Bandwidth، SRTP، Transcoding و تعداد Media Session.
مرحله ۲: نقطه ورود را با DNS SRV یا VIP افزونه‌پذیر کنید
اگر دو Kamailio دارید ولی همه Phoneها فقط IP سرور اول را می‌شناسند، هنوز HA واقعی ندارید.
برای SIP Clientهایی که RFC 3263 و SRV را درست پشتیبانی می‌کنند می‌توانید DNS SRV داشته باشید:
_sip._udp.voip.example.com. 60 IN SRV 10 50 5060 sip-a.example.com.
_sip._udp.voip.example.com. 60 IN SRV 10 50 5060 sip-b.example.com.
sip-a.example.com. 60 IN A 203.0.113.10
sip-b.example.com. 60 IN A 203.0.113.11اما همه IP Phoneها و بعضی Carrierها SRV Failover را یکسان پیاده‌سازی نمی‌کنند. برای محیط‌های کنترل‌شده می‌توانید به‌جای آن VIP، Anycast یا Load Balancer شبکه‌ای استفاده کنید.
قاعده عملی: قبل از انتخاب DNS SRV، رفتار واقعی Phone و SIP Provider خودتان را تست کنید. DNS رکورد Redundant می‌سازد، اما کیفیت Failover به Client هم بستگی دارد.
مرحله ۳: Kamailio را Active-Active طراحی کنید
Kamailio برای این معماری بهتر است Stateless نباشد. Transactionهای INVITE، Failure Route، Dispatcher و Registrar هرکدام مقداری State لازم دارند.
برای Load Balancing Backendها از Dispatcher استفاده می‌کنیم. نمونه مقصدها:
1 sip:10.10.10.11:5060
1 sip:10.10.10.12:5060
1 sip:10.10.10.13:5060Health Check:
loadmodule "dispatcher.so"
modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_method", "OPTIONS")
modparam("dispatcher", "ds_probing_mode", 1)Round Robin ساده برای بعضی Call Flowها کافی است:
if (!ds_select_dst("1", "4")) {
send_reply("503", "No PBX available");
exit;
}
t_on_failure("PBX_FAILOVER");
t_relay();در Dispatcher، مقصدهای بعدی می‌توانند برای Serial Failover نگه‌داری شوند و با ds_next_dst() امتحان شوند.
مرحله ۴: REGISTER را مثل INVITE Round Robin نکنید
اگر Phoneها مستقیماً روی Backendهای Asterisk Register شوند، Registration State بین Nodeها تقسیم می‌شود. در این حالت تماس ورودی به User باید دقیقاً بداند Contact روی کدام Asterisk قرار دارد.
برای معماری بزرگ‌تر، مدل تمیزتر این است که Kamailio خودش Registrar باشد:
loadmodule "usrloc.so"
loadmodule "registrar.so"
if (is_method("REGISTER")) {
if (!save("location")) {
sl_reply_error();
}
exit;
}وقتی تماس برای User وارد می‌شود:
if (lookup("location")) {
route(RELAY);
exit;
}برای Active-Active Kamailio، Contact State نیز باید بین Nodeها Sync شود. Kamailio ماژول dmq_usrloc برای Replication رکوردهای usrloc بین چند Server دارد. در شاخه 6.1 نیز قابلیت‌های جدید Replication برای این ماژول اضافه شده‌اند.
مرحله ۵: Pool چند Asterisk را Stateless تصور نکنید
Asterisk Application Server است، اما هر Call فعال State محلی دارد: Channel، Bridge، Queue State، Recording و Resourceهای مربوط به همان Node. بنابراین Load Balancing تماس جدید ممکن است، ولی انتقال یک Call فعال از Asterisk-1 به Asterisk-2 بعد از Crash معمولاً اتفاق نمی‌افتد.
برای Pool چند Asterisk بهتر است:
🔹 Dialplan و PJSIP Configuration در همه Nodeها یکسان و Version-controlled باشد.
🔹 فایل‌های محلی غیرضروری بین Nodeها متفاوت نباشند.
🔹 Recording روی Storage مستقل یا Replicated قرار گیرد.
🔹 CDR/CEL به Backend مرکزی ارسال شود.
🔹 Nodeهای تحت Maintenance از Dispatcher خارج شوند.
🔹 ظرفیت هر Node با Benchmark واقعی مشخص شود.
اگر می‌خواهید Configuration PJSIP از Database خوانده شود، Asterisk از Sorcery/Realtime برای Objectهایی مثل endpoint، auth، aor و identify پشتیبانی می‌کند. این برای یکسان نگه‌داشتن Configuration چند Node مفید است، اما Realtime Database تماس فعال را بین Asteriskها منتقل نمی‌کند.
مرحله ۶: RTPengine را به‌صورت Pool مستقل بسازید
در Kamailio می‌توانید چند RTPengine را داخل یک Set تعریف کنید و بین آن‌ها Weight بدهید. ماژول رسمی Kamailio Load Balancing خودکار داخل Set را بر اساس Weight انجام می‌دهد.
نمونه دو Node:
loadmodule "rtpengine.so"
modparam("rtpengine", "rtpengine_sock",
"udp:10.20.0.11:2223=1 udp:10.20.0.12:2223=1")در Offer/Answer:
if (has_body("application/sdp")) {
if (!rtpengine_manage()) {
send_reply("500", "Media proxy error");
exit;
}
}برای WebRTC می‌توانید Flagهای ICE، DTLS-SRTP و RTCP-MUX را متناسب با Direction تماس اعمال کنید. برای SIP Phone سنتی نیز RTPengine می‌تواند سمت دیگر را RTP/AVP نگه دارد.
مرحله ۷: Database را نقطه شکست جدید نکنید
بعد از Redundant کردن Kamailio و Asterisk، یکی از رایج‌ترین اشتباه‌ها این است که همه Nodeها به یک Database منفرد وصل شوند و همان DB به Single Point of Failure تبدیل شود.
Database را بر اساس نوع داده تفکیک کنید:
| داده | نیاز به DB مشترک | پیشنهاد |
|---|---|---|
| Kamailio Dispatcher/Subscriber | بسته به طراحی | DB Replicated یا Managed HA |
| Kamailio Registration | الزاماً نه | usrloc + DMQ Replication می‌تواند Hot Path را از DB جدا کند |
| Asterisk PJSIP Config | در Realtime بله | DB HA با Read/Write Strategy مشخص |
| CDR/CEL | بهتر است مرکزی باشد | Queue/Buffer و Storage جدا |
| Recording | DB مناسب فایل نیست | Object/NAS/Storage مستقل |
Kamailio برای MySQL/MariaDB Driver رسمی دارد و Auto-Reconnect و Timeout قابل‌تنظیم ارائه می‌کند. اما High Availability واقعی DB باید در لایه Database طراحی شود؛ خود db_mysql جای Cluster Database را نمی‌گیرد.
اگر DB برای Routing تماس در Hot Path لازم است، Timeout طولانی می‌تواند Worker را معطل کند. بنابراین وابستگی مستقیم هر SIP Request به Query سنگین Database را تا جای ممکن کم کنید.
مرحله ۸: DNS داخلی و DNS خارجی را جدا طراحی کنید
DNS در VoIP فقط برای Domain Name نیست. SIP SRV، Failover Carrier، Service Discovery و Backend Nameها به DNS وابسته می‌شوند.
Kamailio Resolver داخلی با Cache از NAPTR/SRV و DNS Failover پشتیبانی می‌کند. مستند Core تصریح می‌کند DNS-based Failover در TM به DNS Cache داخلی وابسته است.
برای Production:
🔹 حداقل دو DNS Resolver مستقل داشته باشید.
🔹 TTL را خیلی کوتاه یا خیلی بلند انتخاب نکنید.
🔹 Failover واقعی Clientها را با SRV تست کنید.
🔹 نام Backend داخلی را از DNS عمومی جدا نگه دارید.
🔹 تغییر DNS را جای Health Check لحظه‌ای تصور نکنید.
مسیر یک تماس ورودی در این معماری
برای اینکه اجزا روشن‌تر شوند، یک تماس از SIP Carrier به داخلی 1001 را دنبال کنیم:
1. Carrier -> Kamailio A
2. ACL / Sanity / Routing
3. Kamailio -> RTPengine offer
4. Kamailio -> Asterisk 2
5. Asterisk executes IVR / Dialplan
6. Asterisk -> Kamailio for user 1001
7. Kamailio lookup(location)
8. Kamailio -> registered phone
9. RTPengine anchors RTP/SRTP
10. BYE -> Kamailio -> RTPengine deleteدر این مدل، Carrier لازم نیست IP هیچ Asterisk را بداند و Phone نیز مستقیماً Backend را نمی‌بیند.
مسیر REGISTER در معماری Active-Active
Phone
|
v
Kamailio A
|
+--> authenticate
+--> save("location")
|
+--> DMQ usrloc replication
|
v
Kamailio B
Result:
Both edge nodes know the contactاین الگو باعث می‌شود اگر Kamailio A از دسترس خارج شود، Kamailio B Contactهای Replicateشده را داشته باشد. با این حال NAT Binding، Transport Connection و TCP/TLS/WebSocket Sessionهای متصل به Node اول موضوع جدا هستند و Client ممکن است نیاز به Reconnect داشته باشد.
Failure Scenario ۱: Kamailio A Down می‌شود
تماس جدید: DNS SRV/VIP/Load Balancer باید Client را به Kamailio B هدایت کند.
Registration: اگر usrloc Replication فعال است، Contact State در Node دوم موجود است؛ اما Connectionهای TCP/TLS/WSS روی Node A از بین می‌روند و Client باید Reconnect کند.
تماس فعال: اگر SIP Dialog برای Mid-dialog Requestها Route Record مناسب دارد و Node از بین رفته است، رفتار به Topology و Failover طراحی‌شده بستگی دارد. HA Signaling برای Dialog فعال نیازمند طراحی دقیق‌تر از یک DNS Switch ساده است.
Failure Scenario ۲: Asterisk 2 Down می‌شود
قبل از Answer: Dispatcher و Failure Route می‌توانند INVITE را به Asterisk بعدی بفرستند.
بعد از Answer: اگر Call State روی Asterisk 2 بوده و Process/Host Crash کند، تماس معمولاً قطع می‌شود. داشتن Realtime DB این Session را روی Asterisk 3 ادامه نمی‌دهد.
راه کاهش اثر: چند Node، Maintenance Drain، Monitoring و Capacity Headroom داشته باشید تا Failure روی تماس‌های جدید اثر نگذارد و Crash Active Session کمترین دامنه را داشته باشد.
Failure Scenario ۳: RTPengine 1 Down می‌شود
تماس جدید: ماژول Kamailio می‌تواند Node خراب را Disable کند و RTPengine دیگر را انتخاب کند.
تماس فعال: Media Session موجود روی Node خراب‌شده معمولاً قطع می‌شود، مگر معماری Active/Standby و State Recovery مخصوص طراحی شده باشد. صرف داشتن دو RTPengine به معنی Session Migration آنی نیست.
برای Maintenance بهتر است Node را از پذیرش Session جدید خارج کنید و صبر کنید تماس‌های Active آن تخلیه شوند.
Failure Scenario ۴: Database از دسترس خارج می‌شود
اثر آن به این بستگی دارد که DB در Hot Path کجاست.
| نوع وابستگی | اثر احتمالی |
|---|---|
| Kamailio Registrar فقط Memory + DMQ | Registrationهای موجود ممکن است ادامه پیدا کنند |
| Subscriber Auth در DB | REGISTER جدید یا Authentication می‌تواند Fail شود |
| Asterisk Realtime PJSIP | Load Config/Object جدید ممکن است Fail شود |
| CDR DB | تماس ممکن است برقرار شود ولی Accounting آسیب ببیند |
به همین دلیل بهتر است سرویس را طوری طراحی کنید که Down شدن CDR Database الزاماً SIP Call را متوقف نکند، مگر سیاست کسب‌وکار خلاف آن را ایجاب کند.
Failure Scenario ۵: یک Data Center کامل قطع می‌شود
Multi-node داخل یک Rack، شما را در برابر قطع برق، Router، Upstream یا Data Center محافظت نمی‌کند.
برای Multi-DC باید درباره این موارد تصمیم بگیرید:
🔹 DNS/VIP بین Siteها چگونه Failover می‌کند؟
🔹 Registrar State بین Siteها Replicate می‌شود یا User دوباره REGISTER می‌کند؟
🔹 Database Replication Sync است یا Async؟
🔹 Recording و CDR در کدام Site ذخیره می‌شوند؟
🔹 RTPengine به نزدیک‌ترین Site انتخاب می‌شود یا Central است؟
🔹 Split-brain چطور جلوگیری می‌شود؟
اگر Latency بین دو Site زیاد باشد، قرار دادن هر SIP Request یا Database Transaction روی لینک بین‌شهری می‌تواند Performance را خراب کند. تا جای ممکن Hot Path را محلی نگه دارید و State لازم را با روش مناسب Replicate کنید.
HA واقعی را لایه‌به‌لایه تعریف کنید
| لایه | روش HA | چه چیزی را نجات می‌دهد؟ |
|---|---|---|
| DNS / Entry | SRV، VIP، Anycast | ورود تماس جدید |
| Kamailio | Active-Active + DMQ | Routing و Registration جدید |
| Asterisk | Pool + Dispatcher | تماس جدید و Capacity |
| RTPengine | Pool + Weight/Health | Media Session جدید |
| Database | Replication/Cluster | Config و داده مشترک |
| Storage | Replicated/Object Storage | Recording و Artifactها |
هیچ ردیفی از این جدول به‌تنهایی تضمین نمی‌کند تماس Active بدون وقفه باقی بماند. Session Continuity باید جداگانه برای هر Failure Scenario بررسی شود.
Load Balancing را با چه الگوریتمی انجام دهیم؟
برای Backendهای Asterisk چند انتخاب دارید:
| روش | مناسب برای | محدودیت |
|---|---|---|
| Round Robin | Nodeهای تقریباً هم‌ظرفیت | Load واقعی را نمی‌بیند |
| Weighted | Nodeهای با قدرت متفاوت | Weight ثابت است |
| Hash User | Sticky Routing | ممکن است Load نامتوازن شود |
| Call Load / Capacity-aware | ترافیک ناهمگون | State و Monitoring بیشتری لازم دارد |
اگر Asterisk-1 چهار برابر Asterisk-2 CPU دارد، Round Robin برابر انتخاب خوبی نیست. Weight باید بر اساس Benchmark واقعی باشد، نه تعداد vCPU روی کاغذ.
Capacity Planning؛ هر لایه Bottleneck خودش را دارد
| لایه | شاخص اصلی |
|---|---|
| Kamailio | SIP messages/sec، CPS، transactions، TLS connections |
| Asterisk | Concurrent calls، CPS، Queue، IVR، Transcoding، Recording |
| RTPengine | Media sessions، packets/sec، bandwidth، SRTP، transcoding |
| Database | QPS، write latency، connection count، replication lag |
| Storage | IOPS، throughput، retention |
| Network | PPS، jitter، packet loss، bandwidth |
به همین دلیل جمله «این VPS چند تماس می‌گیرد؟» بدون Call Flow پاسخ دقیق ندارد. یک تماس G.711 بدون Recording با WebRTC Opus + SRTP + Recording + Queue بار یکسانی ندارد.
Monitoring؛ قبل از HA باید بدانید چه چیزی خراب شده است
حداقل این شاخص‌ها را جمع‌آوری کنید:
🔹 Kamailio: SIP 2xx/4xx/5xx، Dispatcher State، REGISTER Rate و CPS.
🔹 Asterisk: Active Channels، Calls، Taskprocessors، Queue Depth و CPU.
🔹 RTPengine: Active Sessions، PPS، Byte Rate، Packet Error و One-way Stream.
🔹 DB: Query Latency، Connection Errors، Replication Lag.
🔹 Linux: CPU Steal، SoftIRQ، Memory، Network Drop و Disk Latency.
برای Asterisk:
asterisk -rx "core show channels count"
asterisk -rx "core show taskprocessors"برای Kamailio Dispatcher:
kamcmd dispatcher.listبرای RTPengine نیز RPC/Control Statistics را وارد Monitoring کنید و فقط به CPU نگاه نکنید.
امنیت این معماری را از Edge شروع کنید
وقتی Kamailio Edge رسمی شماست، Backendها نباید دوباره Public Surface جدا داشته باشند.
🔹 Asterisk SIP فقط از Kamailio و Management Network پذیرفته شود.
🔹 RTPengine Control Socket فقط برای Kamailio/OpenSIPS قابل‌دسترسی باشد.
🔹 Media Port Range با Firewall محدود و مانیتور شود.
🔹 Carrierها با IP ACL یا Authentication مناسب محدود شوند.
🔹 TLS برای Signaling و SRTP برای Media در Endpointهای سازگار استفاده شود.
🔹 SSH فقط از IP یا VPN مدیریتی باز باشد.
🔹 Database Port روی Public Internet باز نباشد.
مطلب مرتبط: قبل از Production، خود Linux Nodeها را هم سخت‌سازی کنید.
چگونه SSH را امن کنیم؟ از حذف Root Login تا SSH Key و Fail2Ban
ترتیب پیاده‌سازی پیشنهادی
معماری را یک‌باره روی Production نبرید. این ترتیب ریسک کمتری دارد:
🔹 مرحله ۱: دو Kamailio + یک Asterisk + یک RTPengine در Lab.
🔹 مرحله ۲: Registrar و REGISTER Replication بین Kamailioها.
🔹 مرحله ۳: Asterisk دوم و Dispatcher Failover.
🔹 مرحله ۴: RTPengine دوم و Media Pool.
🔹 مرحله ۵: Database HA و Storage مستقل.
🔹 مرحله ۶: DNS/VIP Failover.
🔹 مرحله ۷: Load Test و Failure Injection.
🔹 مرحله ۸: انتقال درصد کمی از ترافیک واقعی.
Failure Injection؛ HA را با خاموش‌کردن واقعی Node تست کنید
صرف دیدن دو Node سبز در Monitoring کافی نیست. قبل از Production این تست‌ها را اجرا کنید:
| تست | انتظار |
|---|---|
| خاموش‌کردن Kamailio A | REGISTER/INVITE جدید از Kamailio B ادامه یابد |
| خاموش‌کردن Asterisk 1 قبل از Answer | INVITE به Node بعدی Failover شود |
| خاموش‌کردن Asterisk 1 وسط تماس | ثبت شود که تماس Active قطع می‌شود؛ دامنه اثر اندازه‌گیری شود |
| خاموش‌کردن RTPengine 1 قبل از Call | Media Node دوم انتخاب شود |
| خاموش‌کردن RTPengine 1 وسط تماس | رفتار Session Active مستند شود |
| قطع DB Primary | Failover DB و اثر روی Auth/Config اندازه‌گیری شود |
| قطع DNS Resolver | Resolver دوم پاسخ دهد |
| قطع Link بین Siteها | Split-brain یا State Conflict ایجاد نشود |
Load Test را با Production Features انجام دهید
اگر در Production WebRTC، TLS، SRTP، Recording و Queue دارید، Benchmark خام SIP بدون این قابلیت‌ها Capacity واقعی شما را نشان نمی‌دهد.
حداقل این Metrics را ثبت کنید:
🔹 Concurrent Calls.
🔹 CPS.
🔹 P50/P95/P99 Call Setup Time.
🔹 SIP 503/408/Timeout Rate.
🔹 RTP Packet Loss و Jitter.
🔹 CPU User/System/Steal.
🔹 RTPengine PPS و Bandwidth.
🔹 DB Query Latency.
Load Generator را روی همان VPS هدف اجرا نکنید. Generator باید روی Host جدا باشد تا CPU و Network آن با PBX رقابت نکند.
برای WebRTC و AI Voice این معماری چه مزیتی دارد؟
وقتی Media Plane جداست، اضافه‌کردن Browser یا سرویس AI ساده‌تر می‌شود. RTPengine می‌تواند WebRTC، ICE و SRTP را در Edge مدیریت کند و Asterisk تمرکز خود را روی Call Logic نگه دارد.
برای Voice AI نیز می‌توانید Media Processing یا Forking را روی لایه‌ای مستقل قرار دهید تا STT/TTS/AI Workerها مستقیماً به Edge یا Application Layer متصل شوند و مجبور نباشید هر قابلیت جدید را داخل Core PBX پیاده‌سازی کنید.
مطلب مرتبط: اگر معماری شما قرار است Voice AI هم داشته باشد، راهنمای اجرای Voice AI و Whisper روی VPS را ببینید.
چه زمانی این معماری بیش از حد پیچیده است؟
اگر فقط ۲۰ داخلی و چند تماس هم‌زمان دارید، ساخت دو Kamailio، سه Asterisk، دو RTPengine و Cluster Database احتمالاً هزینه عملیاتی بیشتری از فایده آن دارد.
این معماری زمانی توجیه دارد که حداقل یکی از این شرایط وجود داشته باشد:
🔹 Downtime یک PBX برای کسب‌وکار قابل‌قبول نیست.
🔹 چندصد یا چند هزار Endpoint دارید.
🔹 تماس هم‌زمان و CPS بالا دارید.
🔹 چند Carrier و چند Site دارید.
🔹 WebRTC/NAT/SRTP پیچیده دارید.
🔹 Maintenance بدون قطع سرویس لازم است.
🔹 Media و Application باید مستقل Scale شوند.
اشتباه‌های رایج در VoIP چندسروره
🔹 Redundant کردن PBX ولی فراموش‌کردن Single Point of Failure در Kamailio.
🔹 دو Kamailio ولی فقط یک Database.
🔹 Round Robin کردن REGISTER بدون طراحی Registrar State.
🔹 تصور اینکه Realtime Database تماس Active را بین Asteriskها منتقل می‌کند.
🔹 دو RTPengine بدون Plan برای Media Session Active.
🔹 DNS SRV بدون تست رفتار واقعی Phone.
🔹 Public کردن Portهای Asterisk Backend.
🔹 تعیین Weightها بر اساس حدس به‌جای Benchmark.
🔹 یکی دانستن HA تماس جدید و Session Continuity.
می‌خواهید Kamailio + Asterisk + RTPengine را چندسروره راه‌اندازی کنید؟
قبل از انتخاب VPS باید تعداد Endpoint، تماس هم‌زمان، CPS، Codecها، WebRTC، Recording، تعداد Siteها و RTO/RPO مشخص شود. بعد می‌توان تعداد Kamailio، Asterisk و RTPengine را بر اساس Benchmark واقعی تعیین کرد.
ایرانیکاسرور می‌تواند برای تهیه VPS، طراحی شبکه، نصب Kamailio/Asterisk/RTPengine، Firewall، Load Balancing و تست Failure سناریو کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
چرا Kamailio را جلوی Asterisk قرار دهیم؟
Kamailio Signaling، Registrar، Routing، Load Balancing و Security Edge را از Asterisk جدا می‌کند. در نتیجه Backendهای PBX مستقیماً در معرض اینترنت نیستند و تماس‌های جدید می‌توانند بین چند Node توزیع شوند.
RTPengine چرا جدا از Asterisk لازم می‌شود؟
RTPengine Media Plane را مستقل می‌کند و برای NAT، WebRTC، ICE، SRTP و Scaling Media کاربرد دارد. این کار اجازه می‌دهد ظرفیت Media جدا از Signaling و PBX افزایش یابد.
اگر یک Asterisk خراب شود تماس فعال به Node دیگر منتقل می‌شود؟
معمولاً خیر. Load Balancer می‌تواند تماس جدید را به Node سالم ببرد، اما Call State فعال روی Asterisk خراب‌شده به‌صورت خودکار روی Node دیگر ادامه پیدا نمی‌کند.
چطور Registration را بین دو Kamailio هماهنگ کنیم؟
Kamailio می‌تواند Registrar باشد و با usrloc Contactها را ذخیره کند. ماژول dmq_usrloc برای Replication رکوردهای usrloc بین چند Kamailio طراحی شده است.
DNS SRV بهتر است یا VIP؟
به Client و شبکه بستگی دارد. SRV استاندارد SIP است اما رفتار همه Phoneها و Carrierها یکسان نیست. VIP یا Load Balancer شبکه‌ای در بعضی محیط‌ها Failover قابل‌کنترل‌تری می‌دهد.
آیا یک Database مشترک برای همه Nodeها کافی است؟
برای اشتراک Configuration ممکن است مفید باشد، اما اگر فقط یک DB دارید همان DB به Single Point of Failure تبدیل می‌شود. Database نیز باید Replication و Failover مناسب داشته باشد.
چند RTPengine لازم است؟
تعداد Nodeها به Media Session، Packet Rate، Bandwidth، WebRTC، SRTP و Transcoding بستگی دارد. برای HA حداقل دو Node منطقی است، اما ظرفیت باید با Benchmark واقعی تعیین شود.
برای شروع چند سرور لازم است؟
برای Lab می‌توانید دو Kamailio، دو Asterisk و دو RTPengine را حتی با منابع کوچک‌تر تست کنید. در Production تعداد و منابع Nodeها باید بر اساس Peak Concurrent Call، CPS، Codec و Failure Domain تعیین شود.
جمع‌بندی
معماری VoIP مقیاس‌پذیر از اضافه‌کردن سرور بیشتر شروع نمی‌شود؛ از جداکردن مسئولیت‌ها شروع می‌شود. Kamailio باید Signaling و Registrar را مدیریت کند، Asterisk Application و Call Logic را اجرا کند و RTPengine Media را جداگانه Anchor و Scale کند.
دو Kamailio بدون Registration Replication، چند Asterisk بدون Failure Route یا چند RTPengine بدون Health Check هنوز HA کامل نیستند. DNS، Database و Storage نیز باید به‌اندازه خود SIP Layer Redundant طراحی شوند.
مهم‌تر از همه، Failover تماس جدید را با Session Continuity اشتباه نگیرید. خرابی یک Asterisk یا RTPengine وسط تماس می‌تواند همان Session را قطع کند، حتی اگر تماس بعدی بلافاصله روی Node سالم برقرار شود.
اگر قبل از Production Failure Injection، Load Test و Capacity Benchmark اجرا کنید، این معماری می‌تواند بدون تبدیل‌شدن به یک سیستم پیچیده و شکننده، ظرفیت و دسترس‌پذیری VoIP را مرحله‌به‌مرحله افزایش دهد.
برای طراحی VoIP چندسروره کمک می‌خواهید؟
اگر Peak Call، تعداد Endpoint، SIP Provider، WebRTC و سطح دسترس‌پذیری موردنیاز مشخص باشند، می‌توان Topology مناسب را قبل از خرید نهایی منابع روی VPS آزمایشی اعتبارسنجی کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)