عیب‌یابی حرفه‌ای تلفن یالینک با Packet Capture و Log؛ پیدا کردن دقیق خطاها

یک Packet Capture درست می‌تواند نشان دهد REGISTER اصلاً از تلفن خارج شده یا نه، PBX چه Status Codeای برگردانده، INVITE و ACK کامل شده‌اند یا خیر، RTP در هر دو جهت وجود دارد یا نه و مشکل قبل یا بعد از NAT، Firewall یا SIP Server ایجاد شده است. Log دستگاه نیز اتفاقاتی را نشان می‌دهد که الزاماً از روی Packetها دیده نمی‌شوند؛ مانند تغییر وضعیت Account، DNS، Certificate، Provisioning، Firmware و خطاهای داخلی Phone.

در این راهنما یاد می‌گیریم چگونه از Yealink یک بسته عیب‌یابی قابل استفاده تهیه کنیم؛ نه یک PCAP چندساعته و چندصد مگابایتی که هیچ‌کس نداند مشکل در کدام ثانیه آن رخ داده است. در ادامه Local Log، Syslog، PCAP، Export All Diagnostic Files، Call-ID، RTP Stream Analysis، مشکلات TLS/SRTP و نحوه حذف اطلاعات حساس قبل از ارسال فایل برای پشتیبانی را بررسی می‌کنیم.

یک بسته عیب‌یابی خوب Yealink باید چه چیزهایی داشته باشد؟

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

سه فایل اصلی که Yealink برای عیب‌یابی پیشنهاد می‌کند

در مستندات فعلی Yealink، برای بررسی Bug یا مشکل فنی معمولاً سه بخش اصلی درخواست می‌شوند:

به همین دلیل در بسیاری از مدل‌های فعلی، قابلیت Export All Diagnostic Files برای جمع‌کردن این اطلاعات در یک بسته واحد وجود دارد.

بهترین روش برای مشکلی که سریع قابل تکرار است

اگر مشکل را می‌توانید طی چند دقیقه دوباره ایجاد کنید، معمولاً بهترین روش همین Export All Diagnostic Files است.

در بسیاری از تلفن‌های Yealink مسیر زیر وجود دارد:

Settings → Configuration

و در Firmwareها یا پلتفرم‌های جدیدتر ممکن است بخش Diagnostic در مسیر دیگری مانند:

System → System Diagnostic

دیده شود.

نام دقیق منو با مدل و Firmware متفاوت است، اما منطق کار یکسان است.

روش صحیح Export All Diagnostic Files

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

Yealink نیز توصیه می‌کند فایل‌ها بلافاصله بعد از بازتولید مشکل Export شوند تا داده‌های مرتبط بازنویسی نشوند.

Export All Diagnostic Files چه چیزی تولید می‌کند؟

در مدل‌های مستندشده فعلی، خروجی معمولاً یک فایل TAR است و می‌تواند شامل موارد زیر باشد:

PCAP Trace،

boot.log،

sys.log،

Application Log در پلتفرم‌های پشتیبانی‌شده،

و فایل Configuration باینری.

نام فایل می‌تواند مشابه این باشد:

001565A1B2C3-DiagnoseInfo.tar

سطح Log هنگام Export All چه می‌شود؟

در مستندات فعلی Yealink، هنگام Start کردن Export All Diagnostic Files سطح System Log به‌طور خودکار روی 6 قرار می‌گیرد تا اطلاعات کامل‌تری ثبت شوند.

پس از Stop نیز در برخی خانواده‌ها Log Level دوباره به مقدار عادی مانند 3 برمی‌گردد.

این یعنی در استفاده از Export All معمولاً لازم نیست به‌صورت جداگانه Level 6 را دائمی نگه دارید.

Log Level 6 یعنی چه؟

Yealink از ساختار Severity مشابه Syslog استفاده می‌کند:

برای عیب‌یابی کوتاه‌مدت، Yealink معمولاً Level 6 را پیشنهاد می‌کند.

Local Log چیست؟

Local Log داخل خود تلفن ذخیره می‌شود و می‌توانید آن را از Web UI Export کنید.

در خانواده‌هایی که این پارامترها را پشتیبانی می‌کنند، ساختار Provisioning می‌تواند شبیه این باشد:

static.local_log.enable = 1
static.local_log.level = 6

اما قبل از استفاده در Template عمومی، Parameter Guide همان مدل و Firmware را بررسی کنید.

Local Log محدودیت مهمی دارد

Local Log برای مشکل کوتاه‌مدت عالی است، اما برای مشکلی که روزی یک بار رخ می‌دهد انتخاب ایده‌آلی نیست.

Yealink در مستندات فعلی هشدار می‌دهد Local Log ظرفیت محدودی دارد. در برخی پلتفرم‌های فعلی حداکثر آن تا حدود 20MB قابل تنظیم است و پس از پرشدن، اطلاعات قدیمی بازنویسی می‌شوند.

مهم‌تر از آن، Local Log ممکن است پس از Restart دستگاه از بین برود.

بنابراین اگر مشکل شما شامل:

ریست ناگهانی تلفن،

Reboot تصادفی،

قطع رجیستر یک بار در روز،

یا مشکل چندساعته

است، Remote Syslog انتخاب بسیار مناسب‌تری است.

چه زمانی از Remote Syslog استفاده کنیم؟

اگر مشکل احتمالی یا دیرتکرار است، Log را روی یک Server خارجی بفرستید.

مزیت این روش این است که حتی اگر تلفن Reboot شود، Logهای قبل از Restart روی Server باقی می‌مانند.

در مستندات فعلی Yealink نیز Syslog برای مشکلاتی که نیاز به مشاهده طولانی‌مدت دارند توصیه شده است.

تنظیم Syslog Server در Yealink

در مدل‌ها و Firmwareهایی که Parameterهای فعلی Syslog را دارند، Configuration می‌تواند شبیه این باشد:

static.syslog.enable = 1
static.syslog.server = 10.50.10.30
static.syslog.server_port = 514
static.syslog.transport_type = 0
static.syslog.level = 6

در مستندات جدید Yealink برای برخی پلتفرم‌ها Transportهای UDP، TCP و TLS پشتیبانی شده‌اند.

اگر Server و Firmware شما امکان TCP یا TLS دارند، برای محیط سازمانی می‌توانید آن‌ها را نیز بررسی کنید.

UDP Syslog را به کل اینترنت باز نکنید

Syslog Server باید فقط از Voice VLAN یا IP تلفن‌های مجاز قابل دسترسی باشد.

اگر Port 514 را روی یک Server عمومی بدون Firewall باز کنید، هم Logهای ناخواسته دریافت می‌کنید و هم سطح حمله Server افزایش پیدا می‌کند.

ساخت یک Syslog Server ساده روی Ubuntu

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

sudo apt update
sudo apt install -y rsyslog

برای UDP Listener می‌توانید در Configuration مربوط به rsyslog این بخش را فعال کنید:

module(load="imudp")
input(type="imudp" port="514")

سپس:

sudo systemctl restart rsyslog
sudo ss -lunp | grep ':514'

روی Firewall فقط IP یا Subnet تلفن‌ها را Allow کنید.

مرحله بعد: Packet Capture از خود Yealink

PCAP مهم‌ترین ابزار برای مشکلات SIP و شبکه است.

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

Settings → Configuration → Pcap Feature

و در دستگاه‌های جدیدتر:

System → System Diagnostic

برای Capture وجود دارد.

روش استاندارد:

Start → بازتولید مشکل → Stop → Export.

Capture را چند دقیقه قبل از مشکل شروع کنیم؟

برای مشکل قابل تکرار بهتر است فقط چند ثانیه قبل از اقدام موردنظر Capture را Start کنید.

مثلاً برای مشکل تماس خروجی:

این Capture بسیار مفیدتر از فایلی است که 45 دقیقه ترافیک نامرتبط دارد.

چرا زمان دقیق رخداد این‌قدر مهم است؟

یک Capture ممکن است شامل چند REGISTER، چند INVITE، Keepalive، DNS Query و تماس مختلف باشد.

اگر فقط بگویید «حدود ساعت 10 مشکل شد»، Analyst باید صدها Packet را حدس بزند.

اما اگر بگویید:

Issue Time: 10:42:43 +03:30
Extension: 201
Destination: 0912xxxxxxx
Symptom: Call dropped

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

ساعت Yealink و سیستم تحلیل باید هماهنگ باشند

اگر ساعت Phone پنج دقیقه اشتباه باشد، تطبیق Syslog، PBX Log و PCAP دشوار می‌شود.

قبل از تست، NTP و Time Zone را بررسی کنید.

برای مشکلات TLS این موضوع دو برابر مهم است، چون ساعت نادرست علاوه بر Log Timeline می‌تواند Certificate Validation را نیز خراب کند.

اولین Filter در Wireshark: فقط SIP

اگر SIP بدون TLS است، ساده‌ترین Filter:

sip

فقط REGISTERها را ببینید

sip.Method == "REGISTER"

برای مشکل رجیستر شدن و قطع‌ووصلی Account این Filter بسیار مفید است.

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

فقط INVITEها را ببینید

sip.Method == "INVITE"

فقط پاسخ‌های خطای SIP

Wireshark فیلد Status Code را مستقیماً می‌شناسد.

sip.Status-Code >= 400

اما توجه کنید پاسخ‌هایی مثل 401 و 407 همیشه «خرابی» نیستند. در Digest Authentication معمولاً Server ابتدا Challenge ارسال می‌کند و Client سپس Request احراز هویت‌شده را می‌فرستد.

Filter کردن فقط IP تلفن

اگر PCAP شلوغ است:

ip.addr == 192.168.20.45

یک Filter کاربردی برای عیب‌یابی تلفن

ip.addr == 192.168.20.45 && (sip || rtp || dns || tls || icmp)

این Filter برای مشاهده بخش زیادی از ترافیک مرتبط با Phone مناسب است، ولی بسته به مشکل ممکن است پروتکل‌های دیگری نیز لازم باشند.

SIP Call-ID؛ بهترین شناسه برای دنبال‌کردن یک تماس

در SIP هر Dialog دارای شناسه‌ای به نام Call-ID است.

نمونه:

Call-ID: 0_2648917352@192.168.20.45

RFC 3261 تعریف می‌کند که Call-ID برای گروه‌بندی پیام‌های یک تماس استفاده می‌شود و همراه Tagهای From و To در شناسایی Dialog نقش دارد.

فیلتر کردن تماس با Call-ID

Call-ID را از INVITE انتخاب کنید و Filter بسازید:

sip.Call-ID == "0_2648917352@192.168.20.45"

در این حالت پیام‌های SIP مربوط به همان Dialog بسیار راحت‌تر دیده می‌شوند.

یک نکته حرفه‌ای درباره PBX و Call-ID

اگر PBX به‌صورت B2BUA کار کند، ممکن است سمت تلفن و سمت Trunk دو Call-ID متفاوت داشته باشند.

بنابراین Call-ID مشاهده‌شده در PCAP Yealink الزاماً همان Call-ID سمت Provider نیست.

برای تطبیق دو Leg از موارد زیر نیز کمک بگیرید:

زمان تماس،

Calling Number،

Called Number،

Unique ID خود PBX،

و Logهای Server.

تماس 30 ثانیه‌ای؛ در PCAP دنبال چه بگردیم؟

یک Call Flow ساده معمولاً چیزی شبیه این است:

INVITE  -------->
        <-------- 100 Trying
        <-------- 180 Ringing
        <-------- 200 OK
ACK     -------->

RTP     <=======>

BYE     -------->
        <-------- 200 OK

اگر 200 OK آمده ولی ACK به مقصد نرسیده باشد، مسیر عیب‌یابی با حالتی که RTP از یک سمت وجود ندارد کاملاً متفاوت است.

از Telephony → VoIP Calls استفاده کنید

لازم نیست تمام SIP Packetها را دستی دنبال کنید.

در Wireshark:

Telephony → VoIP Calls

را باز کنید.

در این صفحه می‌توانید تماس‌های شناسایی‌شده را ببینید و برای تماس منتخب Flow Sequence را باز کنید.

این Flow به‌خصوص برای INVITE، 180، 200 OK، ACK، BYE، REFER و سایر پیام‌های SIP بسیار مفید است.

RTP را جدا از SIP تحلیل کنید

SIP ممکن است کاملاً سالم باشد ولی Audio مشکل داشته باشد.

در Wireshark:

Telephony → RTP → RTP Streams

را باز کنید.

این صفحه تمام Streamهای RTP شناسایی‌شده را نشان می‌دهد.

RTP Stream Analysis چه چیزی نشان می‌دهد؟

در نسخه‌های فعلی Wireshark، RTP Stream Analysis اطلاعاتی مانند این موارد را ارائه می‌کند:

صدای یک‌طرفه را چگونه با RTP پیدا کنیم؟

در یک تماس دوطرفه معمولاً انتظار داریم Media در دو جهت وجود داشته باشد.

اگر فقط این Stream دیده شود:

192.168.20.45:11782 → 10.10.10.5:18044

ولی Stream برعکس وجود نداشته باشد، علت صدای یک‌طرفه بسیار واضح‌تر می‌شود.

حالا باید NAT، Firewall، SDP Address، RTP Port و Media Path را بررسی کنید.

اگر RTP توسط Wireshark شناسایی نشد چه؟

همه UDP Packetها به‌طور خودکار RTP تشخیص داده نمی‌شوند.

ابتدا SDP داخل INVITE و 200 OK را بررسی کنید و Portهای Media را پیدا کنید.

نمونه:

m=audio 11782 RTP/AVP 0 8 101

بعد می‌توانید همان UDP Port را بررسی کنید یا در Wireshark از Decode As برای تحلیل درست Stream استفاده کنید.

RTP Player چه کمکی می‌کند؟

اگر RTP رمزگذاری نشده و Codec توسط Wireshark پشتیبانی شود، RTP Player می‌تواند Stream را پخش کند.

مسیر:

Telephony → RTP → RTP Player

در این بخش Waveform هر جهت نیز قابل مشاهده است.

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

PCAP می‌تواند خود مکالمه را هم افشا کند

این نکته امنیتی بسیار مهم است.

اگر RTP رمزگذاری نشده باشد، شخصی که PCAP را در اختیار دارد ممکن است بتواند Audio تماس را بازسازی و پخش کند.

بنابراین PCAP مربوط به VoIP را مثل یک فایل ضبط مکالمه حساس در نظر بگیرید.

اگر SRTP فعال باشد چه اتفاقی می‌افتد؟

با SRTP، Payload صوتی رمزگذاری می‌شود و Wireshark بدون Key لازم نمی‌تواند Audio را مثل RTP معمولی پخش کند.

با این حال اطلاعات Header و Timing در بسیاری از Captureها هنوز برای تحلیل Packet Flow، Sequence و Loss مفید هستند.

اگر SIP روی TLS باشد چه؟

در SIP over TLS، Wireshark روی Capture شبکه ممکن است به‌جای INVITE و REGISTER واضح، فقط TLS Session را ببیند.

در چنین Captureای این Filter:

sip.Method == "INVITE"

ممکن است هیچ نتیجه‌ای ندهد، چون SIP داخل TLS رمزگذاری شده است.

در این سناریو از Log تلفن، Log PBX و ابزار Diagnostic خود Server برای بررسی Signaling استفاده کنید و TLS را فقط برای راحت‌ترشدن تحلیل در Production غیرفعال نکنید.

Packet Capture از خود Phone یا از Switch؟

برای بسیاری از مشکلات، Capture خود Yealink کافی است.

اما اگر می‌خواهید مشخص کنید Packet:

از تلفن خارج شده،

به Switch رسیده،

در Firewall Drop شده،

یا از Provider برنگشته است،

گاهی Capture در چند نقطه لازم می‌شود.

مقایسه دو Capture برای پیدا کردن محل گم‌شدن Packet

فرض کنید Yealink INVITE را در PCAP خود دارد:

Yealink PCAP: INVITE transmitted

اما PBX همان INVITE را نمی‌بیند.

در این حالت Phone احتمالاً Request را ساخته و ارسال کرده است و باید مسیر بین Phone و PBX را بررسی کنید.

اگر تلفن روی یک اینترنت کار می‌کند و روی اینترنت دیگر نه، همین روش مقایسه‌ای را می‌توانید همراه راهنمای عیب‌یابی Yealink روی اینترنت‌های مختلف انجام دهید.

Local Log و PCAP باید یکدیگر را تکمیل کنند

هیچ‌کدام به‌تنهایی همیشه کافی نیستند.

مثلاً PCAP نشان می‌دهد:

TLS connection terminated

اما Device Log ممکن است مشخص کند دلیل داخلی:

Certificate Expired،

Trust Failure،

DNS Failure،

یا NTP/Time

بوده است.

برای مشکلات Audio، Audio Diagnostic را هم بررسی کنید

در Firmwareها و مدل‌هایی که گزینه Audio Diagnostic وجود دارد، برای مشکلات خاص Audio بهتر است آن فایل نیز همراه سایر Diagnosticها جمع‌آوری شود.

Yealink در مستندات فعلی اشاره می‌کند که در برخی نسخه‌ها Audio Diagnostic یک فایل جداگانه است و ممکن است داخل بسته معمول All Diagnostic Files قرار نگیرد.

بنابراین اگر مشکل شما:

Noise،

Echo،

قطع Audio،

یا رفتار غیرعادی پردازش صوت

است، وجود این گزینه را در Firmware خود بررسی کنید.

چرا باید فقط یک مشکل را در هر Capture بازتولید کنیم؟

فرض کنید در یک Capture:

سه تماس بگیرید،

Account را Disable کنید،

Firmware Check انجام دهید،

و PBX را Restart کنید.

حالا Analyst نمی‌داند کدام رفتار به مشکل اصلی مربوط بوده است.

روش بهتر:

یک Capture → یک سناریو → یک رخداد.

نمونه گزارش خوب برای پشتیبانی

Model: Yealink T54W
Firmware: xx.xx.xx.xx
Phone IP: 192.168.20.45
Account: 201

Test Date: 2026-10-13
Timezone: +03:30

Call:
201 → 0912xxxxxxx

Issue:
Call established successfully.
Audio was normal.
Call disconnected at 10:42:43.

Expected:
Call should remain connected.

Reproduction:
Reproduced 3/3 times.

Files:
- DiagnoseInfo.tar
- Screenshot
- PBX log

نمونه گزارش بد

Phone not working.
Please check attached file.

حتی بهترین PCAP دنیا بدون توضیح دقیق زمان و سناریو می‌تواند ساعت‌ها وقت تحلیل را تلف کند.

اطلاعات حساس داخل PCAP چیست؟

قبل از ارسال فایل برای شخص ثالث باید بدانید PCAP ممکن است شامل چه اطلاعاتی باشد.

config.bin حتی حساس‌تر است

فایل Configuration می‌تواند اطلاعاتی درباره:

SIP Account،

Provisioning،

Network،

Certificate،

Directory،

و تنظیمات مدیریتی

داشته باشد.

آن را مثل یک فایل عمومی در Ticket یا Forum قرار ندهید.

Sanitization یا پاک‌سازی اطلاعات حساس چگونه انجام شود؟

اول یک نسخه اصلی را بدون تغییر نگه دارید. فایل اصلی برای تحلیل دقیق و اثبات رخداد ارزشمند است.

بعد یک نسخه جدا برای ارسال خارجی بسازید.

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

شماره‌های غیرمرتبط،

نام کاربران،

Credentialهای واضح داخل Log یا CFG،

URLهای حاوی Token،

و اطلاعات شبکه غیرمرتبط

را حذف یا جایگزین کنید.

PCAP را با Hex Editor دست‌کاری نکنید

ویرایش دستی Packet Bytes می‌تواند طول Packet، Checksum یا Structure فایل را خراب کند و تحلیل را غیرقابل اعتماد سازد.

اگر امکان پاک‌سازی استاندارد PCAP ندارید، روش امن‌تر این است که از ابتدا Capture را کوتاه و محدود بگیرید و فایل را فقط از مسیر امن برای فرد مورد اعتماد ارسال کنید.

چگونه PCAP کوچک‌تری برای ارسال بسازیم؟

در Wireshark Display Filter مرتبط را اعمال کنید و سپس از:

File → Export Specified Packets

یک Capture جدید ایجاد کنید.

مثلاً:

ip.addr == 192.168.20.45 && (sip || rtp || dns)

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

از فایل اصلی Hash بگیرید

اگر Diagnostic برای یک پرونده مهم فنی یا امنیتی نگهداری می‌شود، می‌توانید Hash فایل اصلی را ثبت کنید تا بعداً مشخص باشد فایل تغییر نکرده است.

در Linux:

sha256sum 001565A1B2C3-DiagnoseInfo.tar

Hash مشکل را حل نمی‌کند، اما برای مدیریت نسخه اصلی و نسخه Sanitized مفید است.

Diagnostic File را با پیام‌رسان عمومی نفرستید

اگر PCAP حاوی RTP، شماره مشتری یا اطلاعات SIP است، آن را از مسیر کنترل‌شده و ترجیحاً رمزگذاری‌شده منتقل کنید.

همچنین بعد از پایان Ticket مشخص کنید فایل‌های Diagnostic چه مدت باید نگهداری شوند.

قبل از ارسال، اندازه فایل را بررسی کنید

Yealink در راهنمای فعلی خود اشاره می‌کند Diagnostic File بسیار کوچک ممکن است نشانه Capture ناقص باشد؛ در برخی راهنماها فایل‌های زیر حدود 100KB معمولاً مشکوک به Capture نامعتبر در نظر گرفته شده‌اند.

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

اگر مشکل Reboot ناگهانی است چه کنیم؟

Export All Diagnostic معمولی ممکن است نتواند لحظه قبل از Reboot را کامل نگه دارد.

برای این سناریو Remote Syslog بسیار مهم‌تر می‌شود.

Syslog Server را قبل از بروز مشکل فعال کنید و اجازه دهید Phone برای مدت کافی Log ارسال کند.

بعد Timestamp ریست را با Logهای Switch، PoE و PBX مقایسه کنید.

اگر مشکل یک بار در روز رخ می‌دهد چه؟

PCAP داخلی چندساعته همیشه بهترین انتخاب نیست.

بهتر است:

اگر فقط هنگام یک تماس خاص مشکل داریم

شماره مبدأ، مقصد و زمان را ثبت کنید.

بعد Call-ID را از SIP پیدا کنید و تمام پیام‌های همان تماس را دنبال کنید.

سپس RTP Stream همان تماس را بررسی کنید.

این روش بسیار دقیق‌تر از جست‌وجوی کل Capture است.

اگر تماس برقرار نمی‌شود، اول Signaling را بررسی کنید

برای مشکل Call Setup این ترتیب معمولاً مناسب است:

اگر تماس خوب است ولی صدا خراب است، SIP را مقصر ندانید

وقتی Call Setup کامل است:

INVITE → 200 OK → ACK

ولی کاربر از صدای بریده، تأخیر یا قطع Audio شکایت دارد، تمرکز را به RTP منتقل کنید.

Packet Loss، Jitter، Max Delta، Sequence Error و جهت Streamها را بررسی کنید.

اگر مشکل فقط بعد از Provisioning رخ می‌دهد

Capture و Log را از قبل Provisioning شروع کنید.

بعد زمان دقیق Download شدن CFG و Restart احتمالی را ثبت کنید.

در این سناریو config.bin و Log Device اهمیت زیادی دارند، چون فقط PCAP ممکن است نشان دهد فایل با HTTP 200 دریافت شده اما مشخص نکند کدام Parameter رفتار Phone را تغییر داده است.

اگر مشکل بعد از Firmware Update شروع شده

همراه Diagnostic این موارد را هم ثبت کنید:

Previous Firmware: xx.xx.xx.xx
Current Firmware:  yy.yy.yy.yy
Issue before upgrade: No
Issue after upgrade: Yes

این اطلاعات برای تشخیص Firmware Regression بسیار مهم هستند.

اشتباه اول: Capture را بعد از مشکل Start می‌کنیم

اگر Register Failure در ساعت 10:20 رخ داده و شما 10:22 Capture را شروع کرده‌اید، علت اصلی ممکن است دیگر در فایل وجود نداشته باشد.

Capture باید قبل از Reproduction شروع شود.

اشتباه دوم: بعد از مشکل چند دقیقه صبر می‌کنیم

بعد از Reproduction سریع Stop و Export کنید.

ادامه Capture فقط Noise اضافه می‌کند و ممکن است Logهای مهم نیز بازنویسی شوند.

اشتباه سوم: ساعت دقیق را نمی‌نویسیم

برای یک تماس 20 ثانیه‌ای در Capture یک‌ساعته، Timestamp دقیق ارزش بسیار زیادی دارد.

اشتباه چهارم: فقط Screenshot می‌فرستیم

Screenshot عبارت:

Register Failed

نشان نمی‌دهد چرا Register شکست خورده است.

PCAP می‌تواند نشان دهد Server اصلاً پاسخ نداده یا 403، 404، 408 یا خطای دیگری برگشته است.

اشتباه پنجم: فایل config.bin را عمومی منتشر می‌کنیم

این فایل ممکن است شامل Configuration حساس باشد.

آن را فقط برای پشتیبانی مورد اعتماد و از مسیر مناسب ارسال کنید.

اشتباه ششم: برای یک مشکل ساده Capture چندساعته می‌گیریم

Capture بزرگ همیشه Capture بهتر نیست.

بهترین Capture همان است که چند ثانیه قبل از مشکل شروع و چند ثانیه بعد از آن متوقف شده باشد.

اشتباه هفتم: TLS را برای تحلیل خاموش می‌کنیم و همان را Production می‌گذاریم

برای مشکل TLS باید خود TLS را عیب‌یابی کرد.

اینکه UDP کار می‌کند ولی TLS نه یک سرنخ است؛ راه‌حل دائمی خاموش‌کردن Encryption نیست.

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

اگر RTP رمزگذاری نشده باشد، فایل می‌تواند بخشی از مکالمه را در خود داشته باشد.

قبل از اشتراک خارجی، محدوده Capture و اطلاعات موجود در آن را بررسی کنید.

چک‌لیست نهایی قبل از تماس با پشتیبانی

پرسش‌های متداول درباره Log و Packet Capture در Yealink

چطور از تلفن Yealink Packet Capture بگیریم؟

در بسیاری از مدل‌ها از Web UI وارد Settings → Configuration شوید، Pcap Feature یا Export All Diagnostic Files را Start کنید، مشکل را بازتولید کنید، سپس Stop و Export را بزنید. در Firmwareهای جدیدتر ممکن است این بخش در System → System Diagnostic قرار داشته باشد.

Log Level مناسب برای عیب‌یابی Yealink چیست؟

Yealink برای جمع‌آوری Diagnostic کامل معمولاً Level 6 را توصیه می‌کند. در Export All Diagnostic Files نیز این سطح در مدل‌های مستندشده به‌طور خودکار هنگام Capture فعال می‌شود.

Export All Diagnostic Files شامل چه چیزهایی است؟

بسته به مدل، فایل TAR می‌تواند شامل PCAP، boot.log، sys.log، Application Log و فایل Configuration باشد. برای بعضی مشکلات صوتی Audio Diagnostic ممکن است جداگانه نیاز باشد.

چرا باید PCAP را قبل از بروز مشکل Start کنیم؟

پیام اصلی که علت مشکل را نشان می‌دهد ممکن است فقط در لحظه شروع خرابی ارسال شود. اگر Capture بعد از رخداد شروع شود، REGISTER، DNS Query، INVITE یا TLS Handshake اصلی از دست می‌رود.

SIP Call-ID چه کمکی به عیب‌یابی می‌کند؟

Call-ID برای شناسایی و گروه‌بندی پیام‌های یک SIP Dialog استفاده می‌شود. با Filter کردن آن در Wireshark می‌توانید Request و Responseهای مربوط به همان تماس را جدا کنید.

چگونه Packet Loss و Jitter تماس Yealink را ببینیم؟

در Wireshark از Telephony → RTP → RTP Streams و سپس RTP Stream Analysis استفاده کنید. این بخش Packet Loss، Jitter، Delta، Sequence Error و سایر آمار Stream را نمایش می‌دهد.

چرا در PCAP تلفن SIP دیده نمی‌شود؟

اگر SIP over TLS فعال باشد، Signaling روی شبکه رمزگذاری شده و Wireshark ممکن است فقط TLS را نشان دهد. در این حالت از Device Log و PBX Log نیز برای بررسی SIP استفاده کنید.

آیا PCAP می‌تواند صدای تماس را شامل شود؟

بله. اگر RTP رمزگذاری نشده باشد، در بسیاری از تماس‌ها می‌توان Audio را با RTP Player بازسازی کرد؛ بنابراین PCAP VoIP باید فایل حساس تلقی شود.

برای مشکل تصادفی که هر چند ساعت یک بار رخ می‌دهد PCAP بهتر است یا Syslog؟

برای چنین مشکلی Remote Syslog معمولاً ارزش بیشتری دارد، زیرا Local Log ظرفیت محدود دارد و ممکن است پس از Restart از بین برود. در زمان نزدیک به رخداد می‌توان PCAP هدفمند نیز جمع کرد.

قبل از ارسال Log و PCAP چه اطلاعاتی را حذف کنیم؟

شماره‌های غیرضروری، Credentialها، Tokenها و Configuration حساس را بررسی کنید. نسخه اصلی را امن و بدون تغییر نگه دارید و برای اشتراک خارجی نسخه محدود یا Sanitized تهیه کنید. PCAP را با ویرایش دستی Byteها خراب نکنید.

جمع‌بندی

عیب‌یابی حرفه‌ای Yealink از حدس شروع نمی‌شود؛ از جمع‌آوری شواهد شروع می‌شود. برای مشکلی که سریع قابل تکرار است، Export All Diagnostic Files یکی از بهترین گزینه‌هاست زیرا PCAP، Log و Configuration را در یک بازه مشخص جمع می‌کند. Capture را قبل از ایجاد مشکل Start کنید، فقط همان سناریو را اجرا کنید و بلافاصله بعد از رخداد Stop و Export کنید.

زمان دقیق رخداد، Time Zone، مدل، Firmware، Extension، شماره مقصد و شرح رفتار را کنار فایل‌ها بنویسید. برای SIP از Call-ID و Flow Sequence کمک بگیرید و برای مشکلات Audio، RTP Streams را از نظر Packet Loss، Jitter، Delta و Sequence Error بررسی کنید.

برای مشکلاتی که چند ساعت یا چند روز طول می‌کشد تا تکرار شوند، Remote Syslog ارزش بیشتری دارد، چون Local Log ظرفیت محدود دارد و ممکن است پس از Restart از بین برود. در مشکلات Audio نیز اگر Firmware گزینه Audio Diagnostic دارد، آن را همراه سایر فایل‌ها جمع کنید.

در نهایت فراموش نکنید Diagnostic File می‌تواند اطلاعات حساسی داشته باشد. PCAP بدون SRTP حتی ممکن است قابل تبدیل به صدای تماس باشد و config.bin نیز می‌تواند اطلاعات مهم تنظیمات را در خود داشته باشد. نسخه اصلی را امن نگه دارید، برای ارسال خارجی Scope را محدود کنید و فقط اطلاعات لازم برای حل مشکل را با پشتیبانی مورد اعتماد به اشتراک بگذارید.