آموزش آپدیت Firmware تلفن یالینک؛ ارتقای امن و بازگشت به نسخه قبل

روش امن از شناسایی دقیق مدل و Hardware Version شروع می‌شود. بعد باید Firmware فعلی، Firmware مقصد، Release Notes، محدودیت Downgrade، تنظیمات Provisioning و امکان بازیابی دستگاه را بررسی کنیم. سپس از تنظیمات فعلی نسخه پشتیبان می‌گیریم، Firmware را ابتدا روی یک تلفن آزمایشی یا Canary نصب می‌کنیم، تماس ورودی و خروجی و رجیستر را آزمایش می‌کنیم و فقط بعد از تأیید، ارتقا را به گروه‌های کوچک گسترش می‌دهیم.

در این آموزش همچنین تفاوت بین Rollback تنظیمات، Downgrade Firmware و Recovery Mode را روشن می‌کنیم. این تفاوت مهم است؛ چون در بعضی نسل‌ها و نسخه‌های جدید Yealink، بازگشت به Firmware قدیمی به دلایل سازگاری یا امنیتی محدود یا کاملاً مسدود شده است.

آیا واقعاً می‌توان Yealink را بدون قطعی آپدیت کرد؟

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

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

مثلاً اگر ۴۰ تلفن دارید، به‌جای آپدیت هم‌زمان ۴۰ دستگاه می‌توانید این ساختار را اجرا کنید:

مرحله 1:
1 تلفن Canary

مرحله 2:
3 تلفن واحد IT

مرحله 3:
5 تلفن کم‌ریسک

مرحله 4:
10 تلفن

مرحله 5:
باقی دستگاه‌ها به‌صورت Batchهای جداگانه

به این ترتیب اگر Firmware جدید مشکل داشته باشد، قبل از رسیدن آن به همه دستگاه‌ها متوقف می‌شوید.

چرا آپدیت گروهی Firmware می‌تواند خطرناک باشد؟

یک Firmware جدید ممکن است مشکل خود Firmware نداشته باشد اما با محیط شما ناسازگار باشد.

برای مثال ممکن است بعد از ارتقا:

تلفن دیگر روی SIP Server رجیستر نشود.

TLS Certificate قبلی را متفاوت اعتبارسنجی کند.

پارامتر قدیمی Provisioning تغییر رفتار دهد.

Dial Plan یا DSS Key به شکل متفاوتی تفسیر شود.

Firmware جدید Downgrade به نسخه قبلی را مسدود کند.

یک Hardware Revision خاص Firmware دیگری نیاز داشته باشد.

به همین دلیل «Firmware جدیدتر» همیشه به معنی «همین الان روی همه دستگاه‌ها نصب شود» نیست.

مرحله اول: موجودی واقعی تلفن‌ها را تهیه کنید

قبل از دانلود هر فایل ROM، فهرستی از دستگاه‌ها تهیه کنید.

برای هر دستگاه حداقل این اطلاعات را ثبت کنید:

Model تنها کافی نیست؛ Hardware Version را هم بررسی کنید

دو تلفن با نام تجاری مشابه می‌توانند Hardware Revision متفاوت داشته باشند.

در مستندات فعلی Yealink نیز Hardware Version به‌عنوان بخشی از وضعیت دستگاه نمایش داده می‌شود و بعضی Firmwareها محدودیت سخت‌افزاری دارند.

بسته به مدل می‌توانید اطلاعات دستگاه را از بخش Status یا About در رابط خود تلفن یا Web UI مشاهده کنید.

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

Model
Hardware Version
Firmware Version
MAC Address
Serial Number

چرا Hardware Revision این‌قدر مهم است؟

Yealink در راهنمای رسمی Upgrade نمونه‌هایی دارد که یک Hardware Revision خاص اجازه نصب نسخه‌های دیگر Firmware را ندارد.

بنابراین اگر فقط روی فایل Excel نوشته باشید:

T46U
T46U
T46U
T46U

هنوز برای Rollout ایمن اطلاعات کافی ندارید.

Hardware Version را نیز باید مقایسه کنید.

مرحله دوم: Firmware فعلی را دقیق ثبت کنید

Firmware Version را قبل از هر تغییر ذخیره کنید.

مثلاً:

Current:
96.86.0.70

Target:
96.xx.x.xx

عدد Target را از صفحه رسمی همان مدل Yealink بردارید، نه از فایل ROM دریافت‌شده از انجمن‌ها یا سایت‌های متفرقه.

Firmware رسمی و Customized Firmware را تشخیص دهید

در FAQ فعلی Yealink برای تلفن‌های SIP توضیح داده شده که Firmwareهای Customized می‌توانند محدودیت متفاوتی برای Upgrade داشته باشند.

Yealink در همین راهنما برای بعضی Firmwareهای SIP چنین الگویی را ذکر می‌کند:

xx.xx.0.xx
یا
xx.xx.1.xx

به‌عنوان Firmware رسمی Yealink.

اگر بخش سوم نسخه مقدار دیگری داشته باشد، ممکن است Firmware سفارشی Provider یا Vendor باشد.

این قاعده را برای همه محصولات Yealink تعمیم ندهید؛ اگر Firmware دستگاه از سرویس‌دهنده تلفنی یا اپراتور آمده، قبل از جایگزین‌کردن آن با Firmware عمومی Yealink با Provider بررسی کنید.

Firmware سفارشی را بدون بررسی جایگزین نکنید

Firmware یک Provider ممکن است شامل:

Provisioning اختصاصی.

Certificateهای سفارشی.

Account Template.

محدودیت Upgrade.

Branding.

یا تنظیمات مدیریتی خاص باشد.

نصب Firmware عمومی بدون بررسی ممکن است Provisioning دستگاه را خراب کند.

مرحله سوم: Release Notes را قبل از ROM بخوانید

بسیاری از Administratorها ابتدا فایل ROM را دانلود می‌کنند و بعد سراغ Release Notes می‌روند. ترتیب درست برعکس است.

در Release Notes این موارد را پیدا کنید:

مدل‌های پشتیبانی‌شده.

Hardware Versionهای پشتیبانی‌شده.

Known Issues.

Bug Fixها.

Security Changes.

Configuration Changes.

Downgrade Restrictions.

نیاز به Intermediate Firmware.

ممکن است Upgrade مستقیم مجاز نباشد

یک مثال واقعی در مستندات فعلی Yealink مربوط به خانواده T5XW است.

Yealink توضیح می‌دهد بعضی دستگاه‌های این خانواده که روی V84 هستند نمی‌توانند مستقیماً به V86 بروند و باید ابتدا نسخه‌های واسط مشخصی نصب شوند.

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

V84
↓
V86 Latest

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

V84
↓
V85
↓
نسخه واسط V86
↓
V86 Target

این نمونه نشان می‌دهد چرا فقط مقایسه «قدیمی» و «جدید» کافی نیست.

مسیر ارتقا را برای هر گروه جداگانه ثبت کنید

جدول Deployment می‌تواند چنین باشد:

مرحله چهارم: قبل از Firmware از Configuration بکاپ بگیرید

Firmware Rollback و Configuration Backup دو موضوع جدا هستند.

حتی اگر Firmware جدید قابل Downgrade باشد، ممکن است در فرایند Downgrade بعضی تنظیمات پاک شوند.

Yealink نیز در راهنمای Firmware Upgrade هشدار می‌دهد Downgrade در بعضی خانواده‌ها می‌تواند باعث پاک‌شدن بخشی از Configuration شود.

بنابراین قبل از Rollout حداقل نسخه فعلی Configuration را نگه دارید.

در محیط Auto Provisioning چه چیزی را Backup کنیم؟

اگر تلفن‌ها از Provisioning Server تنظیم می‌شوند، این فایل‌ها را Archive کنید:

Common CFG
MAC CFG
Custom CFG
Boot Files
Dial Plan
Firmware URL
Provisioning Server configuration

مثلاً:

archive/
├── 2026-10-11-before-firmware/
│   ├── common/
│   ├── mac/
│   ├── custom/
│   └── firmware-map.txt
│
└── current/

از وضعیت هر تلفن هم Snapshot بگیرید

قبل از Upgrade برای تلفن Canary این موارد را ثبت کنید:

Firmware Version
Hardware Version
Account Register Status
SIP Transport
SIP Server
Provisioning URL
NTP
TLS Settings
MAC Address

اگر بعد از Upgrade مشکلی ایجاد شود، دقیقاً می‌دانید قبل از تغییر چه وضعیتی داشته‌اید.

Factory Reset را با Backup اشتباه نگیرید

Factory Reset یک روش بازگشت Firmware نیست.

Factory Reset تنظیمات دستگاه را پاک می‌کند و تلفن را به Configuration پیش‌فرض Firmware نصب‌شده برمی‌گرداند.

اگر Firmware جدید مشکل دارد، Factory Reset به‌تنهایی Firmware قبلی را برنمی‌گرداند.

مرحله پنجم: تلفن Canary انتخاب کنید

Canary Deployment یعنی قبل از انتشار تغییر روی کل مجموعه، آن را روی تعداد بسیار کمی دستگاه واقعی اجرا کنیم.

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

Canary مناسب باید:

همان مدل دستگاه‌های اصلی باشد.

همان Hardware Revision را داشته باشد.

همان Firmware فعلی را داشته باشد.

از همان PBX و Provisioning Server استفاده کند.

در محیطی باشد که قطع موقت آن بحران ایجاد نکند.

یک تلفن آزمایشگاه با شرایط متفاوت Canary خوبی نیست

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

LAN متفاوت
Firmware متفاوت
Hardware Revision متفاوت
PBX آزمایشی

قرار دارد، موفق‌شدن Upgrade روی آن تضمین زیادی برای دستگاه‌های عملیاتی ایجاد نمی‌کند.

قبل از Canary یک تست پایه ثبت کنید

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

رجیستر SIP سالم است.

تماس داخلی برقرار می‌شود.

تماس خروجی برقرار می‌شود.

تماس ورودی می‌رسد.

صدای دوطرفه سالم است.

TLS در صورت استفاده سالم است.

Auto Provisioning کار می‌کند.

DSS Keyها درست هستند.

تاریخ و NTP صحیح است.

این وضعیت Baseline شما است.

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

برای اولین دستگاه بهتر است ارتقا را تحت کنترل و از Web UI انجام دهید تا نتیجه را مستقیم ببینید.

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

Settings → Upgrade → Upgrade Firmware

است.

فایل Firmware رسمی همان مدل را انتخاب و Upload کنید.

در طول ارتقا:

مرورگر را نبندید یا Refresh نکنید.

کابل شبکه را جدا نکنید.

برق دستگاه را قطع نکنید.

اگر تلفن PoE است، Switch یا Port را در همان زمان Reboot نکنید.

قطع برق وسط Firmware Upgrade خطرناک است

Yealink در مستندات Recovery نیز هشدار می‌دهد خاموش‌شدن دستگاه هنگام Upgrade می‌تواند داده‌های System Flash را خراب کند و تلفن دیگر Boot نشود.

اگر تلفن‌های مهم روی PoE هستند، Upgrade را زمانی اجرا کنید که:

Switch پایدار است.

UPS سالم است.

Maintenance شبکه دیگری در حال انجام نیست.

بعد از Reboot فقط Firmware Version را نگاه نکنید

ممکن است Upgrade از نظر Version موفق باشد اما سرویس تلفنی خراب شده باشد.

پس تمام Baseline قبلی را تکرار کنید.

چک بعد از Upgrade Canary

Canary را بلافاصله بعد از Boot موفق تأیید نکنید

بعضی مشکلات چند دقیقه بعد ظاهر می‌شوند.

برای مثال:

Registration Refresh.

NAT Timeout.

TLS Reconnect.

Repeated Provisioning.

BLF Subscription.

ممکن است بعداً مشکل ایجاد کنند.

Canary را برای یک بازه واقعی زیر بار نگه دارید.

مرحله هفتم: Firmware را با Auto Provisioning گروهی منتشر کنید

Yealink برای ارتقای گروهی Firmware از Auto Provisioning پشتیبانی می‌کند.

پارامتر اصلی در مستندات فعلی:

static.firmware.url

است.

نمونه:

#!version:1.0.0.1

static.firmware.url = https://provision.example.com/firmware/T54W-TARGET.rom

نام فایل نمونه است. باید Firmware واقعی رسمی همان مدل را از Yealink دریافت کنید.

هر مدل باید URL Firmware مخصوص خودش را داشته باشد

اگر چند مدل دارید:

T54W
T46U
T43U
T31G

نباید یک ROM را برای همه آن‌ها تعریف کنید.

ساختار Provisioning Server بهتر است مدل‌محور باشد:

/firmware/
├── T54W/
│   └── target.rom
├── T46U/
│   └── target.rom
├── T43U/
│   └── target.rom
└── T31G/
    └── target.rom

Firmware را در Common CFG همه دستگاه‌ها یک‌باره تغییر ندهید

اگر Common CFG مستقیماً به Firmware جدید اشاره کند، ممکن است تمام تلفن‌های همان مدل در اولین Provisioning آن را بگیرند.

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

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

مثلاً می‌توانید فایل‌های Pilot و Production جدا داشته باشید:

pilot-firmware.cfg
production-firmware.cfg

و ابتدا فقط تلفن‌های Canary را به Pilot متصل کنید.

زمان ارتقا را خارج از ساعات پرترافیک انتخاب کنید

Firmware Upgrade روی هر دستگاه باعث وقفه می‌شود.

پس حتی در Rollout مرحله‌ای بهتر است Batchها را در زمانی اجرا کنید که:

حجم تماس کمتر است.

کاربر پشت تلفن نیست.

تیم فنی حضور دارد.

PBX و Network Maintenance دیگری اجرا نمی‌شود.

همه تلفن‌های یک واحد را در یک Batch نگذارید

مثلاً اگر واحد فروش ۱۲ تلفن دارد، بهتر است:

Batch 1:
3 تلفن فروش

Batch 2:
3 تلفن فروش

Batch 3:
3 تلفن فروش

Batch 4:
3 تلفن فروش

باشد، نه اینکه هر ۱۲ دستگاه هم‌زمان Upgrade شوند.

در این صورت حتی هنگام Upgrade نیز بخشی از ظرفیت تماس باقی می‌ماند.

مرحله هشتم: Rollback را قبل از Rollout تعریف کنید

Rollback باید قبل از Upgrade نوشته شده باشد.

سؤال‌های اصلی:

اگر SIP رجیستر نشد چه می‌کنیم؟

اگر تلفن Boot نشد چه می‌کنیم؟

اگر Firmware جدید قابل Downgrade نبود چه می‌کنیم؟

فایل Configuration قبلی کجاست؟

Firmware قبلی مجاز است یا نه؟

Recovery Mode این مدل چیست؟

دو نوع Rollback داریم

Configuration Rollback یعنی بازگرداندن تنظیمات قبلی.

Firmware Rollback یعنی نصب نسخه Firmware قدیمی‌تر.

Configuration Rollback معمولاً ساده‌تر و کم‌ریسک‌تر است.

Firmware Rollback ممکن است توسط Firmware جدید ممنوع شده باشد.

مهم: Downgrade همیشه امکان‌پذیر نیست

Yealink در راهنمای رسمی Upgrade صراحتاً محدودیت Downgrade را برای بعضی نسخه‌ها اعلام کرده است.

برای مثال در راهنمای فعلی:

xx.xx.xx.160

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

همچنین بعد از ارتقا به خانواده:

xx.87.xx.xx

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

پس قبل از نصب V87 باید فرض کنید شاید مسیر برگشت به V86 وجود نداشته باشد، مگر Release Notes مدل دقیق خلاف آن را تأیید کند.

Release Notes نسخه‌های جدید نیز ممکن است محدودیت Hardware داشته باشند

در Release Note رسمی خانواده جدید T73/T74/T77/T85/T87 برای نسخه 185.87.0.35، Yealink هشدار Downgrade برای دستگاه‌های Hardware V1 را درج کرده است.

این دقیقاً همان دلیلی است که Hardware Revision باید قبل از Rollout ثبت شود.

Rollback امن یعنی قبل از Upgrade جواب این سؤال را بدانید

آیا Firmware مقصد اجازه بازگشت به Firmware فعلی را می‌دهد؟

اگر جواب این سؤال را از Release Notes یا مستندات Yealink پیدا نکرده‌اید، Firmware Upgrade گسترده را شروع نکنید.

اگر Downgrade مجاز بود چگونه تست کنیم؟

روی Canary مسیر برگشت را نیز در صورت نیاز و مجازبودن آزمایش کنید.

اما توجه کنید Yealink هشدار می‌دهد Downgrade می‌تواند بعضی Configurationها را پاک کند.

پس بعد از Downgrade ممکن است لازم باشد:

Factory Reset
↓
Auto Provision
↓
Restore Configuration
↓
Test SIP

انجام شود.

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

Recovery Mode با Downgrade عادی فرق دارد

Recovery Mode برای شرایطی است که Upgrade شکست خورده یا تلفن دیگر به‌طور عادی Boot نمی‌شود.

مثلاً صفحه روی:

Initializing...
Please Wait

گیر کرده است.

Yealink برای خانواده‌های مختلف روش‌های Recovery متفاوتی دارد، از جمله:

HTTP.

TFTP.

USB در مدل‌های پشتیبانی‌شده.

Backup System در برخی دستگاه‌های جدیدتر.

Recovery Mode را به‌عنوان Rollback تضمینی معرفی نکنید

Recovery ممکن است برای بازگرداندن دستگاه به حالت Bootable استفاده شود، اما Firmware و Resource Fileهای موردنیاز به مدل بستگی دارند.

بعضی دستگاه‌ها فقط ROM می‌خواهند و بعضی مدل‌های قدیمی‌تر فایل‌های اضافی مانند:

.bin
.rfs
.rom

نیاز دارند.

نام فایل Recovery نیز می‌تواند الزامات خاص داشته باشد.

بعضی مدل‌های جدید Backup System دارند

Yealink در مستندات Recovery توضیح می‌دهد برخی خانواده‌های جدید از Dual System یا Backup System استفاده می‌کنند.

این ساختار می‌تواند در خرابی Upgrade امکان Recovery را ساده‌تر کند.

اما باز هم باید مستند همان مدل را بررسی کنید؛ وجود Backup System را برای تمام Yealinkها فرض نکنید.

اگر Upgrade روی ۸۰ درصد گیر کرد چه؟

این وضعیت لزوماً به معنی خراب‌شدن دستگاه نیست.

Yealink برای برخی ارتقاهای T5XW از V84 به V86 مشکل شناخته‌شده‌ای دارد که Upgrade مستقیم می‌تواند نزدیک ۸۰ درصد متوقف شود.

راه‌حل رسمی در آن سناریو استفاده از Firmwareهای واسط مشخص است.

پس قبل از Recovery Mode، مسیر Supported Upgrade را بررسی کنید.

اگر ROM Invalid می‌بینید چه؟

Yealink در FAQ فعلی Upgrade برای بعضی Firmwareهای قدیمی V86 توضیح می‌دهد که روش Verification در Web UI می‌تواند هنگام رفتن مستقیم به V87 خطای:

ROM invalid

ایجاد کند.

در این وضعیت Yealink برای مدل‌های مشخص استفاده از Auto Provisioning یا Firmware واسط تعریف‌شده را پیشنهاد می‌کند.

پس ROM Invalid همیشه به معنی خراب‌بودن فایل دانلودی نیست.

بعد از Firmware Upgrade، Auto Provisioning قدیمی را فراموش نکنید

یکی از مشکلات رایج این است که Administrator تلفن را دستی Upgrade می‌کند ولی Provisioning Server هنوز Firmware قدیمی را تعریف کرده است.

در Reboot یا Provisioning بعدی، دستگاه ممکن است دوباره تلاش کند Firmware دیگری بگیرد یا وارد Loop شود.

قبل از Rollout بررسی کنید:

static.firmware.url

در Common، MAC یا Custom CFG به چه نسخه‌ای اشاره می‌کند.

RPS یا سرویس Provider هم می‌تواند روی Upgrade اثر بگذارد

Yealink در راهنمای Upgrade اشاره می‌کند دستگاهی که هنوز توسط RPS یا Provisioning خارجی مدیریت می‌شود ممکن است پس از تغییر دستی دوباره Configuration یا Firmware دریافت کند.

قبل از Rollout مشخص کنید مالک نهایی Provisioning چه سیستمی است:

Local Provisioning Server
RPS
Provider
YMCS
PBX Provisioning

Firmware URL را بعد از Rollout پاک کنیم؟

بستگی به معماری شما دارد.

اگر هدف این است که دستگاه‌ها روی نسخه مشخص Pin شوند، URL می‌تواند باقی بماند.

اما باید مطمئن شوید فایل همان نسخه موردنظر باقی می‌ماند و Provisioning Loop ایجاد نمی‌شود.

اگر Firmware فقط برای Campaign موقت استفاده شده، بعد از تأیید Rollout می‌توانید Configuration را به طراحی عادی خود برگردانید.

Monitoring بعد از هر Batch ضروری است

بعد از Upgrade فقط تعداد دستگاه‌هایی که Version جدید دارند را نشمارید.

این شاخص‌ها مهم‌ترند:

تعداد Accountهای Registered.

تماس ورودی موفق.

تماس خروجی موفق.

صدای دوطرفه.

BLF Subscription.

TLS Registration.

Provisioning Success.

تعداد Rebootهای غیرعادی.

برای هر Batch یک شرط توقف تعریف کنید

مثلاً:

اگر بیش از 1 تلفن Register Failed شد:
Rollout متوقف شود.

اگر تماس ورودی روی Canary خراب شد:
Rollout متوقف شود.

اگر Auto Provisioning بعد از Upgrade Fail شد:
Rollout متوقف شود.

اگر Hardware Limit دیده شد:
کل همان Hardware Group متوقف شود.

این همان چیزی است که جلوی تبدیل یک خطای یک‌دستگاهی به قطعی ۵۰ تلفن را می‌گیرد.

یک Rollout پیشنهادی برای ۵۰ تلفن

این اعداد قانون ثابت نیستند

در یک Call Center ممکن است حتی Batch شش‌تایی هم بزرگ باشد.

در یک دفتر کم‌تماس شاید Batch بزرگ‌تر قابل قبول باشد.

اندازه گروه را بر اساس ظرفیت باقی‌مانده شبکه تلفنی انتخاب کنید، نه صرفاً تعداد کل تلفن‌ها.

چه دستگاه‌هایی را آخر Upgrade کنیم؟

دستگاه‌های حساس را آخر قرار دهید.

مثلاً تلفن:

پذیرش.

نگهبانی.

مدیریت بحران.

مرکز تماس اصلی.

اپراتور اصلی.

ابتدا Firmware را روی دستگاه‌های کم‌ریسک مشابه آن‌ها تأیید کنید.

چه زمانی Firmware را اصلاً آپدیت نکنیم؟

اگر یکی از موارد زیر وجود دارد، Rollout را متوقف کنید:

Release Notes مدل دقیق را پیدا نکرده‌اید.

Hardware Version دستگاه‌ها مشخص نیست.

مسیر Upgrade مستقیم تأیید نشده است.

Firmware Customized است و Provider پاسخ نداده است.

Backup Configuration ندارید.

Rollback یا Recovery Plan ندارید.

Provisioning Server هنوز Firmware دیگری Push می‌کند.

دسترسی فیزیکی یا راه دور برای Recovery ندارید.

چک‌لیست قبل از شروع Firmware Upgrade

پرسش‌های متداول درباره آپدیت Firmware یالینک

آیا می‌توان Firmware همه تلفن‌های Yealink را هم‌زمان آپدیت کرد؟

از نظر فنی در بعضی سیستم‌های مدیریتی امکان Push گروهی وجود دارد، اما برای محیط عملیاتی بهتر است Rollout مرحله‌ای انجام شود. ابتدا Canary، سپس Pilot و بعد Batchهای کوچک تا خرابی یک Firmware کل شبکه تلفنی را هم‌زمان تحت تأثیر قرار ندهد.

آیا هنگام Firmware Upgrade تماس تلفن قطع می‌شود؟

خود دستگاه هنگام نصب و Reboot برای مدتی از سرویس خارج می‌شود. هدف Rollout مرحله‌ای جلوگیری از قطع هم‌زمان تعداد زیادی تلفن است، نه حذف کامل وقفه روی دستگاهی که در حال Upgrade است.

از کجا بفهمیم Firmware با Hardware Revision دستگاه سازگار است؟

Model، Hardware Version و Firmware Version را از Status یا About دستگاه ثبت کنید و Release Notes و Firmware صفحه رسمی همان مدل را بررسی کنید. Yealink برای بعضی Hardware Revisionها محدودیت Firmware مستند کرده است.

آیا می‌توان بعد از آپدیت Yealink به Firmware قبلی برگشت؟

همیشه نه. بعضی نسخه‌ها و شاخه‌های جدید Yealink محدودیت Downgrade دارند. برای نمونه V87 در برخی خانواده‌ها اجازه بازگشت به V86 یا نسخه‌های قبل را نمی‌دهد. قبل از Upgrade باید Release Notes همان مدل و نسخه بررسی شود.

اگر Firmware جدید مشکل داشت ولی Downgrade مجاز نبود چه کنیم؟

Rollout را روی همان Canary یا Batch متوقف کنید، Configuration را بررسی کنید و با مستندات یا پشتیبانی Yealink مسیر اصلاح یا Firmware بعدی را مشخص کنید. Recovery Mode را نباید به‌عنوان Downgrade تضمینی در نظر گرفت.

Recovery Mode چه زمانی استفاده می‌شود؟

وقتی Upgrade شکست خورده و تلفن به‌صورت عادی Boot نمی‌شود یا روی Initializing متوقف می‌ماند. روش Recovery بر اساس مدل می‌تواند HTTP، TFTP، USB یا Backup System باشد.

برای آپدیت گروهی Yealink از چه پارامتری استفاده می‌شود؟

در Auto Provisioning، Yealink پارامتر static.firmware.url را برای تعیین URL فایل Firmware مستند کرده است. Firmware باید دقیقاً مربوط به همان مدل و مسیر ارتقای پشتیبانی‌شده باشد.

چرا بعد از آپدیت دستی، تلفن دوباره Firmware دیگری می‌گیرد؟

Provisioning Server، RPS یا سرویس مدیریتی ممکن است هنوز Firmware URL دیگری روی دستگاه اعمال کند. Common CFG، MAC CFG، RPS و Server URL را بررسی کنید.

جمع‌بندی

آپدیت Firmware یالینک در محیط چندده‌دستگاهی یک عملیات مدیریتی است، نه فقط Upload کردن فایل ROM. قبل از شروع باید Model، Hardware Version و Firmware فعلی هر گروه را بدانید و Release Notes نسخه مقصد را برای محدودیت Upgrade و Downgrade بررسی کنید.

بعد از گرفتن Backup، یک دستگاه Canary واقعی را ارتقا دهید و رجیستر SIP، تماس ورودی، خروجی، RTP، TLS، BLF و Auto Provisioning را آزمایش کنید. اگر این مرحله سالم بود، Rollout را در Batchهای کوچک ادامه دهید تا در تمام مدت بخشی از ظرفیت تلفنی مجموعه فعال بماند.

مهم‌تر از همه، Firmware Rollback را تضمین‌شده فرض نکنید. Yealink در بعضی نسخه‌های جدید Downgrade را به دلایل امنیتی یا سازگاری محدود کرده است. بنابراین بهترین Rollback Plan آن است که قبل از Upgrade بدانید آیا نسخه قبلی قابل نصب است، Configuration قبلی کجا نگهداری شده و Recovery Mode دقیق همان مدل چگونه کار می‌کند.