RTPengine چیست؟ مدیریت NAT، WebRTC و SRTP در شبکه‌های VoIP پرترافیک

تا زمانی که یک PBX ساده با چند تلفن در یک شبکه دارید، ممکن است اصلاً به RTPengine نیاز نداشته باشید. اما وقتی معماری شما شامل چند PBX، کاربران اینترنتی، WebRTC، تلفن‌های پشت CGNAT، چند دیتاسنتر یا لایه SIP Proxy مثل Kamailio و OpenSIPS می‌شود، مدیریت Media به یک مسئله مستقل تبدیل می‌شود.

در چنین معماری‌ای ممکن است SIP کاملاً درست Route شود، تلفن زنگ بخورد و تماس حتی Answer شود، اما هیچ صدایی شنیده نشود؛ چون مسیر SIP و مسیر RTP دو مسئله جدا هستند.

در این مقاله دقیقاً بررسی می‌کنیم RTPengine چیست، چرا در معماری‌های جدید VoIP اهمیت بیشتری پیدا کرده، چه تفاوتی با SIP Proxy و TURN دارد، NAT و WebRTC را چگونه مدیریت می‌کند، SRTP و ICE چه نقشی دارند و برای Scale کردن چند RTPengine چه معماری‌ای مناسب است.

RTPengine چیست؟

نام کامل پروژه در مستندات:

Sipwise NGCP rtpengine

است.

RTPengine یک Proxy برای:

است.

به زبان ساده، به‌جای اینکه صدای تماس مستقیماً بین دو Endpoint ردوبدل شود، می‌توان آن را از RTPengine عبور داد.

مثلاً:

Phone A
   |
   | RTP
   v
RTPengine
   |
   | RTP
   v
Phone B

یا در یک معماری واقعی‌تر:

                 SIP
Phone ─────── Kamailio/OpenSIPS ─────── PBX
  \                                      /
   \                                    /
    └────────── RTPengine ──────────────┘
                   RTP

تفاوت RTPengine با Kamailio و OpenSIPS چیست؟

این تفاوت پایه‌ای را باید قبل از هر چیز بدانید.

Kamailio و OpenSIPS معمولاً Signaling را مدیریت می‌کنند.

RTPengine Media را مدیریت می‌کند.

Signaling شامل پیام‌هایی مثل:

است.

اما صدای واقعی تماس داخل RTP منتقل می‌شود.

یک تماس می‌تواند SIP سالم و RTP خراب داشته باشد

این همان سناریوی معروف:

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

است.

مثلاً SIP چنین مسیری دارد:

Phone → OpenSIPS → Asterisk

اما SDP به تلفن می‌گوید RTP را به:

10.20.0.12:18546

بفرستد.

کاربر اینترنتی طبیعتاً به IP خصوصی 10.20.0.12 دسترسی ندارد.

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

RTPengine این مشکل را چگونه حل می‌کند؟

SIP Proxy هنگام عبور SDP آن را برای RTPengine می‌فرستد.

RTPengine یک Port محلی رزرو می‌کند و SDP را بازنویسی می‌کند.

مثلاً مقدار:

c=IN IP4 10.20.0.12
m=audio 18546 RTP/AVP 0 8 101

می‌تواند در سمت اینترنت به چیزی شبیه:

c=IN IP4 203.0.113.20
m=audio 32784 RTP/AVP 0 8 101

تغییر کند.

از این لحظه Endpoint صدای خود را به RTPengine می‌فرستد.

RTPengine خودش SIP Server نیست

RTPengine به‌طور معمول منتظر INVITE مستقیم کاربران نمی‌ماند.

یک SIP Proxy یا Application دیگر باید به آن فرمان بدهد.

کنترل معمولاً از طرف:

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

Control Plane و Media Plane را جدا ببینیم

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

Control Plane:

Kamailio/OpenSIPS → RTPengine

Media Plane:

Endpoint ↔ RTPengine ↔ PBX/Endpoint

NG Control Protocol چیست؟

Kamailio یا OpenSIPS برای RTPengine پیام‌هایی مثل:

می‌فرستد.

به‌طور مفهومی:

Offer: یک Media Session جدید بساز.

Answer: اطلاعات سمت دوم را تکمیل کن.

Delete: Session را بعد از پایان تماس پاک کن.

Query: وضعیت و آمار Session را بده.

چرا Control Port را نباید روی اینترنت باز کنیم؟

این Port برای کنترل Media Sessionها استفاده می‌شود و باید فقط از SIP Proxyهای مورد اعتماد قابل دسترسی باشد.

اگر Kamailio و RTPengine روی یک Server هستند، می‌توانید Control Interface را روی Loopback نگه دارید.

اگر روی دو Server جدا هستند، از Private Network و Firewall محدود استفاده کنید.

مثال معماری امن

Internet
   |
Kamailio
10.20.0.5
   |
   | Private control network
   |
RTPengine
10.20.0.20:2223

Port کنترل RTPengine نباید برای همه اینترنت Allow شود.

مهم‌ترین کاربرد RTPengine: NAT

NAT هنوز یکی از اصلی‌ترین دلایل مشکلات Media در VoIP است.

Endpoint ممکن است در SDP آدرس خصوصی خودش را قرار دهد:

192.168.1.35

در حالی که از دید اینترنت Public IP چیز دیگری است.

RTPengine می‌تواند Media را Anchor کند و آدرس قابل‌دسترسی خودش را در SDP قرار دهد.

RTPengine می‌تواند Public و Private Interface جدا داشته باشد

این قابلیت در معماری SBC بسیار مهم است.

مثلاً:

Public Media:
203.0.113.20

Private Media:
10.20.0.20

سمت اینترنت Public Interface را می‌بیند و PBXهای داخلی Private Interface را.

نمونه Config با دو Interface

ساختار فعلی RTPengine امکان تعریف Interfaceهای منطقی را می‌دهد.

[rtpengine]
table = 0
listen-ng = 10.20.0.20:2223
interfaces-config = interface

[interface-public]
address = 10.10.0.20
advertised = 203.0.113.20
port-min = 30000
port-max = 39999

[interface-private]
address = 10.20.0.20
port-min = 40000
port-max = 49999

IPها فقط نمونه مستندسازی هستند.

advertised چه کاربردی دارد؟

ممکن است خود RTPengine پشت NAT باشد.

در آن حالت Server روی:

10.10.0.20

گوش می‌دهد ولی در SDP باید:

203.0.113.20

تبلیغ شود.

Media Port Range را از Firewall فراموش نکنید

Default فعلی مستند RTPengine برای Media Port Range از حدود:

30000
تا
40000

است، مگر اینکه خودتان تغییر دهید.

اگر Config شما Range متفاوتی دارد، Firewall هم باید دقیقاً همان Range را Allow کند.

Range بزرگ‌تر همیشه بهتر نیست

هر Media Stream به Port نیاز دارد.

اما باز کردن:

UDP 1-65535

فقط برای راحتی، انتخاب مناسبی نیست.

Range مشخص تعریف و همان Range را در Firewall مدیریت کنید.

چرا WebRTC باعث مهم‌تر شدن RTPengine شده است؟

تلفن SIP سنتی معمولاً با چیزی شبیه:

RTP/AVP + PCMA/PCMU

کار می‌کند.

اما Browser WebRTC معمولاً نیازهای متفاوتی دارد:

پس Browser و یک PBX قدیمی الزاماً Media Protocol یکسانی ندارند.

مثال WebRTC به SIP

سمت Browser:

ICE
DTLS-SRTP
RTP/SAVPF
RTCP-MUX
Opus

سمت PBX یا Carrier:

RTP/AVP
PCMA

RTPengine می‌تواند بین این دو دنیا قرار بگیرد.

RTPengine برای WebRTC چه قابلیت‌هایی دارد؟

در نسخه‌های فعلی:

ICE چیست؟

ICE یا Interactive Connectivity Establishment مکانیزمی است که Endpointهای WebRTC با آن مسیر مناسب Media را بین Candidateهای مختلف پیدا می‌کنند.

Candidateها ممکن است شامل:

باشند.

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

RTPengine می‌تواند:

۱. خودش را به‌عنوان Candidate اضافه کند.

۲. Candidateهای قبلی را حذف و Media را مجبور به عبور از خودش کند.

۳. بین Endpoint دارای ICE و Endpoint بدون ICE Bridge ایجاد کند.

۴. به‌صورت ICE Lite عمل کند.

ICE=force چه مفهومی دارد؟

وقتی Policy روی Force قرار گیرد، Candidateهای موجود می‌توانند کنار گذاشته شوند و RTPengine خودش مسیر Media را کنترل کند.

این حالت زمانی مفید است که:

می‌خواهید Media حتماً از Relay عبور کند.

اما Force کردن Relay در همه تماس‌ها هزینه Bandwidth و CPU را افزایش می‌دهد.

آیا RTPengine همان TURN است؟

نه دقیقاً.

TURN یک Relay استاندارد عمومی برای WebRTC است که Client مستقیماً با پروتکل TURN به آن متصل می‌شود.

RTPengine معمولاً توسط SIP Proxy و بر اساس SDP کنترل می‌شود.

پس برای یک WebRTC Application مبتنی بر SIP، RTPengine می‌تواند بخش بزرگی از نیاز Media Relay را برطرف کند، اما نباید آن را جایگزین عمومی TURN برای هر نوع WebRTC Application دانست.

چه زمانی هنوز TURN لازم است؟

اگر Application شما:

یک TURN Server مانند coturn ممکن است همچنان لازم باشد.

SRTP چیست و RTPengine چه کمکی می‌کند؟

RTP معمولی رمزنگاری نشده است.

SRTP نسخه امن RTP است.

در معماری‌های VoIP ممکن است یک سمت SRTP باشد و سمت دیگر فقط RTP را پشتیبانی کند.

مثلاً:

WebRTC
DTLS-SRTP
    |
    v
 RTPengine
    |
    v
Asterisk
RTP/AVP

RTPengine می‌تواند Crypto Termination را انجام دهد و Media را در سمت دیگر با Profile متفاوت ارسال کند.

RTPengine چه روش‌های SRTP را پشتیبانی می‌کند؟

از جمله:

این یعنی RTPengine خودش یک نقطه حساس امنیتی است

اگر Media رمزنگاری‌شده روی RTPengine Terminate شود، سرور Media Keyها و Media Decrypted را پردازش می‌کند.

در نتیجه امنیت خود RTPengine بسیار مهم است.

بهتر است:

RTPengine فقط Relay نیست؛ Transcoding هم دارد

نسخه‌های فعلی RTPengine قابلیت Transcoding دارند.

برای مثال:

Opus
  ↕
PCMA

یا Codecهای دیگر در صورت پشتیبانی Build.

چه زمانی Transcoding لازم می‌شود؟

مثلاً Browser فقط Opus را ترجیح می‌دهد ولی Carrier شما PCMA می‌خواهد.

اگر هیچ Codec مشترکی وجود نداشته باشد، تماس بدون Transcoding ممکن است برقرار نشود.

Transcoding رایگان نیست

Relay ساده یک Packet با Transcoding همان Packet بسیار متفاوت است.

در Transcoding، Media باید:

Decode → Process → Encode

شود.

مصرف CPU می‌تواند به‌طور قابل توجهی افزایش پیدا کند.

برای همین ظرفیت RTPengine را فقط با تست RTP Pass-through اندازه نگیرید اگر Production شما WebRTC-to-PSTN دارد.

Recording هم روی RTPengine ممکن است

RTPengine قابلیت Recording Media را نیز دارد.

این ویژگی می‌تواند در معماری‌هایی مفید باشد که نمی‌خواهند PBX مسئول ضبط تماس باشد.

اما Recording باعث اضافه‌شدن:

می‌شود.

اگر فقط Media Relay می‌خواهیم، Recording را فعال نکنیم

هر Feature اضافه‌ای می‌تواند Capacity و Complexity را کاهش دهد.

اصل مناسب برای Media Node:

فقط قابلیت‌هایی را فعال کنید که واقعاً لازم دارید.

Packet Forwarding در User Space چه مشکلی دارد؟

RTP شامل Packetهای کوچک اما بسیار پرتعداد است.

در حالت معمول هر Packet:

NIC → Kernel → User Space → RTPengine → Kernel → NIC

را طی می‌کند.

این رفت‌وبرگشت باعث:

می‌شود.

برای همین RTPengine Kernel Forwarding دارد

نسخه‌های فعلی RTPengine از:

nft_rtpengine

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

این Module می‌تواند Media Packetهای Session پایدار را مستقیماً داخل Kernel Forward کند.

مزیت Kernel Forwarding چیست؟

بخش بزرگی از Packetها دیگر لازم نیست برای هر Hop وارد Process اصلی RTPengine شوند.

نتیجه می‌تواند:

باشد.

راهنماهای قدیمی iptables را با احتیاط بخوانید

مستندات جدید RTPengine برای In-kernel Forwarding از:

nftables + nft_rtpengine

صحبت می‌کنند.

بسیاری از آموزش‌های قدیمی اینترنت هنوز بر اساس Moduleهای قدیمی iptables نوشته شده‌اند.

وضعیت Module را بررسی کنیم

lsmod | grep rtpengine

و در صورت نصب صحیح:

modprobe nft_rtpengine

اگر Kernel Module لود نشود چه می‌شود؟

RTPengine می‌تواند به User Space Forwarding برگردد.

پس Failure Module الزاماً به معنی قطع کامل سرویس نیست، اما Capacity و CPU Profile ممکن است تغییر زیادی کند.

برای همین Monitoring باید بفهمد Media واقعاً در چه Modeای Forward می‌شود.

Transcoding همیشه قابل Kernel Offload نیست

Kernel Forwarding برای Packet Forwarding ساده فوق‌العاده است.

اما وقتی نیاز به:

دارید، RTPengine باید Media را عمیق‌تر پردازش کند و User Space نقش بیشتری پیدا می‌کند.

پس Benchmark Relay و Transcoding باید جدا باشد

مثلاً این دو تست یکسان نیستند:

تست A:

PCMA → PCMA

تست B:

WebRTC Opus/DTLS-SRTP
       ↓
Transcoding
       ↓
PCMA/RTP

RTPengine و IPv4/IPv6

یکی دیگر از قابلیت‌های مهم پروژه Bridge کردن:

IPv4 ↔ IPv6

است.

یعنی یک Endpoint IPv6 می‌تواند با Endpoint IPv4 تماس Media داشته باشد و RTPengine در میان آن‌ها قرار بگیرد.

این قابلیت برای شبکه‌های جدید مهم‌تر شده است

برخی Mobile Networkها و Cloud Environmentها IPv6 بیشتری استفاده می‌کنند، در حالی که بسیاری از SIP Carrierها همچنان IPv4 هستند.

داشتن Media Relay دوپشته باعث می‌شود Backend مجبور نباشد تمام Endpointها را مستقیم Reach کند.

چرا RTPengine برای مخفی‌کردن Topology مهم است؟

فرض کنید PBX شما روی:

10.20.0.11

است.

Kamailio می‌تواند SIP Headerها را مخفی کند، اما SDP همچنان ممکن است آدرس PBX را نشان دهد.

RTPengine با Rewrite کردن SDP اجازه می‌دهد Public Client فقط Media IP متعلق به RTPengine را ببیند.

پس Topology Hiding دو بخش دارد

Signaling:

Kamailio/OpenSIPS

Media:

RTPengine

اگر فقط یکی را مخفی کنید، Topology دیگری ممکن است هنوز قابل مشاهده باشد.

RTPengine در کنار Asterisk چه فایده‌ای دارد؟

Asterisk خودش می‌تواند RTP را Anchor و NAT را مدیریت کند.

پس سؤال منطقی این است که چرا RTPengine اضافه کنیم؟

وقتی یک Asterisk دارید، شاید واقعاً نیازی نباشد.

اما وقتی:

RTPengine جذاب‌تر می‌شود.

معماری چند Asterisk بدون RTPengine

           Kamailio
           /   |   \
          /    |    \
       AST1   AST2   AST3
        ↑      ↑      ↑
        └──── RTP ────┘

هر Asterisk باید Media Public/NAT خودش را درست مدیریت کند.

با RTPengine

         Kamailio
         /  |  \
      AST1 AST2 AST3
         \  |  /
          \ | /
        RTPengine
            |
         Clients

Media Edge مستقل‌تر می‌شود.

آیا این یعنی Asterisk دیگر Media را نمی‌بیند؟

نه الزاماً.

اگر مسیر:

Client → RTPengine → Asterisk

باشد، Media هنوز از Asterisk هم عبور می‌کند.

RTPengine فقط لایه دیگری به Media Path اضافه کرده است.

برای حذف Asterisk از Media Path باید معماری و Direct Media جداگانه طراحی شود.

چند RTPengine را چطور Scale کنیم؟

یکی از مزیت‌های مهم، Scale مستقل Media Layer است.

مثلاً:

              SIP Proxy
            /     |     \
           /      |      \
       RTP-01   RTP-02   RTP-03
          |        |        |
        Media    Media    Media

Kamailio و OpenSIPS هر دو چند RTPengine را پشتیبانی می‌کنند

Moduleهای کنترل RTPengine می‌توانند چند Media Proxy را داخل Set قرار دهند.

در OpenSIPS حتی Weight هر Node در Selection قابل تعریف است.

در نتیجه Node قوی‌تر می‌تواند سهم بیشتری از تماس‌ها بگیرد.

نمونه مفهومی Set

Set 1:
RTPengine-01 weight=10
RTPengine-02 weight=10
RTPengine-03 weight=20

Node سوم می‌تواند تقریباً سهم بیشتری بگیرد.

Offer و Answer یک تماس باید روی همان Node بمانند

Media Session State روی RTPengine نگه‌داری می‌شود.

پس نمی‌توانید:

Offer → RTP-01
Answer → RTP-02

را بدون State Design انجام دهید.

Module کنترل باید Selection همان Session را حفظ کند.

Health Check در چند RTPengine

اگر یک Media Node پاسخ Control Message ندهد، Kamailio/OpenSIPS می‌توانند آن را موقتاً Disable و Sessionهای جدید را به Nodeهای سالم بفرستند.

در OpenSIPS پارامترهایی برای:

وجود دارد.

خرابی RTPengine وسط تماس چه می‌شود؟

این بخش با Failover تماس جدید فرق دارد.

اگر Media Node وسط تماس Crash کند، RTP همان تماس روی همان Node بوده است.

انتخاب RTPengine دیگر برای تماس جدید آسان است، اما انتقال تماس فعال نیاز به State Sharing و Failover Design پیشرفته‌تری دارد.

Redis Persistence در RTPengine

RTPengine می‌تواند Session State را داخل Redis ذخیره کند.

در Startup نیز امکان Restore کردن Sessionهای ذخیره‌شده وجود دارد.

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

وجود دارند.

آیا Redis یعنی Failover کاملاً بدون قطع؟

نه.

Persistence و State Takeover ابزارهای مهمی هستند، اما Media Failover همچنان به:

وابسته است.

نباید صرف فعال‌کردن Redis را معادل HA بدون وقفه دانست.

Alias Interface برای Failover

مستندات جدید RTPengine امکان تعریف Alias برای Interface را نیز ارائه می‌کنند.

این قابلیت در کنار Redis Replication مفید است؛ زیرا Standby Node می‌تواند همان Logical Interface را با IP محلی متفاوت نگاشت کند.

چطور یک RTPengine را Drain کنیم؟

نسخه‌های فعلی امکان محدودکردن Sessionهای جدید را دارند.

پارامتر:

max-sessions

برای Admission Control وجود دارد.

در Runtime نیز می‌توان سقف Session را تغییر داد.

برای Maintenance می‌توانید پذیرش Session جدید را متوقف کنید و منتظر بمانید تماس‌های فعال تخلیه شوند.

RTPengine Admission Control دارد

علاوه بر تعداد Session، می‌توان Limitهایی برای:

تعریف کرد.

وقتی Node به سقف برسد، Session جدید Reject می‌شود تا Server کاملاً Overload نشود.

این بهتر از Crash شدن Media Node است

در VoIP Real-Time بهتر است:

تماس جدید به Node دیگری Route شود

تا اینکه Node فعلی به 100 درصد CPU برسد و کیفیت تمام تماس‌های موجود خراب شود.

Port Scaling روی یک Node

یک Public IP تعداد محدودی UDP Port دارد.

RTPengine اجازه می‌دهد چند Interface/IP با نام پایه مشترک تعریف کنید و Port Allocation را Round Robin بین آن‌ها توزیع کنید.

مثلاً:

public:1
public:2
public:3

و هنگام استفاده از نام پایه `public` یکی از Interfaceهای دارای Port آزاد انتخاب شود.

یک RTPengine تا چند تماس را تحمل می‌کند؟

عدد عمومی قابل اعتمادی وجود ندارد.

ظرفیت به این موارد بستگی دارد:

Bandwidth تنها معیار نیست

RTP شامل تعداد زیادی Packet کوچک است.

ممکن است NIC از نظر Mbps هنوز فضای زیادی داشته باشد اما از نظر:

Packets Per Second

یا CPU Interrupt به محدودیت نزدیک شده باشد.

برای Benchmark چه چیزهایی را ثبت کنیم؟

RTPengine خودش آمار Media هم دارد

نسخه‌های فعلی می‌توانند RTP Metrics را اندازه‌گیری کنند.

در Integration Kamailio حتی متغیرهایی برای دریافت:

وجود دارند.

measure-rtp چه کاربردی دارد؟

در حالت ساده Pass-through ممکن است همه Metricهای RTP جمع‌آوری نشوند.

گزینه:

measure-rtp = true

برای اندازه‌گیری Metric حتی در سناریوهای RTP Pass-through قابل استفاده است.

فعال‌کردن Measurement نیز باید از نظر Performance روی بار واقعی تست شود.

آیا باید RTPengine را روی همان Server Kamailio نصب کنیم؟

برای Lab و پروژه کوچک، ممکن است.

اما در Production پرترافیک معمولاً جداسازی مزیت دارد.

Kamailio Signaling-heavy است.

RTPengine Network/Media-heavy است.

با جداکردن آن‌ها می‌توانید هر بخش را مستقل Scale کنید.

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

Public SIP
    |
Kamailio/OpenSIPS
    |
    +------- PBX Pool
    |
    +------- RTPengine-01
             RTPengine-02

معماری بزرگ‌تر

              Clients / Carriers
                      |
                SIP Edge Cluster
               /              \
        Kamailio-01         Kamailio-02
               \              /
                  PBX Pool
            /        |        \
         PBX-01    PBX-02    PBX-03

                Media Layer
            /        |        \
      RTPengine-01 RTPengine-02 RTPengine-03

برای چند دیتاسنتر چه کنیم؟

بهتر است Media تا جای ممکن نزدیک Endpoint عبور کند.

مثلاً User اروپایی نباید فقط به‌خاطر یک Architecture نامناسب RTP را از آسیا عبور دهد.

در معماری Multi-Region می‌توانید RTPengine Set جدا برای هر Region داشته باشید.

مثال Set منطقه‌ای

Set 1 → Iran
Set 2 → Europe
Set 3 → Backup Region

SIP Routing می‌تواند بر اساس User، Carrier یا Region، Media Set مناسب را انتخاب کند.

Latency را در Media Architecture جدی بگیرید

اضافه‌کردن RTPengine یک Hop جدید ایجاد می‌کند.

اگر Media Node در مسیر نامناسب باشد، کیفیت تماس می‌تواند بدتر شود.

هدف Media Proxy این نیست که RTP را هرجا خواستیم عبور دهیم؛ باید مسیر کوتاه و پایدار طراحی شود.

چه زمانی RTPengine واقعاً لازم است؟

چه زمانی RTPengine ممکن است اضافه‌کاری باشد؟

اگر:

اضافه‌کردن RTPengine ممکن است فقط یک Component دیگر برای نگهداری ایجاد کند.

اشتباه رایج: هر مشکل صدای یک‌طرفه را با RTPengine حل کنیم

صدای یک‌طرفه می‌تواند ناشی از:

باشد.

قبل از اضافه‌کردن Media Proxy مشخص کنید مشکل واقعی چیست.

Packet Capture قبل از تغییر معماری

در SIP Proxy:

tcpdump -ni any udp port 5060

و برای Media Range نمونه:

tcpdump -ni any udp portrange 30000-39999

می‌تواند مشخص کند Packet اصلاً وارد Server می‌شود یا خیر.

اگر RTP وارد می‌شود ولی خارج نمی‌شود

مواردی مثل:

را بررسی کنید.

اگر هیچ RTPای وارد نمی‌شود

بیشتر روی:

تمرکز کنید.

RTPengine و QoS

RTPengine امکان تنظیم TOS/QoS Field را دارد.

اما اگر Router یا Provider بعدی DSCP را پاک کند، تنظیم روی Server به‌تنهایی کیفیت را تضمین نمی‌کند.

QoS باید End-to-End تا حد ممکن هماهنگ باشد.

RTPengine یا RTPProxy؟

RTPProxy پروژه قدیمی‌تری با هدف مشابه Media Relay است.

RTPengine در طول زمان قابلیت‌های بسیار گسترده‌تری برای:

اضافه کرده است.

در معماری‌های جدید معمولاً RTPengine گزینه کامل‌تری برای بررسی است.

RTPengine یا Media روی خود PBX؟

یک Test Plan قبل از Production

مرحله ۱: تماس RTP ساده PCMA به PCMA بگیرید.

مرحله ۲: NAT Client را تست کنید.

مرحله ۳: Public-to-Private Interface را تست کنید.

مرحله ۴: صدای دوطرفه را بررسی کنید.

مرحله ۵: WebRTC را با ICE و DTLS-SRTP تست کنید.

مرحله ۶: Opus به PCMA Transcoding را در صورت نیاز تست کنید.

مرحله ۷: RTPengine Node را زیر Load قرار دهید.

مرحله ۸: CPU، PPS، Jitter و Packet Loss را ثبت کنید.

مرحله ۹: یک Media Node را از دسترس خارج کنید.

مرحله ۱۰: بررسی کنید تماس‌های جدید به Node سالم بروند.

مرحله ۱۱: Drain و Maintenance را تست کنید.

مرحله ۱۲: Monitoring و Alert را قبل از ورود کاربران اصلی فعال کنید.

چه چیزهایی را مانیتور کنیم؟

محدودیت Session را قبل از Overload تنظیم کنید

یکی از روش‌های امن این است که RTPengine قبل از رسیدن Server به نقطه بحرانی، Session جدید را نپذیرد.

برای مثال اگر Benchmark نشان داد Node در ۴۰۰۰ Session به Limit نزدیک می‌شود، سقف Production را دقیقاً ۴۰۰۰ قرار ندهید.

Headroom لازم دارید.

چرا Headroom مهم است؟

Load Media همیشه ثابت نیست.

ممکن است ناگهان:

و CPU Profile تغییر کند.

آیا RTPengine روی VPS مناسب است؟

برای ظرفیت کوچک و متوسط، بله؛ به شرط اینکه Network و CPU پایدار باشند.

اما Media Server نسبت به یک Web Server به مواردی مثل:

حساس‌تر است.

برای پروژه پرترافیک بهتر است Benchmark دقیق روی همان نوع زیرساخت انجام شود.

سرور داخل ایران یا خارج؟

محل Media Node باید بر اساس محل واقعی کاربران و Carrier انتخاب شود.

اگر اغلب کاربران و SIP Provider داخل ایران هستند، Media Node داخل ایران می‌تواند Latency را کاهش دهد.

اگر عمده کاربران اروپا هستند، قراردادن Media Node بسیار دور از آن‌ها می‌تواند مسیر RTP را طولانی کند.

معماری Multi-Region برای پروژه بزرگ منطقی‌تر است.

اشتباه‌های رایج RTPengine

اشتباه ۱: تصور می‌کنیم SIP Proxy خودش RTP را عبور می‌دهد.

اشتباه ۲: Control Port RTPengine را روی اینترنت باز می‌کنیم.

اشتباه ۳: Public IP اشتباه در SDP Advertise می‌شود.

اشتباه ۴: Media Port Range در Firewall باز نیست.

اشتباه ۵: WebRTC را مثل SIP/RTP معمولی در نظر می‌گیریم.

اشتباه ۶: Transcoding را در Capacity Planning حساب نمی‌کنیم.

اشتباه ۷: یک RTPengine جلوی چند PBX می‌گذاریم و Media Layer را SPOF می‌کنیم.

اشتباه ۸: Redis را معادل Failover جادویی تماس فعال تصور می‌کنیم.

اشتباه ۹: راهنمای قدیمی iptables را روی معماری جدید nftables بدون بررسی اجرا می‌کنیم.

اشتباه ۱۰: بدون Capture و SDP Analysis به‌سرعت RTPengine اضافه می‌کنیم.

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

RTPengine چیست؟

RTPengine یک Media Proxy برای RTP و سایر Mediaهای VoIP است که می‌تواند NAT، SDP Rewrite، ICE، SRTP، WebRTC، Transcoding، Recording و Media Relay را مدیریت کند.

آیا RTPengine جای Kamailio یا OpenSIPS را می‌گیرد؟

خیر. Kamailio و OpenSIPS عمدتاً SIP Signaling را مدیریت می‌کنند و RTPengine Media را. معمولاً این سیستم‌ها در کنار هم استفاده می‌شوند.

آیا RTPengine برای Asterisk لازم است؟

برای یک Asterisk ساده لزوماً نه. وقتی چند PBX، SIP Proxy، WebRTC، NAT پیچیده یا Media Scaling مستقل دارید RTPengine ارزش بیشتری پیدا می‌کند.

RTPengine چگونه مشکل NAT را حل می‌کند؟

با قرارگرفتن در Media Path و بازنویسی SDP، Endpointها RTP را به آدرس قابل‌دسترسی RTPengine می‌فرستند و RTPengine Media را به سمت مقصد واقعی Relay می‌کند.

آیا RTPengine از WebRTC پشتیبانی می‌کند؟

بله. ICE، Trickle ICE، DTLS-SRTP، RTP/SAVPF، RTCP-MUX و قابلیت‌های موردنیاز برای Bridge کردن WebRTC با SIP/RTP سنتی را پشتیبانی می‌کند.

تفاوت RTPengine و TURN چیست؟

TURN یک Relay عمومی استاندارد برای WebRTC است که Client مستقیماً با آن صحبت می‌کند. RTPengine معمولاً توسط SIP Proxy و از طریق SDP کنترل می‌شود و برای معماری‌های SIP/VoIP طراحی شده است.

آیا RTPengine می‌تواند RTP را به SRTP تبدیل کند؟

بله. RTPengine می‌تواند بین RTP و SRTP و همچنین روش‌های SDES و DTLS-SRTP Interworking انجام دهد.

آیا RTPengine Transcoding انجام می‌دهد؟

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

nft_rtpengine چیست؟

ماژول Kernel فعلی RTPengine برای nftables است که بخش زیادی از Packet Forwarding را داخل Kernel انجام می‌دهد تا CPU و Context Switch کاهش پیدا کند.

برای HA چند RTPengine چه کنیم؟

چند Media Node را داخل Setهای SIP Proxy قرار دهید، Health Check و Weight تعریف کنید و برای تماس‌های جدید Failover داشته باشید. برای State Recovery پیشرفته نیز Redis قابل استفاده است، اما HA تماس فعال نیاز به طراحی کامل شبکه و State دارد.

چطور ظرفیت RTPengine را اندازه بگیریم؟

Concurrent Session، Network PPS، CPU per Core، Bandwidth، Packet Loss، Jitter، MOS، درصد SRTP/WebRTC و تعداد Transcoding Session را روی Workload واقعی اندازه بگیرید.