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

تلفن‌های Cisco می‌توانند اطلاعات بسیار مفیدی از تماس در اختیار مدیر شبکه بگذارند؛ از تعداد RTP Packetهای ارسالی و دریافتی تا Lost Packet، Jitter، Delay، Codec و در برخی مدل‌ها و Firmwareها شاخص‌های Voice Quality مانند MOS و Concealment Ratio.

در این راهنما کیفیت صدای Cisco VoIP را مرحله‌به‌مرحله از خود تلفن تا LAN، سوئیچ، WAN و PBX بررسی می‌کنیم تا بتوانید دقیقاً مشخص کنید مشکل در کدام نقطه ایجاد شده است.

اول مشخص کنید «صدای بد» دقیقاً چه شکلی است

نوع صدایی که کاربر می‌شنود می‌تواند سرنخ اولیه بدهد.

یک نکته مهم: هر صدای بدی مشکل شبکه نیست

Cisco در راهنمای عیب‌یابی فعلی MPP تأکید می‌کند که بسیاری از Voice Quality Metrics بیشتر اثر Frame Loss و Network Impairment را اندازه می‌گیرند و لزوماً نویز آکوستیک، خرابی میکروفن یا اعوجاج Headset را نشان نمی‌دهند.

بنابراین اگر:

ولی صدای کاربر همچنان خش‌دار یا نویزی است، مسیر آکوستیک و لوازم جانبی تلفن را هم بررسی کنید.

سه عدد اصلی کیفیت VoIP

برای شروع سه معیار را همیشه کنار هم ببینید:

Packet Loss + Jitter + Latency

هیچ‌کدام به‌تنهایی تصویر کامل را نمی‌دهند.

Packet Loss چیست؟

در RTP، Packetهای صوتی مرتب و با فاصله زمانی کوتاه ارسال می‌شوند.

اگر برخی Packetها در مسیر گم شوند، بر خلاف TCP معمولاً منتظر Retransmission نمی‌مانیم؛ چون وقتی Packet قدیمی دوباره برسد، زمان پخش آن گذشته است.

به همین دلیل حتی درصد کم Loss هم می‌تواند روی Voice اثر شنیداری داشته باشد.

فرمول ساده Packet Loss

Packet Loss % =
Lost Packets
-------------
Expected Packets
× 100

برای Voice چه مقدار Packet Loss قابل قبول است؟

به‌عنوان یک هدف طراحی عملی، Cisco در راهنماهای QoS قدیمی و جدید خود برای Voice باکیفیت معمولاً:

Packet Loss کمتر از ۱٪

را هدف قرار می‌دهد و در حالت ایده‌آل Loss باید نزدیک صفر باشد.

این عدد قانون مطلق همه Codecها و تمام شبکه‌ها نیست؛ Burst Loss، Codec و Packetization نیز روی اثر شنیداری تأثیر دارند.

چرا Burst Loss از Loss پراکنده بدتر است؟

فرض کنید در یک تماس ۱۰ Packet گم شده باشد.

حالت اول:

1 lost
...
1 lost
...
1 lost

حالت دوم:

10 lost packets in a row

در حالت دوم، Packet Loss Concealment تلفن فرصت بسیار کمتری برای پنهان‌کردن شکاف صوتی دارد و نتیجه می‌تواند یک بریدگی محسوس باشد.

Jitter چیست؟

Jitter یعنی تغییر در فاصله زمانی رسیدن Packetها.

برای مثال:

Packet 1: 20 ms
Packet 2: 22 ms
Packet 3: 19 ms
Packet 4: 74 ms
Packet 5: 21 ms

حتی اگر Average Latency خوب باشد، Packet چهارم بسیار دیر رسیده است.

Jitter Buffer چه می‌کند؟

تلفن Packetها را مستقیم و لحظه‌ای پخش نمی‌کند.

Jitter Buffer مقدار کوچکی Buffer ایجاد می‌کند تا اختلاف زمان رسیدن Packetها را صاف کند.

اما Buffer نامحدود نیست.

اگر Packet خیلی دیر برسد:

Late Packet

محسوب می‌شود و ممکن است دور ریخته شود.

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

Cisco در طراحی Voice باکیفیت، مقدار حدود:

۳۰ms یا کمتر

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

این نیز مرز فیزیکی مطلق نیست؛ اندازه Jitter Buffer و الگوی تغییرات اهمیت دارند.

Average Jitter کافی نیست

ممکن است:

Avg Jitter = 8ms

باشد، اما:

Max Jitter = 140ms

ثبت شود.

کاربر ممکن است فقط در همان Burst کوتاه صدای خراب شنیده باشد.

پس همیشه:

را کنار هم ببینید.

Latency چیست؟

Latency زمان رسیدن Voice از گوینده به شنونده است.

برای مکالمه دوطرفه، One-Way Delay مهم‌تر از Ping ساده است.

راهنمای Cisco با استناد به ITU-T G.114 برای Voice باکیفیت معمولاً:

کمتر از ۱۵۰ms One-Way Delay

را هدف قرار می‌دهد.

اگر Ping برابر 100ms است یعنی One-Way Delay برابر 50ms است؟

فقط به‌عنوان تخمین تقریبی و در مسیر متقارن می‌توان RTT را نصف کرد.

اما در اینترنت واقعی مسیر رفت و برگشت می‌تواند متفاوت باشد.

بهتر است اگر Endpoint یا RTCP مقدار One-Way Delay ارائه می‌کند، همان را بررسی کنید.

تأخیر بالا چه صدایی ایجاد می‌کند؟

Latency بالا لزوماً صدا را رباتی نمی‌کند.

بیشتر باعث می‌شود مکالمه طبیعی نباشد:

یک جدول هدف برای عیب‌یابی

این مقادیر را Threshold خشک برای تمام Codecها و تمام شرایط ندانید؛ آن‌ها بیشتر برای تشخیص سریع و طراحی Voice Network مفید هستند.

MOS چیست؟

MOS مخفف:

Mean Opinion Score

است.

مقیاس کلاسیک آن از:

۱ تا ۵

است؛ عدد بالاتر معمولاً کیفیت بهتر را نشان می‌دهد.

MOS تلفن Cisco الزاماً رأی واقعی کاربر نیست

تلفن از Metricها و مدل‌های Voice Quality برای تخمین MOS استفاده می‌کند.

در Cisco ممکن است اصطلاح‌هایی مانند:

را ببینید.

Listening Quality و Conversational Quality یکی نیستند

Listening Quality بیشتر روی چیزی تمرکز دارد که شنونده دریافت می‌کند.

Conversational Quality تأخیر و تجربه رفت‌وبرگشت مکالمه را هم بیشتر در نظر می‌گیرد.

به همین دلیل ممکن است:

MOS Listening خوب باشد ولی Conversation به‌دلیل Delay بالا آزاردهنده باشد.

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

بهتر است MOS را برای:

استفاده کنید، نه اینکه فقط یک عدد ثابت را معیار مطلق قرار دهید.

Concealment Metrics حتی از MOS هم مفیدتر می‌شوند

وقتی RTP Packet گم یا دیر می‌رسد، DSP تلاش می‌کند صدای گمشده را حدس بزند.

Cisco شاخص‌هایی مانند:

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

اگر MOS افت کرده، Conceal Ratio را هم نگاه کنید

Cisco در Troubleshooting Guide فعلی خود پیشنهاد می‌کند وقتی MOS LQK افت قابل توجهی دارد، Conceal Ratio و Conceal Seconds را برای شواهد Packet Loss و Jitter مقایسه کنید.

مرحله ۱: Call Statistics را روی خود تلفن Cisco ببینید

بسته به مدل و Firmware، Call Statistics از منوی Status یا صفحه تماس قابل مشاهده است.

در مدل‌های Enterprise 8800 پارامترهای مهمی مثل:

در دسترس‌اند.

در MPP نیز چه چیزهایی داریم؟

در خانواده MPP، Call Statistics و RTP Statistics می‌توانند شامل:

باشند.

یک تماس تست حداقل ۲ تا ۵ دقیقه انجام دهید

تماس ۵ ثانیه‌ای برای سنجش شبکه کافی نیست.

بهتر است:

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

مرحله ۲: حداقل چند دقیقه صحبت یا Audio پیوسته داشته باشید.

مرحله ۳: هم‌زمان Traffic معمول شبکه هم وجود داشته باشد.

مرحله ۴: Statistics را قبل از قطع تماس ثبت کنید.

مرحله ۲: End-of-Call Statistics را فعال کنید

یکی از قابلیت‌های بسیار کاربردی Cisco MPP این است که Statistics تماس را داخل SIP Message ارسال کند.

در Web UI:

Voice → SIP → RTP Parameters → Call Statistics

مقدار را روی:

Yes

قرار دهید.

Provisioning آن

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

بعد چه اتفاقی می‌افتد؟

تلفن می‌تواند Statistics را در SIP BYE، پاسخ BYE یا re-INVITE زمان Hold بفرستد.

برای Audio معمولاً Headerهایی مانند:

RTP-RxStat
RTP-TxStat

خواهید دید.

نمونه ساده‌شده RTP-RxStat

Rtp-Rxstat:
Dur=300,
Pkt=14980,
LostPkt=182,
LatePkt=41,
AvgJit=28,
VQMetrics="
VoRxCodec=PCMA;
VoPktSizeMs=20;
VoOneWayDelayMs=142;
maxJitter=81;
MOScq=3.72;
MOSlq=4.02
"

این نمونه آموزشی است.

چطور این مثال را تفسیر کنیم؟

در این تماس:

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

Packet Loss همین مثال چقدر است؟

تقریب تقریبی:

182 / (14980 + 182) × 100
≈ 1.20%

برای Voice باکیفیت این مقدار ارزش بررسی جدی دارد.

مرحله ۳: SIP Trace را ثبت کنید

اگر Asterisk دارید:

asterisk -rvvv

pjsip set logger on

بعد یک تماس تست انجام دهید و BYE را پیدا کنید.

پس از تست:

pjsip set logger off

اگر SIP روی TLS است چه؟

Packet Capture بیرونی محتوای SIP را نشان نمی‌دهد، اما Logger خود PBX همچنان می‌تواند برای دیدن Headerهای SIP مفید باشد.

مرحله ۴: RTP را روی PBX بررسی کنید

برای تست کوتاه روی Asterisk:

rtp set debug on

روی سرور پرترافیک آن را طولانی روشن نگذارید.

پس از تست:

rtp set debug off

Packet Capture برای RTP

اگر Range RTP شما مثلاً 10000 تا 20000 است:

sudo tcpdump -ni any \
udp portrange 10000-20000 \
-w /tmp/voip-quality.pcap

Range واقعی PBX خودتان را استفاده کنید.

Wireshark چه کمکی می‌کند؟

در RTP Stream Analysis می‌توانید مواردی مانند:

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

اگر SRTP دارید، ممکن است Payload قابل Decode نباشد، ولی Flow، Sequence و Timing بسته به Capture و اطلاعات موجود همچنان سرنخ‌های مهمی می‌دهند.

مرحله ۵: مشخص کنید Loss در کدام جهت است

یک اشتباه رایج این است که فقط می‌گوییم:

«تماس Packet Loss دارد.»

سؤال درست:

کدام جهت؟

Cisco Phone
    |
    | RTP A
    v
PBX

PBX
    |
    | RTP B
    v
Cisco Phone

اگر Cisco فقط در Receive Statistics Loss نشان می‌دهد، مسیر:

PBX → Cisco

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

اگر سمت PBX Loss مشاهده می‌شود، مسیر برعکس را بررسی کنید.

مرحله ۶: DSCP RTP را بررسی کنید

برای Voice RTP، Marking شناخته‌شده Cisco:

DSCP EF = 46

است.

EF مخفف:

Expedited Forwarding

است.

در Cisco MPP مقدار پیش‌فرض RTP چه است؟

در راهنمای MPP مقدار پیش‌فرض:

RTP ToS/DiffServ = 0xb8

است.

`0xb8` در بخش DSCP به:

46 یا EF

نگاشت می‌شود.

Marking را با Capture اثبات کنید

به‌جای اینکه فقط Web UI را نگاه کنید، Packet خروجی خود Phone را Capture کنید.

در Wireshark Filter:

ip.dsfield.dscp == 46

اگر Phone EF می‌فرستد ولی WAN آن را CS0 می‌کند

مشکل دیگر Phone نیست.

در یکی از Hopها DSCP:

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

این Configuration ناقص است:

Phone marks EF
        |
        v
Switch removes DSCP
        |
        v
WAN sees Best Effort

Marking روی Endpoint فقط شروع کار است.

مرحله ۷: Trust Boundary را مشخص کنید

در یک LAN استاندارد، باید مشخص شود Switch به Marking تلفن اعتماد می‌کند یا آن را دوباره Classify می‌کند.

اگر Phone و PC روی یک Port هستند، نباید هر Marking دلخواه از PC را بدون Policy به Priority Queue بفرستید.

به همین دلیل Trust Boundary و Phone Detection اهمیت دارند.

LLDP-MED و CDP هم می‌توانند روی QoS اثر بگذارند

Cisco MPP می‌تواند Network Policy را از CDP یا LLDP-MED دریافت کند.

در حالت LLDP-MED، VLAN، Layer 2 Priority و DSCP ممکن است از Network Policy به Phone اعمال شوند.

پس اگر QoS تلفن برخلاف تنظیم Web UI رفتار می‌کند، Policy دریافتی از Switch را نیز بررسی کنید.

مرحله ۸: فقط DSCP را نبینید؛ Queue را ببینید

این بخش یکی از رایج‌ترین خطاهای طراحی QoS است.

ممکن است Packet:

DSCP EF = 46

داشته باشد، اما در Switch هیچ Priority Queue واقعی برای EF تعریف نشده باشد.

در این حالت هنگام Congestion، Voice می‌تواند کنار Traffic عادی منتظر بماند.

روی Catalystهای جدید Priority Queue پیش‌فرض را فرض نکنید

در راهنمای Catalyst 9300 توضیح داده شده که Default Wired QoS ممکن است DSCP را حفظ کند، اما Priority Queuing به‌صورت پیش‌فرض فعال نیست.

پس عبارت:

«DSCP 46 دیده می‌شود، پس QoS سالم است.»

کافی نیست.

Command مهم برای بررسی Policy و Queue

روی Catalyst IOS XE:

show policy-map interface GigabitEthernet1/0/48

Interface را با Uplink واقعی جایگزین کنید.

دنبال چه چیزی بگردیم؟

اگر Voice Queue Drop دارد چه؟

QoS به معنی بی‌نهایت‌کردن ظرفیت نیست.

اگر Priority Queue برای مثلاً ظرفیت مشخصی طراحی شده ولی تعداد تماس از ظرفیت عبور کرده باشد، خود Voice Queue می‌تواند Drop کند.

در این حالت باید:

را دوباره محاسبه کنید.

Auto-QoS را کورکورانه فعال نکنید

روی برخی Catalystها دستورهایی مانند:

auto qos voip trust

وجود دارند و می‌توانند Policyهای متعددی ایجاد کنند.

اما این دستور را بدون بررسی مدل Switch، IOS XE، Policy موجود و اثر روی Uplinkها روی Production اجرا نکنید.

قبل از هر تغییر QoS وضعیت فعلی را ذخیره کنید

show running-config
show policy-map
show policy-map interface

مرحله ۹: Port تلفن را هم بررسی کنید

کیفیت بد می‌تواند قبل از WAN و در همان Access Port ایجاد شود.

بررسی کنید:

show interfaces GigabitEthernet1/0/12

show interfaces counters errors

دنبال چه خطاهایی باشیم؟

اگر Access Port Error دارد QoS مشکل را حل نمی‌کند

Packet خراب یا Dropشده قبل از ورود به Queue Priority با DSCP بهتر نمی‌شود.

ابتدا Layer 1/2 را سالم کنید.

مرحله ۱۰: Uplink را هنگام مشکل بررسی کنید

اگر صدا فقط در ساعات Backup، Upload یا شلوغی شبکه خراب است، روی Uplink مهم‌ترین Counterها را ببینید.

مثلاً:

show interfaces GigabitEthernet1/0/48
show policy-map interface GigabitEthernet1/0/48

Average Utilization پایین می‌تواند گمراه‌کننده باشد

ممکن است نمودار ۵ دقیقه‌ای فقط:

40% utilization

نشان دهد، اما Microburstهای چند میلی‌ثانیه‌ای Queue را پر کنند.

Voice به Burst کوتاه حساس است.

بنابراین Queue Drop Counter از Average Bandwidth مهم‌تر است.

مرحله ۱۱: WAN Latency را اندازه بگیرید

اگر PBX یا SIP Provider در دیتاسنتر دیگری است، مسیر WAN را جدا بررسی کنید.

Ping ساده برای Baseline خوب است:

ping -c 50 PBX_IP

اما ICMP همیشه همان مسیر، Priority یا رفتار RTP را ندارد.

بهتر از Ping: UDP Test شبیه Voice

اگر دو Endpoint تحت کنترل دارید، می‌توانید با ابزارهایی مانند iperf3 UDP رفتار شبکه را تحت بار کنترل‌شده بررسی کنید.

مثال سمت Server:

iperf3 -s

و Client:

iperf3 -c SERVER_IP -u -b 200K -t 60

نرخ تست را متناسب با سناریوی خودتان انتخاب کنید و روی شبکه Production بدون هماهنگی بار سنگین ایجاد نکنید.

مرحله ۱۲: QoS را زیر بار تست کنید

یک شبکه خلوت تقریباً همیشه خوب به نظر می‌رسد.

QoS زمانی ارزش دارد که Link تحت فشار باشد.

روش عملی:

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

مرحله ۲: RTP Statistics را ثبت کنید.

مرحله ۳: Traffic Data کنترل‌شده روی WAN ایجاد کنید.

مرحله ۴: Packet Loss/Jitter تماس را دوباره ببینید.

مرحله ۵: Queue Counterهای Switch/Router را مقایسه کنید.

اگر فقط زیر بار صدا خراب می‌شود

به احتمال زیاد باید روی:

تمرکز کنید.

Shaping در WAN چرا مهم است؟

فرض کنید لینک Provider اسماً 100Mbps است، ولی Policier واقعی در سمت Provider روی 90Mbps کار می‌کند.

اگر Router شما 100Mbps Burst بفرستد، Packetها ممکن است در سمت Provider Drop شوند؛ جایی که Queue Voice شما هیچ کنترلی روی آن ندارد.

در چنین شرایطی Shaping خروجی قبل از Provider می‌تواند کمک کند تا Queue Priority داخل Router خودتان اعمال شود.

مرحله ۱۳: Codec را بررسی کنید

در Statistics دنبال:

بگردید.

G.711 چه ویژگی‌ای دارد؟

G.711 فشرده‌سازی کمی دارد و کیفیت پایه خوبی ارائه می‌دهد، اما Bandwidth بیشتری نسبت به Codecهایی مانند G.729 مصرف می‌کند.

اگر WAN کم‌ظرفیت است، تعداد تماس‌های هم‌زمان می‌تواند Congestion ایجاد کند.

G.729 چه مزیت و ریسکی دارد؟

Bandwidth Voice Payload کمتری مصرف می‌کند، اما اثر Packet Loss می‌تواند محسوس باشد و پردازش Codec بیشتر است.

صرفاً برای کاهش Bandwidth بدون اندازه‌گیری کیفیت، Codec را عوض نکنید.

Packetization نیز مهم است

اگر هر RTP Packet مثلاً 20ms Voice حمل کند، از دست دادن یک Packet یعنی تقریباً 20ms Audio از دست رفته است.

Packetization بزرگ‌تر:

Bandwidth تماس فقط Codec Bitrate نیست

برای طراحی Queue باید:

Codec + RTP + UDP + IP + Layer 2 overhead

را در نظر بگیرید.

مثلاً Codec با Payload 64kbps الزاماً فقط 64kbps روی Wire مصرف نمی‌کند.

مرحله ۱۴: مشکل فقط در یک Phone است؟

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

مقایسه کنید:

تست Swap بسیار مفید است

Phone خراب را روی Port سالم بگذارید.

Phone سالم را روی Port مشکوک بگذارید.

اگر مشکل:

با Phone جابه‌جا شد → Endpoint/Accessory

اگر:

روی Port ماند → LAN/Switch/Cabling

مرحله ۱۵: فقط تماس‌های یک Provider بد است؟

اگر تماس داخلی:

عالی

و تماس بیرونی:

بد

است، مسئله را به دو Media Leg تقسیم کنید.

Cisco Phone
    |
    | RTP Leg 1
    v
PBX / SBC
    |
    | RTP Leg 2
    v
SIP Provider

هر Leg را جدا Capture کنید.

اگر Leg 1 سالم و Leg 2 خراب است

مشکل احتمالاً در:

است.

مرحله ۱۶: VPN هم می‌تواند QoS را از بین ببرد

اگر Voice از VPN عبور می‌کند، بررسی کنید DSCP داخلی بعد از Encapsulation چه می‌شود.

ممکن است RTP داخل Tunnel:

EF

باشد ولی Packet بیرونی Tunnel:

CS0

شود.

در این حالت WAN نمی‌تواند Voice را از Data تشخیص دهد.

MTU و Fragmentation هم مهم‌اند

در VPN، Headerهای اضافه MTU مؤثر را کم می‌کنند.

RTP Packet معمولاً کوچک است، اما اگر مسیر Media یا SRTP/VPN Encapsulation پیچیده باشد، Capture را برای Fragmentation یا Drop بررسی کنید.

مرحله ۱۷: Wi-Fi Phone را جداگانه تحلیل کنید

اگر تلفن Cisco روی Wi-Fi است، DSCP روی Wired Network فقط بخشی از داستان است.

روی Wireless باید:

را نیز بررسی کنید.

در Cisco Wireless Voice، RTP Voice معمولاً با DSCP EF و WMM Voice Queue حمل می‌شود.

مرحله ۱۸: فقط Average MOS را گزارش نکنید

فرض کنید یک تماس ۳۰ دقیقه‌ای ۲۹ دقیقه عالی بوده و فقط ۲۰ ثانیه در زمان Congestion بسیار بد شده است.

Average MOS ممکن است هنوز خوب به نظر برسد.

برای همین:

را هم ثبت کنید.

یک روش استاندارد برای پیدا کردن محل خرابی

چهار نقطه Capture بسازید:

[1] Cisco Phone
      |
[2] Access Switch
      |
[3] WAN Edge
      |
[4] PBX / SBC

اولین نقطه‌ای که:

Sequence Gap / Jitter Spike / Queue Drop

ظاهر می‌شود، محدوده مشکل را کوچک می‌کند.

مثال واقعی برای تحلیل

فرض کنید آمار Phone:

LostPkt=0
AvgJit=4
maxJitter=12
VoOneWayDelayMs=32

اما PBX سمت دریافت:

Packet Loss: 2.4%
Jitter: 68 ms

این نشان می‌دهد مسیر:

Phone → PBX

در جایی بعد از Phone خراب شده است.

اگر برعکس باشد چه؟

اگر PBX خروجی سالم نشان دهد ولی Cisco Receive Statistics Loss بالا دارد، مسیر:

PBX → Phone

مظنون است.

علت‌های پرتکرار Quality Drop در شبکه Cisco

آیا افزایش Internet Speed همیشه مشکل را حل می‌کند؟

نه.

یک لینک 1Gbps بدون Queue مناسب می‌تواند در Microburst Voice Packet را Drop کند.

در مقابل یک لینک بسیار کوچک‌تر با:

می‌تواند Voice پایدارتر داشته باشد.

آیا DSCP EF اینترنت عمومی را مجبور به اولویت می‌کند؟

خیر.

DSCP فقط زمانی اثر دارد که تجهیزات مسیر آن را:

روی اینترنت عمومی تضمینی وجود ندارد که تمام Carrierها EF شما را حفظ یا اولویت‌بندی کنند.

QoS داخل شبکه خودتان را کنترل کنید

بخش‌هایی که در اختیار شما هستند:

باید Policy سازگار داشته باشند.

یک Decision Tree سریع

صدا بد است.

آیا RTP Statistics Loss/Jitter دارد؟

🔹 خیر → Headset، Handset، Acoustic Path، Codec و Endpoint را بررسی کنید.

🔹 بله → جهت Loss را مشخص کنید.

آیا مشکل فقط هنگام شلوغی است؟

🔹 بله → QoS، Queue Drop، Shaping و WAN را بررسی کنید.

آیا DSCP RTP برابر EF46 است؟

🔹 خیر → Phone/LLDP-MED/Marking Policy.

🔹 بله → آیا در Uplink هم EF باقی مانده؟

اگر خیر → Trust/Remarking.

اگر بله → Queue و Drop Counter را بررسی کنید.

سناریوی ۱: Jitter بالا ولی Packet Loss صفر

ممکن است Jitter Buffer هنوز Packetها را جبران کند.

اما اگر Spikeها بزرگ‌تر شوند، Late Packet و Discard شروع می‌شود.

بررسی کنید:

سناریوی ۲: Packet Loss بالا ولی Jitter پایین

این الگو می‌تواند نشان دهد Packetها به‌صورت مستقیم Drop می‌شوند؛ مثلاً:

سناریوی ۳: MOS پایین ولی Loss صفر

بررسی کنید:

Cisco نیز در Troubleshooting Guide پیشنهاد می‌کند تغییر Codec و تغییر MOS Metric بعد از Firmware Update بررسی شود.

سناریوی ۴: فقط تماس به یک شهر یا کشور بد است

احتمالاً LAN مشکل عمومی ندارد.

Route خارجی، SIP Provider و Media POP را بررسی کنید.

Traceroute به‌تنهایی کیفیت RTP را اثبات نمی‌کند؛ Packet Capture و RTCP Statistics مهم‌ترند.

سناریوی ۵: فقط هنگام Backup صدا خراب می‌شود

علامت کلاسیک Congestion است.

بررسی کنید Backup Traffic در Queue خودش قرار دارد و Voice EF واقعاً Priority دارد.

سناریوی ۶: فقط Upload شبکه باعث مشکل می‌شود

احتمالاً Bottleneck در Egress WAN است.

Shaping و LLQ روی Router خروجی را بررسی کنید.

سناریوی ۷: فقط Download باعث مشکل می‌شود

اگر Bottleneck در سمت ISP است، Queue داخل Router شما ممکن است نتواند Traffic ورودی را قبل از Drop Provider کنترل کند.

Traffic Engineering و Service Profile Provider را بررسی کنید.

سناریوی ۸: Phone روی LAN سالم است ولی Remote Phone بد است

مسیر اینترنت، VPN، Wi-Fi، NAT و ISP کاربر Remote را بررسی کنید.

دو تماس را مقایسه کنید:

Local Phone → PBX

و:

Remote Phone → PBX

اگر فقط Remote خراب است، Core Voice شما احتمالاً مشکل اصلی نیست.

سناریوی ۹: صدای یک سمت خوب و سمت دیگر بد است

RTP دو جهت مستقل دارد.

Statistics Receive هر Endpoint را جدا ببینید.

ممکن است فقط Upload یک ISP یا فقط Download یک Site مشکل داشته باشد.

سناریوی ۱۰: تماس داخلی عالی ولی Provider بد است

Call را روی SBC/PBX Split کنید.

اگر:

Phone ↔ PBX سالم

ولی:

PBX ↔ Provider Loss دارد

با Call-ID، Timestamp و RTP Capture به Provider گزارش دهید.

یک گزارش حرفه‌ای برای Provider چه داشته باشد؟

چک‌لیست ۱۵ دقیقه‌ای عیب‌یابی

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

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

مرحله ۳: Rx/Tx Codec را یادداشت کنید.

مرحله ۴: LostPkt و LatePkt را ثبت کنید.

مرحله ۵: AvgJit و MaxJitter را ثبت کنید.

مرحله ۶: Delay را ثبت کنید.

مرحله ۷: MOS/Concealment را ببینید.

مرحله ۸: DSCP RTP را Capture کنید.

مرحله ۹: Switch Queue را بررسی کنید.

مرحله ۱۰: Uplink Drop را بررسی کنید.

مرحله ۱۱: WAN Latency را اندازه بگیرید.

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

جدول تفسیر نهایی

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

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

برای Voice باکیفیت، Cisco در راهنماهای طراحی معمولاً Jitter حدود ۳۰ میلی‌ثانیه یا کمتر را هدف مناسبی می‌داند. Max Jitter و Late Packet را نیز در کنار Average Jitter بررسی کنید.

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

برای کیفیت بالا بهتر است Packet Loss کمتر از ۱ درصد و تا حد ممکن نزدیک صفر باشد. Burst Loss حتی با درصد متوسط پایین می‌تواند صدای محسوسی ایجاد کند.

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

برای مکالمه تعاملی باکیفیت، One-Way Delay کمتر از ۱۵۰ میلی‌ثانیه هدف رایجی است. Delay بالاتر الزاماً تماس را قطع نمی‌کند، اما مکالمه طبیعی را دشوار می‌کند.

MOS چیست؟

MOS یک شاخص کیفیت صوت در مقیاس معمول ۱ تا ۵ است. در Cisco برخی MOSها تخمینی و مبتنی بر Network/Codec Metrics هستند؛ بنابراین بهتر است همراه Packet Loss، Jitter و Delay تفسیر شوند.

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

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

اگر RTP روی EF46 باشد یعنی QoS درست است؟

خیر. Switch و Router باید DSCP را حفظ کنند و EF را به Priority Queue مناسب نگاشت کنند. Queue Drop و Policy خروجی را هم باید بررسی کنید.

چطور Queue Drop روی Catalyst را ببینیم؟

در بسیاری از Catalystهای IOS XE دستور `show policy-map interface` آمار Class و Queue را نمایش می‌دهد. Command دقیق و ساختار Queue به مدل و نسخه IOS XE بستگی دارد.

چرا صدا فقط هنگام شلوغی شبکه خراب می‌شود؟

این الگو معمولاً به Congestion، نبود Priority Queue، Shaping نادرست یا Queue Drop اشاره دارد. QoS باید دقیقاً در شرایط Congestion آزموده شود.

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

نه. Codec می‌تواند Bandwidth و حساسیت به Loss را تغییر دهد، ولی Jitter ناشی از شبکه را رفع نمی‌کند. ابتدا علت Network Variation را پیدا کنید.

آیا MOS خوب یعنی Headset سالم است؟

نه. Cisco توضیح می‌دهد Voice Quality Metrics شبکه لزوماً نویز یا اعوجاج آکوستیک را اندازه نمی‌گیرند. ممکن است MOS خوب باشد ولی Headset یا Handset مشکل داشته باشد.

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

Media Leg داخلی و خارجی را جدا Capture کنید. اگر Cisco تا PBX سالم است ولی PBX تا Provider Loss/Jitter دارد، Trace همان Leg را همراه Call-ID و Timestamp به Provider بدهید.