جیتر (jitter) اصطلاحی در ویپ میباشد که برای توصیف مدت زمان رسیدن Packet ها از مبداء به مقصد از طریق یک شبکه استفاده میشود. در شبکه های Packet Switch به تغییرات در این تاخیرها شناخته میشود. که عموما توسط ازدحام (Congestion) در شبکه ip اتفاق می افتد و میتواند مشکلات جدی را برای ترافیک های Real-Time و دو طرفه همانند voip ایجاد کند. این مقاله درباره چگونگی اندازه گرفتن جیتر توسط اپلیکیشن PathView میباشد و همچنین چگونگی استفاده از آن برای ارزیابی میزان آمادگی یک شبکه برای ترافیک Voip مورد بحث قرار میگیرد.
چرا Jitter مشکل ایجاد میکند؟
شرایط زیر را در نظر بگیرید :
مثلا امروز بعداز ظهر روز جمعه است و تلفن زنگ میخورد و یک از بزرگترین مشتری های شما پشت خط است متاسفانه شما در شرکت تان هستید که اخیرا تصمیم گرفتید تا شبکه Voip تان را با شبکه کلی شرکت تان ادغام کنید. صدای مشتری شما بریده بریده میآید و کاملا متوجه نمیشوید در حقیقت چه چیزی گفته و تنها کلمات زیر را میشنوید : "پشتیبانی ... مشکل ... پاسخگو نبودن ... آیا میشود هماهنگ کنید؟" و بعد از یکسری صداهای کاملا نامفهوم دیگر تماس قطع میشود.
آنچه که دقیقا مشتری گفته به این قرار است "من این هفته با تیم پشتیبانی شما مذاکرات خیلی خوبی داشتم، سه روز مشکل داشتیم و آنها روی آن متمرکز شدند البته شرکت های دیگر پاسخگو نبودند و یا حتی تلاش برای رفع مشکل نمیکردند به همین خاطر ما مشتاقیم که همکاری مان را با شما ادامه بدیم میخواستم با مسئول فنی شما صحبت کنم که گویا در تعطیلات است، آیا میتوانید هماهنگ کنید؟"
صدای آنها تحریف شده و شما کاملا متوجه آن نشدید سیستم تلفن کلمات رو حذف میکند و همین مسئله به اندازه کافی میتواند برای شما وحشت ایجاد کند زمانی که سفارش میلیون دلاری شما به خاطر این قضیه از بین برود.
چگونه PathView جیتر را اندازه گیری میکند؟
خوشبختانه کیفیت ضعیف میتواند با استفاده از جیتر محاسبه شود. برای ترافیک Data نرم افزار PathView با استفاده از تشخیص میانگین تغییر تاخیرات packet و با استفاده از میانگین RTT و حداقل RTT از یک انبوه پکت های دیتا جیتر را اندازه گیری میکند.
برای ترافیک voice (به طور مثال ویپ) pathview به یکی از دو حالت (single ended یا dual ended) جیتر را اندازه گیری میکند.
عملا این متد بستگی به این دارد که آیا pathview تنها کنترل یکی از end point ها (مثلا ip phone) را در دسترس دارد. (حالت single ended) یا میتواند هر دو طرف را به صورت همزمان (dual ended اندازه گیری کند).
برای یک مسیر single ended در حقیقت jitter به واسطه تشخیص میانگین تغییر تاخیرات packet و با استفاده از میانگین RTT و حداقل RTT از یک سری پکت های voice محاسبه میشود.
برای یک مسیر dual ended در حقیقت جیتر به واسطه میانگین تغییرات تاخیر آنی packet (تفاوت بین پکت های متوالی) محاسبه میشود. جیتر متوالی در حقیقت تفاوت بین فاصله های ارسال و دریافت یک پکت هست.
ارزیابی آمادگی یک شبکه برای Voip :
اندازه گیری jitter واقعی بسیار مفید است اما چگونه باید آن را به کیفیت voip مربوط کرد؟ اندازه گیری تاخیر متوالی بسیار ارزشمند است اما مهمتر از آن این است که ما بدانیم آیا یک شبکه توانایی کنترل ترافیک voice را دارد. بهترین راه برای تست قضیه Load Test میباشد. به صورت خاص روی ترافیک voice در SIP یا H323 در pathview خواهیم پرداخت. تعدادی از کدک های رایج صدا نیز پشتیبانی میشوند. (مانند G711 و G729)
ابتدا با تخمین زدن jitter شروع میکنیم. ابزار TC در کرنل لینوکس میتواند مورد استفاده قرار گیرد.
دستور بالا اینترفیس را با یک تاخیر 10 میلی ثانیه ای و +-20 میلی ثانیه تاخیر متغییر کانفیگ میکند. ما از یک تاخیر Normal استفاده میکنیم زیر تاخیر شبکه نسبتا نامتعادل هست. همچنین pfifo queue برای جلوگیری از درخواست دوباره پکت استفاده میشود.
ما برای تست از کدک G711 برای یک تماس 5 دقیقه ای استفاده میکنیم. چارت های زیر نتایج زیر را نمایش میدهد :
رنج جیتر voice از 13.9 میلی ثانیه تا 19 میلی ثانیه میباشد (همانطور که انتظار میرود).
یکسری پکت ها حذف میشوند.
پکت ها دوباره درخواست نمیشوند.
رنج MOS صدا بین 3.4 تا 4.4 (Maximum) میباشد. مهم نیست اگر MOS هر از چندگاهی تغییر کند. میزان MOS 4.4 برای کدک G711 بسیار عالی است و میزان 3.4 بین متوسط (نسبتا آزار دهنده) و خوب (محسوس اما آزار دهنده) میباشد.
کاملا مشخص است که جیتر میتواند اثر چشم گیر روی آمادگی یک شبکه برای ترافیک voip داشته باشد.
تصویر 1 : نمایش Voice Test Summary
تصویر 2 : جیتر voice و حذف شدن packet ها
تصویر 3 : باز درخواست پکت صدا و MOS
کم کردن Jitter :
تکنیک های شناخته شده ای که میتواند اثرات جیتر را کاهش دهند عبارتند از :
jitter buffre به منظور حذف اثرات jitter استفاده میشوند به طوری که زمان رسیدن پکت های ناهمزمان را به یک جریان همزمان تغییر میدهد. جیتر بافر بین تاخیر و احتمال ارسال تیکه تیکه پکت (به علت پکت های با تاخیر (دور انداخته شده)) آنالیز میکند.
QOS راهی برای مارک کردن پکت هاست به طوری که پکت های Real Time مانند ترافیک voice اولویت بالاتری نسبت به سایر پکت ها (مانند ترافیک HTTP یا دانلود فایل) دریافت میکنند. خصوصا ترافیک voice باید به ازای هر RFC 3246 به DSCP EF مارک شوند. سیگنالینگ ترافیک voice باید به DSCP CS3 یا DSCP AF31 مارک بشوند.
نرم افزار pathview voice امکان کانفیگ کردن سایز jitter buffer و همچنین QOS codes را برای ترافیک voice و سیگنالینگ فراهم آورده است.
چرا Jitter مشکل ایجاد میکند؟
شرایط زیر را در نظر بگیرید :
مثلا امروز بعداز ظهر روز جمعه است و تلفن زنگ میخورد و یک از بزرگترین مشتری های شما پشت خط است متاسفانه شما در شرکت تان هستید که اخیرا تصمیم گرفتید تا شبکه Voip تان را با شبکه کلی شرکت تان ادغام کنید. صدای مشتری شما بریده بریده میآید و کاملا متوجه نمیشوید در حقیقت چه چیزی گفته و تنها کلمات زیر را میشنوید : "پشتیبانی ... مشکل ... پاسخگو نبودن ... آیا میشود هماهنگ کنید؟" و بعد از یکسری صداهای کاملا نامفهوم دیگر تماس قطع میشود.
آنچه که دقیقا مشتری گفته به این قرار است "من این هفته با تیم پشتیبانی شما مذاکرات خیلی خوبی داشتم، سه روز مشکل داشتیم و آنها روی آن متمرکز شدند البته شرکت های دیگر پاسخگو نبودند و یا حتی تلاش برای رفع مشکل نمیکردند به همین خاطر ما مشتاقیم که همکاری مان را با شما ادامه بدیم میخواستم با مسئول فنی شما صحبت کنم که گویا در تعطیلات است، آیا میتوانید هماهنگ کنید؟"
صدای آنها تحریف شده و شما کاملا متوجه آن نشدید سیستم تلفن کلمات رو حذف میکند و همین مسئله به اندازه کافی میتواند برای شما وحشت ایجاد کند زمانی که سفارش میلیون دلاری شما به خاطر این قضیه از بین برود.
چگونه PathView جیتر را اندازه گیری میکند؟
خوشبختانه کیفیت ضعیف میتواند با استفاده از جیتر محاسبه شود. برای ترافیک Data نرم افزار PathView با استفاده از تشخیص میانگین تغییر تاخیرات packet و با استفاده از میانگین RTT و حداقل RTT از یک انبوه پکت های دیتا جیتر را اندازه گیری میکند.
برای ترافیک voice (به طور مثال ویپ) pathview به یکی از دو حالت (single ended یا dual ended) جیتر را اندازه گیری میکند.
عملا این متد بستگی به این دارد که آیا pathview تنها کنترل یکی از end point ها (مثلا ip phone) را در دسترس دارد. (حالت single ended) یا میتواند هر دو طرف را به صورت همزمان (dual ended اندازه گیری کند).
برای یک مسیر single ended در حقیقت jitter به واسطه تشخیص میانگین تغییر تاخیرات packet و با استفاده از میانگین RTT و حداقل RTT از یک سری پکت های voice محاسبه میشود.
برای یک مسیر dual ended در حقیقت جیتر به واسطه میانگین تغییرات تاخیر آنی packet (تفاوت بین پکت های متوالی) محاسبه میشود. جیتر متوالی در حقیقت تفاوت بین فاصله های ارسال و دریافت یک پکت هست.
ارزیابی آمادگی یک شبکه برای Voip :
اندازه گیری jitter واقعی بسیار مفید است اما چگونه باید آن را به کیفیت voip مربوط کرد؟ اندازه گیری تاخیر متوالی بسیار ارزشمند است اما مهمتر از آن این است که ما بدانیم آیا یک شبکه توانایی کنترل ترافیک voice را دارد. بهترین راه برای تست قضیه Load Test میباشد. به صورت خاص روی ترافیک voice در SIP یا H323 در pathview خواهیم پرداخت. تعدادی از کدک های رایج صدا نیز پشتیبانی میشوند. (مانند G711 و G729)
ابتدا با تخمین زدن jitter شروع میکنیم. ابزار TC در کرنل لینوکس میتواند مورد استفاده قرار گیرد.
کد PHP:
# tc qdisc add dev eth2 root handle 1: netem delay 10ms 20ms distribution normal
# tc qdisc add dev eth2 parent 1:1 pfifo
ما برای تست از کدک G711 برای یک تماس 5 دقیقه ای استفاده میکنیم. چارت های زیر نتایج زیر را نمایش میدهد :
رنج جیتر voice از 13.9 میلی ثانیه تا 19 میلی ثانیه میباشد (همانطور که انتظار میرود).
یکسری پکت ها حذف میشوند.
پکت ها دوباره درخواست نمیشوند.
رنج MOS صدا بین 3.4 تا 4.4 (Maximum) میباشد. مهم نیست اگر MOS هر از چندگاهی تغییر کند. میزان MOS 4.4 برای کدک G711 بسیار عالی است و میزان 3.4 بین متوسط (نسبتا آزار دهنده) و خوب (محسوس اما آزار دهنده) میباشد.
کاملا مشخص است که جیتر میتواند اثر چشم گیر روی آمادگی یک شبکه برای ترافیک voip داشته باشد.
تصویر 1 : نمایش Voice Test Summary
تصویر 2 : جیتر voice و حذف شدن packet ها
تصویر 3 : باز درخواست پکت صدا و MOS
کم کردن Jitter :
تکنیک های شناخته شده ای که میتواند اثرات جیتر را کاهش دهند عبارتند از :
- Jitter Buffre
- QOS
jitter buffre به منظور حذف اثرات jitter استفاده میشوند به طوری که زمان رسیدن پکت های ناهمزمان را به یک جریان همزمان تغییر میدهد. جیتر بافر بین تاخیر و احتمال ارسال تیکه تیکه پکت (به علت پکت های با تاخیر (دور انداخته شده)) آنالیز میکند.
QOS راهی برای مارک کردن پکت هاست به طوری که پکت های Real Time مانند ترافیک voice اولویت بالاتری نسبت به سایر پکت ها (مانند ترافیک HTTP یا دانلود فایل) دریافت میکنند. خصوصا ترافیک voice باید به ازای هر RFC 3246 به DSCP EF مارک شوند. سیگنالینگ ترافیک voice باید به DSCP CS3 یا DSCP AF31 مارک بشوند.
نرم افزار pathview voice امکان کانفیگ کردن سایز jitter buffer و همچنین QOS codes را برای ترافیک voice و سیگنالینگ فراهم آورده است.