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

SBC یا Session Border Controller لایه‌ای در مرز شبکه VoIP است که بین شبکه داخلی شما و اینترنت، SIP Provider یا شعب دیگر قرار می‌گیرد و روی Signaling و در بسیاری از طراحی‌ها روی Media کنترل اعمال می‌کند. اما هر سانترال VoIP الزاماً به یک SBC کامل و سنگین نیاز ندارد. اگر نیاز شما محدود به پنهان‌کردن Topology، کنترل NAT، TLS/SRTP، محدودکردن درخواست‌های SIP و عبور امن Media باشد، می‌توان یک SBC سبک با Kamailio و RTPengine ساخت؛ به شرطی که محدودیت‌های این معماری را بدانید.

نکته مهم این است که «Kamailio + RTPengine» با یک SBC تجاری تمام‌عیار دقیقاً یک چیز نیست. Kamailio در هسته یک SIP Proxy بسیار سریع است و RTPengine لایه Media Proxy را فراهم می‌کند. ترکیب این دو می‌تواند بخش بزرگی از وظایف Edge/SBC را پوشش دهد، اما اگر به B2BUA کامل، SIP Normalization پیچیده، Interworking سنگین، Policyهای سازمانی بسیار پیشرفته یا پشتیبانی Vendor نیاز دارید، SBC تخصصی انتخاب مطمئن‌تری است.

در اکتبر ۲۰۲۶، نسخه پایدار فعلی Kamailio برابر 6.1.5 است که ۱۵ اکتبر منتشر شده و آخرین Stable شاخه 6.1 محسوب می‌شود. برای Media نیز RTPengine چند Release Train موازی دارد و باید شاخه سازگار با Distribution و ماژول Kamailio خودتان را انتخاب کنید.

SBC در VoIP چیست؟

در معماری SIP، SBC در مرز دو شبکه قرار می‌گیرد. RFC 5853 یکی از نیازهای شناخته‌شده SBC را Topology Hiding معرفی می‌کند؛ یعنی آدرس‌ها و مسیرهای داخلی Proxyها، Gatewayها و Application Serverها نباید بی‌دلیل به طرف بیرونی نمایش داده شوند.

در یک معماری معمول، SBC این وظایف را می‌تواند انجام دهد:

Internet / SIP Carrier
         |
         v
+--------------------+
|    SBC / Edge      |
| Kamailio           |
| RTPengine          |
+--------------------+
         |
         v
Asterisk / FreeSWITCH
Internal VoIP Network

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

وجود SIP به‌تنهایی دلیل کافی برای SBC نیست. نیاز واقعی زمانی شکل می‌گیرد که Edge شبکه باید چیزی را کنترل، پنهان یا تبدیل کند.

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

اگر یک PBX روی شبکه خصوصی دارید، Endpointها از VPN متصل می‌شوند و Provider نیز روی لینک خصوصی یا Firewall کنترل‌شده است، اضافه‌کردن SBC ممکن است فقط Complexity، Latency و نقطه خرابی جدید ایجاد کند.

همچنین اگر فقط هدف شما «بستن Port 5060» است، Firewall درست و ACL روی PBX ممکن است کافی باشد. SBC جای Firewall نیست؛ یک لایه Application-aware برای SIP/Media است.

SBC سبک با Kamailio و RTPengine چه شکلی است؟

در این طراحی Kamailio Signaling را در Edge می‌گیرد و RTPengine Media را Anchor می‌کند:

SIP Carrier / Internet
          |
          | TLS / UDP / TCP
          v
     +-----------+
     | Kamailio  |
     | ACL       |
     | RateLimit |
     | Topology  |
     +-----+-----+
           |
           | SDP control
           v
     +-----------+
     | RTPengine |
     | RTP/SRTP  |
     | NAT       |
     +-----------+
           |
           v
       PBX Pool

در این مدل، PBXهای داخلی فقط IPهای Kamailio/RTPengine را Trust می‌کنند و مستقیماً در معرض اینترنت نیستند.

مرز مهم: Proxy-based SBC با B2BUA کامل فرق دارد

بسیاری از SBCهای کلاسیک به‌صورت B2BUA عمل می‌کنند؛ یعنی یک Dialog SIP را از یک سمت Terminate می‌کنند و Dialog جدیدی در سمت دیگر می‌سازند. RFC 5853 این روش را در بحث Topology Hiding توضیح می‌دهد.

Kamailio ذاتاً Proxy است. می‌تواند Headerها را مخفی یا بازنویسی کند، Transaction/Route را کنترل کند و Media را به RTPengine بدهد؛ اما به‌صورت پیش‌فرض یک B2BUA کامل نیست.

اگر نیاز شما شامل این موارد است، فقط Kamailio Proxy را «SBC کامل» فرض نکنید:

Topology Hiding؛ اولین وظیفه SBC

اگر Provider یک INVITE دریافت کند و داخل Via، Record-Route یا Contact آدرس‌های Private یا نام Backendهای شما را ببیند، مرز شبکه کامل نیست.

ماژول topos در Kamailio برای پنهان‌کردن جزئیات Topology Dialogهای SIP طراحی شده است. مستند رسمی می‌گوید این ماژول Headerهای Routing را که اطلاعات Topology را نشان می‌دهند از پیام خروجی حذف می‌کند و هنگام برگشت دوباره State لازم را Restore می‌کند.

نمونه پایه:

loadmodule "rr.so"
loadmodule "topos.so"

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

برای HA، Storage ماژول Topology نیز باید Redundant باشد. اگر دو Kamailio دارید ولی State توپولوژی فقط روی Memory محلی یک Node باشد، Failover Mid-dialog می‌تواند مشکل ایجاد کند.

ACL؛ Carrier را فقط از IPهای واقعی خودش بپذیرید

اگر SIP Provider IPهای ثابت یا Range رسمی دارد، نباید هر IP روی اینترنت بتواند خودش را به‌عنوان Carrier معرفی کند.

ماژول permissions در Kamailio برای IP-based ACL طراحی شده و Address/Subnet را می‌تواند از Database به RAM Load کند.

نمونه ساده:

loadmodule "permissions.so"

if (!allow_source_address("1")) {
    send_reply("403", "Forbidden");
    exit;
}

Group شماره 1 می‌تواند شامل IPهای Carrier باشد. در Kamailio 6.1، Address Matching حتی Longest Prefix Match را هم پشتیبانی می‌کند.

Rate Limiting؛ قبل از PBX جلوی Flood را بگیرید

Edge باید بتواند Request Rate غیرطبیعی را قبل از رسیدن به Asterisk تشخیص دهد. ماژول pike IP Source را Track می‌کند و وقتی Rate از Threshold عبور کند، Script شما می‌تواند درخواست را Drop کند.

نمونه:

loadmodule "pike.so"

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

if (!pike_check_req()) {
    exit;
}

عدد 30 فقط مثال است. Threshold واقعی را از Baseline ترافیک خودتان بسازید؛ Carrier پرترافیک، REGISTER Farm و Scan اینترنتی الگوی یکسانی ندارند.

TLS در Signaling؛ کجا Terminate شود؟

در SBC سبک معمولاً Kamailio TLS را در Edge Terminate می‌کند. به این ترتیب Client یا Carrier با TLS به Edge وصل می‌شود و شما تصمیم می‌گیرید سمت Backend نیز TLS باشد یا روی شبکه خصوصی Transport دیگری استفاده شود.

دو مدل رایج:

مدل دوم برای Zero-trust یا شبکه چندبخشی امن‌تر است، اما Certificate Lifecycle و Troubleshooting پیچیده‌تر می‌شود.

Kamailio 6.1 قابلیت‌های TLS گسترده‌ای دارد و در Release 6.1 حتی گزینه‌های جدید برای Multi-threaded TLS و چند TLS Connection با Domainهای مختلف اضافه شده است.

SRTP و Media Anchoring با RTPengine

وقتی Media مستقیم بین Carrier و PBX عبور کند، SBC فقط Signaling را می‌بیند. اگر هدف شما کنترل واقعی مرز Media است، RTP باید Anchor شود.

Kamailio از طریق ماژول rtpengine SDP را به RTPengine می‌دهد و RTPengine آدرس و Port Media را Rewrite می‌کند:

loadmodule "rtpengine.so"

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

if (has_body("application/sdp")) {
    if (!rtpengine_manage()) {
        send_reply("500", "Media Proxy Error");
        exit;
    }
}

RTPengine می‌تواند RTP/SRTP Bridging، ICE/WebRTC و Media Proxy را انجام دهد. بنابراین اگر Provider RTP ساده می‌دهد و Client SRTP لازم دارد، Media Layer می‌تواند بین این دو Policy قرار بگیرد.

NAT؛ چرا SBC باید Media را ببیند؟

یکی از مهم‌ترین کاربردهای SBC جلوگیری از One-way Audio در مرزهای NAT است. Endpoint ممکن است در SDP آدرس خصوصی بدهد یا Mapping آن با Source واقعی Packet فرق داشته باشد.

RTPengine Media را روی IP عمومی خودش Anchor می‌کند:

Before:
c=IN IP4 192.168.10.25
m=audio 17824 RTP/AVP 0 8

After SBC media anchoring:
c=IN IP4 203.0.113.30
m=audio 32042 RTP/AVP 0 8

از این لحظه هر دو سمت Media را به RTPengine می‌فرستند و شبکه داخلی شما از Carrier جدا می‌شود.

Transcoding؛ SBC را بی‌دلیل Transcoder نکنید

RTPengine از Audio Transcoding پشتیبانی می‌کند، اما این قابلیت رایگان از نظر منابع نیست. مستند رسمی RTPengine توضیح می‌دهد Transcoding در User Space انجام می‌شود و Streamهای Transcodeشده دیگر از In-kernel Packet Forwarding استفاده نمی‌کنند.

مثلاً اگر Carrier فقط G.711 و Client فقط Opus دارد، می‌توانید Transcoding را فعال کنید. در Kamailio:

rtpengine_offer("codec-transcode=PCMU codec-transcode=opus");

اما اگر دو سمت Codec مشترک دارند، Transcoding را روشن نکنید. SBC باید در حالت عادی Media را تا جای ممکن بدون تبدیل عبور دهد.

SIP Normalization؛ جایی که SBC سبک ممکن است کم بیاورد

بعضی Carrierها Header، Contact، PAI، Diversion، History-Info یا SDP خاصی می‌فرستند که با PBX شما سازگار نیست. Kamailio ابزارهای زیادی برای Rewrite دارد، اما اگر هر تماس به مجموعه بزرگی از Ruleهای Vendor-specific و Stateful Transformation نیاز پیدا کند، بهتر است معماری را دوباره ارزیابی کنید.

نشانه‌هایی که به SBC/B2BUA کامل نزدیک شده‌اید:

امنیت؛ SBC فقط چند ماژول Kamailio نیست

یک Edge امن حداقل باید چند لایه داشته باشد:

HA؛ یک SBC واحد خودش Single Point of Failure است

اگر تمام تماس‌ها از یک Kamailio عبور می‌کنند، خراب‌شدن همان Node کل Edge را از دسترس خارج می‌کند. برای Production جدی حداقل دو Edge Node نیاز دارید.

              SIP Provider
                   |
             DNS / VIP / LB
              /         \
             v           v
       +----------+ +----------+
       | SBC Edge1| | SBC Edge2|
       | Kamailio | | Kamailio |
       +-----+----+ +----+-----+
             \           /
              \         /
          RTPengine Pool
             /     \
            v       v
          PBX1     PBX2

اما HA فقط دو Process نیست. این Stateها را هم بررسی کنید:

اگر Edge-1 وسط تماس از مدار خارج شود، وجود Edge-2 لزوماً Session فعال را بدون وقفه نجات نمی‌دهد. تماس جدید و تماس Active دو Failure Scenario جدا هستند.

OpenSIPS هم می‌تواند SBC سبک باشد؟

بله. OpenSIPS 4.0 نیز ماژول‌های Topology Hiding، Rate Limit، Permissions، Clusterer و RTPengine Integration دارد. نسخه پایدار فعلی شاخه 4.0 برابر 4.0.2 است که ۸ سپتامبر ۲۰۲۶ منتشر شده است.

در OpenSIPS، ماژول topology_hiding Via، Record-Route و Route را پنهان و Contact را بازنویسی می‌کند. همچنین Clusterer برای Replication و وظایف توزیع‌شده بین چند OpenSIPS طراحی شده است.

انتخاب Kamailio یا OpenSIPS برای SBC سبک بیشتر به تجربه تیم، Moduleهای موردنیاز، Automation و Monitoring شما بستگی دارد تا یک برنده مطلق.

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

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

برای یک شرکت با دو SIP Provider، دو Asterisk و WebRTC:

Backendهای Asterisk نباید Port SIP عمومی داشته باشند و فقط از Edge Nodeها Request بپذیرند.

Failure Scenarioهایی که باید قبل از Production تست شوند

Monitoring SBC؛ فقط CPU را نگاه نکنید

Edge VoIP باید بر اساس Protocol Metric مانیتور شود:

برای Pike:

kamcli rpc pike.top ALL

و برای RTPengine:

kamcmd rtpengine.show all
kamcmd rtpengine.ping all

چک‌لیست تصمیم؛ قبل از ساخت SBC این سؤال‌ها را جواب دهید

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

SBC در VoIP چیست؟

SBC یک لایه مرزی برای کنترل SIP و Media بین دو شبکه است و می‌تواند Topology Hiding، NAT، TLS/SRTP، ACL، Rate Limiting، Media Anchoring و Failover را انجام دهد.

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

خیر. اگر PBX فقط داخل شبکه خصوصی است و SIP عمومی ندارید، SBC ممکن است ضروری نباشد. نیاز واقعی وقتی بیشتر می‌شود که SIP Carrier، اینترنت، چند PBX، WebRTC یا NAT پیچیده وارد معماری شوند.

آیا Kamailio به‌تنهایی SBC است؟

Kamailio می‌تواند بخش بزرگی از وظایف Signaling Edge و SBC را انجام دهد، اما ذاتاً SIP Proxy است و B2BUA کامل نیست. برای Media معمولاً RTPengine و برای بعضی Interopهای پیچیده B2BUA یا SBC تخصصی لازم می‌شود.

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

RTPengine Media را Anchor می‌کند و برای NAT، RTP/SRTP Bridging، WebRTC، ICE و در صورت نیاز Transcoding استفاده می‌شود.

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

اطلاعات Route و Headerهایی مثل Via، Record-Route و Contact می‌توانند ساختار داخلی SIP را آشکار کنند. Topology Hiding این اطلاعات را از طرف بیرونی پنهان می‌کند.

آیا SBC جای Firewall را می‌گیرد؟

خیر. Firewall لایه شبکه را کنترل می‌کند و SBC روی SIP و Media Policy آگاهی بیشتری دارد. در معماری امن هر دو لازم‌اند.

آیا Transcoding را روی SBC فعال کنیم؟

فقط وقتی لازم است. اگر دو سمت Codec مشترک دارند، Transcoding منابع CPU را بی‌دلیل مصرف می‌کند. RTPengine Transcoding را در User Space انجام می‌دهد.

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

برای سرویس جدی معمولاً حداقل دو Edge Node لازم است، اما State مربوط به Topology، Media و Entry Point نیز باید در طراحی Failover لحاظ شود.