بررسی کیفیت تماس ویپ با تأخیر، Jitter و Packet Loss

مبنای مراحل تحلیل، Wireshark 4.4.0 و راهنمای رسمی همان برچسب است. بخش آزمون مصنوعی از گزینه‌های iperf3 نسخه 3.16 روی Linux استفاده می‌کند. این‌ها مبنای مستندند، نه توصیه نصب نسخه قدیمی؛ ابزار نصب‌شده و تفاوت گزینه‌ها را ثبت کنید. تماس آزمایشی باید بین دو دستگاه و حساب تحت اختیار شما و بدون محتوای واقعی مشتری باشد.

نام دو نقطه، اتصال کابلی یا Wi‑Fi، مسیر LAN/WAN/VPN، ساعت، کدک مذاکره‌شده و مدت نمونه را یادداشت کنید. برای شروع می‌توانید یک مکالمه کوتاه با جمله‌های مشخص در هر دو جهت اجرا کنید؛ مدت آن باید برای بازتولید نشانه کافی باشد. سپس همان شرایط را در زمان اختلال معمول تکرار کنید. برای ساختن «ساعت شلوغ»، روی شبکه عملیاتی بار نامحدود تولید نکنید.

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

• روی یکی از پایانه‌های آزمایشی یا پورت Mirror مجازِ مسیر رسانه Capture بگیرید. در شبکه سوئیچ‌شده، شنود از یک لپ‌تاپ معمولی ترافیک همه گوشی‌ها را نشان نمی‌دهد.
• رابط شبکه درست را در Wireshark انتخاب کنید. اگر روی VPN تماس می‌گیرید، رابط فیزیکی ممکن است فقط بسته‌های رمز‌شده تونل را ببیند؛ نقطه مشاهده و حدود دسترسی را مشخص کنید.
• Capture را پیش از شماره‌گیری شروع و پس از پایان تماس متوقف کنید تا پیام‌های برقراری تماس و SDP هم در صورت قابل مشاهده بودن ثبت شوند. زمان جمله بریده یا سکوت را یادداشت کنید.
• فایل را با شناسه آزمون و زمان نگه دارید و دسترسی آن را محدود کنید. Capture ممکن است شماره، اطلاعات احراز هویت یا صوت قابل بازسازی داشته باشد؛ آن را عمومی منتشر نکنید.

برای محدودکردن Capture، فیلتر نمونه host 192.168.50.31 فقط ترافیکِ مرتبط با همان IP آزمایشی را می‌گیرد؛ IP را با پایانه واقعی عوض کنید. Capture filter با Display filter یکی نیست. برای دیدن بسته‌های شناخته‌شده پس از ثبت می‌توانید از نمایش sip || rtp || rtcp استفاده کنید؛ این فیلتر، بسته‌ای را که ابتدا ضبط نشده برنمی‌گرداند.

اگر Direct Media فعال باشد، صوت ممکن است مستقیم بین پایانه‌ها برود و Capture روی PBX آن را نبیند. خالی‌بودن RTP در این نقطه، نبود صوت روی کل مسیر را ثابت نمی‌کند. برای SIP روی TLS و رسانه SRTP نیز قابلیت مشاهده متفاوت است؛ رمزنگاری تماس واقعی را برای آسان‌شدن تحلیل خاموش نکنید.

Wireshark معمولاً با دیدن برقراری تماس و SDP می‌تواند RTP را تشخیص دهد. اگر UDP دیده می‌شود ولی RTP شناخته نشده، آدرس و پورت مذاکره‌شده را بررسی کنید و فقط همان جریان معلوم را با Decode As به RTP نسبت دهید. نسبت‌دادن همه UDPها به RTP یا فعال‌کردن تشخیص حدسی بدون بررسی می‌تواند نتیجه غلط بسازد.

در Telephony → RTP → RTP Streams جریان تماس را با آدرس‌ها، پورت، زمان و SSRC پیدا کنید. Find Reverse برای یافتن جهت مقابل کمک می‌کند؛ سپس Analyze را باز کنید. اگر جهت مقابل پیدا نشد، پوشش Capture و مسیر نامتقارن را بررسی کنید. هر جریان باید با شناسه و جهت خودش در گزارش ثبت شود.

آمار را برای هر دو جهت کپی یا خروجی CSV بگیرید و فایل اصلی را حفظ کنید. دو Capture را فقط وقتی مقایسه کنید که جهت، کدک، زمان‌بندی بسته و نقطه مشاهده روشن باشد. عدد loss کلِ کم ممکن است چند بسته متوالیِ گم‌شده و مکث شنیداری داشته باشد؛ تنها میانگین کافی نیست.

برای برآورد تأخیر یک‌طرفه، روش و هم‌زمانی ساعتِ دو نقطه یا ابزار مناسبِ اندازه‌گیری باید مشخص باشد. RTT رفت‌وبرگشت است و نصف‌کردن آن در مسیر نامتقارن، اندازه‌گیری معتبر یک‌طرفه نمی‌سازد. در RTP، timestamp ساعت رسانه است؛ اختلاف ساده آن با ساعت دیواریِ Capture را تأخیر دهان تا گوش اعلام نکنید. زمان کدگذاری، بسته‌بندی، بافر و پخش نیز در تجربه کاربر سهم دارند.

این بخش اختیاری است و دو میزبان Linux مجاز در دو سوی مسیر می‌خواهد؛ iperf3 را صرفاً برای این آزمایش روی مرکز تلفن فعال نصب نکنید. سرور نمونه 192.168.60.20 است و باید از کلاینت قابل دسترسی باشد. نسخه هر دو سمت را با iperf3 --version ثبت کنید. برای مدت آزمون فقط TCP کنترل و UDP آزمونِ پورت 5201 را بین همین دو میزبان در فایروال مجاز کنید؛ سرویس عمومی اینترنتی نسازید.

iperf3 -s -B 192.168.60.20 -p 5201 -1

iperf3 -c 192.168.60.20 -p 5201 -u -b 128K -l 160 -t 20 --get-server-output

در این نمونه -u ترافیک UDP، -b نرخ هدف 128 کیلوبیت بر ثانیه و -l طول بافر ارسال 160 بایت را تعیین می‌کند. عددها انتخاب همین تمرین‌اند؛ نه محاسبه پهنای باند هر تماس و نه توصیه برای همه لینک‌ها. خروجی سمت گیرنده را برای داده دریافت‌شده، Jitter و افت بررسی و با جهت ارسال ثبت کنید. موفقیت TCP کنترل، عبور UDP را ثابت نمی‌کند.

iperf3 -c 192.168.60.20 -p 5201 -u -b 128K -l 160 -t 20 -R --get-server-output

دو جهت پشت سر هم آزموده می‌شوند، نه هم‌زمان. این بسته‌ها SIP/RTP و تماس واقعی نیستند؛ ابزار، کدک، jitter buffer و پاسخ انسان را نمی‌سنجد. ترافیک آزمون ممکن است علامت‌گذاری و صف متفاوتی از ویپ داشته باشد. پس از پایان، سرویس و مجوز موقت را جمع کنید. گزینه نرخ نامحدود یا چند جریان موازی را برای تشخیص اولیه شبکه فعال جایگزین این نمونه نکنید.

مرز قبولی را از نیاز مکالمه، مشخصات پایانه و کدک، سیاست شبکه و نمونه واقعی همان مسیر تعیین کنید. اعداد مشهور مانند 150 میلی‌ثانیه، 30 میلی‌ثانیه و 1 درصد به‌تنهایی گواهی سلامت همه تماس‌ها نیستند. اختلاف روش اندازه‌گیری و افت خوشه‌ای می‌تواند با میانگین ظاهراً مناسب همراه باشد. برای یک نمونه محدود، نبود افت توضیح‌داده‌نشده و شنیدن سالم دو جهت معیار مفیدی است، اما پایداری کل روز را ثابت نمی‌کند.

اگر اختلال فقط با پرشدن لینک رخ می‌دهد، صف خروجیِ نقطه گلوگاه، Drop و شناسایی ترافیک صوت را بررسی کنید. QoS باید در مسیر مؤثر اعمال شود و ظرفیت تازه ایجاد نمی‌کند؛ برچسب‌زدن DSCP روی گوشی بدون بررسی صف‌های بعدی، درمان تأییدشده نیست. اگر فقط Wi‑Fi مشکل دارد، مقایسه کنترل‌شده با کابل کمک می‌کند. هر بار یک متغیر را عوض کنید و همان آزمون را تکرار کنید.

تغییر کدک، خاموش‌کردن SIP ALG یا بازکردن گسترده پورت‌ها را پاسخ خودکار به هر عدد نامناسب ندانید. اگر مشکل در داخلی خارج از دفتر است، مسیر VPN و رسانه نیز باید بررسی شود. گزارش نهایی باید یافته واقعی و کار بعدی را بگوید؛ در این راهنما هیچ Capture، نمودار، تماس یا نتیجه iperf اجراشده ارائه نشده است.