ساخت زیرساخت VoIP پایدار با OpenSIPS؛ چند PBX، Load Balancing و Failover

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

OpenSIPS در اصل یک موتور SIP Signaling است.

یعنی Messageهایی مثل:

را دریافت، بررسی و Route می‌کند.

برخلاف Asterisk، کار اصلی OpenSIPS پخش Music on Hold، اجرای IVR یا Mix کردن Conference نیست.

OpenSIPS بیشتر نقش:

مسیر‌یاب SIP، Registrar، Load Balancer و Edge Proxy

را دارد.

OpenSIPS جای PBX را می‌گیرد؟

معمولاً خیر.

در معماری این مقاله:

OpenSIPS: SIP Routing، Load Balancing، Health Check، Failover و Edge Security

Asterisk/FreeSWITCH: Dialplan، IVR، Queue، Recording، Voicemail و Media Application

را انجام می‌دهند.

معماری هدف ما

فرض کنیم سه PBX داریم:

PBX-01   10.20.0.11:5060
PBX-02   10.20.0.12:5060
PBX-03   10.20.0.13:5060

کاربران و Carrier فقط این آدرس را می‌بینند:

sip.example.com
        |
        v
    OpenSIPS
     /  |  \
    /   |   \
 PBX1 PBX2 PBX3

چرا این معماری بهتر از اتصال مستقیم به PBX است؟

اگر کاربران مستقیماً به یک PBX متصل باشند، ظرفیت و خرابی همان Node مستقیماً روی کاربران اثر می‌گذارد.

با OpenSIPS می‌توانید:

Dispatcher یا Load Balancer؟

این دو Module در OpenSIPS یک کار یکسان انجام نمی‌دهند.

Dispatcher چگونه کار می‌کند؟

Dispatcher مقصد را از بین یک Destination Set انتخاب می‌کند.

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

باشد.

اما Dispatcher در حالت پایه نمی‌داند PBX انتخاب‌شده الآن چند تماس فعال دارد.

بنابراین ممکن است Traffic را از نظر تعداد INVITE تقریباً مساوی پخش کند ولی Load واقعی سرورها برابر نباشد.

یک مثال از مشکل Dispatcher

فرض کنید:

PBX-01 → 100 تماس دو دقیقه‌ای
PBX-02 → 100 تماس بیست دقیقه‌ای

از نظر تعداد Call Attempt ممکن است هر دو مساوی باشند.

اما چند دقیقه بعد:

PBX-01 تقریباً خالی شده است، در حالی که PBX-02 هنوز بیشتر تماس‌های خود را نگه داشته است.

Dispatcher به‌تنهایی الزاماً این تفاوت را نمی‌بیند.

Load Balancer چه تفاوتی دارد؟

ماژول `load_balancer` وضعیت تماس‌های فعال را نگه می‌دارد.

OpenSIPS برای هر Destination ظرفیت تعریف‌شده را می‌داند و مقدار ظرفیت باقی‌مانده را هنگام انتخاب Backend لحاظ می‌کند.

یعنی اگر:

PBX-01 ظرفیت 200 Call
PBX-02 ظرفیت 100 Call
PBX-03 ظرفیت 50 Call

داشته باشند، Load Balancer الزاماً تماس‌ها را 33/33/33 تقسیم نمی‌کند.

Load Balancer چگونه Load را می‌فهمد؟

ماژول Load Balancer از Dialog Tracking استفاده می‌کند.

هنگامی که:

lb_start()

اجرا می‌شود، OpenSIPS تماس را برای Load Balancer دنبال می‌کند.

زمانی که Dialog تمام شود، Resource رزروشده آزاد می‌شود.

Resource در Load Balancer یعنی چه؟

Resource فقط «Call» نیست.

می‌توانید انواع Capacity تعریف کنید.

مثلاً یک Backend ممکن است:

calls=200
transcoding=40
conference=20

ظرفیت داشته باشد.

در نتیجه تماس نیازمند Transcoding را می‌توانید فقط به Nodeهایی بفرستید که Resource مربوطه دارند.

برای سه PBX معمولی چه Resourceای تعریف کنیم؟

اگر همه PBXها یک کار انجام می‌دهند، می‌توانید Resource ساده‌ای مثل:

voice=200

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

نمونه Pool ما

OpenSIPS 4.0 را روی چه سیستم‌عاملی نصب کنیم؟

Repository رسمی فعلی OpenSIPS برای OpenSIPS 4.0 و 3.6 روی Debian Bookworm و Trixie و چند نسخه Ubuntu Package ارائه می‌کند.

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

Debian 12 Bookworm

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

مرحله ۱: Repository رسمی OpenSIPS را اضافه کنید

ابتدا ابزارهای پایه:

apt-get update
apt-get install -y ca-certificates curl gnupg lsb-release mariadb-server

Repository Key:

curl https://apt.opensips.org/opensips-org.gpg \
-o /usr/share/keyrings/opensips-org.gpg

Repository شاخه 4.0 Stable

. /etc/os-release

echo "deb [signed-by=/usr/share/keyrings/opensips-org.gpg] https://apt.opensips.org ${VERSION_CODENAME} 4.0-releases" \
> /etc/apt/sources.list.d/opensips.list

OpenSIPS را نصب کنید

apt-get update
apt-get install -y opensips opensips-cli \
opensips-mysql-module opensips-mysql-dbschema

نسخه را بررسی کنید

opensips -V

مرحله ۲: قبل از Load Balancing شبکه PBXها را درست کنید

بهترین حالت این است که PBXهای Backend روی شبکه Private باشند.

مثلاً:

OpenSIPS: 10.20.0.5
PBX-01:   10.20.0.11
PBX-02:   10.20.0.12
PBX-03:   10.20.0.13

و فقط OpenSIPS Public IP داشته باشد.

Backendها را مستقیم روی اینترنت باز نکنید

اگر SIP ورودی همیشه باید از OpenSIPS بیاید، Firewall هر PBX را طوری تنظیم کنید که SIP فقط از IPهای OpenSIPS مجاز باشد.

این کار باعث می‌شود Botها نتوانند مستقیم Registration یا INVITE به PBX بفرستند.

مرحله ۳: Database را برای OpenSIPS آماده کنید

Load Balancer Destinationها را معمولاً از جدول Database می‌خواند.

جدول `load_balancer` شامل فیلدهای مهم زیر است:

نمونه Destination برای سه PBX

ساختار منطقی جدول می‌تواند چنین باشد:

group_id | dst_uri              | resources | probe_mode
1        | sip:10.20.0.11:5060  | voice=200 | 2
1        | sip:10.20.0.12:5060  | voice=120 | 2
1        | sip:10.20.0.13:5060  | voice=80  | 2

`probe_mode=2` یعنی Destination حتی در حالت سالم هم دائماً Probe می‌شود.

probe_mode چه حالت‌هایی دارد؟

در OpenSIPS سه Mode اصلی داریم:

0: هیچ Probing انجام نشود.

1: فقط وقتی Destination Disabled است Probe شود تا در صورت بازگشت دوباره فعال شود.

2: همیشه Probe شود.

برای PBX Pool تولیدی، Mode 2 معمولاً برای Health Visibility بهتر است؛ البته باید Backend به OPTIONS درست پاسخ دهد.

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

در:

/etc/opensips/opensips.cfg

حداقل Moduleهای مرتبط را Load کنید:

loadmodule "tm.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "dialog.so"
loadmodule "db_mysql.so"
loadmodule "load_balancer.so"

Database URL را تنظیم کنید

modparam("load_balancer", "db_url",
"mysql://opensips:STRONG_DB_PASSWORD@127.0.0.1/opensips")

Credential نمونه را با مقدار واقعی و امن جایگزین کنید.

Health Check با OPTIONS

OpenSIPS به‌صورت پیش‌فرض می‌تواند SIP OPTIONS برای Probing بفرستد.

مثلاً:

modparam("load_balancer", "probing_interval", 10)
modparam("load_balancer", "probing_method", "OPTIONS")

Default مستند `probing_interval` برابر 30 ثانیه است؛ در مثال ما آن را روی 10 ثانیه قرار داده‌ایم تا Recovery سریع‌تر دیده شود.

Interval خیلی کوتاه هم همیشه بهتر نیست

اگر 100 Backend داشته باشید و هر ثانیه Probe بفرستید، Health Check خودش Traffic اضافه تولید می‌کند.

Interval را بر اساس:

انتخاب کنید.

مرحله ۵: تماس جدید را با lb_start به Backend بفرستید

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

if (is_method("INVITE") && !has_totag()) {

    record_route();

    if (!lb_start(1, "voice")) {
        send_reply(503, "No PBX Capacity");
        exit;
    }

    t_on_failure("PBX_FAILOVER");

    if (!t_relay()) {
        send_reply(500, "Relay Failed");
    }

    exit;
}

`lb_start(1, “voice”)` از Group شماره 1 Destinationی را انتخاب می‌کند که Resource `voice` داشته باشد و بیشترین ظرفیت مناسب باقی‌مانده را ارائه دهد.

$du چه می‌شود؟

Load Balancer آدرس Backend انتخاب‌شده را در Destination URI قرار می‌دهد.

یعنی OpenSIPS مشخص می‌کند Request باید به کدام PBX Relay شود.

Dialog Tracking چه زمانی شروع می‌شود؟

در Load Balancing، OpenSIPS برای آن تماس Dialog State ایجاد می‌کند تا Resource مصرف‌شده در طول Call دنبال شود.

با پایان Call، Resource آزاد می‌شود.

چرا BYE مهم است؟

اگر تماس معمولی با BYE تمام شود، Dialog به‌درستی Closed می‌شود.

اما اگر Endpoint یا Network ناگهان از بین برود و BYE نرسد، Dialog تا Timeout باقی می‌ماند.

برای همین Dialog Timeout باید با نوع تماس‌های واقعی شما متناسب باشد.

اگر Dialog State خراب باشد Load هم اشتباه می‌شود

فرض کنید OpenSIPS تصور کند PBX-01 هنوز 100 Call فعال دارد، در حالی که Asterisk Restart شده و همه تماس‌ها از بین رفته‌اند.

Load Balancer ممکن است مدتی ظرفیت آن Node را کمتر از واقعیت در نظر بگیرد.

پس Dialog State و Recovery در معماری HA مهم‌اند.

مرحله ۶: Failover را با lb_next بسازید

اگر Backend اول پاسخ نداد، Destination بعدی را امتحان می‌کنیم.

failure_route[PBX_FAILOVER] {

    if (t_was_cancelled()) {
        exit;
    }

    if (t_check_status("408|500|502|503|504")) {

        if (lb_next()) {
            t_on_failure("PBX_FAILOVER");
            t_relay();
            exit;
        }
    }
}

آیا هر 5xx یعنی Backend خراب است؟

نه.

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

برای مثال 503 ممکن است معنی «ظرفیت سرویس کامل است» بدهد، نه اینکه PBX Offline باشد.

پس Failover روی 5xx قابل استفاده است، اما Disabled کردن کامل Node باید محتاطانه‌تر باشد.

چه زمانی Backend را Disabled کنیم؟

اگر:

دارید، احتمال Down بودن Backend بالاتر است.

در این حالت می‌توانید از:

lb_disable_dst()

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

Node Disabled چطور دوباره وارد Pool می‌شود؟

اگر `probe_mode` مناسب داشته باشد، OpenSIPS به Probe کردن ادامه می‌دهد.

وقتی OPTIONS دوباره پاسخ موفق دریافت کند، Node می‌تواند Auto Enable شود.

Health Check فقط Ping شبکه نیست

ICMP Ping ثابت نمی‌کند SIP Service روی Asterisk سالم است.

ممکن است Server Ping بدهد اما:

OPTIONS Health Check به Application نزدیک‌تر است.

اما OPTIONS هم کامل‌ترین Health Check نیست

ممکن است Asterisk OPTIONS را 200 OK بدهد ولی Database یا Dialplan Application مشکل داشته باشد.

برای سامانه‌های حساس بهتر است Infrastructure Monitoring جداگانه نیز داشته باشید.

وضعیت Load Balancer را در Runtime ببینید

با OpenSIPS CLI:

opensips-cli -x mi load_balancer:list

می‌توانید Destinationها و Load هر Resource را ببینید.

یک Destination را دستی Disable کنید

برای Maintenance:

opensips-cli -x mi load_balancer:status 2 0

در این مثال Destination ID شماره 2 Disabled می‌شود.

Maintenance درست: Drain سپس Restart

اگر PBX تماس فعال دارد، بهتر است:

مرحله ۱: از Load Balancer خارج شود.

مرحله ۲: تماس جدید به آن ارسال نشود.

مرحله ۳: تماس‌های فعال تمام شوند.

مرحله ۴: Upgrade یا Restart انجام شود.

این روش بسیار بهتر از Restart ناگهانی Node است.

Capacity یک Backend را در Runtime تغییر دهید

اگر منابع Server تغییر کرده‌اند، Module امکان Resize Resource را نیز دارد.

مثلاً می‌توانید Capacity `voice` یک Node را بدون طراحی دوباره کل Pool تغییر دهید.

Dispatcher چه زمانی بهتر است؟

با وجود مزایای Load Balancer، Dispatcher هنوز بسیار کاربردی است.

مثلاً برای:

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

وقتی:

جدول مقایسه Dispatcher و Load Balancer

Dialog State چرا در OpenSIPS مهم است؟

یک SIP Proxy می‌تواند Stateless باشد.

اما Load Balancing واقعی تماس نیاز دارد بداند:

این INVITE هنوز Call فعال دارد یا تمام شده است؟

برای همین Module `dialog` وارد معماری می‌شود.

Dialog Module چه اطلاعاتی نگه می‌دارد؟

از جمله:

اگر OpenSIPS Restart شود چه می‌شود؟

این موضوع به Persistency و Cluster Design شما بستگی دارد.

اگر Load Balancer فقط یک Node باشد و تمام Dialog State فقط در RAM باشد، Restart می‌تواند State تماس‌های موجود را از بین ببرد.

در معماری HA باید Dialog Replication را جدی بگیرید.

دو OpenSIPS برای High Availability

می‌توانید دو Edge Node داشته باشید:

             SIP Clients
                 |
            VIP / DNS SRV
              /     \
             /       \
     OpenSIPS-01   OpenSIPS-02
          \           /
           \         /
            PBX Pool

Clusterer چه نقشی دارد؟

Module `clusterer` به چند OpenSIPS اجازه می‌دهد State یا اطلاعات موردنیاز Moduleهای دیگر را بین Nodeها Share یا Replicate کنند.

Dialog Module نیز می‌تواند Dialogها را در Cluster Replicate کند.

Dialog Replication چه فایده‌ای دارد؟

اگر OpenSIPS-01 تماس را ایجاد کرده و OpenSIPS-02 برای Failover آماده است، داشتن Dialog State مشترک می‌تواند باعث شود Node دوم Context بیشتری از تماس داشته باشد.

البته این را نباید با «انتقال زنده RTP» اشتباه گرفت.

OpenSIPS خودش RTP عبور می‌دهد؟

به‌صورت پیش‌فرض خیر.

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

ممکن است SIP مسیر زیر را طی کند:

Phone → OpenSIPS → PBX

ولی Media:

Phone ↔ PBX

باشد.

پس Load Balancing SIP با Load Balancing RTP فرق دارد

اگر OpenSIPS تماس را به PBX-02 انتخاب کرد، SDP باید طوری تنظیم شود که RTP به Media Destination صحیح برسد.

اگر PBXها Public Reachability درست دارند، ممکن است نیازی به Media Relay نباشد.

RTPEngine چه زمانی وارد معماری می‌شود؟

وقتی می‌خواهید Media نیز از یک Layer کنترل‌شده عبور کند.

مثلاً:

معماری با RTPEngine

                 SIP
Phone -------- OpenSIPS -------- PBX
  \                               /
   \                             /
    +--------- RTPEngine --------+
               RTP

OpenSIPS چگونه RTPEngine را کنترل می‌کند؟

Module `rtpengine` SDP را به RTPEngine می‌دهد تا Media Address بازنویسی شود.

در مسیر INVITE معمولاً از:

rtpengine_offer()

و در پاسخ SDP:

rtpengine_answer()

یا Flowهای ساده‌تر با `rtpengine_manage()` استفاده می‌شود.

RTPEngine هم می‌تواند چند Node داشته باشد

Module OpenSIPS از چند RTPEngine و Setهای مختلف پشتیبانی می‌کند.

در نتیجه معماری بزرگ می‌تواند:

OpenSIPS Cluster
      |
PBX Pool
      |
RTPEngine Pool

داشته باشد.

RTPEngine را بی‌دلیل اضافه نکنید

اگر Media مستقیم به‌درستی کار می‌کند و نیازی به NAT Relay، Hiding یا Interworking ندارید، اضافه‌کردن Media Relay فقط Complexity و Bandwidth مصرفی را بیشتر می‌کند.

مالک Media Path را از ابتدا مشخص کنید.

OpenSIPS Load Balancing با FreeSWITCH هم کار می‌کند؟

بله.

Backend لزوماً Asterisk نیست.

OpenSIPS می‌تواند Destinationهایی از نوع:

را Load Balance کند.

یک قابلیت جالب برای FreeSWITCH

Load Balancer OpenSIPS می‌تواند در برخی سناریوها Stats را از FreeSWITCH دریافت کند و ظرفیت را بر اساس اطلاعات واقعی FreeSWITCH به‌روز کند.

برای Asterisk معمولاً Capacity را خودتان تعریف و Dialog Load را OpenSIPS دنبال می‌کند.

امنیت OpenSIPS Load Balancer

وقتی OpenSIPS جلوی PBXها قرار می‌گیرد، خودش مستقیماً در معرض اینترنت قرار دارد.

بنابراین امنیت Edge باید جدی باشد.

Backend PBX را Private نگه دارید

اگر PBX هیچ دلیلی برای دریافت SIP مستقیم از اینترنت ندارد، Port SIP آن را فقط برای OpenSIPS باز کنید.

این مهم‌تر از مخفی‌کردن ساده IP در Headerهاست.

Carrierها را ACL کنید

اگر SIP Provider IPهای ثابت دارد، INVITEهای Trunk را فقط از همان Sourceها قبول کنید.

OpenSIPS Moduleهای ACL و Permissions برای این سناریوها دارد.

Rate Limiting را بر اساس Traffic واقعی تنظیم کنید

یک Carrier ممکن است در ساعت شلوغ 300 CPS داشته باشد.

عددی که برای دفتر 50 نفره Attack است، برای Carrier کاملاً طبیعی است.

Rate Limit را از Config اینترنتی Copy نکنید.

Topology Hiding

اگر نمی‌خواهید آدرس PBXها داخل Via، Record-Route یا Contact دیده شود، OpenSIPS قابلیت Topology Hiding دارد.

اما اگر SDP هنوز IP Backend را نشان دهد، Media Topology همچنان قابل مشاهده است.

برای مخفی‌کردن Media Layer معمولاً RTPEngine نیز وارد طراحی می‌شود.

OpenSIPS یا Kamailio؟

هر دو پروژه SIP Proxy بسیار قدرتمندی هستند و هر دو می‌توانند جلوی چند PBX قرار بگیرند.

تفاوت مهم در این مقاله این است که OpenSIPS یک Module اختصاصی Load Balancer دارد که به‌صورت مستقیم Call Capacity و Resourceهای Backend را دنبال می‌کند.

در Kamailio معمولاً Dispatcher و Logicهای مرتبط برای توزیع Backend بسیار پررنگ هستند.

انتخاب نهایی بیشتر به تجربه تیم، Moduleهای موردنیاز و معماری شما بستگی دارد.

Dispatcher OpenSIPS در چه سناریویی بهتر از Load Balancer است؟

اگر می‌خواهید User همیشه به یک Backend خاص Hash شود، Dispatcher می‌تواند مناسب‌تر باشد.

مثلاً Registrationهایی که State محلی دارند.

REGISTER را مثل INVITE Load Balance نکنید

اگر PBXها خودشان Registrar هستند، Round Robin ساده روی REGISTER می‌تواند State داخلی‌ها را بین Nodeها پخش کند.

مثلاً:

REGISTER 1 → PBX-01
REGISTER 2 → PBX-02
REGISTER 3 → PBX-03

و بعد INVITE ممکن است به Node دیگری برود.

برای Registration چه کار کنیم؟

سه انتخاب معمول داریم:

روش اول: OpenSIPS Registrar باشد.

روش دوم: Mid-Registrar استفاده شود.

روش سوم: REGISTER با Hash ثابت به PBX مشخص Route شود.

این تصمیم را جدا از Load Balancing تماس‌های جدید طراحی کنید.

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

اگر PBX-02 قبل از Answer شدن INVITE Down شود، OpenSIPS می‌تواند Backend دیگری انتخاب کند.

اما اگر PBX-02 وسط تماس فعال Crash کند، معمولاً همان تماس از بین می‌رود.

Dialog Replication در OpenSIPS به معنی انتقال State داخلی Asterisk یا Media Session آن نیست.

High Availability واقعی چند لایه دارد

یک Load Balancer جلوی سه PBX هنوز HA کامل نیست

اگر فقط یک OpenSIPS داشته باشید، همان Node Single Point of Failure است.

پس بعد از Scale کردن PBXها، Edge Layer را نیز Redundant کنید.

Monitoring چه چیزهایی را باید ببیند؟

فقط Ping Server کافی نیست.

حداقل:

تست Failover واقعی

برای Production قبل از انتقال Trunk اصلی این Test Plan را اجرا کنید.

مرحله ۱: هر سه PBX Up باشند.

مرحله ۲: وضعیت آن‌ها را با `load_balancer:list` ببینید.

مرحله ۳: چند ده تماس هم‌زمان ایجاد کنید.

مرحله ۴: Distribution را بررسی کنید.

مرحله ۵: PBX-02 را Stop کنید.

مرحله ۶: ببینید Health Probe آن را Disabled می‌کند.

مرحله ۷: تماس جدید نباید به PBX-02 برود.

مرحله ۸: PBX-02 را برگردانید.

مرحله ۹: Auto-Reenable را بررسی کنید.

مرحله ۱۰: تماس فعال روی Node دیگر نباید تحت تأثیر قرار بگیرد.

Load Test با SIPp

برای تعداد تماس بالا بهتر است SIPp استفاده شود.

مثلاً Load را مرحله‌ای افزایش دهید:

10 CPS
25 CPS
50 CPS
100 CPS
200 CPS

در هر مرحله موارد زیر را ثبت کنید:

Load Balancer ظرفیت را از کجا می‌فهمد؟

Capacity اولیه را شما تعریف می‌کنید.

مثلاً:

PBX-01 voice=200
PBX-02 voice=120
PBX-03 voice=80

این عدد نباید حدس زده شود.

Capacity را با Benchmark تعیین کنید

اگر PBX-01 در تست تا 500 Call زنده می‌ماند، لزوماً Capacity Production را 500 نگذارید.

Headroom برای:

در نظر بگیرید.

Resourceهای متفاوت برای Backendهای متفاوت

یکی از قابلیت‌های جذاب OpenSIPS این است که همه Nodeها لازم نیست دقیقاً یک کار انجام دهند.

مثلاً:

PBX-01:
voice=200;conference=20

PBX-02:
voice=150;transcoding=50

PBX-03:
voice=100;voicemail=100

سپس Call را بر اساس Resource موردنیاز Route کنید.

مثال تماس Conference

if (!lb_start(1, "voice;conference")) {
    send_reply(503, "Conference Capacity Full");
    exit;
}

OpenSIPS فقط Nodeهایی را در نظر می‌گیرد که هر دو Resource را داشته باشند.

اگر تمام Capacity پر شود چه می‌شود؟

`lb_start()` می‌تواند تشخیص دهد Destinationها Up هستند ولی Capacity آزاد ندارند.

در این حالت بهتر است به‌جای ارسال تماس به Node Overloaded، Policy مشخص داشته باشید.

مثلاً:

Overflow Pool

می‌توانید Group جدا داشته باشید:

Group 1 = Primary PBX
Group 2 = Overflow PBX

اگر Group اول Capacity نداشت، تماس‌های خاص به Group دوم ارسال شوند.

Call Load با CPU Load یکسان نیست

OpenSIPS ممکن است بداند Node 100 Call فعال دارد.

اما شاید 50 Call آن‌ها Transcoding سنگین داشته باشند.

پس Resource Design باید به Workload واقعی نزدیک باشد.

فقط `voice=500` همیشه بهترین مدل Capacity نیست.

Monitoring CPU Backend را هم نگه دارید

Load Balancer تماس را می‌شمارد؛ Infrastructure Monitoring باید CPU، RAM و I/O را نیز ببیند.

اگر Node از نظر Dialog ظرفیت دارد ولی CPU به 95 درصد رسیده، باید Alert داشته باشید.

OpenSIPS 4.0 یا 3.6 LTS؟

در حال حاضر هر دو Supported هستند.

4.0: Stable و نسل فعلی

3.6: Stable LTS

برای پروژه جدید، 4.0 منطقی است؛ برای محیطی که سیاست محافظه‌کارانه و چرخه پشتیبانی طولانی‌تر دارد، 3.6 LTS نیز گزینه معتبر است.

قبل از Upgrade نسخه Major چه کنیم؟

OpenSIPS Configuration Script و Moduleها بین Major Versionها می‌توانند تغییر داشته باشند.

پس:

Backup → Staging → Config Validation → Load Test → Production

را رعایت کنید.

Config را قبل از Restart بررسی کنید

برای جلوگیری از Down شدن Edge به‌خاطر Syntax Error:

opensips -C -f /etc/opensips/opensips.cfg

را قبل از Restart اجرا کنید.

اشتباه‌های رایج در OpenSIPS Load Balancing

اشتباه ۱: Dispatcher و Load Balancer را یکی فرض می‌کنیم.

اشتباه ۲: Capacity را بدون Benchmark وارد می‌کنیم.

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

اشتباه ۴: هر 5xx را نشانه Down بودن Node می‌دانیم.

اشتباه ۵: Dialog Timeout اشتباه باعث Load Ghost می‌شود.

اشتباه ۶: REGISTER را مثل INVITE بین PBXها پخش می‌کنیم.

اشتباه ۷: فکر می‌کنیم OpenSIPS خودش RTP را Proxy می‌کند.

اشتباه ۸: یک OpenSIPS جلوی چند PBX می‌گذاریم و Edge را SPOF می‌کنیم.

اشتباه ۹: Backendها همچنان از اینترنت مستقیم قابل دسترسی‌اند.

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

OpenSIPS چیست؟

OpenSIPS یک SIP Server متن‌باز است که برای SIP Proxy، Registrar، Load Balancing، Routing، SBC و معماری‌های Carrier و Hosted PBX استفاده می‌شود.

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

OpenSIPS 4.0.2 جدیدترین نسخه Stable فعلی است و OpenSIPS 3.6.9 نیز شاخه LTS پشتیبانی‌شده محسوب می‌شود.

Dispatcher و Load Balancer چه فرقی دارند؟

Dispatcher مقصد را با الگوریتم‌های Hash و Weight انتخاب می‌کند و الزاماً از تعداد تماس فعال Backend خبر ندارد؛ Load Balancer با Dialog State و Capacity تعریف‌شده، بار واقعی تماس‌ها را در انتخاب مقصد لحاظ می‌کند.

OpenSIPS چگونه PBX خراب را تشخیص می‌دهد؟

Load Balancer می‌تواند با SIP OPTIONS مقصدها را Probe کند. probe_mode تعیین می‌کند Health Check همیشه اجرا شود یا فقط روی Destination Disabled.

اگر PBX اول جواب ندهد تماس چه می‌شود؟

با failure_route و lb_next می‌توان Destination بعدی را انتخاب و INVITE را به PBX دیگری ارسال کرد.

آیا Failover تماس فعال ممکن است؟

Failover تماس جدید و INVITE قبل از Answer ساده‌تر است. اگر PBX وسط تماس فعال Crash کند، انتقال زنده همان تماس معمولاً ممکن نیست چون State و Media روی Backend بوده است.

OpenSIPS خودش RTP را عبور می‌دهد؟

به‌صورت پیش‌فرض خیر. OpenSIPS SIP Signaling را Route می‌کند. برای Media Relay می‌توان RTPEngine را اضافه کرد.

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

برای NAT سخت، مخفی‌کردن Media IP، WebRTC، SRTP/RTP Interworking یا زمانی که PBXهای Backend Private هستند و Media باید از Relay کنترل‌شده عبور کند.

OpenSIPS Load Balancing برای FreeSWITCH هم کار می‌کند؟

بله. Destination می‌تواند Asterisk، FreeSWITCH، Gateway، SBC یا Media Server دیگری باشد.

برای چند PBX بهتر است Dispatcher استفاده کنیم یا Load Balancer؟

اگر هدف پخش ساده یا Hash ثابت است Dispatcher مناسب است؛ اگر ظرفیت PBXها متفاوت است و تعداد تماس فعال باید در تصمیم‌گیری لحاظ شود Load Balancer انتخاب بهتری است.

آیا یک OpenSIPS جلوی چند PBX یعنی High Availability کامل؟

خیر. یک OpenSIPS خودش Single Point of Failure خواهد بود. برای HA واقعی Edge Layer نیز باید Redundant باشد و Dialog/Cluster State مناسب طراحی شود.