چرا کیفیت صدای تلفن Cisco پایین است؟ رفع Jitter، Packet Loss و مشکلات QoS

مزیت تلفن‌های Cisco این است که برای این مشکل لازم نیست فقط به احساس کاربر تکیه کنیم. خود IP Phone می‌تواند آمار RTP، Jitter، Packet Loss، Codec، Delay و در بسیاری از مدل‌ها MOS را نشان دهد. بعد می‌توانیم همان تماس را روی سوئیچ، WAN و PBX دنبال کنیم و مشخص کنیم خرابی دقیقاً در کدام قسمت مسیر اتفاق می‌افتد.

در این آموزش ابتدا از خود تلفن Cisco عدد می‌گیریم، سپس DSCP و QoS را بررسی می‌کنیم، Queueهای سوئیچ را می‌بینیم و در نهایت WAN Latency، Codec و Packet Capture را کنار هم قرار می‌دهیم تا علت کیفیت بد صدا بدون حدس مشخص شود.

صدای بد Cisco معمولاً چه شکلی دارد؟

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

Jitter، Packet Loss و Latency دقیقاً چه هستند؟

Latency مدت زمانی است که صدا از یک سمت شبکه به سمت دیگر می‌رسد. اگر Latency زیاد شود، دو نفر صدای هم را دیر می‌شنوند و مکالمه حالت تماس ماهواره‌ای پیدا می‌کند.

Jitter تغییرپذیری Delay بین Packetهای RTP است. فرض کنید Packetهای صوتی باید تقریباً هر ۲۰ میلی‌ثانیه برسند؛ اگر یکی بعد از ۲۰ms، بعدی بعد از ۵۵ms و بعدی بعد از ۱۸ms برسد، جریان صدا نامنظم شده است.

Packet Loss یعنی بعضی RTP Packetها اصلاً به مقصد نمی‌رسند. چون RTP مانند TCP منتظر Retransmission نمی‌ماند، Packet صوتی از دست‌رفته معمولاً دیگر برنمی‌گردد.

اعداد مناسب برای VoIP چقدر هستند؟

Cisco در طراحی QoS خود برای Voice Bearer Traffic این هدف‌ها را ارائه می‌کند:

این اعداد «مرز جادویی» نیستند. ممکن است تماس با Loss کمتر از یک درصد نیز به دلیل Burst Loss بد شنیده شود، یا Latency شبکه پایین باشد اما Jitter لحظه‌ای کیفیت را خراب کند. به همین دلیل باید چند Metric را کنار هم ببینیم.

مرحله اول: آمار تماس را مستقیم از Cisco Phone بخوانید

در Cisco MPP سری 8800، برای آخرین Voice Stream می‌توانید وارد این مسیر شوید:

Applications → Status → Phone Status → Call Statistics

در این صفحه مواردی مثل Receiver Codec، Sender Codec، Avg Jitter، Max Jitter، Receiver Discarded، Rcvr Lost Packets و Latency قابل مشاهده‌اند.

نکته مهم این است که Cisco آمار را برای Voice Stream نگه می‌دارد، نه الزاماً کل تماس. اگر تماس Hold شود، Stream فعلی متوقف و بعد از Resume یک Stream جدید ایجاد می‌شود؛ بنابراین آمار جدید می‌تواند اطلاعات Stream قبلی را جایگزین کند.

کدام فیلدهای Call Statistics مهم‌تر هستند؟

Lost Packet با Discarded Packet یکی نیست

این تفاوت در عیب‌یابی بسیار مهم است.

Lost Packet اصلاً به تلفن نرسیده است.

Discarded Packet ممکن است به تلفن رسیده باشد، اما آن‌قدر دیر رسیده که از پنجره Jitter Buffer گذشته و دیگر برای پخش صدا قابل استفاده نبوده است.

بنابراین اگر Lost Packet تقریباً صفر است ولی Discarded Packet بالا می‌رود، ممکن است Network Loss نداشته باشید اما Jitter یا Delay Variation زیاد باشد.

Concealment چیست؟

وقتی یک فریم صوتی از دست می‌رود، DSP تلفن سعی می‌کند با Packet Loss Concealment اثر آن را مخفی کند.

به همین دلیل ممکن است چند Packet از دست رفته باشد ولی کاربر هنوز افت کیفیت شدیدی حس نکند.

Cisco معیارهایی مثل Cumulative Conceal Ratio، Interval Conceal Ratio، Max Conceal Ratio و Severely Conceal Seconds را در آمار کیفیت صدا ارائه می‌کند.

اگر Concealment افزایش پیدا می‌کند، حتی اگر کاربر هنوز شکایت شدید ندارد، مسیر RTP را باید بررسی کرد.

MOS چیست؟

MOS یا Mean Opinion Score یک امتیاز کیفیت صوت است که معمولاً از ۱ تا ۵ نمایش داده می‌شود؛ عدد بالاتر کیفیت بهتر را نشان می‌دهد.

در Cisco Phone ممکن است معیارهایی مانند MOS LQK یا در گزارش‌های RTP مقادیری مانند MOScq و MOSlq دیده شوند.

اما MOS را نباید بدون توجه به Codec مقایسه کنید.

در مستندات Cisco، حداکثر MOS LQK عادی برای G.711 حدود ۴.۵ است، در حالی که برای G.729A/AB حدود ۳.۷ ذکر شده است. بنابراین MOS پایین‌تر روی G.729 الزاماً به معنی شبکه خراب نیست؛ سقف کیفی Codec نیز پایین‌تر است.

پس MOS را چطور استفاده کنیم؟

به‌جای اینکه یک عدد ثابت برای همه Codecها تعیین کنید، سه چیز را مقایسه کنید:

اگر MOS دقیقاً در زمانی افت می‌کند که LostPkt یا Max Jitter بالا می‌رود، شواهد خوبی برای مشکل شبکه دارید.

Cisco MPP می‌تواند آمار RTP را داخل SIP BYE بفرستد

در راهنمای فعلی MPP، Cisco قابلیت End-of-Call Statistics را مستند کرده است.

در صورت فعال‌شدن، تلفن هنگام پایان تماس یا Hold، آمار تماس را در Headerهای SIP مانند RTP-RxStat و RTP-TxStat ارسال می‌کند.

این گزارش می‌تواند شامل موارد زیر باشد:

LostPkt، AvgJit، maxJitter، Codec، One-Way Delay، MOS، Packet Size و RTP Bitrate.

فعال‌کردن Call Statistics در Cisco MPP

در Web Interface تلفن:

Voice → SIP → RTP Parameters

گزینه Call Statistics را روی Yes قرار دهید.

در Provisioning XML:

<Call_Statistics ua="na">Yes</Call_Statistics>

طبق راهنمای Cisco، مقدار پیش‌فرض این قابلیت برای ارسال آمار پایان تماس No است.

نمونه RTP-RxStat چه چیزی نشان می‌دهد؟

یک گزارش می‌تواند مفهومی شبیه این داشته باشد:

RTP-RxStat:
LostPkt=18
AvgJit=27
maxJitter=74
VoRxCodec=PCMU
VoPktSizeMs=20
VoOneWayDelayMs=112
MOSlq=3.82

نمونه بالا آموزشی است و اعداد آن مربوط به تماس واقعی خاصی نیستند.

اگر چنین گزارشی داشته باشید، دیگر لازم نیست بگویید «صدا گاهی بد می‌شود». دقیقاً می‌دانید تماس چه مقدار Jitter، Delay و Loss داشته است.

Packet Loss را درصدی محاسبه کنید

صرف دیدن LostPkt=10 کافی نیست. ده Packet در تماس ۱۰ ثانیه‌ای با ده Packet در تماس یک‌ساعته یکسان نیست.

یک تخمین ساده:

Packet Loss % = Lost Packets / (Received Packets + Lost Packets) × 100

اما Burst Loss را فراموش نکنید. چند Packet پشت‌سرهم معمولاً از تعداد مشابه Loss پراکنده، اثر شنیداری بدتری دارد.

مرحله دوم: مطمئن شوید RTP واقعاً DSCP EF دارد

QoS از Endpoint شروع می‌شود.

در Cisco MPP، مقدار پیش‌فرض RTP ToS/DiffServ Value برابر:

0xb8

است.

در این مقدار، شش بیت DSCP برابر 46 هستند؛ یعنی Expedited Forwarding (EF).

این همان Class معمول توصیه‌شده برای RTP Voice است.

SIP و RTP را با هم اشتباه نگیرید

Cisco MPP به‌طور پیش‌فرض برای SIP مقدار:

0x68

را دارد که به DSCP 26 یا AF31 مربوط می‌شود.

اما RTP Voice با 0xb8 یا EF/46 علامت‌گذاری می‌شود.

پس در Packet Capture فقط SIP Packetها را بررسی نکنید؛ کیفیت صدا مربوط به RTP است.

تنظیم DSCP در Cisco MPP

در Line مربوطه از مسیر Network Settings می‌توان مقدارهای SIP و RTP را دید.

در Provisioning XML نمونه رسمی Cisco به این شکل است:

<SIP_TOS_DiffServ_Value_1_ ua="na">0x68</SIP_TOS_DiffServ_Value_1_>
<RTP_TOS_DiffServ_Value_1_ ua="na">0xb8</RTP_TOS_DiffServ_Value_1_>

وجود DSCP EF به‌تنهایی QoS نیست

این یکی از رایج‌ترین اشتباهات در شبکه VoIP است.

ممکن است Wireshark روی تلفن نشان دهد RTP با DSCP 46 ارسال می‌شود، اما اگر سوئیچ و Router هیچ Priority Queue برای EF نداشته باشند، Packetهای Voice همچنان هنگام Congestion پشت ترافیک Backup، Download و Video منتظر می‌مانند.

DSCP فقط «برچسب» است. تجهیزات شبکه باید این برچسب را Classification کنند و رفتار مناسب Queueing به آن بدهند.

QoS باید End-to-End باشد

مسیر را به چند نقطه تقسیم کنید:

تلفن Cisco → Access Switch → Distribution/Core → Router/Firewall → WAN → Router مقصد → PBX یا Gateway.

در هر قسمت ممکن است DSCP:

حفظ شود، Rewrite شود، صفر شود یا اصلاً وارد Queue مناسب نشود.

اگر فقط روی پورت تلفن EF می‌بینید، هنوز ثابت نکرده‌اید WAN نیز EF را درست حمل می‌کند.

چطور DSCP را در Wireshark بررسی کنیم؟

یک تماس آزمایشی برقرار کنید و RTP Packet را انتخاب کنید.

برای فیلتر:

rtp

برای EF:

ip.dsfield.dscp == 46

Capture را در دو نقطه بگیرید؛ مثلاً قبل و بعد از Firewall.

اگر Packet در سمت LAN برابر EF است ولی در WAN به DSCP 0 تبدیل شده، QoS Marking در میانه مسیر از بین رفته است.

Trust Boundary روی سوئیچ چیست؟

سوئیچ باید تصمیم بگیرد آیا Marking ارسال‌شده توسط Endpoint را Trust کند یا آن را Rewrite کند.

در طراحی‌های Cisco، IP Phone معمولاً مرز قابل اعتماد Voice در نظر گرفته می‌شود، در حالی که نباید اجازه داد یک PC متصل پشت تلفن هر ترافیکی را EF علامت بزند و Priority Queue را اشغال کند.

نحوه Trust دقیق به مدل Switch، IOS XE و Policy شبکه بستگی دارد. بنابراین دستورات قدیمی Catalyst را بدون بررسی مدل روی Catalyst جدید کپی نکنید.

Auto-QoS چه کمکی می‌کند؟

روی Catalystهای جدید، Cisco Auto-QoS می‌تواند Class Map و Policy Mapهای لازم برای طبقه‌بندی و Queueing را ایجاد کند.

در راهنمای فعلی Catalyst 9200، Output Priority Queue ایجادشده توسط Auto-QoS ترافیک EF (46) و CoS 5 را در Priority Class قرار می‌دهد.

اما این نکته مهم است: در تنظیم QoS استاندارد، صرفاً Trust شدن DSCP الزاماً به معنی فعال‌بودن Priority Queue نیست.

پس همیشه Policy خروجی واقعی را بررسی کنید.

Queueهای سوئیچ را چطور بررسی کنیم؟

روی Catalyst با MQC، یکی از مهم‌ترین فرمان‌ها این است:

show policy-map interface GigabitEthernet1/0/48

در IOS XEهای جدیدتر برخی پلتفرم‌ها برای Queueing خروجی از این فرم نیز استفاده می‌کنند:

show policy-map type queueing interface GigabitEthernet1/0/48

دستور دقیق به مدل و Release سوئیچ بستگی دارد.

در خروجی Queue دنبال چه چیزی باشیم؟

مهم‌ترین موارد:

Class مربوط به EF: آیا Packetهای RTP وارد آن می‌شوند؟

Total Drops: آیا Priority Queue Drop دارد؟

Bytes/Packets Output: آیا Traffic واقعاً از همان Queue عبور می‌کند؟

Policer: آیا Priority Traffic بیش از Rate تعریف‌شده است و Drop می‌شود؟

Interface Congestion: آیا Output Rate نزدیک ظرفیت Link است؟

حتی Priority Queue هم می‌تواند Packet Drop کند

Priority به معنی Bandwidth نامحدود نیست.

اگر Voice Queue برای ۱۰ تماس طراحی شده ولی ناگهان ۵۰ تماس، RTP Video یا Traffic اشتباه‌علامت‌گذاری‌شده وارد EF شود، خود Priority Queue نیز می‌تواند Drop کند.

همین‌طور اگر Policer روی Voice Class تنظیم شده باشد، Packetهای بالاتر از Rate تعیین‌شده ممکن است حذف شوند.

پس اگر EF فعال است ولی کیفیت هنوز بد است، Queue Counters را ببینید.

علت رایج: Upload لینک WAN را پر کرده است

فرض کنید دفتر یک لینک ۲۰ مگابیتی دارد و Backup ابری یا Upload دوربین تمام Upload را مصرف کرده است.

تماس ممکن است همچنان Register باشد و SIP بدون مشکل کار کند، اما RTP مجبور می‌شود پشت Packetهای بزرگ Data در Queue منتظر بماند.

نتیجه می‌تواند Jitter و Packet Loss باشد.

اگر کاربران می‌گویند «صبح خوب است ولی هنگام Backup صدا خراب می‌شود»، Queueing و WAN Congestion را قبل از Codec بررسی کنید.

WAN Latency را چطور درست اندازه بگیریم؟

Ping معمولی برای تشخیص اولیه مفید است، اما RTP کیفیت را بر اساس مسیر واقعی Media تجربه می‌کند.

اگر Media مستقیم بین Endpoint و PBX است، مسیر همان دو IP مهم است.

اگر SBC یا Media Relay دارید، مسیر RTP ممکن است با SIP متفاوت باشد.

پس ابتدا SDP را ببینید و IP مقصد RTP را مشخص کنید.

Round Trip Time با One-Way Delay یکی نیست

Ping معمولاً RTT را نشان می‌دهد؛ یعنی رفت و برگشت.

اما معیار طراحی VoIP بیشتر به One-Way Latency مربوط است.

یک RTT برابر 200ms الزاماً به این معنی نیست که هر جهت دقیقاً 100ms است؛ Routing ممکن است نامتقارن باشد.

اگر Cisco Phone در RTP Statistics مقدار One-Way Delay یا Latency ارائه می‌کند، آن عدد برای تحلیل تماس ارزش بیشتری دارد.

مشکل Bufferbloat را فراموش نکنید

گاهی Packet Loss تقریباً صفر است ولی در زمان Upload، Ping از ۲۰ms به ۳۰۰ یا ۵۰۰ms می‌رسد.

این وضعیت می‌تواند ناشی از Queue بسیار بزرگ روی Router یا ISP باشد.

در چنین حالتی Packetها Drop نمی‌شوند، اما مدت زیادی داخل Buffer منتظر می‌مانند.

برای VoIP این انتظار طولانی می‌تواند به همان اندازه Packet Loss آزاردهنده باشد.

Codec چقدر روی کیفیت اثر دارد؟

Codec فقط مصرف پهنای باند را تعیین نمی‌کند؛ سقف کیفیت صوت و رفتار تماس در برابر Loss نیز به Codec مربوط است.

G.711 پهنای باند بیشتری مصرف می‌کند اما کیفیت پایه بالایی دارد.

G.729 برای کاهش مصرف Bandwidth طراحی شده، اما کیفیت پایه پایین‌تری نسبت به G.711 دارد.

G.722 Wideband می‌تواند کیفیت صوت بهتری ارائه کند، به شرط اینکه مسیر تماس آن را End-to-End پشتیبانی کند.

Opus نیز در برخی MPPها پشتیبانی می‌شود و انعطاف بالایی دارد، اما باید PBX/SBC و مسیر کامل با آن سازگار باشند.

Codec را از روی حدس تغییر ندهید

اگر شبکه ۵٪ Packet Loss دارد، تغییر G.711 به G.729 مشکل اصلی را حل نمی‌کند.

ممکن است فقط Bandwidth کمتر شود ولی Loss همچنان وجود داشته باشد.

قبل از تغییر Codec، این ترتیب را رعایت کنید:

Loss → Jitter → Latency → QoS/Queue → Bandwidth → سپس Codec.

RTP Packet Size یا ptime چه اثری دارد؟

Cisco MPP برای RTP Packet Size تنظیم دارد و در بسیاری از مدل‌ها مقدار پیش‌فرض ۰.۰۲ ثانیه یا ۲۰ms است.

Packetization بزرگ‌تر تعداد Packet در ثانیه را کم می‌کند و Overhead را کاهش می‌دهد، اما در صورت از دست‌رفتن یک Packet، مقدار بیشتری از صدا را از دست می‌دهید.

همچنین Packetization می‌تواند روی Latency کلی اثر بگذارد.

پس ptime را فقط برای «کم‌کردن مصرف Bandwidth» بدون بررسی PBX و Codec تغییر ندهید.

Transcoding را بررسی کنید

گاهی تماس داخلی خوب است ولی تماس خروجی به PSTN یا Trunk کیفیت بدی دارد.

یکی از تفاوت‌ها می‌تواند Transcoding باشد.

مثلاً Endpoint با G.722 صحبت می‌کند ولی SBC یا Gateway تماس را به G.711 یا G.729 تبدیل می‌کند.

در این حالت CPU، DSP، Codec Negotiation و مسیر Media Gateway نیز وارد عیب‌یابی می‌شوند.

چطور بفهمیم مشکل LAN است یا WAN؟

یک مقایسه ساده بسیار مؤثر است.

تماس بین دو Cisco Phone داخل همان VLAN/Site بگیرید و آمار RTP را ثبت کنید.

بعد تماس مشابه از همان تلفن به یک Extension در Site دیگر بگیرید.

اگر تماس Local تقریباً بدون Loss و Jitter است ولی WAN Call مشکل دارد، محدوده خرابی به WAN، Router، Firewall یا Provider نزدیک‌تر می‌شود.

Capture را در دو سمت بگیرید

برای مشکل‌های جدی، یک Capture در LAN و یک Capture نزدیک PBX یا سمت دیگر WAN بگیرید.

سپس Sequence Numberهای RTP را مقایسه کنید.

اگر Packet در LAN خارج شده ولی در سمت PBX وجود ندارد، Loss بین این دو نقطه اتفاق افتاده است.

اگر هر دو Capture کامل هستند ولی تلفن Discarded Packet دارد، Jitter و Arrival Time مهم‌تر می‌شوند.

Wireshark RTP Analysis

بعد از Capture:

Telephony → RTP → RTP Streams

Stream را انتخاب کنید و Analyze را بزنید.

در آنجا می‌توانید Sequence Error، Lost Packet، Jitter و Timing را بررسی کنید.

این اطلاعات را با Call Statistics خود تلفن مقایسه کنید. اگر هر دو منبع Loss مشابهی نشان می‌دهند، تشخیص بسیار قابل‌اعتمادتر می‌شود.

اگر فقط صدای دریافتی بد است

جهت RTP مهم است.

اگر کاربر Cisco صدای طرف مقابل را بد می‌شنود، آمار Receiver روی Cisco بیشتر اهمیت دارد.

اگر طرف مقابل صدای کاربر Cisco را بد می‌شنود، باید مسیر RTP خروجی Cisco تا Receiver سمت مقابل را بررسی کنید.

یک مشکل یک‌طرفه کیفیت الزاماً روی هر دو Direction دیده نمی‌شود.

اگر کاملاً یک‌طرفه صدا ندارید

اگر یکی از طرفین اصلاً هیچ صدا ندارد، موضوع ممکن است دیگر صرفاً «کیفیت» نباشد.

در این شرایط NAT، Firewall، RTP IP داخل SDP، RTP Port Range و Routing را نیز بررسی کنید.

Jitter بالا معمولاً صدا را خراب می‌کند؛ ولی عدم وجود کامل RTP در یک جهت بیشتر ما را به Media Path می‌رساند.

Interface Error را هم بررسی کنید

قبل از طراحی QoS پیچیده، Physical Layer را فراموش نکنید.

روی Switch Port تلفن و Uplink مواردی مثل CRC Error، Input Error و Link Flap را بررسی کنید.

یک کابل خراب می‌تواند Packet Loss ایجاد کند و شما را بی‌دلیل وارد تنظیم DSCP و Queue کند.

نمونه:

show interfaces GigabitEthernet1/0/12
show interfaces counters errors

یک تست خوب QoS چگونه انجام می‌شود؟

تست را زمانی انجام دهید که مشکل واقعاً رخ می‌دهد.

اگر کاربران فقط ساعت ۱۲ ظهر مشکل دارند ولی شما ساعت ۳ بامداد تست می‌کنید، احتمالاً Queue Congestion را نمی‌بینید.

یک تماس آزمایشی طولانی برقرار کنید و هم‌زمان Traffic واقعی یا همان بار شبکه‌ای که مشکل را ایجاد می‌کند وجود داشته باشد.

بعد چهار چیز را ثبت کنید:

Call Statistics تلفن، Queue Counters سوئیچ، WAN Utilization و Packet Capture.

نمونه تحلیل یک تماس خراب

فرض کنیم Cisco Phone این اطلاعات را نشان می‌دهد:

Receiver Codec: G.711u
Avg Jitter: 12 ms
Max Jitter: 146 ms
Rcvr Lost Packets: 84
Receiver Discarded: 39
Latency: 92 ms

Average Jitter ظاهراً خوب است، اما Max Jitter برابر ۱۴۶ms نشان می‌دهد Spikeهای شدید داشته‌ایم.

Lost Packet و Discard نیز بالا هستند.

Latency عادی است، پس مشکل اصلی احتمالاً Distance شبکه نیست.

حالا اگر روی WAN Interface همزمان Output Drops یا Queue Drop ببینیم، شواهد قوی به سمت Congestion/QoS می‌روند.

نمونه تحلیل تماس با تأخیر ولی بدون Packet Loss

Lost Packets: 0
Avg Jitter: 8 ms
Max Jitter: 18 ms
One-Way Delay: 235 ms

در این حالت QoS Local احتمالاً مشکل اصلی نیست.

Packet Loss و Jitter پایین‌اند ولی Delay زیاد است.

حالا باید WAN Route، فاصله جغرافیایی PBX، VPN Tunnel یا مسیر Provider را بررسی کنید.

اگر PBX روی سرور خیلی دور قرار دارد

اگر کاربران در ایران‌اند اما PBX در یک دیتاسنتر با Route طولانی قرار دارد، حتی شبکه داخلی عالی نمی‌تواند Latency اینترنت را حذف کند.

اول One-Way Delay یا RTT واقعی را اندازه بگیرید.

اگر بخش عمده Delay خارج از شبکه شما ایجاد می‌شود، جابه‌جایی PBX یا استفاده از دیتاسنتری با Route کوتاه‌تر می‌تواند مؤثرتر از تغییر Codec باشد.

QoS روی اینترنت عمومی تضمین‌شده نیست

شما می‌توانید در LAN و WAN مدیریت‌شده DSCP EF را حفظ کنید، اما روی اینترنت عمومی تضمینی وجود ندارد که همه Providerها DSCP شما را Honor کنند.

بعضی شبکه‌ها DSCP را Rewrite یا Ignore می‌کنند.

بنابراین برای شعبی که روی اینترنت عمومی به PBX متصل‌اند، علاوه بر Marking باید Bandwidth، Route Quality و Congestion لینک خودتان را نیز مدیریت کنید.

جدول نهایی تشخیص سریع کیفیت صدای Cisco

مسیر پیشنهادی عیب‌یابی از تلفن تا WAN

مرحله ۱: یک تماس خراب قابل تکرار ایجاد کنید.

مرحله ۲: Call Statistics خود Cisco را ثبت کنید.

مرحله ۳: Receiver/Sender Codec، Avg/Max Jitter، Lost و Discarded را یادداشت کنید.

مرحله ۴: MOS و Concealment را در صورت وجود بررسی کنید.

مرحله ۵: روی RTP Capture بررسی کنید DSCP برابر EF/46 باشد.

مرحله ۶: DSCP را در چند نقطه مسیر مقایسه کنید.

مرحله ۷: Priority Queue و Drop Counter سوئیچ/Router را بررسی کنید.

مرحله ۸: WAN Utilization و Latency را هنگام بروز مشکل ثبت کنید.

مرحله ۹: Codec و Transcoding را بررسی کنید.

مرحله ۱۰: بعد از هر اصلاح، همان تماس و همان بار شبکه را دوباره تست کنید.

پرسش‌های رایج

Jitter مناسب برای Cisco VoIP چقدر است؟

Cisco در طراحی Voice توصیه می‌کند Average One-Way Jitter زیر حدود ۳۰ms هدف‌گذاری شود. Max Jitter لحظه‌ای نیز مهم است و می‌تواند حتی با Average خوب باعث افت کیفیت شود.

Packet Loss قابل قبول برای VoIP چقدر است؟

راهنمای طراحی Cisco برای Voice مقدار حداکثر حدود ۱٪ را توصیه می‌کند؛ با این حال Burst Loss حتی در درصدهای پایین‌تر هم می‌تواند قابل شنیدن باشد.

Latency مناسب برای تماس VoIP چقدر است؟

Cisco برای One-Way Mouth-to-Ear Latency حدود ۱۵۰ms یا کمتر را هدف طراحی می‌داند. Latency بالاتر باعث مکالمه با تأخیر و صحبت هم‌زمان کاربران می‌شود.

DSCP مناسب RTP Voice چیست؟

RTP Voice معمولاً با DSCP EF یا عدد 46 علامت‌گذاری می‌شود. Cisco MPP نیز به‌طور پیش‌فرض RTP ToS/DiffServ را روی 0xb8 قرار می‌دهد که DSCP آن EF/46 است.

چرا با وجود DSCP EF هنوز صدا بد است؟

چون Marking به‌تنهایی QoS نیست. سوئیچ و Router باید EF را به Priority Queue مناسب بفرستند و خود Queue نیز نباید Drop یا Policing نامناسب داشته باشد.

MOS پایین همیشه یعنی شبکه خراب است؟

خیر. سقف MOS به Codec وابسته است. Cisco برای G.711 حداکثر MOS LQK حدود ۴.۵ و برای G.729A/AB حدود ۳.۷ ذکر می‌کند. MOS را همراه Loss، Jitter و Codec تحلیل کنید.

چرا Avg Jitter خوب است ولی صدا همچنان قطع می‌شود؟

ممکن است Max Jitter یا Burst Loss بالا باشد. Average می‌تواند چند Spike شدید را پنهان کند؛ Max Jitter، Lost Packet و Discarded Packet را نیز بررسی کنید.

برای کیفیت VoIP Ping کافی است؟

خیر. Ping فقط یک نشانه از RTT و Loss ICMP است. RTP Statistics، Jitter، DSCP، Queue Drops و Packet Capture اطلاعات دقیق‌تری درباره صدای واقعی تماس می‌دهند.

آیا تغییر Codec مشکل Jitter را حل می‌کند؟

معمولاً نه. Codec می‌تواند مصرف Bandwidth را تغییر دهد، اما اگر علت اصلی Congestion، Queue Drop یا WAN Jitter باشد ابتدا شبکه باید اصلاح شود.