SIP و RTP چه تفاوتی دارند و NAT چه اثری روی تماس می‌گذارد؟

SIP کوتاه‌شده Session Initiation Protocol و RTP کوتاه‌شده Real-time Transport Protocol است. SDP، با نام Session Description Protocol، توصیف جلسه است؛ خودش صدای مکالمه را حمل نمی‌کند. در تماس معمول، طرف‌ها درباره قالب رسانه یا کدک و مقصد دریافت آن اطلاعات مبادله می‌کنند.

RTP معمولاً روی UDP استفاده می‌شود و اطلاعاتی مانند شماره ترتیب و زمان‌بندی نمونه‌ها دارد تا گیرنده جریان را پردازش کند. بازسازی صدا کار دستگاه یا برنامه گیرنده است؛ روتر معمولی صرفاً به‌خاطر دیدن RTP، صدای تماس را مرتب و پخش نمی‌کند. RTCP نیز پروتکل همراه برای گزارش وضعیت انتقال و اطلاعات کنترلی رسانه است؛ با پیام‌های کنترل تماس SIP فرق دارد.

در این مثال فرضی، داخلی ۱۰۱ با داخلی ۱۰۲ از طریق مرکز تلفن تماس می‌گیرد و پاسخ دریافت می‌کند. برای ساده‌ماندن مثال، احراز هویت و پیام‌های میانی نمایش داده نشده‌اند؛ هر سمت ارتباط با مرکز، تبادل پیام خودش را دارد.

• درخواست: INVITE درخواست شروع جلسه را می‌رساند. مرکز براساس مسیر تماس، برای برقراری ارتباط با داخلی مقصد پیام می‌فرستد.
• زنگ‌خوردن و پاسخ: پیام‌هایی مانند 180 Ringing وضعیت زنگ و پاسخ 200 OK به INVITE، پذیرفته‌شدن جلسه را اعلام می‌کنند.
• تأیید: ACK دریافت پاسخ نهایی INVITE را تأیید می‌کند؛ وجود آن با ارسال صوت یکی نیست.
• مکالمه: رسانه طبق توافق دو سمت جابه‌جا می‌شود؛ در این نمونه جریان RTP حامل صداست.
• پایان: BYE برای پایان جلسه برقرارشده فرستاده می‌شود و پاسخ مربوط را می‌گیرد.

این ترتیب یک نمونه ساده است؛ بعضی تماس‌ها پیش از پاسخ نهایی هم رسانه، مانند پیام صوتی شبکه، دارند. همچنین 200 OK پاسخ موفق به یک درخواست است؛ اگر در جواب REGISTER دیده شود، معنی آن «تماس پاسخ داده شد» نیست.

رجیسترشدن، ارتباط هویت کاربر با نشانی تماس‌پذیر او را در سامانه ثبت می‌کند. موفقیت آن، یک مکالمه واقعی با مسیر صوت در هر دو جهت را آزمایش نکرده است. همه ترانک‌ها هم الزاماً با روش ثبت کاربر کار نمی‌کنند؛ شرایط سرویس تعیین‌کننده است.

خیر. در حالتی، مرکز تلفن در مسیر رسانه می‌ماند و هر گوشی صدا را با مرکز تبادل می‌کند. در حالت دیگری، با قابلیت و تنظیم مناسب، رسانه می‌تواند مستقیم میان دو طرف جابه‌جا شود؛ این مفهوم را معمولاً Direct Media می‌نامند. مسیر پیام‌های SIP و مسیر RTP الزاماً یکسان نیستند.

بنابراین برای تحلیل تماس باید بدانیم قرار بوده صدا از کدام اجزا عبور کند. سالم‌بودن مسیر گوشی تا مرکز، مسیر مستقیم گوشی تا طرف دیگر را تأیید نمی‌کند. برای آشنایی با نقش موتور تلفنی در این میان، تفاوت ایزابل و استریسک را ببینید.

در شبکه‌ای با ترجمه آدرس، بسته خروجی ممکن است با IP عمومی روتر دیده شود، در حالی که داخل توصیف رسانه هنوز آدرس خصوصی مرکز نوشته شده باشد. ترجمه آدرسِ خود بسته، الزاماً نشانی‌های نوشته‌شده در پیام SIP یا SDP را اصلاح نمی‌کند. توضیح پایه در راهنمای NAT و Port Forwarding آمده است.

فرض کنید مرکز داخل شرکت آدرس 192.168.10.20 دارد و اپراتور از اینترنت عمومی با آن ارتباط می‌گیرد. در این مثال، شبکه خصوصی مشترک، VPN یا واسط اصلاح‌کننده نشانی نداریم و مرکز در مسیر صوت است. اگر به اپراتور بگوید صدا را به همان 192.168.10.20 بفرستد، اپراتور از اینترنت به این مقصد خصوصیِ دفتر دسترسی ندارد؛ حتی اگر پیام‌های SIP از مسیر ترجمه‌شده رسیده باشند.

برای درست‌بودن ارتباط، مقصد اعلام‌شده رسانه باید با مسیر واقعی و نگاشت لازم سازگار باشد؛ فایروال باید ترافیک مجاز را عبور دهد و برگشت آن هم درست انجام شود. این فقط یک سناریوی ممکن است. در خط خصوصی اپراتور یا معماری دارای واسط رسانه، آدرس خصوصی لزوماً نشانه خطا نیست.

گوشی دورکار هم ممکن است پشت NAT دیگری باشد. روش برخورد با آن، با مرکز داخل دفتر یکسان نیست. راهکارهایی مانند واسط رسانه یا سازوکارهای عبور از NAT، بسته به پشتیبانی دو سمت و طراحی شبکه انتخاب می‌شوند؛ اضافه‌کردن یک Port Forward روی روتر داخلی، همه لایه‌های بالادست را کنترل نمی‌کند.

SIP ALG یا SIP Helper قابلیتی در بعضی روترها و فایروال‌هاست که محتوای پیام‌های SIP را بررسی می‌کند و ممکن است برای عبور از NAT آن را بازنویسی کند. پس با ترجمه معمول آدرس و پورت تفاوت دارد؛ می‌تواند اطلاعات داخل پیام را هم تغییر دهد.

اگر این بازنویسی با انتظار مرکز، گوشی یا سرویس ناسازگار باشد، خودش مشکل ایجاد می‌کند. برای نمونه، راهنمای رسمی 3CX استفاده از تجهیز بدون SIP ALG یا امکان غیرفعال‌کردن آن را توصیه می‌کند. این توصیه مربوط به طراحی همان محصول است؛ وضعیت هر مرکز و روتر باید با مستندات و شواهد همان مسیر بررسی شود.

روشن یا خاموش‌کردن حدسی ALG، بازکردن همه پورت‌ها و کنارگذاشتن فایروال، نتیجه شناخت این مفهوم نیست. محدوده پورت و روش عبور باید از تنظیم واقعی مرکز و مشخصات سرویس گرفته شود؛ بازبودن یک پورت سیگنال، مجوز یا دسترسی کل جریان رسانه را ثابت نمی‌کند.

گوشی رجیستر است ولی تماس نمی‌رسد؟ ثبت موفق را از مسیر تماس ورودی جدا کنید. تماس پاسخ می‌گیرد ولی یک طرف صدا ندارد؟ علاوه بر ابزار صوتی، مسیر رسانه همان جهت مطرح است. تماس پس از چند ثانیه پایان می‌یابد؟ پیام‌های کنترل و زمان‌سنج‌ها نیز باید دیده شوند. هیچ‌کدام از این نشانه‌ها به‌تنهایی علت قطعی را مشخص نمی‌کنند.

برای اقدام متناسب با نشانه، راهنمای نرسیدن تماس ورودی، صدای یک‌طرفه یا قطع تماس پس از چند ثانیه را بخوانید. اگر سیستم فعال شرکت نیاز به رسیدگی دارد، خدمات رفع اختلال ویپ مسیر درخواست کمک است.