OpenSIPS چیست؟ توزیع هوشمند تماس بین چند PBX با Failover خودکار

در اکتبر ۲۰۲۶، دو شاخه پایدار OpenSIPS پشتیبانی می‌شوند: OpenSIPS 4.0 که نسخه فعلی آن 4.0.2 است و OpenSIPS 3.6 LTS که نسخه فعلی آن 3.6.9 است. برای نصب جدید می‌توانید 4.0 را انتخاب کنید؛ اگر سیاست سازمان شما استفاده از شاخه LTS است، 3.6 همچنان گزینه رسمی و پشتیبانی‌شده محسوب می‌شود.

OpenSIPS دقیقاً چه کاری جلوی چند PBX انجام می‌دهد؟

یک معماری معمولی به این شکل است:

Phones / SIP Provider
          |
          v
      OpenSIPS
  +------------------+
  | routing          |
  | load balancing   |
  | health checks    |
  | dialog tracking  |
  | ACL / security   |
  +------------------+
      /     |     \
     v      v      v
   PBX-1  PBX-2  PBX-3
 Asterisk Asterisk FreeSWITCH

اگر یک PBX از دسترس خارج شود، OpenSIPS می‌تواند تماس‌های جدید را به Node سالم هدایت کند. اگر یکی از PBXها ۹۰ درصد ظرفیت خود را مصرف کرده و دیگری فقط ۳۰ درصد درگیر است، ماژول Load Balancer می‌تواند مقصدی را انتخاب کند که ظرفیت آزاد بیشتری دارد.

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

این انتخاب روی طراحی کل سیستم اثر دارد. مستند OpenSIPS به‌صراحت توضیح می‌دهد که Dispatcher اطلاعات Load واقعی مقصد را ندارد؛ در مقابل Load Balancer با کمک Dialog State تعداد تماس‌های در حال اجرا را دنبال می‌کند.

برای مثال: اگر سه PBX تقریباً هم‌اندازه دارید و فقط می‌خواهید REGISTER یا SIP Requestها بر اساس Username به Backend ثابت بروند، Dispatcher مناسب است. اگر PBXها ظرفیت متفاوت دارند یا می‌خواهید تماس جدید به Node با «ظرفیت آزاد واقعی» برود، Load Balancer انتخاب دقیق‌تری است.

Dialog State چرا برای Load Balancing مهم است؟

فرض کنید PBX-1 ظرفیت ۲۰۰ تماس و PBX-2 ظرفیت ۱۰۰ تماس دارد. اگر فقط Round Robin استفاده کنید، هر دو تقریباً تعداد یکسانی Call Setup دریافت می‌کنند، حتی اگر ظرفیتشان متفاوت باشد.

Load Balancer وضعیت تماس‌های برقرارشده را دنبال می‌کند. وقتی یک تماس ایجاد می‌شود، Resource آن Destination مصرف می‌شود و وقتی Dialog با BYE پایان پیدا می‌کند، ظرفیت دوباره آزاد می‌شود.

OpenSIPS این آگاهی را از dialog module می‌گیرد. این ماژول می‌تواند تعداد Dialogهای فعال، Attributeهای هر تماس، Timeout و Profileها را نگه دارد.

برای مشاهده Dialogهای فعال:

opensips-cli -x mi dialog:list

سناریوی عملی: سه PBX با ظرفیت متفاوت

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

در جدول Load Balancer می‌توانید برای هر Destination یک Resource مثل calls تعریف کنید و Capacity هر Node را مطابق Benchmark واقعی قرار دهید.

سپس Script تماس را با lb_start() شروع می‌کند:

if (is_method("INVITE")) {
    if (!lb_start(1, "calls")) {
        send_reply(503, "No PBX capacity available");
        exit;
    }

    t_on_failure("PBX_FAILOVER");
    if (!t_relay()) {
        send_reply(500, "Relay failed");
    }
    exit;
}

lb_start() مقصدی را انتخاب می‌کند که برای Resource درخواستی ظرفیت آزاد مناسب‌تری دارد و Destination URI را در $du قرار می‌دهد.

Health Check؛ OpenSIPS از کجا می‌فهمد PBX سالم است؟

Load Balancer می‌تواند SIP Probe بفرستد. روش پیش‌فرض Probe معمولاً OPTIONS است. برای هر Destination می‌توان مشخص کرد فقط هنگام Disabled بودن Probe شود یا دائماً سلامت آن بررسی شود.

نمونه Module Parameter:

modparam("load_balancer", "probing_interval", 10)
modparam("load_balancer", "probing_method", "OPTIONS")
modparam("load_balancer", "probing_from", "sip:health@lb.example.com")

این اعداد نمونه‌اند. Probe بسیار سریع روی تعداد زیاد Backend می‌تواند ترافیک اضافه ایجاد کند؛ Interval را بر اساس اندازه Cluster و RTO موردنظر تنظیم کنید.

Failover؛ اگر PBX وسط Call Setup پاسخ نداد چه می‌شود؟

در Failure Route می‌توانید Destination فعلی را Disabled کنید و از OpenSIPS بخواهید PBX بعدی را انتخاب کند.

failure_route[PBX_FAILOVER] {
    if (t_check_status("(408)|(5[0-9][0-9])")) {
        lb_disable_dst();

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

lb_next() Destination بعدی را از همان Session Load Balancing انتخاب می‌کند. Probeهای بعدی می‌توانند Node سالم‌شده را دوباره وارد Pool کنند.

اگر Dispatcher بخواهیم، چه زمانی بهتر است؟

Dispatcher برای Routing ساده و سریع عالی است. الگوریتم‌هایی مثل Hash روی Call-ID، From URI، To URI، Request-URI، Authorization Username و Weighted Round Robin دارد.

مثلاً اگر می‌خواهید هر داخلی همیشه بر اساس Username به PBX تقریباً ثابت برسد، Hash روی Authorization Username مفید است:

if (!ds_select_dst(1, 5, "f")) {
    send_reply(503, "No destination");
    exit;
}

t_on_failure("DISPATCH_FAILOVER");
t_relay();

در Dispatcher، الگوریتم 5 بر اساس Authorization Username Hash می‌کند و Flag مربوط به Failover اجازه می‌دهد مقصدهای بعدی با ds_next_dst() امتحان شوند.

اما اگر PBX-1 ظرفیت ۵۰۰ تماس و PBX-2 ظرفیت ۱۰۰ تماس دارد، صرف Hash یا Round Robin به‌اندازه Load Balancer از ظرفیت واقعی آگاه نیست.

Dialog Replication؛ اگر خود OpenSIPS دو Node داشته باشد

اگر فقط یک OpenSIPS دارید، جلوی چند PBX هنوز یک Single Point of Failure وجود دارد. برای HA واقعی Edge معمولاً دو OpenSIPS یا بیشتر استفاده می‌شود.

ماژول dialog می‌تواند Dialogها را با کمک clusterer بین Nodeها Replicate کند. در نتیجه Node دوم از وضعیت Dialogهای Node اول آگاه می‌شود و برای سناریوهای HA و Load Balancing وضعیت مشترک‌تری در اختیار دارید.

نمونه فعال‌کردن Replication:

modparam("dialog", "dialog_replication_cluster", 1)

برای Cluster باید Nodeها در clusterer تعریف شوند و حداقل یک Node مناسب برای Sync اولیه وجود داشته باشد.

Load Balancer چگونه ظرفیت واقعی هر PBX را می‌بیند؟

Load Balancer فقط «تعداد تماس کمتر» را انتخاب نمی‌کند. هر Destination می‌تواند Capacity متفاوتی برای Resourceهای مختلف داشته باشد.

مثلاً:

PBX-1: calls=200;transcoding=20
PBX-2: calls=100;transcoding=80
PBX-3: calls=300;transcoding=10

یک تماس ساده می‌تواند فقط Resource calls بخواهد؛ ولی Call Flow خاصی که Transcoding دارد می‌تواند Resourceهای متفاوتی درخواست کند. این مدل نسبت به Weight ثابت، برای Clusterهای ناهمسان انعطاف بیشتری دارد.

وضعیت لحظه‌ای Load Balancer:

opensips-cli -x mi load_balancer:list

RTPengine چه نقشی کنار OpenSIPS دارد؟

OpenSIPS عمدتاً Signaling را مدیریت می‌کند. اگر RTP باید از یک Media Proxy عبور کند، WebRTC دارید، NAT پیچیده است یا می‌خواهید Media Path از Backend PBX جدا شود، RTPEngine وارد معماری می‌شود.

                 SIP
Phone ----------> OpenSIPS ----------> PBX
  \                   |
   \                  | control
    \                 v
     +----------> RTPEngine
                    |
                    +---- RTP / SRTP

OpenSIPS می‌تواند چند RTPEngine را در یک Set قرار دهد و داخل Set بر اساس Weight آن‌ها را توزیع کند. اگر Node انتخاب‌شده پاسخ ندهد یا محدودیت Session/Port داشته باشد، ماژول می‌تواند به RTPEngine دیگری Failover کند.

نمونه تعریف چند Node:

modparam("rtpengine", "rtpengine_sock",
    "1 == udp:10.20.0.11:2223 udp:10.20.0.12:2223")

و انتخاب Set:

rtpengine_use_set(1);
rtpengine_manage();

Failover PBX و Failover RTPEngine را قاطی نکنید

دو مسیر مستقل دارید:

اگر تماس از PBX-1 به PBX-2 Failover شود، باید مطمئن شوید RTPEngine Session قبلی هم درست Cleanup می‌شود و Media Set جدید در Branch بعدی به‌اشتباه با Session قبلی مخلوط نمی‌شود.

Health Check را فقط با «پورت باز است» نسنجید

SIP OPTIONS بهتر از TCP Port Check ساده است، اما هنوز ممکن است Asterisk پاسخ 200 بدهد در حالی که Queue Database یا Trunk Carrier خراب است.

برای سامانه حساس، Health را چندلایه کنید:

با MI می‌توانید Destination را دستی Disable/Enable کنید:

opensips-cli -x mi load_balancer:status 2 0

# فعال‌کردن دوباره:
opensips-cli -x mi load_balancer:status 2 1

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

                    SIP Clients / Carrier
                             |
                       DNS SRV / VIP
                         /       \
                        v         v
                 +----------+ +----------+
                 |OpenSIPS-A| |OpenSIPS-B|
                 +-----+----+ +----+-----+
                       \         /
                        \       /
                   Dialog Replication
                          |
              +-----------+-----------+
              |           |           |
              v           v           v
            PBX-1       PBX-2       PBX-3
              \           |           /
               \          |          /
                +---- RTPEngine ----+
                     Pool / Sets

در این ساختار، VIP یا DNS SRV نقطه ورود را Redundant می‌کند، Dialog State بین OpenSIPSها Replicate می‌شود، تماس‌های جدید بین PBXهای سالم توزیع می‌شوند و Media Proxy نیز Cluster جدا دارد.

OpenSIPS یا Kamailio برای Load Balancing؟

هر دو پروژه SIP Proxy بالغ و بسیار قدرتمند هستند، اما فلسفه و Moduleهای آن‌ها تفاوت‌هایی دارد. در OpenSIPS، load_balancer به‌صورت مشخص Load تماس و Capacity Resource را با Dialog Tracking وارد تصمیم می‌کند. در Kamailio معمولاً Dispatcher و Logicهای Script/Moduleهای مرتبط بیشتر محور طراحی هستند.

برای انتخاب فقط به Syntax نگاه نکنید. تجربه تیم، Monitoring، Database، HA، Registrar Architecture، RTPengine Integration و ابزارهای عملیاتی شما مهم‌تر هستند.

چه زمانی OpenSIPS انتخاب خوبی است؟

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

برنامه تست قبل از Production

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

OpenSIPS چیست؟

OpenSIPS یک SIP Server متن‌باز برای Proxy، Registrar، Routing، Load Balancing، NAT و امنیت Signaling است و معمولاً جلوی Asterisk، FreeSWITCH یا SIP Gatewayها قرار می‌گیرد.

نسخه فعلی OpenSIPS چیست؟

در اکتبر ۲۰۲۶، OpenSIPS 4.0.2 نسخه فعلی شاخه Stable 4.0 است. شاخه 3.6 نیز LTS است و نسخه فعلی آن 3.6.9 محسوب می‌شود.

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

Dispatcher بر اساس Hash، Weight یا Round Robin مقصد را انتخاب می‌کند و Load واقعی تماس‌ها را نمی‌داند. Load Balancer با Dialog State و Capacity تعریف‌شده، تماس را به مقصد با ظرفیت آزاد مناسب‌تر هدایت می‌کند.

OpenSIPS چطور Health Check انجام می‌دهد؟

Load Balancer می‌تواند SIP Probe مانند OPTIONS به Destinationها بفرستد و Node Disabled را پس از موفقیت Probe دوباره فعال کند.

اگر یک PBX Down شود تماس قطع نمی‌شود؟

تماس‌های جدید می‌توانند به PBX دیگر Failover شوند، اما تماس Active روی PBX خراب‌شده معمولاً با Load Balancer به Node دیگر منتقل نمی‌شود.

Dialog Replication چه کاربردی دارد؟

در Cluster چند OpenSIPS، Dialog Replication وضعیت تماس‌های فعال را بین Nodeها منتقل می‌کند و برای HA و Load Balancing توزیع‌شده کاربرد دارد.

RTPEngine چرا کنار OpenSIPS استفاده می‌شود؟

OpenSIPS بیشتر Signaling را مدیریت می‌کند؛ RTPEngine برای Anchor کردن RTP/SRTP، NAT، WebRTC و مدیریت Media Path استفاده می‌شود.

برای سه Asterisk، Dispatcher بهتر است یا Load Balancer؟

اگر فقط توزیع ساده یا Sticky Hash می‌خواهید Dispatcher مناسب است. اگر ظرفیت PBXها متفاوت است و تعداد تماس فعال باید وارد تصمیم شود، Load Balancer انتخاب دقیق‌تری است.