پرش به محتوا 
مقدمه
RTP (Real-time Transport Protocol) پروتکلی است که جریان‌های صوت و تصویر را در تماس‌های VoIP منتقل می‌کند. وقتی SIP تماس را برقرار می‌کند، خود صوت/ویدئو معمولاً روی RTP جابجا می‌شود. شناخت دقیق RTP برای عیب‌یابی کیفیت، پیکربندی فایروال، QoS و پیاده‌سازی SRTP در پروژه‌های Asterisk/Issabel حیاتی است.
RTP بسته‌های زمان‌بندی‌شده‌ای می‌فرستد که حامل فریم‌های صوت یا ویدئو هستند. این پروتکل تضمین ترتیب یا بازیابی بسته‌ها را نمی‌دهد — به همین خاطر بسته‌های از دست‌رفته یا jitter باید با لایه‌های دیگر (مثلاً Jitter Buffer) مدیریت شوند. RTP معمولاً همراه با RTCP (RTP Control Protocol) استفاده می‌شود تا کیفیت و آمار جریان (packet loss, jitter, round-trip time) گزارش شود.
پورت‌ها: معمولاً محدوده UDP (مثلاً ۱۰۰۰۰-۲۰۰۰۰) برای RTP روی Asterisk/Issabel استفاده می‌شود (قابل تنظیم در rtp.conf).
پروتکل انتقال: UDP (برای سرعت و تأخیر کم).
کنترل و گزارش: RTCP برای اندازه‌گیری کیفیت استفاده می‌شود.
نمونه تنظیم RTP در Asterisk (/etc/asterisk/rtp.conf):
باز کردن پورت‌ها در فایروال (نمونه iptables):
Packet Loss (از دست رفتن بسته): بالای ۱–۲% مشکل‌ساز است.
Jitter: نوسان تأخیر میان بسته‌ها؛ باید پایین نگه داشته شود یا jitter buffer استفاده شود.
Latency (تاخیر): زیر 150ms برای مکالمه‌ی طبیعی مطلوب است.
ابزارها: rtpengine, rtpproxy, sngrep, wireshark, tcpdump، مانیتورینگ با Grafana/Prometheus برای شاخص‌های شبکه.
مثال tcpdump برای ضبط RTP:
برای امنیت صدا، از SRTP (Secure RTP) استفاده می‌کنیم. SRTP نیاز به تبادل کلید دارد (DTLS-SRTP یا SDES). برای WebRTC و کلیاینت‌های وب، DTLS-SRTP ضروری است و نیازمند TLS معتبر روی سرور است.
نکات عملی:
برای WebRTC در Issabel/Asterisk حتماً TLS معتبر (Let’s Encrypt) نصب کن.
بررسی کن که کلاینت‌ها SRTP پشتیبانی کنند.
در Asterisk فعال‌سازی SRTP معمولاً در کانفیگ PJSIP یا chan_sip انجام می‌پذیرد.
رایج‌ترین مشکل RTP در پروژه‌ها: One-way audio یا بی‌صدا شدن یک طرف تماس. دلایل معمول:
NAT ترجمه آدرس/پورت RTP را بدرستی انجام نمی‌دهد.
پورت‌های RTP در فایروال سرور بسته است.
SDP حاوی آدرس خصوصی (private IP) به جای آدرس عمومی است.
راهکارهای عملی:
در Asterisk/Issabel تنظیمات external_ip و local_net (یا معادل PJSIP) را انجام بده.
استفاده از STUN/ICE/TURN برای کلاینت‌های پشت NAT (مهم برای WebRTC).
در صورت محدودیت ISP (CGNAT)، استفاده از VPN site-to-site یا TURN برای رله کردن جریان.
باز کردن کامل بازه پورت‌های RTP در فایروال و NAT forwarding.
sngrep — برای دیدن سیگنالینگ SIP و جریان‌های مربوطه.
Wireshark — تحلیل عمیق پکت‌ها و محاسبه jitter/loss.
tcpdump — ضبط پکت‌ها برای آنالیز آفلاین.
rtpengine/rtpproxy — برای رله/نرمال‌سازی RTP در موارد NAT.
Asterisk CLI: rtp set debug on، core show channels برای دیدن کانال‌ها.
در ارائه‌ی سرویس VoIP به مشتریان ایرانی، همواره از بازه پورت‌های گسترده‌تر (مثلاً ۱۰۰۰۰–۲۰۰۰۰) استفاده کنید تا کمبود پورت باعث تداخل نشود.
هنگام راه‌اندازی WebRTC، از Turn server (coturn) استفاده کن تا در شبکه‌های سخت و CGNAT نیز ارتباط برقرار شود.
اگر تماس‌ها روی هاست‌های اشتراکی یا VPS با NAT اجرا می‌شود، VPN یا رله RTP را پیشنهاد کن؛ چند بار دیده‌ایم که مشتری روی VPS با NAT داخلی صدای پایدار نداشته است.
برای تحلیل‌های دوره‌ای کیفیت تماس از متریک‌های RTCP در گزارش‌ها استفاده کن و این آمارها را در Grafana نشان بده؛ مشتری‌های سازمانی خیلی به این KPI نیاز دارند.
TLS معتبر روی وب‌سرور الزامی (Let’s Encrypt).
پشتیبانی Opus (بهترین کدک برای WebRTC) و SRTP لازم است.
فعال‌سازی ICE/STUN/TURN و پیکربندی icesupport=yes در Asterisk.
مسئله: شرکتی تماس‌های بین‌شعبه‌ای داشت؛ یک‌طرف صدا شنیده می‌شد و قطع و وصل بود.
آنالیز: پورت‌های RTP روی روتر مسدود بود و ISP از CGNAT استفاده می‌کرد.
راه‌حل: با نصب TURN server (coturn) و پیکربندی آدرس عمومی در Asterisk، و تنظیم QoS روی روتر، نرخ Packet Loss به زیر ۰.۵% رسید و کیفیت به شکل قابل‌قبولی بازگشت.
بدون پیکربندی صحیح RTP هیچ تماس VoIP پایدار و با کیفیت نخواهی داشت. از باز کردن پورت‌ها و پیکربندی NAT تا پیاده‌سازی SRTP و TURN — همه جزء ملزومات پروژه‌های حرفه‌ای VoIP هستند. تیم ویپ ایران در پیاده‌سازی مراکز تماس و رفع مشکلات RTP در پروژه‌های سازمانی تجربه‌ی زیادی داشته و می‌تواند در راه‌اندازی، آنالیز کیفیت و بهینه‌سازی کمک کند.
