پیشنهاد اصلی و کلیک‌خورتر: چرا Cisco 78xx و 88xx MPP بعد از آپدیت رجیستر نمی‌شوند؟ علت و روش رفع مشکل

برای همین اولین کار نباید Factory Reset یا Downgrade کورکورانه باشد. ابتدا باید مشخص کنیم تلفن در کدام مرحله متوقف می‌شود: آیا DNS مقصد را پیدا نمی‌کند؟ TCP/TLS ساخته نمی‌شود؟ Certificate رد می‌شود؟ REGISTER اصلاً ارسال نمی‌شود؟ یا REGISTER ارسال می‌شود اما PBX پاسخ 401، 403 یا Timeout می‌دهد؟

در این مقاله Cisco 78xx و 88xx را بعد از Firmware Upgrade مرحله‌به‌مرحله بررسی می‌کنیم و دو مسیر Trust را از هم جدا می‌کنیم: حالتی که خود Cisco باید Certificate سرور را Trust کند و حالتی که سرور، SBC، ISE یا Provisioning Server باید Certificate خود تلفن را Trust کند. این تفاوت یکی از مهم‌ترین بخش‌های تشخیص این مشکل است.

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

نوشتن «Cisco 8841» به‌تنهایی برای عیب‌یابی کافی نیست. حداقل این اطلاعات را ثبت کنید:

Model:
Product ID:
MPP / Enterprise:
Old Firmware:
New Firmware:
Hardware Revision:
SIP Transport:
Proxy / Outbound Proxy:
Registration Server:
Provisioning Method:

مخصوصاً مشخص کنید دستگاه MPP/3PCC است یا Enterprise؛ چون Release، Provisioning، Certificate Management و Registration این دو خانواده یکسان نیست.

آخرین Firmware برای همه 88xx یکسان نیست

در زمان نگارش این مقاله، Cisco برای سری‌های 7800 MPP و بخش عمده سری 8800 MPP، Release Notes نسخه 12.0(7)SR5 را منتشر کرده است.

اما نباید عبارت «8800» را به این معنی بگیریم که تمام مدل‌ها دقیقاً یک چرخه پشتیبانی دارند. برای مثال Cisco در اعلامیه‌های Webex Calling گفته بود 8845 و 8865 از SR3 به بعد دیگر مشمول آن ارتقا نبودند و این مدل‌ها باید جداگانه بر اساس صفحه پشتیبانی خودشان بررسی شوند.

پس قبل از Upgrade یا Rollback همیشه Release Notes همان مدل را باز کنید، نه صرفاً همان Series.

بعد از آپدیت اولین سؤال: آیا اصلاً SIP REGISTER ارسال می‌شود؟

مسیر سالم Registration روی TLS تقریباً چنین است:

DNS
 ↓
TCP connection
 ↓
TLS ClientHello
 ↓
ServerHello + Certificate
 ↓
TLS Finished
 ↓
SIP REGISTER
 ↓
401 Unauthorized
 ↓
REGISTER + Authorization
 ↓
200 OK

اگر REGISTER اصلاً دیده نمی‌شود، Auth ID و Password را فعلاً تغییر ندهید. مشکل هنوز قبل از Authentication قرار دارد.

جدول تشخیص سریع بعد از Firmware Upgrade

Trust Store را اول به دو جهت تقسیم کنید

عبارت Trust Store در سیستم‌های Cisco می‌تواند دو مسئله کاملاً متفاوت را توصیف کند.

این دو را با هم قاطی نکنید؛ چون راه‌حل کاملاً متفاوت است.

حالت اول: Cisco Certificate سرور را Trust نمی‌کند

این سناریو بیشتر در SIP over TLS، HTTPS Provisioning یا سرویس‌های امن دیده می‌شود.

مثلاً Cisco به:

sip.example.com:5061

متصل می‌شود و Server این زنجیره را ارائه می‌دهد:

sip.example.com
    ↓
Intermediate CA
    ↓
Root CA

اگر Intermediate ناقص باشد، Root مورد اعتماد Device نباشد، Certificate منقضی شده باشد یا Hostname تطبیق نداشته باشد، TLS قبل از REGISTER متوقف می‌شود.

Certificate واقعی سرور را با OpenSSL ببینید

openssl s_client \
-connect sip.example.com:5061 \
-servername sip.example.com \
-showcerts

به این بخش‌ها توجه کنید:

subject=
issuer=
Certificate chain
Server Temp Key
Protocol
Cipher
Verify return code

تاریخ Certificate را جداگانه بررسی کنید

openssl x509 \
-in server.crt \
-noout \
-subject \
-issuer \
-dates

مخصوصاً این دو مقدار:

notBefore
notAfter

چرا NTP بعد از Firmware Upgrade مهم می‌شود؟

Firmware Upgrade معمولاً با Reboot همراه است. اگر تلفن پس از Boot نتواند زمان صحیح را از NTP بگیرد، Certificate Validation می‌تواند Fail شود.

ممکن است Certificate واقعاً سالم باشد اما Phone تصور کند:

Certificate Not Yet Valid

یا:

Certificate Expired

است.

پس زمان خود تلفن را قبل از هر تغییر بررسی کنید

ساعت روی صفحه، NTP Server و DHCP Option 42 را بررسی کنید.

اگر NTP Hostname است، DNS آن را نیز تست کنید.

dig A ntp.example.com +short

Hostname و SAN را بررسی کنید

اگر Phone به:

sip.example.com

متصل می‌شود، Certificate باید هویت مناسب همان Hostname را ارائه کند.

SAN را ببینید:

openssl x509 \
-in server.crt \
-noout \
-ext subjectAltName

استفاده از IP به‌جای Domain همیشه راه‌حل نیست

اگر Certificate برای:

sip.example.com

صادر شده باشد، تغییر Proxy به:

203.0.113.10

ممکن است DNS را دور بزند اما Certificate Name Validation را خراب کند.

حالت دوم: Server دیگر Certificate خود Cisco را Trust نمی‌کند

این سناریو در mTLS، Secure Provisioning، 802.1X و بعضی استقرارهای امن اهمیت دارد.

Cisco تلفن‌ها را با Manufacturer Installed Certificate یا MIC و Secure Unique Device Identifier یا SUDI عرضه می‌کند.

در این حالت Server ممکن است از Phone Client Certificate بخواهد:

Cisco Phone Certificate
        ↓
Cisco Manufacturing CA
        ↓
Cisco Root CA

اگر Server Trust Store این CA را نشناسد، حتی اگر خود Phone هیچ مشکلی با Certificate Server نداشته باشد، اتصال امن رد می‌شود.

Field Notice مهم Cisco درباره CAهای جدید

Cisco در Field Notice با شناسه FN72302 اعلام کرده دستگاه‌های جدید می‌توانند با Device Certificate صادرشده از CAهای جدید مانند موارد زیر عرضه شوند:

Cisco Manufacturing CA III
Cisco Manufacturing HA SUDI CA
Cisco Basic Assurance Root CA 2099
Cisco Root CA 2099

اگر این CAها در Trust Store سمت Server نباشند، Secure Deployment ممکن است Fail شود.

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

ممکن است Firmware جدید Certificate یا SUDI تازه‌شده‌ای را استفاده کند یا Secure Provisioning دوباره Negotiation شود.

بنابراین بعد از Update متوجه مشکل می‌شوید، اما علت واقعی ممکن است این باشد که Server هنوز CA جدید Cisco را Trust نکرده است.

این تفاوت مهم است:

Firmware triggered the condition
≠
Firmware itself is necessarily defective

Field Notice دوم: MIC قدیمی می‌تواند منقضی شود

Cisco در FN72593 توضیح داده که MIC بعضی MPPها می‌تواند بعد از دوره اعتبار خود منقضی شود.

اثرات ممکن شامل این موارد است:

Secure Provisioning مبتنی بر Client Certificate، mTLS، بعضی Firmware Upgradeها و 802.1X مبتنی بر MIC.

برای Firmwareهای جدیدتر از 12.0.3، Cisco اعلام کرده Refresh مربوط به SUDI به‌صورت خودکار انجام می‌شود.

برای Firmwareهای 11.3.5 تا 12.0.2 چه؟

Cisco برای برخی نسخه‌های آن بازه پارامتر زیر را مستند کرده است:

<MIC_Cert_Refresh_Enable ua="na">Yes</MIC_Cert_Refresh_Enable>

اما برای Device جدید روی Firmware فعلی، از این پارامتر به‌عنوان راه‌حل عمومی و بدون بررسی نسخه استفاده نکنید.

Firmware فعلی چه نکته‌ای درباره Registration دارد؟

در Release Notes نسخه 12.0(7)SR5 برای هر دو خانواده 7800 MPP و 8800 MPP، Cisco باگ زیر را در Resolved Caveats آورده است:

CSCwt49527
Intermittent SIP registration issues caused by DNS Lookup Failures

این مورد بسیار مهم است، چون نشان می‌دهد هر Registration Failure بعد از Firmware Change را نباید فوراً Certificate فرض کرد.

اگر روی SR4 یا نسخه قدیمی‌تر هستید و Registration ناپایدار است

DNS Lookup را در Capture بررسی کنید و Release Notes نسخه خودتان را با SR5 مقایسه کنید.

ممکن است مشکل شما به Caveat شناخته‌شده‌ای مرتبط باشد که در نسخه بعدی رفع شده است.

اما صرف وجود یک Fix در SR5 ثابت نمی‌کند هر DNS Failure روی نسخه قدیمی همان Bug است؛ PCAP و Log باید رفتار مشابه را نشان دهند.

DNS را در Cisco بعد از Upgrade جدا تست کنید

اگر Proxy شما Domain است:

dig A sip.example.com
dig AAAA sip.example.com

اگر SRV دارید:

dig SRV _sips._tcp.example.com

DNS Resolver خود تلفن را با لپ‌تاپ یکی فرض نکنید

Firmware Upgrade و Reboot ممکن است باعث شود Phone دوباره DHCP بگیرد.

اگر Voice VLAN DHCP Scope DNS اشتباه دارد، ممکن است قبل از Upgrade از Cache قبلی استفاده شده باشد اما بعد از Boot مشکل ظاهر شود.

بنابراین DNS1 و DNS2 واقعی Phone را ثبت کنید.

Packet Capture تعیین می‌کند مشکل Certificate است یا DNS

فیلتر DNS در Wireshark:

dns

فقط SRV:

dns.qry.type == 33

فیلتر TLS

tls

TLS Alert:

tls.alert_message

فیلتر SIP Registration

sip.Method == "REGISTER"

یک Capture خراب از Certificate چه شکلی است؟

Cisco → Server    ClientHello
Server → Cisco    ServerHello
Server → Cisco    Certificate
Cisco → Server    TLS Alert

No SIP REGISTER

در این سناریو SIP Credential هنوز وارد ماجرا نشده است.

یک Capture خراب از DNS چه شکلی است؟

Cisco → DNS     Query A / SRV
Cisco → DNS     Retransmission
Cisco → DNS     Retransmission

No response
No TCP
No TLS
No REGISTER

یک Registration سالم بعد از TLS چه شکلی است؟

TLS Handshake complete

REGISTER  --------------------->
          <---------------- 401

REGISTER + Authorization ---->
          <---------------- 200 OK

اگر 401 می‌بینید Certificate احتمالاً مشکل اصلی نیست

رسیدن به 401 یعنی SIP Request از داخل TLS عبور کرده و Server آن را پردازش کرده است.

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

User ID، Auth ID، Password، Realm و Registration Policy.

اگر 403 بعد از Firmware Upgrade ظاهر شد

403 بیشتر از Certificate به SIP Policy یا Credential اشاره می‌کند.

مقایسه کنید آیا Provisioning بعد از Upgrade این مقادیر را تغییر داده است:

User ID
Auth ID
Password
Proxy
Outbound Proxy
SIP Transport

Provisioning می‌تواند بعد از Upgrade Config متفاوتی اعمال کند

گاهی Firmware Upgrade درست انجام شده، اما اولین Resync بعد از Boot فایل Configuration دیگری دریافت می‌کند.

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

Config before upgrade
Config after upgrade

مخصوصاً Profile Rule، Transport، TLS Name Validate، Proxy، DNS SRV و Certificate-related parameters را بررسی کنید.

در Asterisk هم‌زمان SIP Logger بگیرید

asterisk -rvvv

سپس:

pjsip set logger on

تلفن را Reboot یا Register کنید و ببینید آیا REGISTER اصلاً به Asterisk می‌رسد.

اگر هیچ REGISTER روی Asterisk دیده نمی‌شود

تمرکز را روی Phone → DNS → TCP/TLS قرار دهید.

در این مرحله تغییر PJSIP Endpoint معمولاً اتلاف وقت است.

اگر REGISTER می‌رسد ولی پاسخ Server به Phone نمی‌رسد

Firewall، NAT، TLS Connection State و مسیر برگشت را بررسی کنید.

Firmware Regression را چطور واقعاً ثابت کنیم؟

صرف اینکه مشکل بلافاصله بعد از Upgrade شروع شده کافی نیست.

برای اینکه احتمال Regression بالا برود بهتر است این شرایط را داشته باشید:

مثال واقعی از Caveat مربوط به Registration

نسخه 12.0(7)SR5 یک نمونه خوب است. Cisco در همین Release مشکل:

CSCwt49527

را به‌عنوان DNS Lookup Failure ایجادکننده SIP Registration ناپایدار برطرف کرده است.

وجود Bug ID به شما امکان می‌دهد بررسی را از «احساس می‌کنم Firmware خراب شده» به یک Evidence واقعی تبدیل کنید.

Known Issues را فقط از مقاله‌های قدیمی نخوانید

Cisco خودش در Release Notes تأکید می‌کند وضعیت Caveatها می‌تواند تغییر کند و برای نمای به‌روزتر باید Bug Search همان Release بررسی شود.

پس قبل از Downgrade:

Release Notes نسخه نصب‌شده، Open Caveats، Resolved Caveats و Bug Search را بررسی کنید.

Downgrade اولین راه‌حل نیست

اگر Certificate یا Trust Store سمت Server مشکل دارد، Downgrade فقط ممکن است موقتاً رفتار قبلی را برگرداند و ریشه مشکل را پنهان کند.

قبل از Rollback باید بدانید:

آیا نسخه مقصد برای مدل پشتیبانی می‌شود؟

آیا مسیر Downgrade مجاز است؟

آیا Provisioning دوباره نسخه جدید را Push نمی‌کند؟

آیا نسخه قدیمی Security Fix مهمی را از دست می‌دهد؟

آیا Release Notes محدودیت خاصی دارد؟

قبل از Rollback Provisioning را کنترل کنید

اگر Upgrade Rule همچنان نسخه جدید را Push می‌کند، Downgrade دستی ممکن است بعد از اولین Resync دوباره Upgrade شود.

ابتدا Upgrade Rule و Provisioning Server را بررسی کنید.

Factory Reset هم راه‌حل Certificate نیست

Factory Reset ممکن است Configuration محلی را پاک کند اما:

Root CA سمت Server را اضافه نمی‌کند، Certificate Server را تمدید نمی‌کند، NTP شبکه را اصلاح نمی‌کند و Firmware Bug را رفع نمی‌کند.

پس فقط وقتی Configuration Corruption یا تنظیم محلی مشکوک دارید سراغ Reset بروید.

سناریوی ۱: بعد از Upgrade هیچ REGISTER نمی‌بینیم و TLS Alert داریم

Certificate Chain، Root CA، SAN، NTP و TLS Version را بررسی کنید.

اگر Server از mTLS استفاده می‌کند، Server Trust Store را هم بررسی کنید.

سناریوی ۲: بعد از Upgrade هیچ TLS Connectionی ساخته نمی‌شود

DNS، Port، Firewall، Proxy و SIP Transport را بررسی کنید.

Certificate هنوز وارد مرحله عیب‌یابی نشده است.

سناریوی ۳: بعد از Upgrade DNS مرتب Fail می‌شود

Resolver واقعی Phone، SRV/A Lookup و PCAP را بررسی کنید.

اگر روی نسخه‌ای قبل از 12.0(7)SR5 هستید، Caveat `CSCwt49527` را نیز با رفتار واقعی سیستم مقایسه کنید.

سناریوی ۴: TLS سالم است اما 403 می‌گیریم

Firmware Certificate را مقصر ندانید.

Credential، Auth ID، Realm، Account Policy و Provisioning را بررسی کنید.

سناریوی ۵: فقط mTLS بعد از Update خراب شده

Server Certificate Trust Store را بررسی کنید.

ممکن است Phone Device Certificate یا CA Chain متفاوتی ارائه کند و سرور هنوز Cisco Manufacturing CA جدید را Trust نکرده باشد.

سناریوی ۶: بعد از Upgrade HTTPS Provisioning خراب شده و سپس SIP هم خراب است

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

ابتدا Provisioning را حل کنید، چون SIP Configuration موردنیاز ممکن است اصلاً به Device نرسیده باشد.

سناریوی ۷: ساعت بعد از Reboot اشتباه است

قبل از Certificate Troubleshooting، NTP را درست کنید.

اگر Clock غلط باشد تقریباً تمام نتیجه‌های Certificate Validation زیر سؤال می‌روند.

سناریوی ۸: فقط یک مدل از 88xx بعد از Update مشکل دارد

مدل و Release Support را جدا بررسی کنید.

مثلاً چرخه پشتیبانی 8845/8865 لزوماً با 8841/8851/8861 یکسان نیست.

سناریوی ۹: چند تلفن قدیمی سالم‌اند ولی Phone جدید رجیستر نمی‌شود

این الگو می‌تواند به Device Certificate جدید مربوط باشد.

Field Notice FN72302 دقیقاً توضیح می‌دهد دستگاه‌های جدید ممکن است از Cisco Manufacturing CAهای جدید استفاده کنند و Server باید CAهای جدید را در Trust List داشته باشد.

سناریوی ۱۰: تلفن قدیمی بعد از سال‌ها ناگهان Secure Provisioning را از دست می‌دهد

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

FN72593 مشخصاً برای همین خانواده MPP درباره انقضای Manufacturer Installed Certificate هشدار داده است.

سناریوی ۱۱: Registration فقط متناوب قطع می‌شود

زمان‌ها را ثبت کنید.

اگر TLS Connection کامل می‌شود اما DNS Lookup گاهی Timeout می‌شود، DNS و Firmware Caveat را در اولویت قرار دهید.

سناریوی ۱۲: بعد از Rollback مشکل فوراً رفع می‌شود

این نتیجه احتمال Firmware Interaction را بالا می‌برد، اما هنوز Config Migration و Certificate Behavior را بررسی کنید.

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

چه اطلاعاتی قبل از تماس با پشتیبانی جمع کنیم؟

چک‌لیست نهایی قبل از Downgrade

پرسش‌های متداول درباره رجیستر نشدن Cisco بعد از Firmware Update

چرا Cisco 78xx یا 88xx بعد از آپدیت رجیستر نمی‌شود؟

علت می‌تواند DNS، NTP، TLS، Certificate Chain، Trust Store، Provisioning، تغییر Device Certificate یا یک Caveat واقعی Firmware باشد. ابتدا مشخص کنید REGISTER اصلاً ارسال می‌شود یا نه.

آیا بعد از آپدیت فوراً باید Firmware را Downgrade کنیم؟

خیر. ابتدا Release Notes، Caveatها، DNS، NTP و TLS را بررسی کنید. Downgrade بدون تشخیص ممکن است فقط مشکل Trust یا Provisioning را پنهان کند.

Trust Store در این مشکل یعنی Trust Store تلفن یا Server؟

هر دو ممکن است نقش داشته باشند. Phone باید Certificate سرور را Trust کند و در mTLS، Server نیز باید MIC یا SUDI تلفن و CA صادرکننده آن را Trust کند.

چرا بعد از Update ساعت Cisco مهم است؟

Firmware Upgrade با Reboot همراه است و اگر NTP درست کار نکند، ساعت اشتباه می‌تواند Certificate معتبر را Expired یا Not Yet Valid نشان دهد.

جدیدترین Firmware فعلی Cisco 7800/8800 MPP چیست؟

در زمان نگارش این مقاله، Cisco Release Notes نسخه 12.0(7)SR5 را با تاریخ ۳۱ مارس ۲۰۲۶ برای سری 7800 MPP و بخش عمده سری 8800 MPP منتشر کرده است. مدل دقیق را جداگانه بررسی کنید.

آیا در Firmwareهای اخیر مشکل SIP Registration شناخته‌شده وجود داشته است؟

بله. Cisco در 12.0(7)SR5 باگ CSCwt49527 مربوط به Registration متناوب ناشی از DNS Lookup Failure را به‌عنوان Resolved Caveat ثبت کرده است.

MIC و SUDI در Cisco چه هستند؟

Certificateهای هویتی Device هستند که برای احراز هویت امن تلفن در سرویس‌هایی مانند mTLS، Secure Provisioning و بعضی سناریوهای 802.1X استفاده می‌شوند.

چرا دستگاه‌های جدید Cisco روی همان Server قدیمی Fail می‌شوند؟

یکی از احتمال‌ها این است که Device Certificate توسط Cisco Manufacturing CA جدید صادر شده باشد و Trust Store سمت Server هنوز Root/CA جدید را نداشته باشد.

چطور بفهمیم مشکل Certificate است؟

در PCAP اگر TCP و TLS شروع شوند، Certificate دریافت شود و بعد TLS Alert ببینید ولی هیچ REGISTER ارسال نشود، Certificate/Trust/NTP از مظنون‌های اصلی هستند.

اگر REGISTER و 401 را می‌بینیم هنوز Certificate مشکل دارد؟

احتمالش بسیار کمتر است؛ مشاهده REGISTER و 401 نشان می‌دهد TLS Session تا SIP Layer جلو رفته است و باید Authentication را بررسی کنید.

Factory Reset مشکل Trust Store را حل می‌کند؟

معمولاً خیر. Reset نمی‌تواند CA گمشده سمت Server، Certificate منقضی‌شده، NTP خراب یا Firmware Caveat را اصلاح کند.

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

وقتی مشکل روی نسخه جدید قابل تکرار باشد، نسخه قبلی با همان Config و Network سالم باشد، Release Notes مسیر Rollback را اجازه دهد و شواهد PCAP یا Caveatها Firmware را به‌عنوان عامل محتمل نشان دهند.

جمع‌بندی

اگر Cisco 78xx یا 88xx درست بعد از Firmware Upgrade رجیستر نمی‌شود، آپدیت را به‌عنوان تنها مظنون در نظر نگیرید. اولین کار این است که مشخص کنید Registration در کدام مرحله متوقف شده است: DNS، TCP، TLS، Certificate Validation یا SIP.

در TLS دو Trust Store متفاوت داریم. در یک جهت Phone باید Certificate سرور را Trust کند؛ در جهت دیگر، اگر mTLS یا Secure Device Authentication دارید، Server باید MIC/SUDI تلفن و CAهای Cisco را بشناسد. Field Noticeهای رسمی Cisco نشان می‌دهند این بخش در سری‌های MPP اهمیت عملی دارد.

NTP نیز بخش اصلی عیب‌یابی است. یک Reboot بعد از Firmware Upgrade می‌تواند باعث شود دستگاه بدون زمان صحیح بالا بیاید و Certificate سالم را نامعتبر تشخیص دهد.

در کنار Certificate حتماً Release Notes همان Firmware را بررسی کنید. در نسخه 12.0(7)SR5، Cisco باگ CSCwt49527 را رفع کرده که باعث SIP Registration متناوب بر اثر DNS Lookup Failure می‌شد؛ نمونه‌ای روشن از اینکه Registration Failure همیشه Certificate نیست.

بهترین روش این است که Capture نسخه سالم و نسخه مشکل‌دار را کنار هم قرار دهید. اگر رفتار DNS، TLS یا SIP در Firmware جدید واقعاً تغییر کرده باشد، آن‌وقت Rollback یا Update به Maintenance Release جدیدتر تصمیمی مبتنی بر مدرک خواهد بود، نه حدس.