SBC در VoIP چیست؟ ساخت یک SBC سبک و امن با Kamailio و RTPengine

اما هر سیستم تلفنی به SBC نیاز ندارد. اگر فقط یک Asterisk کوچک با یک Trunk مطمئن دارید، اضافه‌کردن Kamailio، RTPengine، Redis و چند لایه Firewall ممکن است فقط پیچیدگی ایجاد کند. در مقابل، وقتی SIP را مستقیماً روی اینترنت منتشر می‌کنید، چند Carrier دارید، کاربران WebRTC یا Remote Phone دارید یا نمی‌خواهید IP و ساختار داخلی PBXها دیده شود، SBC از یک گزینه جانبی به یکی از مهم‌ترین اجزای معماری تبدیل می‌شود.

در این مقاله ابتدا مشخص می‌کنیم SBC VoIP واقعاً چیست، سپس یک معماری سبک با Kamailio و RTPengine طراحی می‌کنیم و در ادامه بررسی می‌کنیم چه زمانی همان معماری متن‌باز کافی است و چه زمانی بهتر است سراغ SBC کامل‌تر یا تجاری بروید.

SBC چیست؟

SBC مخفف:

Session Border Controller

است.

ترجمه ساده آن می‌شود:

کنترل‌کننده مرزی Sessionهای ارتباطی

اما در عمل SBC یک وظیفه واحد ندارد.

RFC 5853 نیز صراحتاً توضیح می‌دهد که اصطلاح SBC تعریف کاملاً محدود و استانداردی ندارد و محصولات مختلف ممکن است مجموعه متفاوتی از قابلیت‌ها را زیر این نام ارائه کنند.

وظایف معمول SBC در سه گروه قرار می‌گیرند.

SBC کجای معماری VoIP قرار می‌گیرد؟

بدون SBC ممکن است ساختار شما چنین باشد:

Internet / SIP Carrier
          |
          v
       Asterisk
          |
          v
      Extensions

در این مدل Public SIP مستقیماً به PBX می‌رسد.

با SBC:

Internet / SIP Carrier
          |
          v
         SBC
     /           \
Signaling       Media
   |              |
   v              v
 Kamailio      RTPengine
      \          /
       \        /
        Asterisk
           |
       Internal LAN

اکنون PBX مستقیماً در معرض اینترنت نیست.

SBC با Firewall چه تفاوتی دارد؟

Firewall معمولی بیشتر IP، Port و Connection را می‌بیند.

اما SBC SIP را می‌فهمد.

مثلاً می‌تواند تشخیص دهد Packet دریافتی:

در نتیجه تصمیم امنیتی فقط بر اساس Port 5060 گرفته نمی‌شود.

SBC جای Firewall را هم نمی‌گیرد

طراحی درست معمولاً ترکیبی است از:

Network Firewall + SIP-aware SBC

Firewall ترافیک غیرضروری را قبل از Application حذف می‌کند و SBC درخواست‌هایی را که به لایه SIP رسیده‌اند تحلیل می‌کند.

مهم‌ترین وظیفه اول: Topology Hiding

اگر SIP Trunk مستقیماً به Asterisk وصل باشد، Headerهای SIP ممکن است اطلاعاتی مانند:

را نمایش دهند.

مثلاً:

Via: SIP/2.0/UDP 10.20.0.15:5060
Contact: <sip:1001@10.20.0.15:5060>

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

Topology Hiding چه می‌کند؟

SBC مسیر داخلی را از پیام خروجی حذف یا بازنویسی می‌کند.

طرف بیرونی ممکن است فقط چیزی شبیه:

sbc.example.com

را ببیند.

Topology Hiding رمزنگاری نیست

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

مخفی‌کردن:

Via / Route / Contact / Internal IP

به معنی Encryption پیام SIP نیست.

برای محافظت از Signaling در مسیر شبکه هنوز TLS لازم است.

Kamailio چگونه Topology را مخفی می‌کند؟

در Kamailio 6.1 ماژول:

topos

برای این کار وجود دارد.

این ماژول Headerهای Routing را هنگام خروج حذف و برای پیام‌های بعدی همان Dialog دوباره بازسازی می‌کند.

State مربوط به Topology کجا ذخیره می‌شود؟

Kamailio TOPOS در نسخه فعلی Storageهای مختلفی دارد:

برای یک SBC تک‌سروره، htable می‌تواند ساده باشد.

اما برای دو SBC در HA باید از ابتدا فکر کنید اگر Request بعدی یک Dialog به Node دوم رسید، State لازم از کجا خوانده می‌شود.

نمونه مفهومی TOPOS با Redis

loadmodule "topos.so"

modparam("topos", "storage", "redis")

این فقط بخش مفهومی Configuration است و Redis URL، Module وابسته و سیاست HA آن باید متناسب با معماری خودتان تنظیم شوند.

Record-Route را فراموش نکنید

SBC باید در Dialog باقی بماند تا BYE، re-INVITE، UPDATE و سایر Requestهای Mid-dialog دوباره از همان مرز عبور کنند.

در Proxyهای SIP این موضوع معمولاً با:

record_route();

انجام می‌شود.

Topology Hiding ممکن است Featureها را تحت تأثیر قرار دهد

SBC در پیام SIP دست می‌برد.

این یعنی باید Featureهایی مثل:

را بعد از فعال‌سازی Topology Hiding تست کنید.

RFC 5853 نیز توضیح می‌دهد که برخی رفتارهای SBC می‌توانند اصول End-to-End SIP را تغییر دهند.

وظیفه دوم: NAT Traversal

یکی از مهم‌ترین کاربردهای SBC مدیریت تماس میان شبکه‌هایی است که Addressing متفاوت دارند.

مثلاً:

Remote Phone:
192.168.1.20

Public NAT:
198.51.100.45

PBX:
10.20.0.15

هر سه آدرس در یک تماس ممکن است دیده شوند.

NAT در SIP و Media دو مسئله جداست

Signaling:

REGISTER / INVITE / Contact / Via

را Kamailio/OpenSIPS مدیریت می‌کند.

Media:

RTP / SRTP / ICE / SDP

را معمولاً RTPengine مدیریت می‌کند.

چرا فقط fix_nated_contact کافی نیست؟

ممکن است SIP سالم شود ولی SDP هنوز IP خصوصی داشته باشد.

نتیجه:

تماس وصل می‌شود اما صدا ندارید.

برای همین SBC واقعی معمولاً Signaling و Media Border را با هم کنترل می‌کند.

RTPengine چه نقشی در SBC دارد؟

RTPengine Media Proxy است.

می‌تواند:

معماری سبک پیشنهادی

Public Internet
      |
      |
  Kamailio SBC
   /        \
SIP          NG Control
 |              |
 |          RTPengine
 |              |
 +------ PBX ---+
         |
      Private LAN

آیا RTPengine باید همیشه در مسیر Media باشد؟

نه الزاماً.

اگر دو Endpoint مسیر مستقیم امن و قابل‌کنترلی دارند، ممکن است Media Anchoring لازم نباشد.

اما وقتی هدف SBC این است که:

قرارگرفتن RTPengine در مسیر منطقی‌تر است.

Media Anchoring هزینه دارد

وقتی RTP از SBC عبور می‌کند، Bandwidth سرور SBC مصرف می‌شود.

پس اگر ۱۰۰۰ تماس هم‌زمان دارید، فقط CPU Kamailio مهم نیست.

باید:

را هم اندازه بگیرید.

وظیفه سوم: TLS برای SIP

اگر SIP روی اینترنت عمومی است، TLS می‌تواند Signaling را رمزنگاری کند.

مدل معمول:

Remote Phone
    |
 SIP/TLS
    |
    SBC
    |
 SIP/TLS or SIP
    |
    PBX

TLS Termination در SBC چه مزیتی دارد؟

PBXهای داخلی لازم نیست Certificate تمام Clientها یا Carrierها را مستقیم مدیریت کنند.

SBC می‌تواند Policy TLS مرز شبکه را یکپارچه کند.

اما TLS فقط Signaling را امن می‌کند

برای Media به:

SRTP

نیاز دارید.

TLS و SRTP را با هم اشتباه نگیریم

SRTP در SBC

RFC 3711 برای SRTP قابلیت‌هایی مانند:

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

RTPengine و SRTP

RTPengine فعلی از:

پشتیبانی می‌کند.

در نتیجه می‌توانید مثلاً:

Internet Side:
SRTP

        |
        v

RTPengine

        |
        v

Private PBX:
RTP

این کار End-to-End Encryption نیست

اگر SRTP روی SBC Terminate و دوباره Encrypt شود، Media در خود SBC قابل پردازش است.

بنابراین:

Encrypted on each leg

با:

End-to-end encryption

یکسان نیست.

وظیفه چهارم: SIP Rate Limiting

SIP روی اینترنت دائماً Scan می‌شود.

نمونه حملات رایج:

Rate Limiting باید قبل از PBX باشد

اگر Bot مستقیماً Asterisk را هدف بگیرد، حتی Authentication Failureها منابع PBX را مصرف می‌کنند.

بهتر است SBC درخواست‌های نامناسب را قبل از Backend حذف کند.

Kamailio PIKE

ماژول `pike` نرخ Request بر اساس Source IP را دنبال می‌کند.

خود ماژول تصمیم نهایی Blocking را اعمال نمی‌کند؛ فقط Script را مطلع می‌کند که Source رفتار Floodگونه دارد.

نمونه ساده:

loadmodule "pike.so"

modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 30)

request_route {

    if (!pike_check_req()) {
        xlog("L_WARN",
             "SIP flood detected from $si\n");
        exit;
    }

    # ادامه Routing
}

عدد ۳۰ را Copy نکنید

Threshold باید بر اساس Traffic واقعی انتخاب شود.

یک Carrier ممکن است از یک IP صدها INVITE سالم در ثانیه بفرستد.

اگر همان IP را مانند یک Softphone معمولی محدود کنید، خودتان سرویس را مختل می‌کنید.

Rate Limit باید Context-aware باشد

بهتر است Policy جدا داشته باشید برای:

Carrier IPها را Allowlist کنیم؟

اگر Provider مجموعه IP ثابت و رسمی داده است، Source ACL بسیار مؤثر است.

مثلاً Trunk ورودی فقط از Subnetهای اعلام‌شده Provider پذیرفته شود.

این کار Attack Surface را به‌شدت کوچک می‌کند.

اما کاربران Remote را نمی‌توان همیشه IP-whitelist کرد

کاربر اینترنت خانگی یا موبایل IP متغیر دارد.

در این بخش باید ترکیبی از:

استفاده شود.

SBC جای Fail2Ban نیست؛ Fail2Ban هم جای SBC نیست

Fail2Ban معمولاً Log را بعد از رخداد تحلیل می‌کند.

Kamailio می‌تواند Request را همان لحظه در لایه SIP تصمیم‌گیری کند.

هر دو می‌توانند مکمل یکدیگر باشند.

وظیفه پنجم: Protocol Normalization

در دنیای واقعی همه Carrierها SIP را دقیقاً یکسان پیاده نمی‌کنند.

ممکن است تفاوت در:

باعث مشکل شود.

SBC می‌تواند این تفاوت‌ها را در مرز Network اصلاح کند تا مجبور نباشید برای هر Carrier داخل تمام PBXها Configuration جدا بسازید.

اما SIP را بی‌دلیل Rewrite نکنید

هر Rewrite اضافه ممکن است Feature جدیدی را خراب کند.

اصل مناسب:

فقط چیزی را Normalize کنید که یک Interoperability Problem واقعی حل می‌کند.

وظیفه ششم: Transcoding

فرض کنید Carrier فقط:

PCMA

را قبول کند.

اما سمت WebRTC از:

Opus

استفاده کند.

اگر Codec مشترک وجود نداشته باشد، Transcoding لازم می‌شود.

RTPengine می‌تواند Transcoding کند

نسخه فعلی RTPengine Transcoding صوت را پشتیبانی می‌کند.

ولی این قابلیت به‌صورت خودکار برای هر تماس فعال نمی‌شود و باید Policy مشخصی برای آن تعریف شود.

Transcoding را Default نکنید

Transcoding نسبت به RTP Relay ساده CPU بسیار بیشتری مصرف می‌کند.

ضمن اینکه مستند رسمی RTPengine توضیح می‌دهد Transcoding در User Space انجام می‌شود و In-kernel Forwarding برای Codecهای Transcodeشده قابل استفاده نیست.

بنابراین اگر Codec مشترک دارید:

Pass-through معمولاً بهتر است.

SBC سبک پیشنهادی از چه اجزایی ساخته شود؟

دو مسیر منطقی برای ساخت SBC متن‌باز در ۲۰۲۶

مسیر اول: Kamailio + RTPengine

این روش برای کسانی مناسب است که می‌خواهند Routing Script و Policyها کاملاً تحت کنترل خودشان باشد.

مزیت:

اما نیاز به دانش SIP بیشتری دارد.

مسیر دوم: OpenSIPS SBC Community Edition

در سال ۲۰۲۶ پروژه OpenSIPS یک SBC Community Edition رسمی منتشر کرده است.

این Platform از ابتدا برای Edge SIP طراحی شده و مواردی مانند:

را آماده‌تر در اختیار شما می‌گذارد.

برای Lab یا پروژه کوچک کدام بهتر است؟

اگر هدف یادگیری یا ساخت Policy خاص است:

Kamailio + RTPengine

انعطاف بیشتری دارد.

اگر می‌خواهید سریع‌تر یک SBC واقعی قابل تست داشته باشید:

OpenSIPS SBC Community Edition

نقطه شروع بسیار جالبی در ۲۰۲۶ است.

یک SBC سبک با Kamailio از کجا شروع شود؟

Moduleهای پایه معمولاً چیزی شبیه این‌ها هستند:

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

loadmodule "pike.so"
loadmodule "dispatcher.so"
loadmodule "topos.so"
loadmodule "rtpengine.so"

اگر TLS دارید، Module و TLS Config نیز اضافه می‌شود.

اولین لایه Validation

قبل از Routing:

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

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

هدف این مرحله جلوگیری از Loop و Requestهای malformed است.

Source Policy را زود اعمال کنید

اگر Request از SIP Carrier می‌آید، قبل از Routing مشخص کنید Source جزو Providerهای مجاز است یا خیر.

Carrier Trunk عمومی نباید به هر IP اینترنتی اجازه ورود بدهد.

REGISTER و Carrier Trunk را یکی نکنید

دو Trust Zone متفاوت هستند.

مثلاً:

ZONE 1:
Trusted SIP Carriers

ZONE 2:
Remote Registered Users

ZONE 3:
Internal PBX Servers

Policy هر Zone باید متفاوت باشد.

PBXها را پشت Private Network قرار دهید

معماری بهتر:

Public:
SBC 203.0.113.10

Private:
SBC 10.20.0.10
Asterisk 10.20.0.20
Asterisk 10.20.0.21

و روی PBX:

فقط SIP از SBCها Allow شود.

Dispatcher برای چند PBX

SBC می‌تواند چند Asterisk یا FreeSWITCH را پشت خودش قرار دهد.

       SBC
     /  |  \
    /   |   \
 PBX1 PBX2 PBX3

Kamailio Dispatcher می‌تواند:

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

Health Check Backend ضروری است

اگر PBX2 Down شد، SBC نباید همچنان INVITE جدید به آن ارسال کند.

OPTIONS Probe یکی از روش‌های رایج Health Check است.

اما OPTIONS فقط Process را می‌سنجد

ممکن است Asterisk به OPTIONS جواب دهد ولی Database یا Dialplan آن خراب باشد.

برای سرویس حساس، Synthetic Call Test نیز در کنار OPTIONS مفید است.

SBC خودش نباید SPOF شود

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

سه PBX داریم ولی فقط یک SBC.

در این حالت تمام Redundancy Backend با خرابی SBC بی‌اثر می‌شود.

حداقل HA برای SBC

          SIP Users / Carriers
                |
          DNS SRV / VIP
           /          \
       SBC-01        SBC-02
        |  \          /  |
        |   \        /   |
     RTP-01          RTP-02
           \        /
            PBX Pool

DNS SRV یا VIP؟

DNS SRV برای معرفی چند SIP Edge بسیار کاربردی است.

VIP برای Active/Standby در یک Network می‌تواند Failover شفاف‌تری ایجاد کند.

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

State در HA مهم‌تر از IP است

اگر SBC-01 تماس را ساخته و اطلاعات Topology Hiding فقط در RAM خودش باشد، انتقال IP به SBC-02 تمام مشکل را حل نمی‌کند.

Requestهای Mid-dialog باید State لازم را داشته باشند.

بنابراین HA باید شامل:

باشد.

RTPengine HA هم مستقل است

اگر Signaling سالم باشد ولی تنها RTPengine شما Down شود، تماس‌های جدید ممکن است Signaling کامل داشته باشند اما Media نداشته باشند.

حداقل دو Media Node برای سرویس HA منطقی‌تر است.

تماس فعال در خرابی SBC چه می‌شود؟

این سؤال پاسخ ساده‌ای ندارد.

اگر Node Signaling Down شود:

Media ممکن است تا مدتی ادامه پیدا کند.

اما BYE یا re-INVITE ممکن است شکست بخورد.

اگر Media Node Down شود:

صدا معمولاً قطع می‌شود.

HA تماس فعال بسیار پیچیده‌تر از Failover تماس جدید است.

چه زمانی واقعاً به SBC نیاز داریم؟

این بخش مهم‌ترین قسمت مقاله است.

سناریویی که SBC احتمالاً اضافه‌کاری است

شرکت کوچکی را فرض کنید که:

در این وضعیت Firewall مناسب و Asterisk درست‌کانفیگ‌شده ممکن است کاملاً کافی باشد.

سناریویی که SBC ارزش زیادی دارد

حالا فرض کنید:

در این معماری نبود SBC معمولاً باعث پراکنده‌شدن NAT، Firewall، TLS، Carrier Policy و Load Balancing بین تمام PBXها می‌شود.

SBC این وظایف را در یک Edge Layer متمرکز می‌کند.

SBC سبک یا SBC تجاری؟

این تصمیم به Feature Count بستگی ندارد؛ به Risk و SLA بستگی دارد.

SBC متن‌باز برای چه پروژه‌ای مناسب است؟

چه زمانی SBC تجاری منطقی‌تر می‌شود؟

Kamailio + RTPengine آیا «SBC واقعی» محسوب می‌شود؟

این ترکیب می‌تواند بخش بزرگی از وظایف عملی یک SBC را پیاده کند.

اما نام‌گذاری مهم‌تر از Function نیست.

ممکن است معماری شما:

ولی مثلاً:

نداشته باشد.

برای Hosted PBX کوچک و متوسط ممکن است همین دقیقاً چیزی باشد که نیاز دارید.

OpenSIPS SBC Community Edition چه تغییری ایجاد کرده است؟

در ۲۰۲۶ پروژه OpenSIPS یک SBC آماده Community Edition منتشر کرد.

این موضوع مهم است چون فاصله بین:

«SIP Proxy خام»

و:

«SBC قابل‌استفاده»

کمتر شده است.

نسخه Community Edition برای:

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

آیا همان را مستقیم Production کنیم؟

هر Setup آماده‌ای قبل از Production باید با:

تطبیق داده شود.

Ready-to-run به معنی Ready-for-every-network نیست.

Monitoring برای SBC حیاتی است

اگر SBC مرز تمام تماس‌هاست، خرابی آن روی کل سرویس اثر دارد.

حداقل مانیتور کنید:

SIP Trace مرکزی داشته باشید

در Production بهتر است Call-ID قابل Correlation باشد و SIP Flowها در سیستم Trace مرکزی قابل جست‌وجو باشند.

بدون Trace، عیب‌یابی مشکل بین:

Carrier → SBC → PBX

زمان‌بر می‌شود.

آیا Call-ID را در Topology Hiding تغییر دهیم؟

بعضی پیاده‌سازی‌ها امکان Mask کردن Call-ID را دارند.

اما قبل از فعال‌کردن آن بررسی کنید:

به Call-ID اصلی وابسته نباشند.

Maintenance SBC چگونه انجام شود؟

برای دو Node:

مرحله ۱: Node اول را از دریافت Session جدید خارج کنید.

مرحله ۲: Dialogهای موجود را Drain کنید.

مرحله ۳: Upgrade کنید.

مرحله ۴: SIP/TLS/RTP Test بگیرید.

مرحله ۵: Node را به Pool برگردانید.

مرحله ۶: Node دوم را Upgrade کنید.

هم‌زمان Kamailio و RTPengine را Upgrade نکنید

اگر بعد از Maintenance Media خراب شود، نمی‌دانید مشکل از SIP Proxy بوده یا RTPengine.

تغییرها را مرحله‌ای انجام دهید.

Rollback Plan داشته باشید

قبل از Upgrade ذخیره کنید:

Failure Scenario ۱: Kamailio Down

تماس‌های جدید باید به SBC دوم برسند.

اما برای Mid-dialog Requestها State Sharing و Routing اهمیت دارد.

Failure Scenario ۲: RTPengine Down

Signaling ممکن است کامل شود ولی تماس‌های جدید Media نداشته باشند.

RTPengine دوم باید برای Session جدید انتخاب شود.

Failure Scenario ۳: Backend PBX Down

Dispatcher باید Backend را از Pool حذف کند و تماس‌های جدید را به PBX سالم بفرستد.

Failure Scenario ۴: Redis Down

اگر TOPOS یا Dialog State به Redis وابسته است، اثر خرابی Redis را قبل از Production تست کنید.

Shared State نباید خودش Single Point of Failure شود.

Failure Scenario ۵: Carrier Down

SBC می‌تواند Route جدید را به Provider دوم ببرد.

ولی Failover باید روی:

Policy مشخص داشته باشد.

همه 503ها را Failover نکنید

503 ممکن است Temporary Overload باشد.

اما ممکن است Route یا Account Provider مشکل داشته باشد.

Retry روی Carrier دوم باید جلوی Loop و Duplicate Billing را هم بگیرد.

Capacity Planning برای SBC

برای Signaling فقط تعداد Extension کافی نیست.

باید اندازه بگیرید:

برای Media جدا Benchmark کنید

RTPengine را با:

بسنجید.

Transcoding Ratio بسیار مهم است

۵۰۰ تماس Pass-through با ۵۰۰ تماس Transcoding از نظر CPU یکسان نیستند.

Benchmark باید Workload واقعی شما را تقلید کند.

SBC روی یک VPS قابل اجراست؟

بله، برای بسیاری از پروژه‌های کوچک و متوسط.

Kamailio به‌تنهایی بسیار سبک است.

اما وقتی RTPengine روی همان سرور قرار دارد، Network Quality و PPS اهمیت بیشتری پیدا می‌کند.

برای HA دو VPS مستقل بهتر است

اگر هر دو SBC روی یک Physical Host باشند، خرابی Host هر دو را از بین می‌برد.

در صورت اهمیت SLA، Failure Domain زیرساخت را هم بررسی کنید.

SBC ایران یا خارج؟

باید بر اساس مسیر واقعی Carrier و کاربران تصمیم بگیرید.

اگر:

کاربران + Carrier + PBX

همگی در ایران هستند، قرار دادن SBC/Media Edge داخل ایران می‌تواند Latency را کاهش دهد.

اگر کاربران بین‌المللی‌اند، معماری Multi-Region منطقی‌تر است.

Media را بی‌دلیل از مسیر دور عبور ندهید

فرض کنید کاربر تهران و PBX تهران هستند ولی RTPengine اروپا است.

شما فقط برای عبور صدا یک رفت‌وبرگشت غیرضروری ساخته‌اید.

SBC باید مسیر Media را کنترل کند، نه اینکه آن را بی‌دلیل طولانی کند.

چک‌لیست SBC سبک برای Production

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

SBC VoIP چیست؟

SBC یک لایه مرزی برای کنترل SIP و Media است که می‌تواند امنیت، Topology Hiding، NAT Traversal، TLS/SRTP، Rate Limiting، Routing و Media Policy را قبل از رسیدن تماس به PBX اعمال کند.

آیا هر Asterisk به SBC نیاز دارد؟

خیر. برای یک PBX کوچک با Trunk ثابت و شبکه کنترل‌شده ممکن است Firewall و تنظیم صحیح خود Asterisk کافی باشد. SBC زمانی ارزش بیشتری دارد که SIP در اینترنت عمومی، چند Carrier، چند PBX یا کاربران Remote داشته باشید.

تفاوت SBC و SIP Proxy چیست؟

SIP Proxy معمولاً روی Signaling تمرکز دارد. SBC علاوه بر Signaling معمولاً Policy امنیتی، Topology Hiding، NAT، Media Anchoring، TLS/SRTP و کنترل مرز شبکه را نیز انجام می‌دهد.

آیا Kamailio یک SBC است؟

Kamailio یک SIP Server/Proxy بسیار منعطف است که با Moduleهای مناسب و Media Proxy مانند RTPengine می‌تواند بسیاری از وظایف SBC را پیاده کند.

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

RTPengine Media را Relay می‌کند، SDP را بازنویسی می‌کند، NAT را مدیریت می‌کند و می‌تواند RTP/SRTP، WebRTC، ICE و Transcoding را مدیریت کند.

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

اطلاعات Routing داخلی مانند Via، Record-Route، Route و Contact می‌توانند از دید شبکه خارجی پنهان یا بازنویسی شوند.

آیا Topology Hiding همان Encryption است؟

خیر. Topology Hiding فقط ساختار داخلی شبکه را پنهان می‌کند. برای رمزنگاری Signaling باید TLS و برای Media باید SRTP استفاده شود.

آیا SBC می‌تواند جلوی حمله SIP را بگیرد؟

می‌تواند سطح بزرگی از حملات را با ACL، Authentication، Rate Limit، Flood Detection و Policyهای SIP کاهش دهد، اما همچنان Network Firewall و Monitoring لازم هستند.

آیا SBC می‌تواند Transcoding انجام دهد؟

بله، اگر Media Layer قابلیت Transcoding داشته باشد. RTPengine از Transcoding صوت پشتیبانی می‌کند، ولی این قابلیت CPU بیشتری مصرف می‌کند و بهتر است فقط در صورت نیاز فعال شود.

برای HA چند SBC لازم است؟

اگر SBC یک سرویس حیاتی است، یک Node کافی نیست. معمولاً حداقل دو Signaling Edge و در صورت Media Anchoring حداقل دو Media Node نقطه شروع منطقی‌تری هستند.

OpenSIPS SBC Community Edition چیست؟

یک Platform رسمی متن‌باز است که در سال ۲۰۲۶ توسط پروژه OpenSIPS منتشر شد و مجموعه‌ای از قابلیت‌های SBC شامل Topology Hiding، NAT Traversal، RTPEngine، Failover، PSTN Routing و Monitoring را آماده ارائه می‌کند.

چه زمانی SBC تجاری بهتر از نسخه متن‌باز است؟

وقتی Vendor Support، Certification، Compliance، Interoperability پیچیده، SLA سخت یا Media Processing بسیار سنگین دارید، محصول تجاری می‌تواند ریسک عملیاتی کمتری داشته باشد.