QoS برای VoIP زمانی مؤثر است که بستهٔ صوت درست شناسایی شود، در محل ازدحام به صف مناسب برسد و نتیجه زیر بار کنترل‌شده سنجیده شود. نوشتن DSCP روی بسته، به‌تنهایی کیفیت تماس را تضمین نمی‌کند. اگر صدا هنگام انتقال فایل یا پشتیبان‌گیری تکه‌تکه می‌شود، ابتدا محل رقابت بر سر ظرفیت را پیدا کنید؛ سپس سیاست صف و ظرفیت تماس را با شواهد ارزیابی کنید.
این راهنما برای طراحی و پذیرش تغییر در شبکهٔ سازمانی است. بخش Asterisk به مستندات نسخهٔ ۲۲ و درایور PJSIP متکی است؛ دستورات اختصاصی روتر ارائه نمی‌شود، چون نحو و قابلیت‌ها به سازنده و نسخه وابسته‌اند. هیچ آزمون بار یا تغییری نباید بدون برنامهٔ نگهداری و راه بازگشت روی شبکهٔ فعال انجام شود.
۱. ابتدا مسئلهٔ کیفیت را از مسئلهٔ مسیر جدا کنید
سناریو را به یک جملهٔ قابل‌آزمون تبدیل کنید: «در تماس شعبه با دفتر مرکزی، هنگام ارسال فایل از شعبه، صدای دریافتی دفتر قطع‌و‌وصل می‌شود». زمان، جهت صدا، نوع اتصال و فعالیت هم‌زمان را بنویسید. این ثبت ساده کمک می‌کند تغییرات پراکنده به نتیجهٔ ظاهراً خوب نسبت داده نشوند. تماس داخلی سالم و تماس بیرونی نامناسب، نقطهٔ شروع بررسی را تغییر می‌دهد؛ اما به‌تنهایی علت را ثابت نمی‌کند.
اگر صدا از ابتدای تماس در یک جهت کاملاً غایب است، پیش از دست‌کاری صف‌ها از راهنمای بررسی SDP و مسیر RTP استفاده کنید. اگر تماس اصلاً به مقصد نمی‌رسد، مسئلهٔ شما ممکن است به شناسایی ترانک و مسیر ورودی مربوط باشد. QoS جایگزین تشخیص مسیر، مجوز یا مقصد تماس نیست.
برای این مقاله، فرض آموزشی ما تماس برقرارشونده‌ای است که کیفیت آن با افزایش بار افت می‌کند. این فرض باید در محیط شما تأیید شود. هم‌بستگی با زمان بک‌آپ، شاهد اولیه است؛ برای انتساب علت، شمارندهٔ صف و مشاهدهٔ جریان را نیز لازم دارید.
۲. DSCP چه می‌گوید و چه چیزی را اثبات نمی‌کند؟
DSCP کدی شش‌بیتی در سرآیند IP است که برای انتخاب رفتار عبور بسته در شبکه استفاده می‌شود؛ نگاشت کد به رفتار، بخشی از سیاست هر دامنهٔ شبکه است. این تعریف در RFC 2474 آمده است. بنابراین دیدن علامت درست در خروجی تلفن، اثبات نمی‌کند روتر بعدی همان اولویت را اعمال کرده است.
راهنمای RFC 4594 برای رسانهٔ تلفنی کلاس EF و برای سیگنالینگ کلاس CS5 را پیشنهاد می‌کند و بر مهندسی ظرفیت و کنترل پذیرش تماس تأکید دارد. این پیشنهاد باید با سیاست شبکه و قرارداد اپراتور تطبیق داده شود؛ همهٔ تجهیزات و سرویس‌ها الزاماً همین نگاشت را ندارند.
| ترافیک | نمونهٔ علامت | شاهد لازم |
|---|---|---|
| رسانهٔ صوتی RTP | EF = 46 | علامت در بسته و افزایش شمارندهٔ کلاس صوت |
| سیگنالینگ تماس | CS5 = 40 | طبقه‌بندی مستقل و تطبیق با سیاست توافق‌شده |
| ترافیک عمومی | CS0 = 0 | حفظ سرویس داده و نبود ورود اشتباه به صف صوت |
مقادیر عددی جدول از ثبت رسمی IANA گرفته شده‌اند. عدد DSCP را با مقدار کامل بایت ToS یکی نگیرید؛ هنگام استفاده از رابط عددی، تعریف همان فیلد را در مستندات محصول بخوانید. در این راهنما نام نمادین EF به عدد خام ترجیح داده شده تا ابهام کمتر شود.
طبق تعریف EF در RFC 3246، رفتار موردنظر به سرویس‌دادن جریان تجمیعی با نرخ تنظیم‌شده وابسته است. برای پذیرش عملی، سه پرسش جدا بنویسید: چه چیزی علامت می‌خورد، کجا صف‌بندی می‌شود و ظرفیت آن صف چگونه تعیین شده است؟ پاسخ «QoS روشن است» برای هیچ‌کدام کافی نیست.
۳. گلوگاه و مرز اعتماد را روی نقشه مشخص کنید
مسیر واقعی رسانه را رسم کنید: تلفن، سوئیچ دسترسی، روتر شعبه، ارتباط بیرونی و مقصد رسانه. فرض نکنید همهٔ صدا از مرکز تلفن عبور می‌کند. محل صف مؤثر همان جایی است که رقابت بر سر خروجی رخ می‌دهد؛ روی نقشه، هر دو جهت ارتباط را جدا علامت بزنید. این کار را پیش از انتخاب هر فرمان پیکربندی انجام دهید.
یک مرز اعتماد تعریف کنید: علامت دستگاه‌های مدیریت‌شده را در چه نقطه‌ای می‌پذیرید و ترافیک دستگاه‌های عمومی را چگونه بازطبقه‌بندی می‌کنید؟ پذیرفتن بی‌قید علامت همهٔ کاربران، اعتبار صف صوت را از بین می‌برد. قواعد را با هویت شبکه، مسیر و نوع سرویس تطبیق دهید؛ اختصاص اولویت به کل ترافیک یک سرور می‌تواند انتقال فایل همان سرور را هم وارد کلاس صوت کند.
برای خروجی WAN، سرعت فیزیکی پورت را با ظرفیت سرویس خریداری‌شده یکی نگیرید. اگر ازدحام در تجهیز بالادست رخ دهد، صف محلی ممکن است فرصت مدیریت آن را نداشته باشد. امکان شکل‌دهی ترافیک پیش از آن نقطه را با مستندات تجهیز و اپراتور بررسی کنید؛ نرخ آماده و همگانی پیشنهاد نمی‌شود. تونل، وای‌فای و شبکهٔ اپراتور نیز باید مرزهای جدا در طرح پذیرش داشته باشند.
۴. در Asterisk 22 علامت رسانه را از سیگنالینگ جدا ببینید
در مستندات ماژول res_pjsip نسخهٔ ۲۲، گزینهٔ tos_audio متعلق به endpoint است و مقدار پیش‌فرض آن صفر است. گزینهٔ tos در transport به سیگنالینگ مربوط می‌شود. این دو محل تنظیم را با یکدیگر یا با گزینه‌های درایور قدیمی chan_sip مخلوط نکنید.
; Illustration only: add to the existing endpoint definition
; Not a complete pjsip.conf file
[voice-endpoint-example]
type=endpoint
tos_audio=efاین قطعه فقط مفهوم گزینه را نشان می‌دهد؛ endpoint کامل، اطلاعات اتصال و تنظیمات امنیتی در آن وجود ندارد. آن را به‌عنوان فایل آماده جایگزین پیکربندی نکنید. در سیستم‌های دارای رابط مدیریتی، ابتدا سازوکار تولید فایل و محل override پشتیبانی‌شده را مشخص کنید؛ ویرایش مستقیم فایل تولیدشده ممکن است با ذخیرهٔ بعدی رابط از بین برود.
راهنمای رسمی QoS در Asterisk نام نمادین ef را می‌پذیرد و هشدار می‌دهد تغییرات transport با reload ساده اعمال نمی‌شوند و به restart نیاز دارند. به همین دلیل، برای بررسی کیفیت یک تماس، transport تولید را آزمایشی تغییر ندهید. ابتدا baseline و نسخهٔ پشتیبان بگیرید؛ اعمال تغییر فقط با برنامهٔ مجاز نگهداری انجام شود. CoS لایهٔ دوم نیز با DSCP یکسان نیست و به نگاشت سیستم‌عامل و تجهیزات وابسته است.
۵. آزمون پذیرش را قبل از تغییر بنویسید
پیشنهاد اجرایی ما یک مقایسهٔ کوچک و تکرارپذیر است. تماس آزمایشی و مسیرش را ثابت نگه دارید، یک بازهٔ بدون بار ثبت کنید و سپس بار مجاز و محدود را در محیط آزمایش یا پنجرهٔ نگهداری اضافه کنید. زمان آغاز و پایان هر مرحله و محل مشاهده را بنویسید. ترافیک اشباع‌کننده را بدون هماهنگی روی شبکهٔ تولید اجرا نکنید.
- پیش از تغییر، تنظیم مرتبط، شمارنده‌های صف و وضعیت تماس را ذخیره کنید؛ تفاوت شمارنده‌ها در هر بازه مهم‌تر از مجموع قدیمی است.
- برای همان جریان، علامت بسته را نزدیک مبدأ و در مرز خروجی بررسی کنید؛ دامنهٔ جمع‌آوری را محدود و دادهٔ تماس را محرمانه نگه دارید.
- بررسی کنید شمارندهٔ کلاس صوت با تماس رشد می‌کند و انتقال فایل وارد آن کلاس نمی‌شود.
- دو جهت ارتباط را جدا بسنجید و کیفیت شنیداری را کنار شواهد فنی ثبت کنید.
- پس از تغییر مجاز، همان سناریو و مدت آزمون را تکرار و اثر روی سرویس داده را نیز بررسی کنید.
RFC 3550 برای RTCP گزارش اتلاف بسته و برآورد نوسان زمان رسیدن را تعریف می‌کند؛ خود RTP تضمین QoS یا رزرو منبع نمی‌دهد. jitter گزارش‌شده را با تأخیر یک‌طرفه یکی نگیرید و واحد آن را در ابزار بررسی کنید. برای این مقاله آستانهٔ عددی همگانی یا امتیاز کیفیت ساختگی تعیین نشده است؛ معیار پذیرش را با نیاز سرویس و روش اندازه‌گیری توافق کنید.
۶. اگر نتیجه بهتر نشد، کدام فرضیه را بررسی کنیم؟
| مشاهده | فرضیهٔ قابل‌بررسی | اقدام تشخیصی بعد |
|---|---|---|
| EF در مبدأ هست، شمارندهٔ صف صوت ثابت است | نگاشت کلاس یا محل مشاهده نادرست است | ورودی policy و مسیر واقعی رسانه را تطبیق دهید |
| صف صوت شمارش دارد، اتلاف زیر بار ادامه دارد | ظرفیت کلاس یا گلوگاه دیگری محدود است | شمارندهٔ drop و ظرفیت هر مرز را مقایسه کنید |
| فقط یک جهت خراب است | مسیر یا سیاست دو جهت متفاوت است | خروجی سمت مقابل و مرز اپراتور را جدا بررسی کنید |
| بدون بار هم مشکل وجود دارد | ازدحام تنها علت نیست | مسیر رسانه، لینک دسترسی و منابع پردازشی را بررسی کنید |
این جدول تشخیص قطعی نیست؛ هر ردیف یک فرضیه و شاهد لازم برای آزمودن آن است. خطای رایج، افزایش نامحدود اولویت صوت یا علامت‌گذاری همهٔ UDPها به‌عنوان EF است. خطای دیگر، پذیرش یک تماس خوب به‌عنوان نتیجهٔ نهایی و نادیده‌گرفتن تکرارپذیری است. اگر معیار توافق‌شده بدتر شد، مطابق برنامهٔ بازگشت به baseline برگردید و دادهٔ مقایسه را حفظ کنید.
۷. خروجی قابل‌تحویل یک پروژهٔ QoS چیست؟
تحویل مناسب شامل نقشهٔ مسیر رسانه، سیاست طبقه‌بندی، مرز اعتماد، ظرفیت و رفتار صف‌ها، گزارش آزمون دوطرفه و روش بازگشت است. محدودیت خارج از کنترل سازمان، مانند رفتار شبکهٔ عمومی، باید روشن ثبت شود. این مدارک کمک می‌کنند هنگام افزایش تماس هم‌زمان، نیاز به ظرفیت تازه از تغییر علامت‌گذاری تفکیک شود.
برای شروع، فقط یک مسیر مسئله‌دار انتخاب کنید و شواهد پیش و پس از تغییر را کنار هم بگذارید. اگر برای طراحی سیاست یا تدوین آزمون پذیرش به همراهی نیاز دارید، از صفحهٔ تماس آسیاپرداز اقدام کنید؛ نقشهٔ پاک‌سازی‌شده و سناریوی رخداد مفید است و نیازی به ارسال رمز، فایل ضبط مکالمه یا پیکربندی محرمانه نیست.