ساخت Load Balancer برای Asterisk با Kamailio؛ مدیریت تماس‌های پرترافیک

اگر فقط یک Asterisk دارید، شاید اصلاً به Kamailio نیاز نداشته باشید. اما وقتی تعداد کاربران، SIP Trunkها یا تماس‌ها افزایش پیدا می‌کند و می‌خواهید چند Asterisk پشت یک آدرس واحد داشته باشید، Kamailio می‌تواند به لایه‌ای تبدیل شود که تمام SIP Traffic ابتدا وارد آن شده و سپس به Backend مناسب هدایت شود.

در این معماری، کاربر یا SIP Provider لزوماً نمی‌داند پشت آدرس عمومی شما سه، پنج یا ده Asterisk وجود دارد.

در این مقاله فقط Kamailio را معرفی نمی‌کنیم؛ یک معماری واقعی می‌سازیم که در آن چند Asterisk پشت یک SIP Proxy قرار دارند و مرحله‌به‌مرحله مشخص می‌کنیم Registrar کجا باشد، Load Balancing چگونه انجام شود، NAT و RTP چه می‌شوند، Failover چگونه طراحی می‌شود و چطور IPهای داخلی Asterisk را از اینترنت مخفی کنیم.

Kamailio دقیقاً چیست؟

Kamailio یک SIP Server مبتنی بر استاندارد SIP است که مهم‌ترین وظیفه آن پردازش و مسیریابی پیام‌های SIP است.

یعنی پیام‌هایی مثل:

می‌توانند قبل از رسیدن به Asterisk توسط Kamailio بررسی، احراز هویت، محدود یا Route شوند.

Kamailio با Asterisk چه تفاوتی دارد؟

Asterisk معمولاً یک B2BUA است.

یعنی تماس را دریافت می‌کند، Dialplan را اجرا می‌کند، Channel می‌سازد، Bridge ایجاد می‌کند و در صورت نیاز RTP را نیز پردازش می‌کند.

Kamailio در حالت معمول SIP Proxy است.

یعنی SIP Dialog را مثل Asterisk به دو تماس مستقل تبدیل نمی‌کند؛ بیشتر نقش Router بسیار سریع SIP را دارد.

پس Kamailio جای Asterisk را نمی‌گیرد

در معماری مورد بحث ما:

Kamailio = لایه ورودی، Routing، Registration، Security و Load Balancing

Asterisk = منطق تماس، Dialplan، Queue، IVR، Recording و Application

این دو مکمل هم هستند، نه رقیب مستقیم.

معماری ساده چند Asterisk پشت Kamailio

یک معماری پایه می‌تواند چنین باشد:

IP Phones / SIP Providers
           |
           v
    +---------------+
    |    Kamailio   |
    |  SIP Proxy/LB |
    +---------------+
       /     |     \
      /      |      \
     v       v       v
Asterisk1 Asterisk2 Asterisk3
10.20.0.11 10.20.0.12 10.20.0.13

کاربران فقط:

sip.example.com

را می‌بینند.

Asteriskها می‌توانند کاملاً روی Private Network قرار داشته باشند.

چرا Kamailio را جلوی Asterisk بگذاریم؟

مهم‌ترین دلایل عبارت‌اند از:

Registrar و Proxy را با هم اشتباه نگیریم

این مهم‌ترین مفهوم مقاله است.

Kamailio می‌تواند فقط Proxy باشد یا هم‌زمان نقش Registrar را نیز انجام دهد.

SIP Proxy چیست؟

Proxy یک SIP Request را دریافت می‌کند و آن را به مقصد دیگری Forward می‌کند.

مثلاً:

INVITE
Phone
  ↓
Kamailio
  ↓
Asterisk-02

در این سناریو Kamailio تصمیم گرفته Asterisk-02 تماس را پردازش کند.

Registrar چیست؟

Registrar مقصد پیام REGISTER است.

وقتی تلفن Register می‌شود، Registrar باید بداند:

داخلی 1001 اکنون از چه IP و Portی قابل دسترسی است؟

مثلاً:

1001
sip:1001@198.51.100.25:50872
expires=300

Kamailio برای این کار از ماژول‌های:

registrar
usrloc

استفاده می‌کند.

سه مدل معماری Registration داریم

مدل اول: Kamailio فقط Proxy است

REGISTER از تلفن وارد Kamailio می‌شود ولی Kamailio آن را به یکی از Asteriskها Forward می‌کند.

پس Contact داخل Asterisk ذخیره می‌شود.

مزیت این مدل سادگی Migration است.

اگر قبلاً تمام داخلی‌ها روی Asterisk Register می‌شدند، تغییر کمتری لازم دارید.

مشکل این مدل چیست؟

Registration State روی همان Asterisk باقی می‌ماند.

اگر داخلی 1001 روی Asterisk-01 Register شده باشد ولی تماس بعدی به Asterisk-03 فرستاده شود، Asterisk-03 Contact همان تلفن را ندارد.

در چنین معماری‌ای باید Sticky Routing داشته باشید.

برای REGISTER از Hash استفاده کنیم

Dispatcher الگوریتمی برای Hash بر اساس Authentication Username دارد.

در نتیجه می‌توانید تلاش کنید تمام REGISTERهای یک User به همان Backend برسند.

اما Failover همچنان پیچیده است؛ چون Registration State بین Asteriskها به‌طور خودکار مشترک نیست.

مدل دوم: Kamailio خودش Registrar است

در این معماری:

Phone REGISTER
      ↓
   Kamailio
 registrar/usrloc
      ↓
   200 OK

Asterisk دیگر مالک Contact تلفن نیست.

تمام Location State روی Kamailio قرار دارد.

مزیت بزرگ Registrar مرکزی

حالا Asteriskها Statelessتر می‌شوند.

تماس ورودی می‌تواند روی هر Asterisk پردازش شود و وقتی لازم است به User برسد، دوباره به Kamailio فرستاده شود.

Kamailio با Location Lookup مقصد واقعی تلفن را پیدا می‌کند.

اما این مدل پیچیده‌تر است

اگر FreePBX، VitalPBX یا Dialplan شما فرض می‌کند Extensionها مستقیماً روی Asterisk Register می‌شوند، نمی‌توانید Registrar را بدون طراحی مجدد ناگهان به Kamailio منتقل کنید.

Authentication، Presence، BLF، MWI، Contact State و Device Status باید در معماری جدید بررسی شوند.

مدل سوم: Kamailio Edge + Registrar + Asterisk Application Pool

این معماری برای سیستم‌های بزرگ بسیار جذاب است.

Phones
   |
REGISTER
   |
   v
Kamailio Registrar
   |
   +---- Location / NAT
   |
INVITE
   |
   v
Kamailio Dispatcher
   |
   +---------+---------+
   |         |         |
   v         v         v
Asterisk1 Asterisk2 Asterisk3

در این حالت Asteriskها بیشتر نقش Application Server را دارند.

برای این مقاله کدام معماری را می‌سازیم؟

برای اینکه Setup پایه قابل‌فهم و کم‌ریسک باشد، ابتدا Kamailio را به‌عنوان:

SIP Edge Proxy + Load Balancer

جلوی چند Asterisk قرار می‌دهیم.

بعد Registrar مرکزی را به‌عنوان مرحله پیشرفته‌تر بررسی می‌کنیم.

نسخه فعلی Kamailio

در زمان بررسی این مقاله:

Kamailio 6.1.5

آخرین نسخه پایدار است.

شاخه 6.1 چه تغییر مهمی دارد؟

از تغییرهای شاخه 6.1 می‌توان به مواردی مثل:

اشاره کرد.

سیستم‌عامل پیشنهادی

Repository رسمی Kamailio برای 6.1.x در حال حاضر Packageهای Debian 12 و Debian 13 را ارائه می‌کند.

برای این آموزش از:

Debian 12 Bookworm

استفاده می‌کنیم.

مرحله ۱: نصب Repository رسمی Kamailio

apt update
apt install -y wget gpg ca-certificates

Signing Key رسمی:

wget -O- https://deb.kamailio.org/kamailiodebkey.gpg \
| gpg --dearmor \
| tee /usr/share/keyrings/kamailio.gpg >/dev/null

Repository شاخه 6.1 روی Debian 12

echo 'deb [signed-by=/usr/share/keyrings/kamailio.gpg] http://deb.kamailio.org/kamailio61 bookworm main' \
> /etc/apt/sources.list.d/kamailio.list

apt update

مرحله ۲: نصب Kamailio

برای Proxy پایه:

apt install -y kamailio kamailio-tls-modules

اگر بعداً Registrar با Database می‌سازید، Driver دیتابیس مناسب مثل MySQL/MariaDB یا PostgreSQL را نیز نصب کنید.

نسخه نصب‌شده را بررسی کنید

kamailio -V

فایل اصلی تنظیمات کجاست؟

/etc/kamailio/kamailio.cfg

قبل از هر تغییر:

cp /etc/kamailio/kamailio.cfg \
/etc/kamailio/kamailio.cfg.before-lb

مرحله ۳: Backendهای Asterisk را روی شبکه خصوصی قرار دهید

مثلاً:

IPها مثال مستندسازی هستند.

در Production بهتر است Asteriskها از اینترنت Public SIP مستقیم دریافت نکنند.

Asterisk فقط باید Kamailio را ببیند

در Firewall Backendها، SIP ورودی را تا حد امکان فقط از:

10.20.0.5

یا IPهای Kamailio Cluster مجاز کنید.

این کار Attack Surface را بسیار کاهش می‌دهد.

مرحله ۴: Dispatcher را فعال کنید

ماژول `dispatcher` برای پخش SIP Request بین چند مقصد ساخته شده است.

در Configuration:

loadmodule "dispatcher.so"
loadmodule "tm.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "sanity.so"

فایل مقصدهای Dispatcher

برای نمونه:

1 sip:10.20.0.11:5060 0 0 duid=ast01;weight=50
1 sip:10.20.0.12:5060 0 0 duid=ast02;weight=50
1 sip:10.20.0.13:5060 0 0 duid=ast03;weight=50

هر سه داخل Dispatcher Set شماره 1 هستند.

مسیر فایل را مشخص کنید

modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list")

Health Check را فعال کنید

اگر Backend خراب شد، نمی‌خواهیم تماس جدید همچنان به آن ارسال شود.

برای نمونه:

modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_mode", 1)

Kamailio به مقصدها OPTIONS می‌فرستد و وضعیت Availability آن‌ها را بررسی می‌کند.

روی Asterisk به OPTIONS پاسخ بدهید

Health Check فقط وقتی مفید است که پاسخ Backend واقعاً نشان‌دهنده سلامت سرویس باشد.

اگر Firewall یا PJSIP روی Asterisk OPTIONS را بی‌دلیل Reject کند، Kamailio ممکن است Backend سالم را Down تصور کند.

الگوریتم‌های Dispatcher

Dispatcher فقط Round Robin نیست.

برای شروع کدام الگوریتم را انتخاب کنیم؟

برای سه Asterisk تقریباً هم‌اندازه، Round Robin نقطه شروع مناسبی است.

ds_select_dst("1", "4")

اگر سرورها منابع متفاوت دارند

Weight-based بهتر است.

مثلاً Asterisk-01 دو برابر Asterisk-03 CPU دارد.

می‌توانید Weight متفاوت تعریف کنید تا سهم بیشتری از تماس‌ها بگیرد.

Call Load Distribution چه زمانی بهتر است؟

Round Robin فقط تعداد انتخاب‌ها را تقریباً تقسیم می‌کند.

اما ممکن است Node اول 100 تماس طولانی داشته باشد و Node دوم تماس‌های کوتاه زیادی دریافت کرده باشد.

الگوریتم Call Load Distribution می‌تواند بر اساس بار تماس فعال تصمیم دقیق‌تری بگیرد.

نمونه Routing پایه INVITE

یک Baseline ساده:

request_route {

    if (!sanity_check("1511", "7")) {
        exit;
    }

    if (!mf_process_maxfwd_header("10")) {
        sl_send_reply("483", "Too Many Hops");
        exit;
    }

    if (is_method("OPTIONS") && uri == myself) {
        sl_send_reply("200", "OK");
        exit;
    }

    if (has_totag()) {
        if (loose_route()) {
            route(RELAY);
        }
        exit;
    }

    if (is_method("INVITE")) {
        record_route();

        if (!ds_select_dst("1", "4")) {
            sl_send_reply("503", "No Asterisk Available");
            exit;
        }

        t_on_failure("ASTERISK_FAILOVER");
        route(RELAY);
        exit;
    }

    route(RELAY);
}

route[RELAY] {
    if (!t_relay()) {
        sl_reply_error();
    }
    exit;
}

این Configuration فقط Baseline آموزشی است و Production کامل محسوب نمی‌شود.

چرا record_route مهم است؟

اگر Kamailio فقط INVITE اولیه را Route کند و از مسیر Dialog خارج شود، Requestهای بعدی مثل:

ممکن است مسیر دیگری طی کنند.

`record_route()` باعث می‌شود Kamailio در Route Set تماس باقی بماند.

loose_route چه کاری انجام می‌دهد؟

Requestهای داخل Dialog را طبق Route Header موجود Route می‌کند.

نکته مهم این است که تماس اولیه را با Dispatcher انتخاب می‌کنیم؛ قرار نیست هر BYE یا re-INVITE دوباره Round Robin شود و به Asterisk دیگری برود.

Failover Backend را اضافه کنیم

اگر Asterisk انتخاب‌شده پاسخ مناسب نداد، می‌توان Destination بعدی Dispatcher را امتحان کرد.

نمونه مفهومی:

failure_route[ASTERISK_FAILOVER] {

    if (t_is_canceled()) {
        exit;
    }

    if (t_check_status("408|5[0-9][0-9]")) {

        if (ds_next_dst()) {
            t_on_failure("ASTERISK_FAILOVER");
            t_relay();
            exit;
        }
    }
}

Failover تماس جدید با Failover تماس فعال فرق دارد

این نکته بسیار مهم است.

اگر Asterisk-01 قبل از Answer شدن تماس خراب شود، Kamailio می‌تواند INVITE را به Backend بعدی بفرستد.

اما اگر Asterisk وسط یک تماس ۳۰ دقیقه‌ای Crash کند، Kamailio نمی‌تواند به‌سادگی همان تماس فعال را به Asterisk-02 منتقل کند.

State تماس و Media روی Asterisk-01 بوده است.

پس High Availability واقعی یعنی چه؟

در بسیاری از معماری‌های عملی هدف این است:

تماس‌های جدید بلافاصله از Node خراب دور شوند.

نه اینکه هر تماس فعال بدون وقفه بین Asteriskها Live Migrate شود.

وضعیت Dispatcher را ببینیم

از RPC:

kamcmd dispatcher.list

استفاده کنید.

بعد از تغییر فایل مقصدها:

kamcmd dispatcher.reload

قبل از Reload فایل Kamailio را Validate کنید

kamailio -c -f /etc/kamailio/kamailio.cfg

در Production ابتدا Syntax Check و سپس Reload یا Restart کنترل‌شده انجام دهید.

NAT در معماری Kamailio + Asterisk

یکی از اصلی‌ترین دلیل‌های استفاده از SIP Edge Proxy، مدیریت بهتر NAT است.

اما باید دو بخش را جدا کنید:

SIP Signaling NAT

RTP Media NAT

Kamailio به‌صورت پیش‌فرض Media Proxy نیست

این اشتباه رایج است.

اگر INVITE از Kamailio عبور کند لزوماً RTP از Kamailio عبور نمی‌کند.

مسیر می‌تواند چنین باشد:

SIP:
Phone → Kamailio → Asterisk

RTP:
Phone ↔ Asterisk

nathelper برای Signaling NAT

Kamailio ماژول:

nathelper

دارد.

این ماژول می‌تواند NAT Detection، Contact Handling و NAT Keepalive را مدیریت کند.

fix_nated_contact را کورکورانه استفاده نکنید

مستند رسمی خود Kamailio هشدار می‌دهد `fix_nated_contact()` خود Contact Header را Rewrite می‌کند و این روش کاملاً RFC-compliant نیست.

در بسیاری از سناریوهای جدید، ترکیب‌هایی مثل:

add_contact_alias()
handle_ruri_alias()

انتخاب استانداردتری هستند.

NAT Binding باید زنده بماند

تلفن‌های پشت NAT ممکن است Port Mapping خود را بعد از مدتی از دست بدهند.

Kamailio می‌تواند Keepalive یا SIP Ping ارسال کند تا Binding فعال بماند.

اگر Media را هم کنترل کنیم چه؟

در این حالت RTPEngine به معماری اضافه می‌شود.

        SIP
Phone -------- Kamailio -------- Asterisk
  \                                 /
   \                               /
    +--------- RTPEngine ----------+
              RTP Media

RTPEngine چه کاری انجام می‌دهد؟

Kamailio SDP را به RTPEngine می‌دهد.

RTPEngine آدرس Media را Rewrite می‌کند تا RTP از Media Relay عبور کند.

توابع مهم ماژول Kamailio:

rtpengine_offer()
rtpengine_answer()
rtpengine_manage()
rtpengine_delete()

چه زمانی RTPEngine لازم است؟

مثلاً وقتی:

اگر Asterisk خودش Media را Anchor می‌کند چه؟

لزومی ندارد حتماً RTPEngine اضافه کنید.

هر Media Relay جدید Complexity و مصرف منابع ایجاد می‌کند.

اول مشخص کنید چه کسی مالک Media Path است:

Asterisk یا RTPEngine؟

دو بار Rewrite کردن SDP در لایه‌های مختلف بدون طراحی مشخص می‌تواند باعث صدای یک‌طرفه شود.

Topology Hiding چیست؟

وقتی SIP Packet از چند Proxy و Backend عبور می‌کند ممکن است Headerهایی مثل:

اطلاعات شبکه داخلی را آشکار کنند.

topoh چه کاری می‌کند؟

ماژول `topoh` Routing Headerهای SIP را Mask می‌کند.

مثلاً کاربر بیرونی نباید ببیند تماس از:

10.20.0.11
10.20.0.12

عبور کرده است.

topos چه تفاوتی دارد؟

`topos` Routing Headerهای مربوط به Topology را Strip می‌کند و اطلاعات موردنیاز برای بازسازی مسیر را داخل Storage نگه می‌دارد.

Backendهای Storage آن می‌توانند شامل:

باشند.

برای HA، انتخاب Storage اهمیت دارد

اگر چند Kamailio Active دارید و از `topos` استفاده می‌کنید، Topology State باید در معماری Failover دیده شود.

Storage صرفاً Local ممکن است باعث شود Node دیگر اطلاعات لازم برای بازسازی Dialog را نداشته باشد.

در چنین طراحی‌هایی Redis یا Database مشترک می‌تواند بررسی شود.

Topology Hiding امنیت کامل نیست

مخفی‌کردن IP داخلی مفید است، اما:

Topoh یا Topos جای Firewall نیست.

اگر Backend Asterisk همچنان از اینترنت قابل دسترسی باشد، مخفی‌شدن IP داخل SIP Header تضمین امنیت نمی‌کند.

برای مخفی‌کردن کامل Backend باید Media را هم در نظر بگیرید

ممکن است SIP Headerها کاملاً Mask شده باشند ولی داخل SDP هنوز این IP دیده شود:

c=IN IP4 10.20.0.11

اگر هدف واقعی مخفی‌کردن Media Topology است، SDP نیز باید با RTPEngine یا Media Architecture مناسب مدیریت شود.

امنیت Kamailio؛ Edge Server مستقیماً روی اینترنت است

وقتی Kamailio جلوی همه Asteriskها قرار می‌گیرد، خودش اولین نقطه تماس اینترنت با SIP Infrastructure می‌شود.

پس Edge Security باید جدی‌تر از یک PBX داخلی باشد.

اول Firewall

فقط Protocol و Portهایی را باز کنید که واقعاً استفاده می‌کنید.

اگر UDP/5060 دارید، نیازی نیست ده‌ها Port SIP دیگر بدون کاربرد باز باشند.

اگر Provider IP ثابت دارد، Traffic Trunk را بر اساس Source IP محدود کنید.

Backendها را به Internet Exposure ندهید

یکی از مهم‌ترین مزایای Kamailio همین است.

اگر Asterisk-01 فقط باید از Kamailio SIP بگیرد، Firewall آن را همین‌طور تنظیم کنید.

Sanity Check قبل از Routing

ماژول:

sanity

می‌تواند Packetهای SIP معیوب را قبل از ورود به Logic اصلی رد کند.

Max-Forwards را بررسی کنید

برای جلوگیری از Routing Loop:

mf_process_maxfwd_header("10")

یک Guard ساده اما ضروری است.

ACL با permissions

Kamailio ماژول `permissions` دارد که می‌تواند IP-based ACL را برای مواردی مثل:

مدیریت کند.

چرا ACL برای SIP Trunk مهم است؟

اگر Carrier فقط از سه IP مشخص INVITE می‌فرستد، لازم نیست یک INVITE ناشناس از هرجای اینترنت وارد Routing Trunk شود.

Authentication و ACL می‌توانند در لایه Edge قبل از رسیدن Packet به Asterisk اعمال شوند.

Flood Protection

Kamailio ماژول‌هایی مثل:

pike
ratelimit
htable
secfilter

برای شناسایی یا محدودکردن الگوهای مشکوک دارد.

اما Threshold را از اینترنت Copy نکنید.

یک Carrier ممکن است در Peak صدها INVITE در ثانیه بفرستد و همان عدد برای یک شبکه کوچک Attack به نظر برسد.

TLS را کجا Terminate کنیم؟

یکی از معماری‌های رایج این است:

Phone/Provider → TLS → Kamailio → Private SIP → Asterisk

در این حالت Certificate Public روی Kamailio مدیریت می‌شود.

اگر Compliance یا Zero-Trust داخلی دارید، می‌توانید بین Kamailio و Asterisk نیز TLS داشته باشید.

Kamailio 6.1 TLS چندریسمانی را بهبود داده است

شاخه 6.1 امکان Multi-threaded TLS Operations را اضافه کرده است.

برای Platformهایی با تعداد TLS Connection بالا، این تغییر می‌تواند از نظر طراحی ظرفیت اهمیت داشته باشد.

Registrar مرکزی را چطور طراحی کنیم؟

اگر تصمیم گرفتید Registration روی Kamailio Terminate شود، حداقل این اجزا نیازند:

فقط save(“location”) کافی نیست

یک Configuration ناامن ممکن است چیزی شبیه:

if (is_method("REGISTER")) {
    save("location");
    exit;
}

داشته باشد.

این نمونه برای Production مناسب نیست.

قبل از `save()` باید Authentication و Registration Policy اعمال شود.

چرا Registration Permissions مهم است؟

ماژول `permissions` حتی می‌تواند Contactهایی را که نباید Register شوند رد کند.

مثلاً نباید یک User مخرب بتواند Contact خودش را روی IP یک PSTN Gateway ثبت کند و Routing Security را دور بزند.

Location Table را مشاهده کنیم

اگر Kamailio Registrar است:

kamcmd ul.dump

می‌تواند Contactهای ثبت‌شده را نشان دهد.

HA Registrar با دو Kamailio

اگر فقط یک Kamailio دارید و Registrar روی آن است، همان Server تبدیل به Single Point of Failure می‌شود.

برای معماری بزرگ‌تر می‌توانید دو یا چند Kamailio داشته باشید.

                SIP Clients
                    |
               VIP / DNS
                /      \
               /        \
        Kamailio-01  Kamailio-02
             \          /
              \        /
             Asterisk Pool

Location Recordها را بین Kamailioها Replicate کنیم

ماژول:

dmq_usrloc

برای Replication رکوردهای `usrloc` بین Kamailio Nodeها ساخته شده است.

این ماژول از:

dmq
usrloc

استفاده می‌کند.

DMQ چیست؟

Distributed Message Queue مکانیزمی داخل Kamailio است که اطلاعات را بین Nodeهای Kamailio Replicate می‌کند.

Location Record، Cached Data و برخی Stateها می‌توانند از طریق Channelهای DMQ منتقل شوند.

یک نکته نسخه‌ای مهم در DMQ

مستند رسمی هشدار می‌دهد Nodeهای DMQ باید Major Version یکسان داشته باشند.

مثلاً Cluster 6.1 را با Node 6.0 بدون بررسی دقیق مخلوط نکنید.

Kamailio خودش نباید Single Point of Failure شود

یکی از اشتباه‌های معماری این است که سه Asterisk HA بسازیم ولی فقط یک Kamailio داشته باشیم.

در آن صورت:

Asteriskها High Available هستند اما Edge Proxy نه.

روش‌های دسترسی به چند Kamailio

بسته به شبکه می‌توانید از:

استفاده کنید.

انتخاب روش باید با UDP/TCP/TLS Session Behavior و Registrar State هماهنگ باشد.

Load Balancer عمومی HTTP را برای SIP فرض نکنید

SIP با HTTP یکسان نیست.

اگر Load Balancer جلوی Kamailio قرار می‌دهید، باید UDP/TCP/TLS و حفظ Flowها را درست پشتیبانی کند.

Kamailio یا HAProxy؟

HAProxy و Load Balancerهای L4 می‌توانند Connection Distribution انجام دهند، اما Kamailio SIP را می‌فهمد.

یعنی می‌تواند بر اساس:

تصمیم Route بگیرد.

برای چند Asterisk کدام Topology مناسب‌تر است؟

برای شروع:

Internet
   |
Kamailio x2
   |
Dispatcher
   |
Asterisk x3
   |
DB / Services

معماری خوبی است.

اگر Registration روی Kamailio است:

DMQ/Location Replication را نیز اضافه کنید.

اگر Media Relay نیاز دارید:

RTPEngine Cluster را جدا کنید.

Asterisk Backend باید چه چیزی بداند؟

Asterisk باید بداند ترافیک SIP قانونی از Kamailio می‌آید.

اما نباید صرفاً Source IP Kamailio را معادل User Authentication فرض کنید مگر معماری شما دقیقاً همین‌طور طراحی شده باشد.

Kamailio می‌تواند Headerها، Identity و Authentication را قبل از Backend بررسی کند.

Source IP اصلی کاربر را گم نکنیم

وقتی تمام Packetها از Kamailio وارد Asterisk می‌شوند، Asterisk در لایه Network ممکن است Source را Kamailio ببیند.

اگر برای Logging، Fraud Detection یا CDR به IP واقعی User نیاز دارید، آن را با Header یا Metadata کنترل‌شده منتقل کنید.

به Header دلخواه Client اعتماد نکنید؛ Kamailio باید آن را حذف و خودش مقدار معتبر تولید کند.

REGISTER را Round Robin نکنید بدون طراحی State

این یکی از رایج‌ترین اشتباه‌هاست.

اگر:

REGISTER شماره ۱ → Asterisk-01

REGISTER شماره ۲ → Asterisk-02

REGISTER شماره ۳ → Asterisk-03

شود، Device State شما بین Serverها پخش و ناپایدار می‌شود.

برای Registration یا Registrar مرکزی بسازید یا Sticky Routing طراحی کنید.

INVITE جدید را می‌توان Load Balance کرد

برخلاف REGISTER، تماس جدید برای Application Pool راحت‌تر قابل توزیع است.

Kamailio Backend را انتخاب می‌کند و همان Dialog از همان مسیر ادامه پیدا می‌کند.

BLF و Presence را فراموش نکنید

اگر سیستم شما فقط Voice Call نیست و Featureهایی مثل:

دارد، Multi-Asterisk Design پیچیده‌تر می‌شود.

SUBSCRIBE State باید با Backend و Registrar Architecture هماهنگ باشد.

Database مشترک همه مشکلات را حل نمی‌کند

ممکن است سه Asterisk به یک Database متصل باشند، اما SIP Dialog و Registration Memory همچنان State محلی داشته باشند.

Shared DB را با Shared Runtime State اشتباه نگیرید.

Monitoring چه چیزهایی لازم دارد؟

برای Kamailio فقط CPU را مانیتور نکنید.

مهم‌اند:

Latency-aware Dispatching

Dispatcher جدید الگوریتمی دارد که می‌تواند Latency Backendها را در انتخاب مقصد لحاظ کند.

این قابلیت زمانی مفید است که Nodeها در دیتاسنترهای متفاوت یا با Performance متفاوت باشند.

اما در Cluster هم‌مکان و Stable، پیچیدگی غیرضروری ایجاد نکنید؛ Round Robin یا Call Load ممکن است کافی باشد.

چطور معماری را Test کنیم؟

Test Plan فقط نباید یک تماس دستی باشد.

مرحله ۱: هر Asterisk جداگانه تماس بگیرد.

مرحله ۲: Dispatcher هر سه را Up نشان دهد.

مرحله ۳: ۳۰ تماس جدید ایجاد کنید و Distribution را ببینید.

مرحله ۴: Asterisk-02 را Stop کنید.

مرحله ۵: ببینید OPTIONS Health Check آن را Down تشخیص می‌دهد.

مرحله ۶: تماس جدید نباید به Node خراب برود.

مرحله ۷: Asterisk-02 را برگردانید.

مرحله ۸: Recovery Dispatcher را بررسی کنید.

مرحله ۹: NAT Client واقعی تست شود.

مرحله ۱۰: تماس دوطرفه و RTP تست شود.

Load Test با SIPp

برای سامانه جدی، SIPp می‌تواند INVITE Rate و Call Concurrency را افزایش دهد.

در Load Test بررسی کنید:

Kamailio احتمالاً زودتر از Asterisk Bottleneck می‌شود؟

در بسیاری از معماری‌ها Kamailio بسیار سبک است و Media را پردازش نمی‌کند؛ بنابراین Bottleneck زودتر ممکن است روی:

ظاهر شود.

اما هیچ عدد عمومی را جای Benchmark واقعی نگذارید.

یک معماری پیشنهادی Production

                      Internet
                         |
                    sip.example.com
                         |
                 +----------------+
                 | VIP / SIP Edge |
                 +----------------+
                    /          \
                   /            \
          Kamailio-01         Kamailio-02
              |                   |
              +------ DMQ --------+
                      |
                 Dispatcher
                 /    |    \
                /     |     \
               v      v      v
           Asterisk Asterisk Asterisk
             01       02       03
               \       |      /
                \      |     /
                 Application DB

Optional Media:
Kamailio ↔ RTPEngine Cluster

چرا دو Kamailio و سه Asterisk؟

این عدد قانون نیست.

هدف فقط جداکردن Failure Domainها است.

Kamailio Edge Failure نباید کل سیستم را قطع کند و Asterisk Application Node Failure نیز نباید تماس‌های جدید را متوقف کند.

Backendها را Drain کنیم، نه ناگهان خاموش

برای Maintenance بهتر است ابتدا Backend را از Dispatcher Selection خارج کنید.

تماس‌های فعال را اجازه دهید تمام شوند.

بعد Service را Restart یا Upgrade کنید.

این روش از قطع بی‌دلیل تماس‌های فعال جلوگیری می‌کند.

Upgrade Kamailio 6.1.x

Releaseهای Minor شاخه 6.1 مانند 6.1.5 با Compatibility Configuration و Database Schema شاخه قبلی 6.1 منتشر شده‌اند.

با این حال روی Production:

Backup → Node Drain → Upgrade یک Node → Test → Upgrade Node بعدی

روش امن‌تری است.

Kamailio چه زمانی اضافه‌کاری است؟

اگر فقط:

یک شرکت کوچک، ۲۰ تلفن و یک Asterisk دارید، اضافه‌کردن Kamailio ممکن است فقط Complexity ایجاد کند.

یک Asterisk درست کانفیگ‌شده احتمالاً کافی است.

چه زمانی Kamailio ارزش واقعی پیدا می‌کند؟

وقتی یکی از این نیازها دارید:

Kamailio با FreePBX قابل استفاده است؟

از نظر فنی بله، چون FreePBX روی Asterisk است.

اما اگر چند FreePBX پشت Kamailio قرار می‌دهید، Database و Extension Configuration هر Node باید با معماری Registration و Routing شما هماهنگ باشد.

قرار دادن چند FreePBX پشت Round Robin بدون طراحی State، HA واقعی ایجاد نمی‌کند.

Kamailio با VitalPBX چطور؟

همان اصل برقرار است.

Kamailio می‌تواند SIP Edge باشد ولی باید مشخص باشد:

Registrar چه سیستمی است؟

BLF کجا مدیریت می‌شود؟

Extension State کجا نگه‌داری می‌شود؟

Dialplan کدام Node را انتخاب می‌کند؟

Kamailio با FusionPBX چه؟

FusionPBX مبتنی بر FreeSWITCH است، اما Kamailio می‌تواند جلوی FreeSWITCH هم همان نقش SIP Proxy و Dispatcher را انجام دهد.

پس معماری Kamailio محدود به Asterisk نیست.

مقایسه نقش‌ها

اشتباه‌های رایج در معماری Kamailio + Asterisk

اشتباه ۱: REGISTER را Round Robin می‌کنیم بدون اینکه State را طراحی کنیم.

اشتباه ۲: تصور می‌کنیم Kamailio خودش RTP Proxy است.

اشتباه ۳: Asteriskها هنوز از اینترنت مستقیم در دسترس‌اند.

اشتباه ۴: یک Kamailio جلوی پنج Asterisk می‌گذاریم و Edge را SPOF می‌کنیم.

اشتباه ۵: Topology Hiding را جای Firewall می‌گیریم.

اشتباه ۶: NAT را هم در Kamailio و هم Asterisk بدون Ownership مشخص Rewrite می‌کنیم.

اشتباه ۷: OPTIONS Health Check داریم ولی Backendها پاسخ درست نمی‌دهند.

اشتباه ۸: Dialogهای فعال را هنگام Maintenance ناگهان Kill می‌کنیم.

پرسش‌های رایج

Kamailio چیست؟

Kamailio یک SIP Server متن‌باز و بسیار سبک است که می‌تواند به‌عنوان SIP Proxy، Registrar، Location Server، Load Balancer و Security Edge در جلوی Asterisk یا FreeSWITCH استفاده شود.

آخرین نسخه Kamailio در اکتبر ۲۰۲۶ چیست؟

آخرین نسخه پایدار فعلی Kamailio نسخه 6.1.5 است که ۱۵ اکتبر ۲۰۲۶ منتشر شده است.

آیا Kamailio جای Asterisk را می‌گیرد؟

معمولاً خیر. Kamailio بیشتر مسئول SIP Routing و Edge است و Asterisk برای Dialplan، IVR، Queue، Recording و Application Logic استفاده می‌شود.

آیا Kamailio می‌تواند Registrar باشد؟

بله. ماژول registrar همراه usrloc می‌تواند Contactهای کاربران را ذخیره و Location Lookup انجام دهد.

برای چند Asterisk چه ماژولی استفاده کنیم؟

ماژول dispatcher برای توزیع SIP بین چند Asterisk طراحی شده و الگوریتم‌هایی مثل Round Robin، Weight، Call Load و Latency-aware دارد.

اگر یکی از Asteriskها Down شود چه می‌شود؟

با Dispatcher Probing و Failover می‌توان تماس‌های جدید را از Backend خراب دور کرد. تماس فعال روی Node خراب الزاماً قابل انتقال زنده نیست.

آیا RTP از Kamailio عبور می‌کند؟

به‌صورت پیش‌فرض خیر. Kamailio SIP Signaling را Proxy می‌کند. برای Anchor کردن Media می‌توان RTPEngine یا Media Proxy دیگری به معماری اضافه کرد.

برای NAT، Kamailio بهتر است یا Asterisk؟

هر دو قابلیت NAT Handling دارند. در معماری Edge بهتر است مالکیت NAT مشخص باشد و از Rewrite دوگانه بدون طراحی جلوگیری شود. Kamailio می‌تواند Signaling NAT را مدیریت و در صورت نیاز RTPEngine Media NAT را انجام دهد.

Topology Hiding چه کاری می‌کند؟

ماژول‌هایی مثل topoh و topos اطلاعات Routing داخلی را از SIP Headerها مخفی می‌کنند. این قابلیت جای Firewall نیست و برای مخفی‌کردن Media IP باید SDP نیز جداگانه مدیریت شود.

آیا Kamailio خودش Single Point of Failure می‌شود؟

اگر فقط یک Node داشته باشید بله. در معماری HA بهتر است حداقل دو Kamailio و در صورت Registrar بودن Replication مناسب usrloc داشته باشید.

چطور Registrar State بین چند Kamailio هماهنگ می‌شود؟

یکی از روش‌های رسمی استفاده از dmq_usrloc است که رکوردهای User Location را از طریق DMQ بین Kamailio Nodeها Replicate می‌کند.

Kamailio برای یک شرکت کوچک لازم است؟

نه لزوماً. اگر فقط یک Asterisk و تعداد کمی User دارید، Kamailio ممکن است Complexity غیرضروری ایجاد کند. ارزش اصلی آن در Scale، SIP Edge، Multi-Node و HA دیده می‌شود.