آپدیت امن Firmware تلفن Cisco؛ تشخیص MPP و Enterprise و جلوگیری از Brick شدن

برای همین در تلفن‌های Cisco 7800 و 8800 مهم‌ترین مرحله «دانلود جدیدترین Firmware» نیست؛ بلکه اول باید Product ID، مدل، VID، نوع Firmware فعلی، نسخه نصب‌شده و Release Notes همان مدل را مشخص کنید. فقط بعد از این بررسی می‌توان درباره Upgrade Path، Rollback و فایل مناسب تصمیم گرفت.

در این راهنما یک روش کم‌ریسک برای آپدیت Cisco IP Phone ارائه می‌کنیم که هم تلفن‌های MPP/3PCC و هم Enterprise را از هم جدا می‌کند و قبل از هر Upgrade، سازگاری Model و Firmware Branch، Hardware Revision، Release Notes، Backup، مسیر ارتقا و امکان بازگشت را بررسی می‌کند.

اولین قانون: MPP و Enterprise را با هم اشتباه نگیرید

Cisco برای بسیاری از تلفن‌های 7800 و 8800 دو خانواده Firmware متفاوت دارد:

MPP فقط یک نسخه متفاوت از همان فایل Enterprise نیست. Cisco این دو را Firmware Family جدا در نظر می‌گیرد و تبدیل بین آن‌ها در مدل‌های پشتیبانی‌شده فرآیند Migration مستقل، شرایط Hardware و در برخی سناریوها Licensing خاص خود را دارد.

چطور بفهمیم تلفن Cisco MPP است یا Enterprise؟

یکی از سرنخ‌های اصلی، Product ID روی برچسب دستگاه است.

مثلاً:

CP-8841-3PCC

وجود عباراتی مانند 3PCC، 3PC یا 3PW روی PID معمولاً به خانواده MPP اشاره می‌کند.

در MPP همچنین از داخل:

Settings → Status → Product Information

یا در Web Interface بخش Info → Status می‌توانید Product Name و Software Version را ببینید.

Software Version را قبل از هر کاری ثبت کنید

یک نمونه MPP ممکن است چیزی شبیه این نشان دهد:

Product Name: CP-8841-3PCC
Software Version: sip88xx.x-x-xMPP-xxx

نام دقیق فایل در نسخه‌های مختلف فرق می‌کند. این مثال فقط برای تشخیص الگو است و نباید به‌عنوان Firmware واقعی تلفن دیگری استفاده شود.

جدیدترین نسخه برای همه Ciscoها یکسان نیست

این یکی از مهم‌ترین نکات این مقاله است.

در صفحه پشتیبانی فعلی Cisco، برای سری 7800 MPP نسخه‌های شاخه 12.0(7) منتشر شده‌اند و 12.0(7)SR5 در مارس ۲۰۲۶ فهرست شده است.

در سری 8800 MPP نیز Release Notes شاخه 12.0(7)SR5 برای مدل‌هایی مانند 8811، 8841، 8851 و 8861 منتشر شده است.

اما مدل‌هایی مانند 8845 و 8865 ممکن است در صفحه Release Notes همان خانواده روی Service Release متفاوتی متوقف شده باشند.

پس عبارت زیر اشتباه است:

Latest Cisco 8800 firmware = one file for every 8800 model

مدل دقیق باید در صفحه همان Product بررسی شود.

Enterprise Firmware هم شاخه مستقل خودش را دارد

در Enterprise Firmware فعلی، سری 7800 روی شاخه 14.4(1) قرار دارد و Service Releaseهای سال ۲۰۲۶ نیز منتشر شده‌اند.

در 8800 نیز شاخه 14.4(1) وجود دارد، اما حتی Service Release جدید می‌تواند فقط برای گروه خاصی از مدل‌ها منتشر شده باشد.

برای نمونه Cisco نسخه 14.4(1)SR4 را برای 8845 و 8865 منتشر کرده است؛ در حالی که گروه 8811، 8841، 8851 و 8861 Release Note جداگانه‌ای برای SR3 دارد.

قبل از دانلود Firmware این پنج مورد را ثبت کنید

VID چیست و چرا در Firmware مهم است؟

VID یا Hardware Version نشان می‌دهد دستگاه متعلق به کدام Revision سخت‌افزاری است.

این موضوع فقط اطلاعات جانبی نیست. Cisco برای بعضی مدل‌های 8800 حداقل Firmware متفاوتی بر اساس VID تعریف کرده است.

مثلاً Hardware Revision جدیدتر ممکن است اصلاً اجازه اجرای یک Firmware قدیمی را نداشته باشد.

نمونه محدودیت Hardware در سری 8800

طبق Compatibility Matrix فعلی Cisco، مدل‌هایی مانند 8811، 8841 و 8851 در بعضی VIDها حداقل Firmware مشخص دارند.

منطق کلی چنین است:

Newer hardware VID
        ↓
Minimum supported firmware
        ↓
Older firmware may be blocked

بنابراین Rollback قبل از آنکه انجام شود باید با Compatibility Matrix همان VID بررسی شود.

مثال مهم: Cisco 8832 با VID جدید

Cisco در Compatibility فعلی برای بعضی Hardware Revisionهای 8832 حداقل Firmware مشخصی تعیین کرده است.

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

Release Notes را قبل از فایل Firmware باز کنید

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

Download latest ZIP
        ↓
Upload to phone
        ↓
Read release notes if it fails

ترتیب بهتر:

Identify model / VID / branch
        ↓
Read release notes
        ↓
Check upgrade restrictions
        ↓
Check downgrade restrictions
        ↓
Download exact firmware
        ↓
Pilot upgrade

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

مهم‌ترین بخش‌ها عبارت‌اند از Installation، Upgrade Firmware، Hardware Requirements، Limitations، Resolved Caveats، Open Caveats و Downgrade Limitations.

اگر Release Notes گفته باشد یک Hardware Revision حداقل نسخه مشخصی نیاز دارد، آن شرط باید از هر توصیه عمومی دیگری مهم‌تر در نظر گرفته شود.

MPP و Enterprise را مستقیم روی هم Flash نکنید

اگر دستگاه Enterprise است و هدف شما MPP است، این کار یک Upgrade معمولی نیست؛ Firmware Migration است.

همین موضوع برای MPP به Enterprise نیز صدق می‌کند.

Cisco برای مدل‌های واجد شرایط فرآیند رسمی Conversion دارد و در برخی سناریوها Migration License و Cloud Upgrader درگیر هستند.

تبدیل Firmware می‌تواند Factory Reset ایجاد کند

Cisco در Migration Guide هشدار می‌دهد که Firmware Migration تلفن را Factory Reset می‌کند و اطلاعاتی مانند Local Contact و Call History ممکن است از بین بروند.

بنابراین اگر هدف فقط Patch کردن یک نسخه MPP است، آن را با E2M یا M2E اشتباه نگیرید.

تفاوت Upgrade با Migration

هر Cisco 7800 یا 8800 قابل Migration نیست

در 7800 حتی Hardware Revision می‌تواند Eligibility را تغییر دهد.

Cisco برای برخی مدل‌ها حداقل Version سخت‌افزاری مشخص کرده و توصیه می‌کند برای وضعیت به‌روز Eligibility از Cloud Upgrader و مستند Migration استفاده شود.

قبل از آپدیت از چه چیزهایی Backup بگیریم؟

حداقل اطلاعات زیر را خارج از Phone ثبت کنید: Product Name، VID، MAC Address، Serial Number، Software Version، Firmware Family، Proxy یا Call Control، Voice VLAN، Provisioning URL و تنظیمات اختصاصی Line.

اگر سیستم Provisioning مرکزی دارید، نسخه فعلی Config را نگه دارید.

اگر تلفن دستی تنظیم شده است، قبل از Upgrade از صفحات اصلی Configuration Screenshot یا Export پشتیبانی‌شده همان Firmware تهیه کنید.

یک فایل وضعیت قبل از Upgrade بسازید

مثلاً:

Model: CP-8841-3PCC
VID: Vxx
MAC: 001122AABBCC
Current Firmware: ...
Target Firmware: ...
Call Control: Asterisk
Provisioning: HTTPS
Rollback Version: ...
Upgrade Date: ...

قبل از Upload، فایل دانلودشده را Verify کنید

اگر Cisco برای Download موردنظر Hash منتشر کرده است، آن را با مقدار محلی مقایسه کنید.

در Linux:

sha256sum firmware-file.zip

فقط وقتی Hash رسمی همان Download موجود است نتیجه را مقایسه کنید.

فایل ZIP را مستقیم به Upgrade Rule ندهید

در MPP معمولاً بسته دانلودشده شامل چند فایل است.

پس از Extract باید فایل Load مناسب همان مدل را مطابق Release Notes انتخاب کنید.

نمونه عمومی:

firmware-package.zip
        ↓ extract
firmware files
        ↓
exact .loads file required by the phone

روش Upgrade در Cisco MPP

در MPP از Web Interface وارد:

Admin Login → advanced → Voice → Provisioning

شوید.

در بخش Firmware Upgrade ابتدا بررسی کنید:

Upgrade Enable = Yes

Upgrade Rule چه شکلی است؟

فرمت عمومی مستند Cisco:

<tftp|http|https>://<server>/<exact-load-name>

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

https://firmware.example.com/cisco/EXACT-FIRMWARE.loads

نام فایل را از Release Notes و Package همان مدل بردارید؛ نام نمونه بالا واقعی نیست.

قبل از دادن Upgrade Rule، فایل را روی سرور تست کنید

curl -I https://firmware.example.com/cisco/EXACT-FIRMWARE.loads

پاسخ مطلوب معمولاً HTTP 200 است.

Redirect و Authentication را قبل از Upgrade حذف یا تست کنید

هر Redirect، Basic Auth، Reverse Proxy و TLS Certificate یک نقطه خطای اضافه ایجاد می‌کند.

برای Upgrade حساس، URL نهایی و مستقیم روی یک سرور قابل اعتماد ساده‌تر است.

HTTPS بهتر است، اما Certificate باید معتبر باشد

اگر MPP نتواند TLS Handshake را کامل کند، Firmware اصلاً دانلود نمی‌شود.

برای بررسی سرور:

openssl s_client \
-connect firmware.example.com:443 \
-servername firmware.example.com

هیچ‌وقت وسط Firmware Upgrade برق تلفن را قطع نکنید

Cisco در راهنمای Upgrade MPP صریحاً هشدار می‌دهد هنگام Upgrade دستگاه را خاموش نکنید.

تلفن ممکن است در طول فرآیند چند بار Restart شود و این به‌تنهایی نشانه خرابی نیست.

اگر تلفن PoE است، قبل از Upgrade برق را پایدار کنید

Upgrade زمان خوبی برای تست یک Switch ناپایدار یا کابل مشکوک نیست.

اگر قبلاً Phone ریست تصادفی دارد، ابتدا مشکل PoE، کابل و Switch Port را حل کنید؛ بعد Firmware را ارتقا دهید.

Firmware Upgrade را روی تلفن پرترافیک انجام ندهید

یک Maintenance Window انتخاب کنید که قطع سرویس آن Device قابل قبول باشد.

Firmware Upgrade می‌تواند Reboot ایجاد کند و Registration برای مدتی قطع شود.

اول یک Pilot، بعد کل سازمان

اگر ۱۰۰ تلفن دارید، Upgrade Rule را در همان لحظه روی ۱۰۰ تلفن اعمال نکنید.

Pilot باید Hardware VID واقعی محیط را پوشش دهد

اگر ۳۰ عدد 8841 دارید اما بخشی V08 و بخشی V16 هستند، آزمایش فقط روی یک VID کافی نیست.

حداقل یک Device از هر Hardware Revision موجود را آزمایش کنید.

بعد از Upgrade فقط Version را چک نکنید

یک Firmware می‌تواند با موفقیت Boot شود اما در عملکرد واقعی مشکل داشته باشد.

پس این موارد را بررسی کنید: Registration، تماس ورودی، تماس خروجی، صدای دوطرفه، Transfer، Hold، BLF، Voicemail، Headset، Expansion Module و Provisioning.

نسخه جدید را از Info → Status تأیید کنید

بعد از Boot کامل:

Info → Status → Product Information

را باز کنید و Software Version را با Target Version مقایسه کنید.

Firmware Rollback را قبل از Upgrade طراحی کنید

Rollback نباید برنامه‌ای باشد که بعد از خراب‌شدن تلفن به فکر آن بیفتید.

قبل از Upgrade پاسخ این سؤال‌ها را داشته باشید:

آیا Cisco اجازه Downgrade از Target Version را می‌دهد؟ Hardware VID حداقل نسخه‌ای دارد؟ فایل قبلی هنوز روی Server موجود است؟ Release Notes محدودیت Downgrade دارد؟

«نسخه قبلی» همیشه قابل نصب نیست

اگر Hardware Revision جدید حداقل Firmware بالاتری لازم داشته باشد، برگشت به نسخه‌ای که روی Device قدیمی کار می‌کرد ممکن است روی Device جدید ممنوع باشد.

پس این تصور خطرناک است:

If upgrade fails:
just install any older firmware

Enterprise Release Notes هم Downgrade Limitation دارند

Cisco در Release Notes Enterprise بخش مستقلی با عنوان Downgrade Limitation دارد.

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

اگر Firmware اشتباه را به Upgrade Rule بدهیم چه می‌شود؟

در بهترین حالت Device فایل را رد می‌کند.

اما تکیه به این رفتار به‌عنوان مکانیزم Safety اشتباه است.

نام فایل، Product Family و Release Notes را قبل از اعمال Rule بررسی کنید.

Firmware 8841 را به‌دلیل شباهت ظاهری روی 8845 فرض نکنید

مدل‌های 8800 ممکن است ظاهر نزدیک و حتی شماره‌های مشابه داشته باشند اما Package و Release Support آن‌ها همیشه یکسان نیست.

صفحه Download باید روی مدل دقیق Device تنظیم شده باشد.

اگر تلفن بعد از Upgrade Boot Loop شد چه کنیم؟

اول برق را پشت سر هم قطع و وصل نکنید.

زمان کافی برای Upgrade و Restart طبیعی بدهید.

اگر Device واقعاً وارد Boot Loop پایدار شده است، Release Notes و Recovery Method همان مدل را بررسی کنید و از Firmware تصادفی یا فایل Recovery مدل دیگر استفاده نکنید.

Factory Reset اولین راه‌حل بعد از Upgrade نیست

Factory Reset می‌تواند Configuration را پاک کند اما Firmware ناسازگار را الزاماً به نسخه قبلی برنمی‌گرداند.

پس قبل از Reset، Boot Stage، Log، Provisioning و Firmware Version را ثبت کنید.

اگر بعد از Upgrade رجیستر نمی‌شود

ابتدا بررسی کنید Firmware Family عوض نشده و Config مربوط به همان Branch هنوز معتبر است.

بعد DNS، TLS، Provisioning و SIP را جداگانه بررسی کنید.

اگر روی MPP بعد از Upgrade Provisioning هم Fail شده، عیب‌یابی Resync را از Profile Rule تا HTTP/TLS انجام دهید.

اگر بعد از Upgrade TLS خراب شد

Firmware جدید می‌تواند TLS Policy یا Certificate Validation متفاوتی داشته باشد.

ClientHello، TLS Version، Cipher، CA Chain و ساعت NTP را دوباره بررسی کنید.

اگر بعد از Upgrade BLF یا Headset مشکل پیدا کرد

Release Notes را برای Open Caveats و Resolved Caveats بخوانید.

فقط چون Firmware جدیدتر است به این معنا نیست که برای تمام Peripheralها و Workflowهای محیط شما بهترین نسخه است.

Field Notice مدل‌های قدیمی 8800 را جدی بگیرید

Cisco درباره برخی مدل‌های قدیمی 8800 که از Enterprise به MPP مهاجرت می‌کنند هشدار داده است که محدودیت سخت‌افزاری می‌تواند در سناریوهای سنگین مانند تعداد زیاد BLF، Key Expansion Module یا Call Volume بالا باعث کاهش Performance شود.

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

برای Enterprise Upgrade روی CUCM چه می‌شود؟

در محیط Enterprise، Firmware معمولاً از طریق CUCM/TFTP و Package مناسب همان Release مدیریت می‌شود.

فایل‌های Enterprise را از صفحه همان مدل و Release دریافت کنید و Installation Requirement همان Release Notes را اجرا کنید.

روی Production ابتدا Device Default را کورکورانه تغییر ندهید

اگر CUCM تعداد زیادی تلفن دارد، تغییر Default Load می‌تواند Rollout گسترده ایجاد کند.

ابتدا Upgrade را برای Phone یا Device Pool آزمایشی برنامه‌ریزی کنید و سپس دامنه را توسعه دهید.

یک جدول تصمیم قبل از Upgrade

چک‌لیست قبل از Upgrade Cisco IP Phone

پرسش‌های متداول درباره آپدیت Cisco IP Phone

جدیدترین Firmware برای Cisco 8841 چیست؟

نسخه مناسب به Firmware Family وابسته است. MPP و Enterprise شاخه‌های جدا دارند و باید صفحه Release Notes مخصوص مدل 8841 و همان Firmware Family را بررسی کنید. فقط عدد بزرگ‌تر به معنی فایل مناسب نیست.

از کجا بفهمیم Cisco ما MPP است یا Enterprise؟

Product ID و Product Information را بررسی کنید. وجود 3PCC، 3PC یا 3PW معمولاً به MPP اشاره می‌کند. Software Version و عنوان منوی دستگاه نیز سرنخ‌های مهمی هستند.

آیا می‌توان Firmware Enterprise را مستقیم روی MPP نصب کرد؟

این کار Upgrade عادی نیست. تبدیل MPP و Enterprise فرآیند Migration رسمی Cisco دارد و ممکن است به Eligibility، نسخه پایه، License یا Cloud Upgrader نیاز داشته باشد.

VID چه اهمیتی در Firmware دارد؟

VID نشان‌دهنده Hardware Revision است. بعضی VIDهای جدید حداقل Firmware مشخص دارند و امکان Downgrade به نسخه‌های قدیمی‌تر را محدود می‌کنند.

آیا همیشه باید آخرین Firmware را نصب کنیم؟

نه بدون بررسی. ابتدا Release Notes، مدل، VID، Compatibility، Open Caveats و Upgrade Path را بررسی کنید. جدیدترین نسخه برای مدل دیگر یا Hardware Revision دیگر مناسب نیست.

آیا Upgrade تنظیمات تلفن را پاک می‌کند؟

Upgrade عادی معمولاً با Migration متفاوت است، اما همیشه قبل از تغییر Firmware از Config و اطلاعات مهم نسخه پشتیبان داشته باشید. Firmware Migration بین Enterprise و MPP می‌تواند Factory Reset ایجاد کند.

چرا بعد از Upgrade تلفن چند بار Reboot می‌شود؟

Cisco در راهنمای MPP اشاره می‌کند که تلفن ممکن است حین Firmware Upgrade چند بار Restart شود. تا پایان فرآیند برق را قطع نکنید.

اگر Firmware جدید مشکل داشت می‌توانیم نسخه قبلی را نصب کنیم؟

فقط اگر Release Notes و Hardware Compatibility اجازه دهند. بعضی VIDها حداقل Firmware دارند و برخی Releaseها محدودیت Downgrade دارند.

آیا Factory Reset Firmware را به نسخه قبلی برمی‌گرداند؟

خیر. Factory Reset عمدتاً Configuration را پاک می‌کند و نباید به‌عنوان Firmware Rollback در نظر گرفته شود.

بهترین روش Upgrade تعداد زیادی Cisco MPP چیست؟

ابتدا یک Lab و Pilot بسازید، سپس Firmware را با Upgrade Rule یا Provisioning مرکزی به Batchهای کوچک بدهید و فقط پس از تأیید تماس، BLF، TLS، Headset و Provisioning به Rollout کامل بروید.

چرا بعد از Upgrade Cisco رجیستر نمی‌شود؟

Firmware Family، Provisioning، DNS، TLS و SIP را بررسی کنید. اگر Firmware اشتباه یا Config ناسازگار باشد، Registration می‌تواند بعد از Boot شکست بخورد.

آیا فایل Firmware همه مدل‌های 8800 یکی است؟

نباید چنین فرضی کرد. بعضی مدل‌ها فایل یا Release Support متفاوت دارند. فایل را از صفحه Download و Release Notes مدل دقیق انتخاب کنید.

جمع‌بندی

برای آپدیت Cisco IP Phone، مهم‌ترین کار دانلود آخرین فایل نیست؛ شناسایی دقیق دستگاه است. Product Model، Firmware Family، Hardware VID و Software Version باید قبل از هر تغییر ثبت شوند.

MPP و Enterprise دو شاخه مستقل هستند. MPP به MPP و Enterprise به Enterprise یک Firmware Upgrade محسوب می‌شوند، اما تبدیل بین آن‌ها Firmware Migration است و باید مطابق مسیر رسمی Cisco انجام شود.

Release Notes را قبل از Upgrade بخوانید. Cisco برای بعضی Hardware Revisionها حداقل Firmware تعریف کرده و Releaseهای Enterprise نیز می‌توانند محدودیت Downgrade داشته باشند. بنابراین Rollback را قبل از Upgrade طراحی کنید.

در MPP می‌توانید Firmware را از طریق TFTP، HTTP یا HTTPS و Upgrade Rule نصب کنید، اما URL باید دقیقاً به Load مناسب همان مدل اشاره کند. هنگام Upgrade برق دستگاه را قطع نکنید و Rebootهای میانی را طبیعی در نظر بگیرید.

در محیط سازمانی نیز هیچ‌گاه همه Phoneها را هم‌زمان ارتقا ندهید. یک Lab، سپس Pilot روی مدل‌ها و VIDهای واقعی و بعد Rollout مرحله‌ای، احتمال Brick، Downtime گسترده و ناسازگاری Firmware را به‌شدت کاهش می‌دهد.