Amir Jabbari
در این راهنما ابتدا PRT را از تلفن Cisco می‌گیریم، بعد ساختار آن را می‌شناسیم و در نهایت یاد می‌گیریم چطور زمان رخداد، وضعیت رجیستر، اطلاعات شبکه و خطاهای مرتبط را با لاگ PBX، CUCM یا SBC تطبیق دهیم. در پایان نیز توضیح می‌دهیم چرا قبل از ارسال فایل برای شخص دیگر باید به اطلاعات حساس داخل آن توجه کنید.
PRT چیست؟ عبارت PRT مخفف Problem Report Tool است؛ یعنی ابزار گزارش مشکل. این ابزار برای ثبت تصویر تشخیصی از وضعیت تلفن در نزدیکی زمان رخداد مشکل ساخته شده است. PRT جای Packet Capture، لاگ PBX یا Trace سمت سرور را نمی‌گیرد، اما معمولاً بهترین نقطه شروع برای فهمیدن وضعیت خود تلفن است.
PRT برای چه مشکلاتی به درد می‌خورد؟
فرض کنید کاربر می‌گوید «تلفن امروز صبح برای چند دقیقه رجیستر نبود». این جمله برای عیب‌یابی کافی نیست. باید بدانیم ساعت تلفن چه بوده، IP دستگاه چه بوده، با کدام سرور ارتباط داشته، Firmware چه نسخه‌ای بوده، آیا شبکه قطع شده، تلفن چه علت Unregister را ثبت کرده و آیا همان زمان سرور نیز Disconnect یا Timeout دیده است.
PRT دقیقاً برای جمع‌کردن چنین سرنخ‌هایی مفید است. در رابط خود تلفن نیز هنگام ایجاد گزارش می‌توانید نوع مشکل را انتخاب کنید؛ برای مثال قطع یا ریبوت تلفن، خرابی اتصال شبکه، شکست رجیستر، برقرار نشدن تماس، پاسخ داده نشدن تماس، مشکل کیفیت صدا یا تصویر و موارد مشابه.
نکته کلیدی این است که PRT باید تا حد امکان نزدیک به زمان وقوع مشکل ساخته شود. لاگ‌های تلفن دائماً در حال تغییر و چرخش هستند و اگر چند ساعت یا چند روز صبر کنید، ممکن است بخشی از رخداد مهم دیگر در فایل‌های فعال باقی نمانده باشد.
چه مدل‌هایی از Cisco 78xx/88xx از PRT پشتیبانی می‌کنند؟
راهنمای رسمی به‌روزشده Cisco برای جمع‌آوری PRT، مدل‌های 7811، 7821، 7841 و 7861 از خانواده 7800 و مدل‌های 8811، 8821، 8841، 8845، 8851، 8851NR، 8861 و 8865 از خانواده 8800 را در فهرست نمونه‌های پشتیبانی‌شده آورده است.
مسیر منو و محتوای دقیق بسته ممکن است با Firmware، مدل و این‌که تلفن از شاخه Enterprise یا Multiplatform Firmware استفاده می‌کند فرق داشته باشد. بنابراین اگر نام فایل‌های داخل PRT شما دقیقاً با نمونه‌های این مقاله یکسان نبود، این موضوع به‌تنهایی نشانه خرابی فایل نیست.
قبل از ساخت PRT، مهم‌ترین کار: زمان مشکل را ثبت کنید
بزرگ‌ترین اشتباه این است که فقط PRT را بگیرید و بنویسید «حدود صبح مشکل داشت». برای تطبیق با لاگ سرور، زمان هرچه دقیق‌تر باشد ارزش گزارش بیشتر می‌شود.
اگر امکان دارد این چهار مورد را کنار هم یادداشت کنید: ساعت نمایش‌داده‌شده روی تلفن، زمان واقعی از یک سیستم معتبر، کاری که کاربر انجام داده و نتیجه‌ای که دیده است. مثلاً بنویسید: «۱۰:۲۴:۳۷، کاربر شماره را گرفت، تماس قبل از پخش Ringback قطع شد».
اگر ساعت تلفن با ساعت واقعی چند دقیقه یا چند ساعت اختلاف دارد، همان اختلاف را هم ثبت کنید. بعداً هنگام مقایسه با سرور همین اختلاف بسیار مهم خواهد شد.
نکته مهم: زمان «وقوع مشکل» با زمان «ساخت PRT» یک چیز نیست. نام فایل PRT زمان تولید گزارش را نشان می‌دهد، اما در خود گزارش می‌توانید زمان اعلام‌شده برای رخداد مشکل را نیز داشته باشید. برای تحلیل، ابتدا باید بدانید دنبال کدام لحظه هستید.
روش اول: ساخت PRT از خود تلفن Cisco
در راهنمای فعلی Cisco برای بسیاری از مدل‌های 78xx/88xx، از صفحه اصلی تلفن دکمه Settings یا Applications را باز می‌کنید، وارد Phone Information می‌شوید و گزینه Report problem را انتخاب می‌کنید.
در صفحه گزارش مشکل، تاریخ و زمان رخداد را وارد کنید و توضیحی را انتخاب کنید که بیشترین شباهت را به مشکل واقعی دارد. اگر مورد مناسبی پیدا نکردید، گزینه Other منطقی‌تر از انتخاب یک دسته اشتباه است.
پس از Submit، تلفن شروع به جمع‌آوری لاگ‌ها می‌کند. این فرایند ممکن است مدتی کوتاه طول بکشد.
Cisco در راهنمای فعلی خود اشاره کرده است که حتی اگر روی خود تلفن پیامی شبیه خطای ارسال گزارش ببینید، ممکن است فایل PRT همچنان روی دستگاه ساخته شده باشد و از رابط وب قابل دریافت باشد. بنابراین فقط با دیدن خطای Upload نتیجه نگیرید که PRT تولید نشده است.
روش دوم: ساخت PRT از رابط وب در تلفن‌های MPP
در بسیاری از تلفن‌های Multiplatform می‌توانید از مرورگر وارد IP تلفن شوید و پس از ورود مدیریتی، مسیر Admin Login → Advanced → Info → Debug Info را باز کنید.
در بخش Problem Reports گزینه Generate PRT وجود دارد. تاریخ و زمان مشکل را وارد کنید، نوع مشکل را انتخاب کنید و گزارش را بسازید.
این روش زمانی مفید است که تلفن در دسترس فیزیکی شما نیست ولی از شبکه به رابط مدیریتی آن دسترسی دارید.
فایل PRT را از کجا دانلود کنیم؟
در بسیاری از مدل‌های 78xx/88xx می‌توانید IP تلفن را در مرورگر باز کنید، وارد صفحه Console Logs شوید و در پایین صفحه بخش Problem Report Tool Logs را پیدا کنید.
نام فایل معمولاً شکلی شبیه نمونه زیر دارد:
prt-20261014-102437-AABBCCDDEEFF.tar.gzاین فقط یک نمونه ساختگی برای توضیح قالب نام فایل است. بخش تاریخ و ساعت، زمان ساخت بسته PRT را نشان می‌دهد و بخش پایانی معمولاً شناسه سخت‌افزاری دستگاه را در خود دارد.
اگر تلفن رجیستر نیست نیز در نسخه‌های جدیدتر می‌توانید با بررسی Event Log و رابط وب، فایل PRT ذخیره‌شده را پیدا کنید. این قابلیت در سناریوهایی مانند MRA که خود تلفن ممکن است رجیستر نباشد بسیار کاربردی است.
قبل از بازکردن فایل، یک نسخه دست‌نخورده نگه دارید
فایل اصلی را مستقیماً ویرایش نکنید. یک نسخه از آرشیو را به‌عنوان مدرک اولیه نگه دارید و تحلیل را روی کپی انجام دهید. این کار مخصوصاً زمانی مهم است که گزارش قرار است برای تیم دیگری، پشتیبانی یا Cisco TAC ارسال شود.
اگر لازم است ثابت کنید فایلی که تحلیل کرده‌اید با فایل اولیه یکسان بوده، می‌توانید Hash آن را ذخیره کنید.
در لینوکس:
sha256sum prt-20261014-102437-AABBCCDDEEFF.tar.gzدر PowerShell ویندوز:
Get-FileHash .\prt-20261014-102437-AABBCCDDEEFF.tar.gz -Algorithm SHA256داخل PRT دقیقاً چه چیزی وجود دارد؟
ساختار PRT میان Firmwareها یکسان و تضمین‌شده نیست، اما یک نمونه فنی منتشرشده توسط یکی از مهندسان Cisco برای 78xx/88xx نشان می‌دهد بسته می‌تواند چند دسته اطلاعات مهم داشته باشد: فایل مشخصات اولیه، فایل پیکربندی، لاگ کنسول، خروجی فرمان‌های تشخیصی، آرشیو لاگ‌های قدیمی و در صورت وقوع Crash یا Backtrace، فایل‌های مربوط به آن رخداد.
| بخش | اطلاعات معمول | کاربرد عیب‌یابی |
|---|---|---|
| Description / PRT Info | مدل، Firmware، Device ID، زمان اعلام مشکل و اطلاعات شناسایی دستگاه | ساخت خط مبنا و اطمینان از این‌که گزارش مربوط به تلفن و نسخه درست است |
| Configuration | تنظیمات دریافت‌شده از سامانه مدیریت، خطوط، Proxy و بخشی از تنظیمات دستگاه | بررسی این‌که تلفن با چه تنظیمی واقعاً بالا آمده است |
| Console / Logcat | رخدادهای زمان‌دار سرویس‌ها و ماژول‌های تلفن | پیداکردن خطا در نزدیکی لحظه مشکل |
| Show Output | CPU، حافظه، IP، Route، DHCP، Registration و خروجی‌های تشخیصی دیگر | دیدن وضعیت فعلی دستگاه هنگام تولید PRT |
| Archived Logs | نسخه‌های قدیمی‌تر لاگ | بررسی رخدادی که کمی قبل‌تر از ساخت PRT اتفاق افتاده است |
| Crash / Backtrace | فایل‌های مربوط به Crash یا Backtrace در صورت وجود | بررسی ریبوت یا Crash غیرمنتظره |
این جدول را به‌عنوان نقشه راه بخوانید، نه قرارداد ثابت فایل‌ها. نام و جزئیات دقیق آن‌ها ممکن است با شاخه Firmware یا مدل شما فرق کند.
اولین فایلی که باید باز کنید: اطلاعات پایه گزارش
در نمونه‌های Enterprise، فایلی با نامی شبیه description-YYYYMMDD-HHmmss.log دیده می‌شود. این فایل برای شروع بسیار ارزشمند است چون به شما می‌گوید گزارش متعلق به کدام دستگاه و کدام Firmware است و کاربر چه زمانی را به‌عنوان زمان مشکل ثبت کرده است.
در نمونه منتشرشده Cisco، این بخش اطلاعاتی مانند Firmware فعال، مدل، User ID، Device ID، شماره سریال و آدرس صفحه وب تلفن را در خود داشته است.
اگر روی ده‌ها تلفن مشابه کار می‌کنید، همین مرحله جلوی یک اشتباه ساده ولی رایج را می‌گیرد: تحلیل PRT دستگاه اشتباه.
فایل تنظیمات می‌تواند تفاوت «آنچه فکر می‌کردیم» و «آنچه تلفن گرفته» را نشان دهد
در تلفن‌های Enterprise، نمونه PRT می‌تواند فایل تنظیماتی را که دستگاه از CUCM دریافت کرده در خود داشته باشد. داخل آن ممکن است اطلاعات مربوط به Line، شماره داخلی، Proxy، Port و تنظیمات دیگر دیده شود.
این موضوع هنگام عیب‌یابی بسیار مهم است. ممکن است در CUCM یا سامانه Provisioning انتظار داشته باشید تلفن روی تنظیم A باشد، ولی فایل واقعی داخل PRT نشان دهد دستگاه تنظیم B را دریافت کرده است.
برای MPP نیز اصل تحلیل همین است: ابتدا وضعیت واقعی دریافت‌شده توسط Endpoint را مشخص کنید و بعد آن را با تنظیمی که سمت سرور یا Provisioning انتظار دارید مقایسه کنید.
حریم خصوصی: فایل Configuration را بدون بررسی در فروم عمومی، گروه پیام‌رسان یا تیکت غیرقابل اعتماد آپلود نکنید. این بخش ممکن است نام خطوط، شماره‌های داخلی، نام سرورها، IPها یا اطلاعات ساختاری شبکه را نشان دهد. نباید فرض کنید چون فایل «Log» نام دارد، انتشار عمومی آن بی‌خطر است.
لاگ کنسول؛ جایی که Timeline واقعی را می‌سازید
فایل Console یا Logcat معمولاً یکی از مهم‌ترین بخش‌هاست، چون رخدادها را با Timestamp نشان می‌دهد. به‌جای جست‌وجوی تصادفی میان تمام Errorها، ابتدا زمان دقیق مشکل را پیدا کنید و چند دقیقه قبل و بعد از آن را بخوانید.
چرا چند دقیقه قبل؟ چون علت واقعی ممکن است پیش از علامتی که کاربر دیده اتفاق افتاده باشد. برای مثال DHCP Renew، قطع Link، DNS Failure یا تغییر Registration State می‌تواند پیش از زمانی رخ دهد که صفحه تلفن «Unregistered» را نشان می‌دهد.
در نمونه‌های لاگ Cisco، هر خط می‌تواند زمان، سطح لاگ و نام ماژول را داشته باشد. این سه جزء برای ساخت Timeline بسیار مهم‌اند.
چطور میان صدها فایل و خط سریع جست‌وجو کنیم؟
پس از Extract کردن PRT، لازم نیست همه فایل‌ها را دستی باز کنید. در لینوکس یا macOS ابتدا آرشیو را استخراج کنید:
mkdir cisco-prt
tar -xzf prt-20261014-102437-AABBCCDDEEFF.tar.gz -C cisco-prtبعد یک جست‌وجوی اولیه انجام دهید:
grep -RniE 'register|unreg|fail|error|timeout|dns|dhcp|ntp|tls|ssl|reboot|crash' cisco-prtاین فرمان فقط برای پیداکردن نامزدهاست. وجود واژه Error در یک خط به معنی علت قطعی مشکل نیست. بعد از یافتن خط مناسب باید خطوط قبل و بعد و Timestamp را نیز بررسی کنید.
در PowerShell می‌توانید از این مسیر استفاده کنید:
Get-ChildItem .\cisco-prt -Recurse -File |
Select-String -Pattern 'register|unreg|fail|error|timeout|dns|dhcp|ntp|tls|ssl|reboot|crash'برای مشکل رجیستر، داخل PRT دنبال چه چیزی بگردیم؟
در یک نمونه مستندشده از PRT سری 78xx/88xx، خروجی‌های تشخیصی شامل فرمان‌هایی با موضوع show register، show register-gsi و show unreg-reason بوده است. همین بخش‌ها می‌توانند سرنخ مستقیمی از وضعیت رجیستر و علت Unregister بدهند.
برای تلفن SIP، تحلیل را فقط به کلمه Registered محدود نکنید. دنبال تغییر State، تلاش مجدد، Timeout، DNS، قطع Transport و رویدادهایی باشید که کمی قبل از Unregister رخ داده‌اند.
اگر PRT می‌گوید تلفن Unregistered شده اما هیچ دلیل روشنی در سمت Endpoint دیده نمی‌شود، مرحله بعدی سرور است. اینجا همان Timestamp اهمیت پیدا می‌کند.
بخش شبکه PRT چه چیزی به ما می‌گوید؟
در نمونه‌های Cisco، Show Output می‌تواند اطلاعاتی از IP Address، DHCP، Route، CDP، IPv6، Network Configuration، Network Statistics و Interfaceها داشته باشد.
این داده‌ها برای پاسخ به چند سؤال ساده اما مهم هستند: تلفن هنگام ساخت PRT چه IP داشته؟ Gateway آن چه بوده؟ آیا DHCP اطلاعات مورد انتظار را داده؟ آیا Route و Interface فعال بوده‌اند؟ آیا تلفن روی شبکه‌ای قرار داشته که انتظار داشتیم؟
اگر مشکل فقط در یک VLAN یا یک ساختمان دیده می‌شود، همین اطلاعات می‌تواند تفاوت شبکه‌ای دستگاه سالم و معیوب را آشکار کند.
چطور Timestamp تلفن را با لاگ سرور تطبیق دهیم؟
این مهم‌ترین بخش تحلیل PRT است. هدف این نیست که دو فایل را کنار هم باز کنید و دنبال واژه مشابه بگردید؛ باید یک Timeline مشترک بسازید.
ابتدا Time Zone و ساعت خود تلفن را مشخص کنید. در بعضی لاگ‌های Cisco منطقه زمانی در ابتدای لاگ دیده می‌شود. بعد Time Zone سرور را مشخص کنید. ممکن است تلفن زمان محلی بنویسد ولی CUCM، SBC یا یک سرور لینوکسی زمان UTC ثبت کند.
فرض کنید مشکل طبق تلفن در ساعت 14:22:10 UTC+04:00 رخ داده و سرور لاگ‌ها را با UTC می‌نویسد. بازه متناظر روی سرور نزدیک 10:22:10 UTC است. این فقط نمونه است؛ Offset محیط خودتان را استفاده کنید.
بعد یک بازه کوچک، مثلاً ۳۰ تا ۶۰ ثانیه قبل و بعد از رخداد، روی هر دو طرف بررسی کنید. اگر رخداد پیچیده است، بازه را بزرگ‌تر کنید.
| از PRT | سمت سرور | هدف |
|---|---|---|
| Timestamp | Timestamp Trace یا Log | قرار دادن دو رخداد روی یک Timeline |
| Device ID / MAC | شناسه Endpoint در PBX/CUCM | اطمینان از تحلیل دستگاه درست |
| IP تلفن | Source IP در Trace یا Firewall | ردگیری مسیر ارتباط |
| Line / Extension | Extension یا Device Registration | تطبیق حساب یا خط |
| Registration State یا علت Unregister | Disconnect، Timeout، Reject یا Restart | فهمیدن این‌که کدام سمت ابتدا ارتباط را از دست داده است |
در CUCM چه لاگ‌هایی را کنار PRT بگذاریم؟
برای مشکل رجیستر در محیط CUCM، خود Cisco توصیه می‌کند علاوه بر PRT یا Console Log تلفن، لاگ مؤلفه‌های سمت سرور نیز جمع‌آوری شوند.
این مجموعه بسته به سناریو می‌تواند شامل Cisco CallManager Traces، Event Viewer Application Log، Event Viewer System Log و Cisco TFTP باشد. در موارد پیچیده‌تر ممکن است Packet Capture از CUCM یا خود تلفن نیز لازم شود.
مهم‌تر از تعداد فایل‌ها این است که همه آن‌ها همان بازه زمانی و همان Endpoint را پوشش دهند. یک CallManager Trace عالی که ده دقیقه بعد از مشکل گرفته شده، ممکن است از یک PRT متوسط که دقیقاً نزدیک رخداد تولید شده کم‌ارزش‌تر باشد.
در Asterisk، FreePBX یا SBC چه چیزی را تطبیق دهیم؟
در سامانه‌های SIP غیر CUCM نیز منطق همان است: زمان، IP، داخلی و جریان Registration یا Call را کنار هم بگذارید.
اگر سرور در همان لحظه هیچ بسته یا تلاش رجیستری از IP تلفن نمی‌بیند، بررسی شبکه، DNS، TLS یا خود Endpoint اهمیت بیشتری پیدا می‌کند. اگر درخواست به سرور رسیده ولی Reject شده، پاسخ SIP و دلیل سمت PBX راهنمای بهتری است.
اگر یک Call-ID، Branch یا شناسه تراکنش در هر دو سمت قابل مشاهده است، می‌تواند تطبیق را بسیار دقیق‌تر کند؛ اما وجود این شناسه‌ها در همه Firmwareها و همه نوع گزارش تضمین نشده است.
PRT چه زمانی کافی نیست؟
PRT برای دیدن وضعیت داخلی تلفن فوق‌العاده است، اما همه اتفاقات شبکه را با جزئیات Packet-level نشان نمی‌دهد.
اگر می‌خواهید ثابت کنید دقیقاً کدام SIP Message ارسال شده، TLS Handshake در کدام Packet شکست خورده، چه Retransmissionهایی رخ داده یا RTP در کدام جهت قطع شده، Packet Capture ارزش بیشتری دارد.
در نسخه به‌روزشده راهنمای Cisco برای جمع‌آوری PRT نیز تصریح شده است که سطح عادی Console Logging برای تحلیل پایه می‌تواند کافی باشد، اما برای تحلیل قطعی ممکن است Packet Capture از Endpoint لازم باشد.
قاعده ساده: PRT به شما می‌گوید تلفن «چه چیزی فهمیده و چه وضعیتی داشته»؛ Packet Capture به شما کمک می‌کند ببینید «واقعاً چه چیزی روی شبکه ردوبدل شده است». برای خطاهای پیچیده رجیستر، TLS و صدا، کنار هم گذاشتن این دو بسیار قدرتمندتر از استفاده از هرکدام به‌تنهایی است.
PRT و حریم خصوصی؛ قبل از ارسال فایل این بخش را بخوانید
PRT یک Screenshot ساده نیست. نمونه‌های مستندشده Cisco نشان می‌دهند این بسته می‌تواند Device ID، MAC، شماره سریال، User ID، IP تلفن، Firmware، Line Configuration و بخش‌هایی از تنظیمات شبکه را در خود داشته باشد.
به همین دلیل فایل را در سایت عمومی، فروم باز یا سرویس اشتراک فایل ناشناس منتشر نکنید.
اگر قرار است PRT را برای Cisco TAC یا تیم داخلی قابل اعتماد بفرستید، بهتر است نسخه اصلی دست‌نخورده را از مسیر امن ارسال کنید. اگر می‌خواهید بخشی از آن را در یک بحث عمومی منتشر کنید، فقط خطوط لازم را جدا کنید و شناسه‌های شخصی، IPهای خصوصی یا عمومی حساس، شماره داخلی، دامنه‌های داخلی، MAC، Serial و نام‌های سازمانی را در صورت عدم نیاز حذف یا ماسک کنید.
همچنین فرض نکنید فایل PRT هرگز اطلاعات حساس احراز هویت ندارد. ساختار Firmwareها متفاوت است؛ قبل از انتشار عمومی باید محتوای واقعی همان فایل را بررسی کنید.
چطور PRT دو تلفن سالم و خراب را مقایسه کنیم؟
یکی از سریع‌ترین روش‌های عیب‌یابی این است که از یک تلفن سالم با همان مدل، Firmware و شبکه نیز PRT بگیرید و تفاوت‌ها را مقایسه کنید.
اما مقایسه فقط وقتی ارزش دارد که دو دستگاه واقعاً مشابه باشند. اگر یکی روی VLAN دیگر، Firmware دیگر یا سرور رجیستر متفاوت است، تفاوت لاگ لزوماً علت خرابی نیست.
از Description شروع کنید، بعد Version و Network را مقایسه کنید و در نهایت سراغ Registration State و Console Logs بروید. معمولاً این ترتیب سریع‌تر از Diff گرفتن از کل چند هزار خط است.
برای خطای ریبوت یا Crash کدام بخش مهم‌تر است؟
اگر تلفن خودبه‌خود ریبوت شده، فقط Console Log لحظه بعد از بالا آمدن را نگاه نکنید. پوشه‌های Backtrace و Crash و زمان فایل‌های داخل آن‌ها را بررسی کنید.
در نمونه ساختاری که Cisco منتشر کرده، Backtrace و Crash در مسیرهای جداگانه داخل آرشیو PRT نگهداری می‌شوند. همچنین آرشیوهای قدیمی‌تر Log می‌توانند رخدادی را که قبل از Reboot اتفاق افتاده نگه داشته باشند.
اگر Crash File دقیقاً در زمان گزارش‌شده کاربر ساخته شده باشد، این سرنخ بسیار قوی‌تری از یک Error عمومی چند ساعت قبل است.
یک روش عملی برای تحلیل PRT در کمتر از چند دقیقه
ابتدا نام دستگاه و Firmware را تأیید کنید. سپس زمان گزارش‌شده مشکل را به Time Zone مشترک با سرور تبدیل کنید. بعد فقط همان بازه زمانی را در Console Log بخوانید.
اگر مشکل رجیستر است، وضعیت Registration و علت Unregister را بررسی کنید. اگر مشکل شبکه است، IP، DHCP، Route و Interface را ببینید. اگر ریبوت رخ داده، Crash و Backtrace را کنترل کنید.
بعد سرور را باز کنید و همان Device، IP یا Extension را در همان بازه زمانی پیدا کنید. فقط اگر دو طرف برای پاسخ قطعی کافی نبودند سراغ Packet Capture و Debug سطح بالاتر بروید.
این ترتیب باعث می‌شود به‌جای غرق شدن در حجم زیاد لاگ، هر مرحله یک سؤال مشخص را پاسخ دهد.
لاگ تلفن یک طرف ماجراست؛ سمت سرور را هم بررسی کنید
اگر PRT نشان می‌دهد تلفن در زمان مشخصی Registration، DNS، TLS یا ارتباط شبکه را از دست داده، قدم بعدی بررسی همان لحظه روی سرور تلفنی، SBC یا زیرساخت میزبان است. تطبیق Endpoint و Server Log معمولاً خیلی سریع‌تر از تغییر تصادفی تنظیمات تلفن به علت واقعی می‌رسد.
ثبت درخواست بررسی و کانفیگ سرور
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج درباره Cisco PRT Log
PRT همان Packet Capture است؟
خیر. PRT مجموعه‌ای از لاگ‌ها و اطلاعات تشخیصی تلفن است. Packet Capture بسته‌های واقعی عبوری از شبکه را ثبت می‌کند. برای بعضی مشکلات PRT کافی است، اما برای تحلیل قطعی Signaling، TLS یا RTP ممکن است PCAP لازم باشد.
بهترین زمان برای ساخت PRT چه زمانی است؟
هرچه نزدیک‌تر به لحظه بروز مشکل بهتر است. اگر چند ساعت صبر کنید، Log Rotation ممکن است بخشی از اطلاعات مربوط به رخداد را جابه‌جا یا حذف کند.
از کجا بفهمم PRT مربوط به کدام تلفن است؟
نام فایل معمولاً شناسه دستگاه را در خود دارد و فایل Description نیز می‌تواند مدل، Device ID، MAC، Serial و Firmware را نشان دهد. قبل از تحلیل همیشه این موارد را بررسی کنید.
برای مشکل رجیستر کدام بخش PRT مهم‌تر است؟
زمان رخداد، Console Log، Registration State، علت Unregister، اطلاعات شبکه و تنظیمات دریافتی دستگاه مهم‌ترین نقاط شروع هستند. بعد همان زمان را با لاگ PBX یا CUCM تطبیق دهید.
چرا Timestamp PRT با لاگ سرور یکی نیست؟
اغلب به‌دلیل تفاوت Time Zone یا مشکل همگام‌سازی ساعت است. قبل از مقایسه لاگ‌ها باید هر دو زمان را به یک منطقه زمانی مشترک تبدیل کنید و اختلاف ساعت دستگاه را نیز در نظر بگیرید.
آیا می‌توان PRT را در اینترنت عمومی آپلود کرد؟
بهتر است این کار را نکنید. PRT می‌تواند اطلاعاتی مانند MAC، Serial، IP، User ID، شماره داخلی، تنظیمات و ساختار شبکه را در خود داشته باشد. برای انتشار عمومی فقط بخش لازم را پس از حذف یا ماسک‌کردن اطلاعات حساس به اشتراک بگذارید.
اگر PRT هیچ علت روشنی نشان نداد چه کنیم؟
لاگ سرور و Packet Capture را بررسی کنید. Cisco برای مشکلات رجیستر نیز توصیه می‌کند اطلاعات Endpoint و سمت CUCM یا شبکه در کنار Timestamp مشکل جمع‌آوری شود. PRT همیشه به‌تنهایی برای نتیجه قطعی کافی نیست.
جمع‌بندی
PRT زمانی بیشترین ارزش را دارد که آن را «فایل خطا» نبینید، بلکه یک Snapshot زمان‌دار از وضعیت تلفن بدانید. اول زمان و هویت دستگاه را مشخص کنید، سپس Registration، Console Log و اطلاعات شبکه را بخوانید و همان لحظه را با لاگ سرور تطبیق دهید.
اگر مشکل در سطح Packet باقی ماند، سراغ PCAP بروید. اگر گزارش را برای فرد دیگری ارسال می‌کنید، حریم خصوصی را جدی بگیرید و فایل کامل را فقط در اختیار پشتیبانی یا تیم قابل اعتماد قرار دهید.
منابع
Cisco — Collect Collaboration Endpoint PRT File for 78XX and 88XX IP Phones
Cisco — Troubleshoot IP Phone Unregistration Issues in CUCM
Cisco — Cisco IP Phone 7800 Series Multiplatform Phones Administration Guide
Cisco — Report Phone Issues on the Cisco IP Phone 8800 Series Multiplatform Phone
Cisco Community — نمونه ساختار و محتوای PRT در 78xx/88xx
برای تطبیق PRT با لاگ سرور کمک می‌خواهید؟
اگر PRT را گرفته‌اید ولی هنوز مشخص نیست قطعی، Unregister یا خطای تماس از Endpoint است یا سرور، زمان دقیق مشکل، مدل تلفن، Firmware و اطلاعات سرور را کنار هم بررسی کنید. در صورت نیاز می‌توانید درخواست بررسی و کانفیگ مرتبط با زیرساخت سرور خود را ثبت کنید.
ثبت درخواست کانفیگ — تماس با ایرانیکاسرور
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)