در اکتبر ۲۰۲۶، نسخه پایدار فعلی Kamailio 6.1.5 است که در ۱۵ اکتبر ۲۰۲۶ منتشر شده است. شاخه 6.1 برای Debian 12 Bookworm و Debian 13 Trixie Repository رسمی دارد و برای یک طراحی جدید انتخاب منطقیتری از شاخههای قدیمی است.
معماری پیشنهادی این مقاله: Phone / SIP Trunk → Kamailio → Dispatcher → Asterisk 1 / Asterisk 2 / Asterisk 3. در صورت نیاز، RTPengine برای Media/NAT، Database برای Registrar و یک Kamailio دوم برای HA اضافه میشود.
Kamailio دقیقاً چیست؟
Kamailio در هسته یک SIP Proxy/Registrar قابلبرنامهریزی است. SIP Messageها را میخواند، Rule اجرا میکند و بر اساس Request-URI، Header، IP، User، Domain، Dispatcher Group یا Database تصمیم میگیرد پیام به کجا برود.
این یعنی Kamailio معمولاً Audio را Mix یا Record نمیکند و IVR یا Queue سنگین را مثل Asterisk اجرا نمیکند. تمرکز آن روی Signaling است.
SIP Phone / Trunk
|
v
Kamailio
/ | \
v v v
AST1 AST2 AST3
برای همین در شبکههای پرترافیک، Kamailio معمولاً در Edge قرار میگیرد و Asteriskها را از اینترنت مستقیم مخفی میکند.
SIP Proxy با Registrar چه فرقی دارد؟
این تفاوت پایه معماری شما را تعیین میکند.
| نقش | کار اصلی | State کاربر |
|---|---|---|
| SIP Proxy | Forward کردن REGISTER/INVITE/MESSAGE به مقصد دیگر | میتواند Stateless یا Transaction Stateful باشد |
| Registrar | پذیرفتن REGISTER و ذخیره Contact کاربر | Contact در usrloc نگهداری میشود |
| Load Balancer | تقسیم SIP Request بین چند Backend | با Dispatcher و Health Check |
ماژول registrar خود Kamailio منطق REGISTER را اجرا میکند و اطلاعات Contact را در usrloc نگه میدارد. تابع save("location") برای ذخیره Registration و lookup("location") برای پیدا کردن Contact استفاده میشود.
دو معماری معتبر برای Kamailio جلوی Asterisk
مدل ۱: Kamailio فقط Proxy/Load Balancer باشد
در این مدل REGISTER و INVITE به یکی از Asteriskها Forward میشوند و Registration اصلی روی همان Asterisk باقی میماند.
مزیت: سادهتر.
مشکل: باید Sticky Routing داشته باشید تا REGISTER و درخواستهای بعدی همان User تا حد ممکن به همان Backend بروند. اگر Node خراب شود، Registrationهای آن Node تا Re-register شدن Device از بین میروند.
برای Sticky Routing میتوانید از Hash روی Username یا Call-ID استفاده کنید.
مدل ۲: Kamailio خودش Registrar باشد
این مدل برای Scale معمولاً تمیزتر است. Phoneها روی Kamailio Register میشوند و Contactها در usrloc قرار میگیرند. Asteriskها پشت Kamailio فقط Application Server هستند.
Phone REGISTER
|
v
Kamailio
registrar + usrloc
|
+---- INVITE ----> Asterisk Pool
|
<---- INVITE ----- Asterisk
|
lookup(location)
|
v
Phone
مزیت این مدل این است که Registration State از Backendهای Asterisk جدا میشود.
قاعده طراحی: اگر Kamailio فقط Load Balancer باشد، Registration Affinity را جدی بگیرید. اگر Kamailio Registrar باشد، Asterisk باید تماس برگشتی به Endpoint را دوباره از Kamailio عبور دهد تا lookup درست انجام شود.
وضعیت نسخه Kamailio در ۲۰۲۶
نسخه پایدار فعلی 6.1.5 است. این Release در ۱۵ اکتبر ۲۰۲۶ منتشر شده و طبق اعلام رسمی، Configuration File و Database Schema شاخه 6.1 با Release قبلی سازگار ماندهاند.
اگر سرور جدید دارید، Repository رسمی Kamailio برای Debian 12 و Debian 13 موجود است. در این مقاله مثال را با Debian 12 مینویسیم چون هنوز در بسیاری از سرورهای VoIP استفاده میشود.
مرحله ۱: نصب Kamailio 6.1 روی Debian 12
ابتدا کلید Repository رسمی:
wget -O- https://deb.kamailio.org/kamailiodebkey.gpg \
| gpg --dearmor \
| sudo tee /usr/share/keyrings/kamailio.gpg >/dev/null
Repository:
echo "deb [signed-by=/usr/share/keyrings/kamailio.gpg] http://deb.kamailio.org/kamailio61 bookworm main" \
| sudo tee /etc/apt/sources.list.d/kamailio.list
نصب:
apt update
apt install -y kamailio
نسخه را بررسی کنید:
kamailio -V
مرحله ۲: سه Asterisk را در Dispatcher تعریف کنید
Dispatcher برای Load Balancing ساخته شده و الگوریتمهای Round Robin، Hash، Weight و Call Load دارد.
یک فایل ساده بسازید:
nano /etc/kamailio/dispatcher.list
نمونه:
1 sip:10.10.10.11:5060
1 sip:10.10.10.12:5060
1 sip:10.10.10.13:5060
هر سه Backend داخل Set شماره 1 هستند.
مرحله ۳: Dispatcher Module را Load کنید
در /etc/kamailio/kamailio.cfg:
loadmodule "tm.so"
loadmodule "sl.so"
loadmodule "rr.so"
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)
OPTIONS Probe کمک میکند Backend خراب از Pool خارج شود.
مرحله ۴: تماس را بین Asteriskها توزیع کنید
برای نمونه Round Robin:
route[TO_ASTERISK] {
if (!ds_select_dst("1", "4")) {
send_reply("503", "No PBX available");
exit;
}
t_on_failure("RTF_DISPATCH");
route(RELAY);
}
failure_route[RTF_DISPATCH] {
if (t_is_canceled()) {
exit;
}
if (ds_next_dst()) {
t_on_failure("RTF_DISPATCH");
t_relay();
exit;
}
}
در Dispatcher الگوریتم 4 Round Robin است. برای طراحی Sticky میتوانید از Hash روی Call-ID، Request-URI یا Authorization Username استفاده کنید؛ برای تماسهای همزمان زیاد نیز الگوریتم Call Load وجود دارد.
Health Check؛ اگر یک Asterisk Down شد چه میشود؟
Load Balancer بدون Health Check کافی نیست. Kamailio میتواند با SIP OPTIONS سلامت Backendها را بررسی کند.
وضعیت Dispatcher را با RPC ببینید:
kamcmd dispatcher.list
در Production باید Failure Route را طوری طراحی کنید که اگر Transaction به Backend اول Fail شد، Destination بعدی امتحان شود.
HA تماس فعال: Dispatcher میتواند تماس جدید را به Node سالم بفرستد، اما اگر Asterisk وسط یک تماس Active Crash کند، آن مکالمه معمولاً باقی نمیماند. Failover تماس جدید با Session Survival دو موضوع جدا هستند.
REGISTER را Round Robin نکنید مگر معماریاش را فهمیده باشید
REGISTER با INVITE معمولی فرق دارد. اگر Phone هر بار روی Asterisk متفاوت Register شود، Contact State بین Backendها پراکنده میشود.
سه روش رایج:
🔹 Kamailio خودش Registrar باشد.
🔹 REGISTER بر اساس Username Hash به Backend ثابت برود.
🔹 Backendها Registration State مشترک یا Architecture مخصوص داشته باشند.
برای بسیاری از Deploymentهای چند Asterisk، Registrar شدن Kamailio مدل قابلکنترلتری است.
نمونه Registrar ساده در Kamailio
ماژولها:
loadmodule "usrloc.so"
loadmodule "registrar.so"
REGISTER:
if (is_method("REGISTER")) {
if (!save("location")) {
sl_reply_error();
}
exit;
}
تماس به User:
if (lookup("location")) {
route(RELAY);
exit;
}
برای Production باید Authentication، Database Persistence، NAT و Multi-domain را هم اضافه کنید.
NAT؛ Kamailio فقط Signaling را حل میکند
این یکی از اشتباههای رایج است: Kamailio NAT SIP را مدیریت میکند، اما خود RTP لزوماً از Kamailio عبور نمیکند.
برای SIP Contact و NAT Keepalive میتوانید از nathelper استفاده کنید. این ماژول میتواند NAT Ping بفرستد تا Mapping کلاینتهای UDP باز بماند.
اما اگر Media باید Anchor شود، معمولاً یک Media Proxy مثل RTPEngine کنار Kamailio قرار میگیرد.
Phone
|
SIP
v
Kamailio
|
+---- SIP ----> Asterisk
|
+---- SDP Control ----> RTPEngine
|
RTP
چه زمانی RTPEngine لازم است؟
🔹 دو Endpoint پشت NAT پیچیده هستند.
🔹 WebRTC و DTLS-SRTP دارید.
🔹 میخواهید Media Topology مستقل از Asterisk باشد.
🔹 چند Media Node دارید و Load Balancing RTP لازم است.
🔹 نیاز به RTP Recording/Transcoding/Statistics در لایه Media Proxy دارید.
Kamailio 6.1 میتواند چند RTPEngine را داخل Set تعریف و بر اساس Weight بین آنها Load Balance کند.
Topology Hiding؛ IP داخلی Asteriskها را لو ندهید
اگر Kamailio جلوی چند PBX است ولی Headerهای SIP، Route، Record-Route یا Via اطلاعات Backend را آشکار کنند، هدف Edge Security کامل نشده است.
ماژول topos برای مخفیکردن جزئیات Topology طراحی شده است و Headerهایی که اطلاعات مسیر داخلی را نشان میدهند از پیام خروجی پنهان میکند.
loadmodule "topos.so"
اگر Topology Hiding بخشی از معماری شماست، آن را همراه Record-Route، NAT و Media Path تست کنید؛ مخصوصاً وقتی تماس از Carrier وارد میشود و از Asterisk دوباره خارج میشود.
امنیت؛ Kamailio را به یک Port Forward ساده تبدیل نکنید
Edge SIP Server باید Filter داشته باشد. فقط اینکه UDP/5060 روی Kamailio باز باشد و همه چیز به Asterisk Forward شود امنیت ایجاد نمیکند.
چند لایه مهم:
🔹 permissions: ACL بر اساس IP برای Carrier و Trusted Source.
🔹 pike: تشخیص IPهایی با Request Rate غیرطبیعی.
🔹 sanity: ردکردن SIP Messageهای malformed.
🔹 maxfwd: جلوگیری از Loop.
🔹 TLS برای SIP Signaling در صورت پشتیبانی Endpoint/Carrier.
🔹 Firewall OS برای محدودکردن Management و Backend Network.
Carrier را با ACL محدود کنید
اگر Provider IP ثابت دارد، بهجای قبول SIP از کل اینترنت، فقط Range رسمی Provider را Trust کنید.
ماژول permissions Address-based ACL و Trusted Request را پشتیبانی میکند و ACLها میتوانند در Database Load شوند.
Flood Detection با Pike
pike Request Rate هر Source IP را دنبال میکند و وقتی Rate از Threshold بالاتر رفت، Script شما تصمیم میگیرد چه کاری انجام دهد؛ Drop، Block یا Log.
loadmodule "pike.so"
modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 30)
این اعداد Example هستند، نه مقدار Production قطعی. Threshold باید با Traffic واقعی شما تنظیم شود.
Kamailio جای SBC را میگیرد؟
نه همیشه. Kamailio میتواند بخش مهمی از معماری SBC باشد، اما بهتنهایی تمام وظایف SBC تجاری را انجام نمیدهد.
اگر به Media Anchoring، Transcoding، SRTP Interworking، Codec Policy یا Recording در Edge نیاز دارید، باید RTPEngine یا Media Layer جدا اضافه کنید.
اگر فقط Signaling Proxy، ACL، Load Balancing و Topology Hiding میخواهید، Kamailio میتواند بخش بزرگی از نیاز را پوشش دهد.
Topology پیشنهادی برای سه Asterisk
Internet
|
SIP 5060/5061
|
v
+---------------+
| Kamailio |
| Proxy/Registrar|
| Dispatcher |
+-------+-------+
|
+-------------+-------------+
| | |
v v v
+---------+ +---------+ +---------+
|Asterisk1| |Asterisk2| |Asterisk3|
+---------+ +---------+ +---------+
\ | /
\ | /
+------ Shared Apps -----+
Optional Media Path:
Kamailio ---> RTPEngine Pool ---> Endpoints/Carriers
Backendهای Asterisk بهتر است Public Port مستقیم نداشته باشند و فقط از IPهای Kamailio/Management Network SIP بپذیرند.
Kamailio خودش Single Point of Failure نشود
اگر سه Asterisk دارید ولی فقط یک Kamailio جلوی آنهاست، هنوز یک Single Point of Failure دارید.
برای HA Edge معمولاً دو Kamailio استفاده میشود:
SIP Clients / Carrier
|
DNS SRV / VIP
/ \
v v
Kamailio1 Kamailio2
\ /
\ /
Asterisk Pool
برای Registrar HA، Contact Database و usrloc Replication هم باید طراحی شود؛ فقط داشتن دو Process کافی نیست.
Load Balancing را چطور انتخاب کنیم؟
| روش | کاربرد | نکته |
|---|---|---|
| Round Robin | پخش ساده تماس | برای Backendهای مشابه |
| Weight | سرورهای با ظرفیت متفاوت | Node قویتر سهم بیشتر میگیرد |
| Hash Call-ID | Sticky Dialog | Requestهای Dialog به مسیر پایدار نزدیک میشوند |
| Hash Username | Registration Affinity | برای Proxy-only architecture کاربردی است |
| Call Load | تقسیم بر اساس تعداد Call فعال | برای INVITE طراحی شده است |
| Latency Optimized | چند Site با Latency مختلف | به Probe و Latency Stats وابسته است |
چطور صحت Routing را تست کنیم؟
Config را قبل از Restart بررسی کنید:
kamailio -c -f /etc/kamailio/kamailio.cfg
سرویس:
systemctl restart kamailio
systemctl status kamailio
Log:
journalctl -u kamailio -f
برای SIP Trace در Production بهتر است از HEP/Homer یا Capture کنترلشده استفاده کنید و Debug گسترده را دائمی روشن نگذارید.
چه چیزهایی را قبل از Production تست کنیم؟
| تست | نتیجه مورد انتظار |
|---|---|
| Round Robin | INVITEها بین Nodeها توزیع شوند |
| Backend Failure | Node Down از Pool خارج شود |
| Failure Route | تماس جدید روی Node بعدی Retry شود |
| REGISTER | State روی Registrar درست بماند |
| NAT | تماس دوطرفه و Re-register پایدار |
| Carrier ACL | SIP ناشناخته Reject شود |
| Flood | Request Rate غیرعادی محدود شود |
| Topology | IP داخلی Backend در SIP Header دیده نشود |
| TLS | Handshake و Certificate معتبر باشد |
| Kamailio HA | خرابی Edge باعث قطع Registration جدید نشود |
اشتباههای رایج
🔹 Round Robin کردن REGISTER بدون Sticky یا Registrar Design.
🔹 بازگذاشتن Asterisk Backend روی اینترنت عمومی.
🔹 تصور اینکه Kamailio خودش RTP را Proxy میکند.
🔹 نداشتن Health Check روی Dispatcher.
🔹 فقط یک Kamailio جلوی چند PBX و تصور اینکه HA کامل است.
🔹 Trust کردن کل اینترنت بهجای ACL Provider.
🔹 فعالکردن Topology Hiding بدون تست Record-Route و NAT.
🔹 Debug SIP دائمی روی Edge پرترافیک.
میخواهید Kamailio را جلوی چند Asterisk راهاندازی کنید؟
برای طراحی درست باید مشخص باشد Kamailio فقط Proxy است یا Registrar، چند Asterisk دارید، Endpointها از اینترنت یا VPN متصل میشوند، Media روی Asterisk میماند یا RTPEngine دارید و Failover تماس جدید چگونه انجام میشود.
ایرانیکاسرور میتواند برای تهیه VPS، نصب Kamailio، Asterisk، SIP Routing، Dispatcher، Firewall و تست Failover کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسشهای رایج
Kamailio چیست؟
Kamailio یک SIP Server متنباز و بسیار سبک است که برای Proxy، Registrar، Routing، Load Balancing و Security در شبکههای VoIP استفاده میشود.
نسخه فعلی Kamailio در اکتبر ۲۰۲۶ چیست؟
نسخه پایدار فعلی 6.1.5 است که در ۱۵ اکتبر ۲۰۲۶ منتشر شده است.
Kamailio جای Asterisk را میگیرد؟
خیر. Kamailio بیشتر Signaling و Routing را مدیریت میکند، در حالی که Asterisk معمولاً Dialplan، IVR، Queue، Recording و Media Application را اجرا میکند.
چطور چند Asterisk را Load Balance کنیم؟
ماژول dispatcher میتواند Backendها را با Round Robin، Weight، Hash یا Call Load انتخاب کند و با SIP OPTIONS سلامت Nodeها را بررسی کند.
بهتر است Phoneها روی Kamailio Register شوند یا Asterisk؟
هر دو ممکن است. برای Proxy-only باید Affinity و Failover Registration طراحی شود. در معماری Registrar، Kamailio REGISTER را ذخیره میکند و Asteriskها Application Server میشوند.
Kamailio NAT و RTP را هم حل میکند؟
Kamailio Signaling NAT را مدیریت میکند، اما برای Media Anchoring معمولاً RTPEngine یا Media Proxy دیگری لازم است.
Topology Hiding چیست؟
Topology Hiding اطلاعات Route و Backendهای داخلی را از SIP Messageهای خروجی مخفی میکند تا IP و ساختار داخلی شبکه کمتر آشکار شود.
Kamailio برای امنیت SIP چه ابزارهایی دارد؟
ACL با permissions، تشخیص Flood با pike، Sanity Check، Max-Forwards، TLS و Topology Hiding از ابزارهای مهم آن هستند.
جمعبندی
Kamailio زمانی ارزش واقعی خود را نشان میدهد که یک Asterisk دیگر کافی نیست یا نمیخواهید Backendهای PBX مستقیماً در معرض اینترنت باشند. با Dispatcher میتوانید تماسها را بین چند Node پخش کنید و با Health Check، Backend خراب را از مسیر تماس جدید خارج کنید.
مهمترین تصمیم قبل از Config این است که مشخص کنید Kamailio فقط SIP Proxy است یا Registrar هم هست. REGISTER را نمیتوان مثل یک INVITE معمولی بدون فکر Round Robin کرد؛ Registration State باید یا در Kamailio نگهداری شود یا با Affinity مشخص به Backend ثابت برسد.
برای NAT و Media نیز مرز مسئولیت را روشن نگه دارید: Kamailio Signaling را مدیریت میکند و در صورت نیاز RTPEngine لایه Media را میگیرد. با ACL، Pike، TLS و Topology Hiding میتوانید Edge امنتری بسازید.
و اگر Availability واقعاً مهم است، جلوی سه Asterisk فقط یک Kamailio نگذارید؛ Edge را هم بهصورت دو Node و با روش Failover مناسب طراحی کنید.
برای نصب Kamailio و Load Balancing Asterisk کمک میخواهید؟
اگر IPهای Asterisk، نوع Registration، تعداد Endpoint و SIP Provider مشخص باشند، میتوان معماری Proxy یا Registrar را انتخاب کرد و Dispatcher، NAT، ACL و Failover را قبل از Production تست کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
کلیدواژه کانونی:
عنوان سئو:
نامک:
توضیح متا:
اطلاعات تصویر
متن جایگزین:
عنوان:
عنوان تصویر:
توضیح:
عنوان نهایی مقاله:
Kamailio چیست؟ ساخت SIP Proxy و Load Balancer جلوی چند Asterisk
برچسبها:






دیدگاهها (۰)