رفع نویز و اکو Yealink؛ تشخیص تأخیر و مشکل شبکه VoIP

در این آموزش کیفیت تماس را با عدد و Packet بررسی می‌کنیم. ابتدا با جابه‌جایی بین Handset، Speaker و Headset مشخص می‌کنیم مشکل به خود دستگاه مربوط است یا خیر. بعد Latency، Jitter و Packet Loss را از RTP اندازه می‌گیریم، MOS را درست تفسیر می‌کنیم، DSCP و QoS را بررسی می‌کنیم و در نهایت Codec و Jitter Buffer را با مسیر شبکه مقایسه می‌کنیم.

هدف این نیست که با تغییر چند گزینه صدا موقتاً بهتر شود؛ هدف این است که بتوانید ثابت کنید منشأ مشکل در تلفن، تجهیزات صوتی، LAN، اینترنت، PBX یا سمت مقابل قرار دارد.

اول مشخص کنیم نویز، اکو و تأخیر چه تفاوتی دارند

مرحله اول: شبکه را از خود تلفن جدا کنید

سریع‌ترین تست این است که همان تماس را با سه مسیر صوتی مختلف آزمایش کنید:

Handset
Speakerphone
Headset

برای مثال اگر نویز فقط روی Handset وجود دارد ولی Speaker و Headset کاملاً سالم هستند، مشکل شبکه احتمال کمتری دارد؛ چون RTP برای هر سه حالت از همان شبکه عبور می‌کند.

در این سناریو باید Handset، سیم فنری، کانکتور و Audio Hardware را بررسی کنید.

روش رسمی Yealink برای جداکردن خرابی Handset

Yealink برای نویز، Static و Echo پیشنهاد می‌کند از Handset به Speaker یا Headset تغییر حالت دهید.

اگر مشکل ناپدید شد:

Network RTP
احتمالاً سالم‌تر است

و باید بررسی شود:
Handset
Handset Cord
Phone Audio Hardware
Phone Settings

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

اگر نویز همراه همان Handset به تلفن دوم منتقل شد، احتمال خرابی خود Handset بسیار بالا می‌رود.

اگر هر سه حالت صوتی مشکل دارند چه؟

حالا باید ببینید مشکل فقط روی یک تلفن است یا چند تلفن.

اگر فقط یک Yealink مشکل دارد:

Phone Configuration
Firmware
Audio Hardware
Codec Negotiation

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

اگر تمام تلفن‌های همان شبکه تقریباً هم‌زمان صدای خراب دارند:

LAN
WAN
QoS
Congestion
PBX
Internet Path

مظنون‌های مهم‌تری هستند.

یک تست چهارحالته بسازید

تفاوت تماس داخلی و خارجی یک تست بسیار مهم است

یک تماس داخلی بین دو Yealink روی همان LAN برقرار کنید.

بعد تماس به مقصد خارجی یا شعبه دیگر را امتحان کنید.

مثلاً:

Extension 201 → Extension 202
صدا عالی

Extension 201 → PSTN
تأخیر و صدای رباتی

در این وضعیت خود تلفن و LAN داخلی احتمالاً مشکل اصلی نیستند.

مسیر:

PBX
↓
SBC / Gateway
↓
Internet / Provider
↓
Remote Network

باید بررسی شود.

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

Latency مدت زمانی است که Packet برای طی‌کردن مسیر نیاز دارد.

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

نتیجه همان حالتی است که دو طرف مدام روی حرف یکدیگر می‌آیند.

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

برای طراحی شبکه صوتی باکیفیت می‌توان از این مقادیر به‌عنوان هدف مهندسی استفاده کرد:

این اعداد را به‌عنوان Threshold جادویی در نظر نگیرید. Codec، Jitter Buffer، Packet Loss Burst و مسیر واقعی تماس روی تجربه نهایی اثر می‌گذارند.

Ping به‌تنهایی کیفیت VoIP را ثابت نمی‌کند

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

ping pbx.example.com

را اجرا کنید، اما Ping با ICMP انجام می‌شود و RTP لزوماً همان رفتار را ندارد.

بنابراین:

Ping = 20 ms

به‌تنهایی ثابت نمی‌کند تماس صوتی سالم است.

اندازه‌گیری اصلی باید روی RTP همان تماس خراب انجام شود.

مرحله سوم: Jitter را اندازه بگیرید

RTP Packetها قرار است تقریباً با فاصله زمانی منظم برسند. اگر بعضی Packetها سریع و بعضی با تأخیر برسند، Variation در زمان رسیدن Packet ایجاد می‌شود که Jitter نام دارد.

مثلاً:

Packet 1 → 20 ms
Packet 2 → 21 ms
Packet 3 → 19 ms
Packet 4 → 70 ms
Packet 5 → 8 ms

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

Jitter چه صدایی ایجاد می‌کند؟

Jitter زیاد بیشتر با علائمی مانند:

صدای رباتی.

قطع‌شدن هجاها.

تغییر نامنظم کیفیت.

مکث کوتاه وسط کلمات.

همراه است.

Yealink برای Jitter Buffer چه کاری انجام می‌دهد؟

Yealink از Jitter Buffer استفاده می‌کند تا Packetهای RTP را برای مدت کوتاهی نگه دارد و بعد با فاصله منظم به Audio Processor تحویل دهد.

در مستندات فعلی تلفن‌های SIP Yealink دو حالت وجود دارد:

Fixed Jitter Buffer
Adaptive Jitter Buffer

در حالت Adaptive، تلفن Buffer را با تغییرات Delay شبکه هماهنگ می‌کند.

Yealink به‌طور کلی استفاده از Adaptive Jitter Buffer را توصیه می‌کند.

پارامترهای Jitter Buffer در Yealink

voice.jib.adaptive
voice.jib.min
voice.jib.max
voice.jib.normal

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

voice.wifi_jib.adaptive
voice.wifi_jib.min
voice.wifi_jib.max
voice.wifi_jib.normal

این مقادیر را بدون PCAP تغییر ندهید.

Jitter Buffer بزرگ‌تر ممکن است Packetهای دیررس بیشتری را نجات دهد، اما خودش Delay بیشتری به صدا اضافه می‌کند.

پس بزرگ‌تر کردن Buffer همیشه بهتر نیست

فرض کنید شبکه Jitter بالایی دارد.

افزایش Buffer ممکن است صدای تکه‌تکه را کمتر کند، اما:

Network Delay
+
Jitter Buffer Delay
+
Codec / Processing Delay
=
End-to-End Delay بیشتر

و حالا مشکل «صدای رباتی» ممکن است به «مکالمه با تأخیر» تبدیل شود.

مرحله چهارم: Packet Loss را بررسی کنید

RTP معمولاً برای تماس صوتی Real-Time روی UDP منتقل می‌شود و Packet گم‌شده دوباره مثل TCP Retransmit نمی‌شود.

اگر Packet صوتی نرسد، Endpoint باید صدا را با روش‌هایی مانند Packet Loss Concealment ترمیم کند یا بخشی از صدا از بین می‌رود.

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

Packet Loss چه صدایی ایجاد می‌کند؟

0% Loss
→ معمولاً صدای طبیعی

Loss پراکنده
→ حذف بعضی هجاها

Burst Loss
→ قطع محسوس کلمات

Loss شدید
→ صدای رباتی / غیرقابل فهم

بنابراین فقط Average Loss را نبینید؛ زمان و Burst Pattern نیز مهم است.

مرحله پنجم: RTP را با Wireshark تحلیل کنید

برای پیدا کردن Jitter و Packet Loss بهتر است از خود Yealink Diagnostic بگیرید.

در بسیاری از مدل‌ها:

Settings → Configuration
→ Export All Diagnostic Files

قبل از تماس:

Start

را بزنید.

تماس خراب را بازتولید کنید و بعد:

Stop
↓
Export

را انجام دهید.

Diagnostic را هنگام مشکل بگیرید، نه بعداً

Yealink برای بررسی مشکلات صوتی پیشنهاد می‌کند PCAP، Syslog سطح 6 و Config.bin مربوط به همان رخداد جمع‌آوری شوند.

یعنی:

Start Diagnostic
↓
Call
↓
Echo / Noise / Delay occurs
↓
Stop
↓
Export immediately

اگر نیم ساعت بعد Capture بگیرید، Packetهای تماس مشکل‌دار داخل فایل نیستند.

RTP Stream Analysis در Wireshark

فایل PCAP را باز کنید و از مسیر:

Telephony
→ RTP
→ RTP Streams

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

Wireshark برای هر Stream اطلاعاتی مانند:

Packets
Lost Packets
Loss %
Max Delta
Mean Jitter
Max Jitter
Sequence Errors
Bandwidth
Skew

را نمایش می‌دهد.

دو جهت RTP را جدا بررسی کنید

تماس معمولاً حداقل دو RTP Stream دارد:

A → B

B → A

ممکن است فقط یکی از آن‌ها Packet Loss داشته باشد.

مثلاً:

Yealink → PBX
Loss = 0%

PBX → Yealink
Loss = 4%

در این حالت کاربر Yealink صدای خراب دریافت می‌کند، اما طرف مقابل ممکن است صدای او را کاملاً شفاف بشنود.

این تست جهت مشکل را مشخص می‌کند

از کاربر بپرسید:

شما صدای طرف مقابل را خراب می‌شنوید؟

یا طرف مقابل صدای شما را خراب می‌شنود؟

بعد همان جهت RTP را در Wireshark بررسی کنید.

مرحله ششم: MOS را درست تفسیر کنید

MOS یا Mean Opinion Score روشی برای بیان کیفیت ادراک‌شده صداست.

در سامانه‌های مانیتورینگ امروزی MOS می‌تواند به‌صورت تخمینی و بر اساس مدل‌هایی مانند E-model محاسبه شود.

عواملی مانند:

Delay
Packet Loss
Codec
Equipment Impairment

روی این برآورد اثر دارند.

ITU-T G.107 برای همین نوع تحلیل E-model را تعریف می‌کند.

MOS را با تست سرعت اینترنت اشتباه نگیرید

ممکن است یک خط اینترنت:

Download = 500 Mbps
Upload = 500 Mbps

داشته باشد ولی:

Jitter بالا
Packet Loss Burst
Latency متغیر

باعث صدای بد شود.

VoIP بیشتر از اینکه فقط به «سرعت زیاد» نیاز داشته باشد به انتقال منظم و قابل پیش‌بینی Packetها نیاز دارد.

MOS پایین علت نیست؛ علامت است

اگر سیستم مانیتورینگ MOS پایین نشان می‌دهد، باید علت زیر آن را پیدا کنید.

مثلاً:

MOS پایین
↓
Packet Loss بالا
↓
WAN Congestion
↓
Upload اشباع شده

یا:

MOS پایین
↓
Delay بالا
↓
Media Relay دور
↓
مسیر جغرافیایی طولانی

مرحله هفتم: QoS و DSCP را بررسی کنید

وقتی شبکه شلوغ می‌شود، Voice Packetها باید نسبت به دانلود، Backup یا سایر ترافیک‌های کم‌حساس‌تر اولویت مناسبی داشته باشند.

Yealink از مدل DiffServ برای QoS پشتیبانی می‌کند.

در مدل‌های فعلی مانند T54W، مقادیر پیش‌فرض مستندشده عبارت‌اند از:

RTP Audio DSCP:
46

SIP Signaling DSCP:
26

DSCP 46 معمولاً با Expedited Forwarding برای ترافیک Voice مرتبط است.

مسیر تنظیم QoS در Yealink

در بسیاری از تلفن‌های SIP:

Network → Advanced → QoS

پارامترهای Configuration نیز شامل:

static.network.qos.audiotos
static.network.qos.signaltos

هستند.

طبق مستندات Yealink تغییر این پارامترها ممکن است باعث Reboot تلفن شود؛ بنابراین روی تلفن عملیاتی در زمان تماس تغییر ندهید.

DSCP 46 روی تلفن به‌تنهایی QoS نمی‌سازد

این اشتباه بسیار رایج است.

تلفن فقط Packet را Mark می‌کند.

Switch، Router و Firewall نیز باید این Marking را:

Trust
Classify
Queue
Prioritize

کنند.

اگر Router تمام DSCPها را پاک کند:

Yealink:
DSCP 46

Router WAN:
DSCP 0

تنظیم QoS تلفن عملاً در مسیر اینترنت اثری ندارد.

DSCP را در PCAP بررسی کنید

یک RTP Packet را در Wireshark باز کنید.

در بخش IP Header مقدار:

Differentiated Services Field

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

اگر Capture نزدیک Yealink انجام شده، RTP باید مطابق Configuration تلفن Mark شده باشد.

برای تشخیص اینکه Router Mark را حفظ کرده است باید Capture دیگری بعد از Router یا روی SPAN Port مناسب بگیرید.

LLDP می‌تواند تنظیم دستی DSCP را Override کند

Yealink در مستندات QoS توضیح می‌دهد در صورت فعال‌بودن LLDP، اطلاعات QoS دریافتی از Network Policy می‌تواند نسبت به تنظیم دستی اولویت داشته باشد.

بنابراین اگر در Web UI عدد 46 وارد کرده‌اید اما Packet رفتار دیگری دارد، LLDP Policy را نیز بررسی کنید.

QoS بیشتر هنگام Congestion خودش را نشان می‌دهد

اگر لینک تقریباً خالی است، QoS تفاوت زیادی ایجاد نمی‌کند.

اما فرض کنید Upload اینترنت فقط:

20 Mbps

است و Backup با:

19.8 Mbps

در حال ارسال است.

در این شرایط Queue Router می‌تواند باعث Jitter و Packet Loss برای RTP شود.

یک تست عملی برای Congestion

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

حالت 1:
شبکه تقریباً بیکار

حالت 2:
Upload یا Download سنگین

اگر فقط هنگام مصرف پهنای باند صدا خراب می‌شود، Queueing و QoS را جدی‌تر بررسی کنید.

اما برای تست شبکه Production عمداً لینک را تا مرز اشباع نبرید مگر در Maintenance Window کنترل‌شده.

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

Codec مشخص می‌کند Voice چگونه Encode و Decode شود.

Yealink T54W در مستندات فعلی از Codecهایی مانند این‌ها پشتیبانی می‌کند:

G.722
PCMA / G.711 A-law
PCMU / G.711 μ-law
G.729
G.726
iLBC

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

Codec انتخاب‌شده را از SIP/SDP پیدا کنید

در Packet Capture، INVITE و 200 OK را باز کنید.

در SDP خطوطی شبیه این می‌بینید:

m=audio 12000 RTP/AVP 9 0 8 18

a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000

Codec نهایی باید بین دو طرف Negotiated شده باشد.

اولویت Codec در Yealink

در Web UI:

Account → Codec → Audio Codec

می‌توانید Codecهای فعال و Priority آن‌ها را ببینید.

پارامترها:

account.X.codec.<payload_type>.enable
account.X.codec.<payload_type>.priority

هستند.

G.722 به‌تنهایی مشکل شبکه را حل نمی‌کند

G.722 یک Codec Wideband است و می‌تواند کیفیت شنیداری بهتری ایجاد کند، اما اگر شبکه Packet Loss دارد:

Codec بهتر
≠
Network سالم

حتی بهترین Codec نمی‌تواند Packetهایی را که به مقصد نمی‌رسند به‌طور کامل بازسازی کند.

Codec کم‌حجم هم همیشه بهترین انتخاب نیست

G.729 Bitrate پایین‌تری نسبت به G.711 یا G.722 دارد، اما انتخاب Codec فقط بر اساس مصرف Bandwidth منطقی نیست.

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

PBX Support
Endpoint Support
Transcoding
License در برخی سیستم‌ها
CPU Load
Audio Quality
Packet Loss Behavior

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

اگر Yealink با G.722 صحبت می‌کند اما PBX مجبور است تماس را برای Trunk به Codec دیگری تبدیل کند، Transcoding وارد مسیر می‌شود.

برای تست می‌توانید در یک تماس آزمایشی Codec مشترک End-to-End را محدود کنید و ببینید مشکل تغییر می‌کند یا خیر.

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

تغییر Codec یک تست تشخیصی است

اگر:

G.722 → مشکل

G.711 → سالم

نتیجه فقط این نیست که «G.722 بد است».

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

Transcoding
Negotiation
PBX Codec Handling
Bandwidth
DSP
Packetization

در کدام بخش فرق کرده است.

مرحله نهم: Echo را از Network Delay جدا کنید

اکو زمانی ایجاد می‌شود که صدای گوینده از مسیر دیگری دوباره به او برگردد.

منشأ آن می‌تواند Acoustic Coupling در Speaker یا تجهیزات سمت مقابل باشد.

Delay شبکه معمولاً Echo را ایجاد نمی‌کند، اما Echo موجود را بسیار محسوس‌تر می‌کند.

صدایی که فقط چند میلی‌ثانیه برمی‌گردد ممکن است تقریباً حس نشود، اما همان Echo با Delay زیاد واضح و آزاردهنده می‌شود.

Yealink از Echo Canceller پشتیبانی می‌کند

Yealink در مستندات Audio خود Echo Cancellation سازگار با G.168 را برای تلفن‌هایش ذکر می‌کند.

پارامتر Provisioning مرتبط:

voice.echo_cancellation = 1

است.

قبل از خاموش‌کردن Echo Cancellation برای «آزمایش» از Configuration فعلی Backup بگیرید. در محیط عادی بهتر است Echo Canceller فعال باشد.

یک تست بسیار خوب برای پیدا کردن سمت تولیدکننده Echo

فرض کنید:

A = Yealink شما
C = طرف مقابل

A هنگام صحبت صدای خودش را به‌صورت Echo می‌شنود.

از C بخواهید Microphone را Mute کند.

اگر A همچنان Echo را می‌شنود، منشأ Echo به سمت A نزدیک‌تر است.

اگر Echo ناپدید شود، مسیر یا تجهیزات سمت C باید بیشتر بررسی شوند.

این روش در راهنمای عیب‌یابی Echo خود Yealink نیز پیشنهاد شده است.

Speakerphone می‌تواند Echo آکوستیک ایجاد کند

در Speakerphone، صدا از بلندگو خارج می‌شود و Microphone همان دستگاه نیز فعال است.

Echo Canceller باید بخش برگشتی آن را حذف کند.

اگر:

Speaker = Echo

Handset = Clean

Headset = Clean

ابتدا Acoustic Path و Speakerphone را بررسی کنید، نه اینترنت.

Volume خیلی زیاد را هم آزمایش کنید

در بعضی محیط‌ها Speaker Volume بسیار بالا باعث می‌شود صدای بلندگو بیشتر وارد Microphone شود.

برای تست:

Speaker Volume را چند درجه کم کنید
↓
همان تماس را تکرار کنید

اگر Echo واضحاً کم شد، Acoustic Coupling بخشی از مسئله است.

مرحله دهم: نویز محیط را از نویز شبکه جدا کنید

Packet Loss معمولاً صدایی شبیه هیس الکتریکی ثابت ایجاد نمی‌کند.

اگر یک نویز ثابت دارید که:

با قطع کابل شبکه هم در Local Audio احساس می‌شود

یا فقط روی یک Handset وجود دارد

بیشتر باید Hardware و تجهیزات صوتی را بررسی کنید.

Acoustic Shield در مدل‌های پشتیبانی‌شده

بعضی Yealinkهای جدید از Acoustic Shield برای کاهش صدای محیط پشتیبانی می‌کنند.

در مدل‌های پشتیبانی‌شده مسیر می‌تواند:

Settings → Voice → Acoustic Shield

باشد.

پارامتر:

features.acoustic_shield.mode

نیز در مستندات Yealink وجود دارد.

این قابلیت برای صدای محیط طراحی شده و جایگزین رفع Packet Loss یا Jitter شبکه نیست.

Headset را هم جداگانه تست کنید

اگر مشکل فقط با Headset رخ می‌دهد:

Headset را روی تلفن سالم تست کنید.

یک Headset سالم را روی تلفن مشکل‌دار آزمایش کنید.

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

Firmware Headset را در مدل‌های قابل مدیریت بررسی کنید.

Gain و Hearing Protection را کنترل کنید.

اگر USB Headset دارید، سازگاری همان مدل با تلفن Yealink را بررسی کنید.

یک ماتریس ساده Headset بسازید

Phone A + Headset A = Noise

Phone A + Headset B = Clean

Phone B + Headset A = Noise

این نتیجه تقریباً Headset A را به‌عنوان مظنون اصلی مشخص می‌کند.

اما اگر هر دو Headset روی Phone A خراب‌اند

Phone A + Headset A = Noise
Phone A + Headset B = Noise

Phone B + Headset A = Clean

حالا Phone A، Port یا Configuration آن مظنون‌تر است.

مرحله یازدهم: Wi-Fi را از Ethernet جدا کنید

اگر مدل Yealink شما Wi-Fi دارد و کیفیت صدا فقط روی بی‌سیم خراب است، تماس را روی Ethernet آزمایش کنید.

مثلاً:

Wi-Fi:
Jitter بالا

Ethernet:
Clean

حالا باید موارد Wi-Fi مانند:

RSSI
Channel Congestion
Roaming
Interference
2.4 GHz / 5 GHz
Wireless QoS

بررسی شوند.

اگر روی Ethernet نیز همان Packet Loss وجود دارد، مشکل فقط Wireless نیست.

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

یکی از قوی‌ترین روش‌های تشخیص این است که دو PCAP داشته باشید:

Capture A:
Call with good audio

Capture B:
Call with bad audio

سپس مقایسه کنید:

مثال اول: مشکل واضح شبکه

Good Call:
Loss = 0%
Mean Jitter = 3 ms

Bad Call:
Loss = 3.2%
Mean Jitter = 48 ms

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

مثال دوم: PCAP سالم ولی Handset نویز دارد

RTP Loss = 0%
Jitter = پایین
Latency = طبیعی

Handset = Noise
Speaker = Clean
Headset = Clean

در این سناریو تغییر QoS احتمالاً وقت تلف‌کردن است.

Handset، کابل یا مسیر صوتی همان تلفن را بررسی کنید.

مثال سوم: Echo فقط از سمت مقصد خارجی

Internal Call:
Clean

External Call:
Echo

Speaker / Handset:
هر دو Echo

RTP:
No significant loss

در این حالت Gateway، PSTN Path یا Endpoint سمت مقابل باید بررسی شود.

مثال چهارم: فقط هنگام Backup صدا خراب می‌شود

Normal:
Clean

Backup Active:
High Jitter
Packet Loss
Choppy Audio

این الگو Congestion و Queueing را مطرح می‌کند.

QoS در Router و Switch، Upload Saturation و DSCP Handling را بررسی کنید.

قبل از تغییر تنظیمات تلفن این ترتیب را رعایت کنید

1. Handset / Speaker / Headset comparison

2. Internal vs External call

3. One phone vs multiple phones

4. Capture RTP

5. Measure Loss / Jitter / Delta

6. Check Codec

7. Check DSCP

8. Check Congestion

9. Check Echo Canceller

10. Change one setting only

11. Retest with same call scenario

اگر پنج گزینه را هم‌زمان تغییر دهید و مشکل حل شود، دیگر نمی‌دانید کدام تغییر علت را رفع کرده است.

چه زمانی Factory Reset منطقی است؟

Factory Reset باید بعد از تست‌های ساده‌تر انجام شود، نه در مرحله اول.

اگر:

فقط یک تلفن مشکل دارد.

Handset و کابل سالم هستند.

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

Configuration مشکوک است.

می‌توانید بعد از Backup، Reset کنترل‌شده انجام دهید.

اگر تلفن از Auto Provisioning استفاده می‌کند، ابتدا مطمئن شوید همان Configuration خراب بعد از Reset دوباره روی دستگاه اعمال نمی‌شود.

اگر مشکل بعد از Auto Provisioning ایجاد شده

پارامترهای صوتی داخل Common CFG یا MAC CFG را بررسی کنید.

به‌خصوص اگر تغییراتی در:

Codec Priority
Echo Cancellation
Audio Gain
Jitter Buffer
QoS
Acoustic Settings

اعمال شده است.

فایل قبلی را با نسخه فعلی Diff کنید و تغییر صوتی را روی یک تلفن آزمایشی Rollback کنید.

چک‌لیست نهایی تشخیص کیفیت تماس Yealink

پرسش‌های متداول درباره اکو و تأخیر VoIP در Yealink

چطور بفهمیم نویز Yealink از شبکه است یا خود تلفن؟

همان تماس را با Handset، Speaker و Headset امتحان کنید و تلفن را با دستگاه‌های دیگر همان شبکه مقایسه کنید. اگر فقط یک مسیر صوتی یا یک تلفن مشکل دارد، سخت‌افزار یا تنظیمات Endpoint محتمل‌تر است. اگر چند دستگاه هم‌زمان مشکل دارند، شبکه و زیرساخت را بررسی کنید.

چه مقدار Packet Loss برای VoIP زیاد است؟

برای طراحی صدای باکیفیت بهتر است Packet Loss بسیار پایین باشد و معمولاً کمتر از حدود یک درصد هدف مناسبی است. با این حال Burst Loss می‌تواند حتی با میانگین پایین نیز شنیدنی باشد؛ بنابراین فقط Average Loss را بررسی نکنید.

Jitter در تماس VoIP چیست؟

Jitter تغییر در فاصله زمانی رسیدن Packetهای RTP است. مقدار زیاد باعث می‌شود Packetها نامنظم به Audio Processor برسند و صدا تکه‌تکه یا رباتی شود.

آیا افزایش Jitter Buffer مشکل را حل می‌کند؟

گاهی می‌تواند Packetهای دیررس بیشتری را جبران کند، اما Buffer بزرگ‌تر Delay را نیز افزایش می‌دهد. بهتر است ابتدا Jitter واقعی شبکه اندازه‌گیری و علت آن برطرف شود.

DSCP 46 در Yealink چه کاربردی دارد؟

Yealink در بسیاری از تلفن‌های SIP مقدار DSCP 46 را به‌صورت پیش‌فرض برای RTP استفاده می‌کند تا شبکه بتواند Voice Traffic را به‌عنوان ترافیک حساس شناسایی کند. Switch و Router نیز باید این Marking را حفظ و برای آن Queue مناسب تعریف کنند.

آیا Codec باعث اکو می‌شود؟

Codec معمولاً منشأ اصلی Echo آکوستیک نیست. Echo بیشتر به Acoustic Coupling و Echo Cancellation مرتبط است، هرچند Delay و پردازش Media می‌توانند آن را محسوس‌تر کنند.

چرا فقط با Speakerphone اکو دارم؟

اگر Handset و Headset سالم‌اند ولی Speakerphone Echo دارد، Acoustic Coupling و Echo Canceller را بررسی کنید. کاهش موقت Speaker Volume نیز تست مفیدی است.

MOS چیست و آیا برای پیدا کردن مشکل کافی است؟

MOS شاخصی برای کیفیت ادراک‌شده یا تخمینی صداست. MOS پایین می‌گوید کیفیت مناسب نیست، اما علت را مشخص نمی‌کند؛ باید Packet Loss، Jitter، Delay، Codec و مسیر RTP نیز بررسی شوند.

بهترین روش برای بررسی کیفیت تماس Yealink چیست؟

از تماس مشکل‌دار PCAP بگیرید، دو جهت RTP را در Wireshark جداگانه Analyze کنید و Loss، Jitter، Delta، Codec و DSCP را با یک تماس سالم مقایسه کنید. هم‌زمان Handset، Speaker و Headset را نیز آزمایش کنید تا مشکل دستگاه از شبکه جدا شود.

جمع‌بندی

برای رفع نویز، اکو و تأخیر صدا در Yealink نباید همه مشکلات صوتی را «ضعف اینترنت» بدانید. اولین مرحله این است که Handset، Speaker و Headset را با هم مقایسه کنید. اگر فقط یک مسیر صوتی خراب است، احتمال مشکل دستگاه یا تجهیزات صوتی بیشتر می‌شود؛ اگر چند تلفن روی یک شبکه هم‌زمان صدای رباتی یا تکه‌تکه دارند، شبکه باید جدی‌تر بررسی شود.

بعد از این تفکیک، PCAP همان تماس را بگیرید و RTP را در Wireshark تحلیل کنید. Packet Loss، Jitter، Max Delta و جهت Stream نشان می‌دهند کدام سمت تماس مشکل دارد. Latency زیاد معمولاً مکالمه را کند می‌کند، Jitter باعث نامنظم‌شدن صدا می‌شود و Packet Loss هجاها و بخش‌هایی از صوت را حذف می‌کند.

در نهایت QoS و DSCP را End-to-End بررسی کنید؛ DSCP 46 روی خود Yealink زمانی مفید است که Switch و Router نیز آن را حفظ و اولویت‌بندی کنند. Codec، Jitter Buffer، Echo Cancellation و Headset را فقط بعد از اندازه‌گیری شبکه تغییر دهید. با این روش به‌جای تغییر تصادفی تنظیمات، می‌توانید دقیقاً مشخص کنید مشکل از تلفن، شبکه داخلی، اینترنت، PBX یا سمت مقابل است.