چرا تلفن سیسکو رجیستر نمی‌شود؟ رفع مشکل Register Failed در سری 7800 و 8800

این دو Firmware ظاهر سخت‌افزاری تقریباً یکسانی دارند اما مسیر رجیسترشدن آن‌ها متفاوت است. مدل MPP برای SIP PBXهای ثالث، سرویس‌دهندگان VoIP و Webex Calling طراحی شده است؛ در حالی که Enterprise Firmware برای Cisco Unified Communications Manager یا CUCM ساخته شده است. بنابراین اگر Enterprise Phone را مستقیماً برای Asterisk یا یک SIP Trunk معمولی تنظیم کنید، عیب‌یابی DNS و Password شما را به نتیجه نمی‌رساند، چون از ابتدا Firmware مناسب آن معماری نیست.

در این راهنما ابتدا MPP و Enterprise را دقیق تشخیص می‌دهیم و بعد دو مسیر عیب‌یابی کاملاً جدا می‌سازیم. در شاخه MPP، DNS A/SRV، Proxy، SIP REGISTER، خطاهای 401 و 403، TLS، Certificate، NTP و Packet Capture بررسی می‌شوند. در شاخه Enterprise نیز DHCP، TFTP، Option 150، فایل Configuration، CUCM، CTL/ITL و Certificate بررسی خواهند شد.

اولین مرحله: MPP است یا Enterprise؟

این مرحله را رد نکنید. دو تلفن Cisco 8841 می‌توانند از بیرون کاملاً مشابه باشند اما یکی با MPP Firmware و دیگری با Enterprise Firmware اجرا شود.

تشخیص از برچسب پشت تلفن

Cisco در راهنمای رسمی Migration اعلام می‌کند اگر داخل PID عبارت‌هایی مانند 3PCC، 3PC یا 3PW دیده شود، دستگاه در اصل به‌عنوان Multiplatform Phone عرضه شده است.

مثلاً:

CP-8841-3PCC-K9

نشانه MPP است؛ در حالی که:

CP-8841-K9

در اصل Enterprise SKU است.

اما یک استثنا وجود دارد: تلفن‌های 7800 و 8800 واجد شرایط می‌توانند بین Enterprise و MPP تبدیل شوند. پس برچسب پشت دستگاه سابقه سخت‌افزار را نشان می‌دهد، نه الزاماً Firmware فعلی.

تشخیص Firmware فعلی از خود تلفن

Cisco برای تشخیص وضعیت فعلی پیشنهاد می‌کند از منوی دستگاه استفاده کنید.

اگر عنوان صفحه اصلی تنظیمات:

Information and settings

باشد، معمولاً MPP Firmware اجرا می‌شود.

در بخش:

Status → Product information

Product Name و Software Version را بررسی کنید.

نمونه MPP:

Product Name: CP-8841-3PCC
Software Version: sip88xx....MPP...

اگر منوی اصلی با عنوان Applications باز می‌شود و Model Number عبارت 3PCC ندارد، معمولاً Enterprise Firmware اجرا شده است.

درخت تصمیم سریع برای Cisco IP Phone Register Failed

شاخه اول: Cisco MPP یا 3PCC رجیستر نمی‌شود

اگر تلفن MPP است و قرار است روی Asterisk، FreePBX، Issabel، BroadWorks، Metaswitch یا یک سرویس SIP دیگر رجیستر شود، این شاخه را دنبال کنید.

مرحله اول MPP: تلفن واقعاً IP، Gateway و DNS دارد؟

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

در Status یا Network Status این موارد را ثبت کنید:

اگر Gateway یا DNS خالی است، هنوز نباید سراغ SIP Password بروید.

Registration State را از خود MPP ببینید

در Web Interface تلفن‌های MPP، بخش Status اطلاعات مستقیمی درباره Extension دارد.

در Ext Status می‌توانید مواردی مانند:

Registration State، Last Registration At، Next Registration In Seconds و Mapped SIP Port را ببینید.

اگر Registration State برابر Not Registered است، Timestamp و Extension مشکل‌دار را ثبت کنید.

مرحله دوم: Proxy و Account را بررسی کنید

در MPP معمولاً مسیر زیر را باز کنید:

Admin Login → advanced → Voice → Ext(n)

دو بخش مهم عبارت‌اند از:

SIP Settings و Proxy and Registration.

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

User ID و Auth ID همیشه یکسان نیستند

فرض کنید داخلی کاربر:

201

باشد، اما Provider برای Authentication این شناسه را داده باشد:

customer-201-48291

در این صورت قراردادن 201 در هر دو فیلد می‌تواند باعث Authentication Failure شود.

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

اگر Proxy به‌صورت Domain وارد شده است، اول مشخص کنید تلفن باید چه Recordی را Resolve کند.

فرض کنیم SIP Server این است:

sip.example.com

از یک سیستم داخل همان شبکه ابتدا A/AAAA Record را ببینید:

nslookup sip.example.com

DNS SRV در Cisco MPP

Cisco MPP قابلیت DNS SRV برای Proxy و Outbound Proxy دارد، اما در مستند فعلی مقدار پیش‌فرض Use DNS SRV برابر No است.

پس صرف اینکه در DNS یک SRV Record ساخته‌اید به معنی استفاده تلفن از آن نیست.

در Voice → Ext(n) تنظیم زیر را بررسی کنید:

Use DNS SRV = Yes

Prefixهای SRV برای UDP، TCP و TLS

اگر DNS SRV Auto Prefix فعال باشد، Cisco بر اساس Transport از Prefixهای مربوط استفاده می‌کند.

برای مثال:

nslookup -type=SRV _sip._udp.example.com
nslookup -type=SRV _sip._tcp.example.com
nslookup -type=SRV _sips._tcp.example.com

با dig هم SRV را ببینید

dig SRV _sip._udp.example.com +short
dig SRV _sip._tcp.example.com +short
dig SRV _sips._tcp.example.com +short

اگر تلفن TLS استفاده می‌کند ولی فقط `_sip._udp` ساخته‌اید، نتیجه DNS می‌تواند با Transport مورد انتظار هماهنگ نباشد.

Priority و Weight در SRV را فراموش نکنید

SRV فقط برای پیدا کردن یک IP نیست؛ می‌تواند چند SIP Proxy با Priority و Weight متفاوت تعریف کند.

اگر تلفن گاهی روی Server سالم و گاهی روی Server خراب می‌رود، تمام Targetهای SRV را بررسی کنید.

ممکن است فقط یکی از Backendها Certificate، Firewall یا SIP Configuration نادرست داشته باشد.

اگر با IP رجیستر می‌شود ولی با Domain نه

این تست سرنخ بسیار خوبی است.

اگر:

Proxy = 10.10.20.15

کار می‌کند ولی:

Proxy = sip.example.com

کار نمی‌کند، DNS، SRV/NAPTR و در TLS موضوع Hostname/Certificate را در اولویت قرار دهید.

مرحله چهارم: SIP Transport دقیقاً با Server یکسان است؟

در MPP، SIP Transport می‌تواند UDP، TCP، TLS یا در برخی Firmwareها Auto باشد.

اگر PBX فقط روی UDP 5060 گوش می‌دهد و Phone روی TLS تنظیم شده، Registration انجام نمی‌شود.

همچنین اگر Server روی TLS 5061 است اما Phone به TCP معمولی متصل می‌شود، باز هم نتیجه مشابه است.

مرحله پنجم: SIP REGISTER را بخوانید

یک Registration سالم با Digest Authentication معمولاً از نظر منطقی چنین الگویی دارد:

Cisco Phone                  SIP Registrar
    |                              |
    |------ REGISTER ------------->|
    |<----- 401 Unauthorized ------| | | |-- REGISTER + Authorization ->|
    |<--------- 200 OK ------------|
    |                              |

بنابراین دیدن اولین 401 Unauthorized الزاماً خطا نیست. در SIP Digest Authentication، 401 می‌تواند Challenge طبیعی Server باشد.

چیزی که مهم است مرحله بعد است: آیا Phone REGISTER دوم را همراه Authorization می‌فرستد و آیا Server در نهایت 200 OK برمی‌گرداند؟

اگر فقط REGISTER می‌رود و هیچ پاسخی برنمی‌گردد

مظنون‌های اصلی:

Firewall،

Route،

Port اشتباه،

NAT،

IP اشتباه DNS،

Transport اشتباه،

یا Down بودن SIP Server هستند.

در این حالت عوض‌کردن Password معمولاً بی‌فایده است؛ چون Server هنوز به مرحله Authentication نرسیده است.

خطاهای مهم SIP Registration را چگونه تفسیر کنیم؟

401 چه زمانی واقعاً مشکل می‌شود؟

این وضعیت طبیعی است:

REGISTER
401 Unauthorized
REGISTER + Authorization
200 OK

اما این وضعیت نیاز به بررسی دارد:

REGISTER
401 Unauthorized
REGISTER + Authorization
401 Unauthorized
REGISTER + Authorization
401 Unauthorized

در این حالت Auth ID، Password، Realm و تنظیم Account را بررسی کنید.

خطای 403 را فقط «رمز اشتباه» معنی نکنید

403 یعنی Server Request را فهمیده اما آن را رد کرده است. در سیستم‌های واقعی علت می‌تواند یکی از این موارد باشد:

Account غیرفعال،

IP Restriction،

Device Limit،

Domain اشتباه،

Credential نامعتبر،

یا Policy سرویس‌دهنده.

در این مرحله Log خود PBX یا SIP Provider بسیار مهم است.

423 Interval Too Brief چیست؟

اگر Cisco REGISTER را با Expiry کوتاه‌تری از حداقل موردقبول Registrar بفرستد، Server می‌تواند پاسخ 423 برگرداند و مقدار Min-Expires را اعلام کند.

طبق RFC 3261، Client می‌تواند دوباره با Expiration برابر یا بیشتر از Min-Expires ثبت‌نام کند.

در MPP مقدار Register Expires در مستند فعلی به‌صورت پیش‌فرض 3600 ثانیه ذکر شده است.

مرحله ششم: اگر TLS استفاده می‌کنید، SIP را موقتاً فراموش کنید

در TLS قبل از اینکه REGISTER ارسال شود باید TCP و TLS Handshake کامل شوند.

ترتیب منطقی:

DNS
 ↓
TCP Connection
 ↓
TLS Handshake
 ↓
SIP REGISTER
 ↓
Authentication
 ↓
200 OK

اگر TLS Handshake شکست بخورد، تغییر SIP Password هیچ تأثیری ندارد.

TLS Name Validate در Cisco MPP

در Firmwareهای فعلی MPP، وقتی SIP Transport روی TLS است، تلفن می‌تواند Hostname را با Certificate Server مقایسه کند.

Cisco برای TLS Name Validate مقدار پیش‌فرض Yes را مستند کرده است.

یعنی اگر Phone به این Host متصل شود:

sip.example.com

Certificate باید با همین Hostname سازگار باشد.

IP به‌جای Domain می‌تواند TLS را خراب کند

فرض کنید Certificate برای:

sip.example.com

صادر شده است اما Proxy را این‌طور تنظیم کرده‌اید:

203.0.113.20

اگر IP داخل SAN Certificate نباشد، Hostname Validation می‌تواند Connection را رد کند.

Certificate Server را از یک سیستم مدیریتی بررسی کنید

روی Linux:

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

این تست Certificate و TLS سمت Server را نشان می‌دهد، اما جای Trust Store و رفتار واقعی خود تلفن Cisco را نمی‌گیرد.

در TLS این موارد را بررسی کنید

مرحله هفتم: NTP را بررسی کنید

ساعت اشتباه فقط یک مشکل ظاهری نیست. Certificate دارای بازه اعتبار است و Time اشتباه می‌تواند یک Certificate سالم را Not Yet Valid یا Expired نشان دهد.

در MPP می‌توان Primary و Secondary NTP Server تعریف کرد.

نمونه Configuration XML:

<Primary_NTP_Server ua="rw">10.20.30.10</Primary_NTP_Server>
<Secondary_NTP_Server ua="rw">10.20.30.11</Secondary_NTP_Server>

Cisco همچنین DHCP Option 42 را برای NTP پشتیبانی می‌کند، اما در مستند فعلی MPP تنظیم مستقیم Primary/Secondary NTP اولویت بالاتری دارد.

اگر UDP رجیستر می‌شود ولی TLS نه

این نتیجه بسیار مفید است.

اگر همان User ID و Password روی UDP کار می‌کنند، Authentication Credential احتمالاً سالم است.

تمرکز را روی:

TLS Listener، Certificate، CA Trust، Hostname Validation، DNS و NTP قرار دهید.

اما UDP را فقط به‌عنوان تست تشخیصی در نظر بگیرید؛ اگر Policy سازمان TLS است، راه‌حل نهایی باید TLS سالم باشد.

مرحله هشتم: از خود Cisco MPP Packet Capture بگیرید

راهنمای فعلی Cisco برای MPP امکان گرفتن Packet Capture مستقیم از Phone را فراهم می‌کند.

از Web UI:

Info → Debug Info

و در بخش Problem Report Tool، Packet Capture را Start کنید.

Cisco دو حالت مهم ارائه می‌دهد:

All برای تمام Packetهای دریافتی تلفن، و Host IP Address برای Packetهایی که Source یا Destination آن‌ها خود Phone است.

ترتیب درست Capture

این ترتیب را رعایت کنید:

Filterهای Wireshark برای Cisco Register Failed

تمام SIP:

sip

فقط REGISTER:

sip.Method == "REGISTER"

خطاهای SIP:

sip.Status-Code >= 400

DNS:

dns

فقط IP تلفن:

ip.addr == 192.168.20.45

اگر SIP روی TLS است چرا REGISTER در Wireshark دیده نمی‌شود؟

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

در این شرایط ممکن است در PCAP فقط TCP و TLS دیده شوند.

پس ابتدا دنبال:

TCP SYN/SYN-ACK، TLS Client Hello، Server Hello، Certificate و TLS Alert بگردید.

برای Signaling رمزگذاری‌شده باید PCAP را با PRT/Device Log و Log سمت PBX ترکیب کنید.

خاموش‌کردن دائمی TLS فقط برای اینکه Wireshark بتواند REGISTER را بخواند راه‌حل مناسبی نیست.

شاخه دوم: Cisco Enterprise روی CUCM رجیستر نمی‌شود

اگر Firmware دستگاه Enterprise است، مسیر عیب‌یابی MPP را کنار بگذارید.

در این معماری Phone معمولاً ابتدا Network Configuration می‌گیرد، TFTP Server را پیدا می‌کند، Configuration مربوط به خود را دانلود می‌کند و سپس بر اساس اطلاعات CUCM رجیستر می‌شود.

بنابراین DNS SRV مربوط به SIP Provider اولین مرحله عیب‌یابی نیست.

مرحله اول Enterprise: DHCP و Voice VLAN

بررسی کنید Phone IP مناسب Voice VLAN را گرفته باشد.

اگر تلفن IP ندارد:

Switch Port،

Voice VLAN،

DHCP Relay،

DHCP Scope

و Network Access Control را بررسی کنید.

مرحله دوم Enterprise: TFTP Server 1

در CUCM Deployment، TFTP یکی از مراحل اصلی Boot است.

Cisco در راهنمای فعلی 8800 می‌گوید در حالت DHCP، تلفن معمولاً TFTP Server را از DHCP Option 150 دریافت می‌کند.

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

Admin settings → Network setup → Ethernet setup → IPv4 setup → TFTP Server 1

در 7800 مسیر بسته به Firmware کمی متفاوت است اما TFTP Server 1 باید مقدار صحیح داشته باشد.

DHCP Option 150 را بررسی کنید

در CUCM On-Premises، یکی از رایج‌ترین علت‌های Boot نشدن Phone همین Option است.

منطق DHCP باید چیزی شبیه این باشد:

DHCP Option 150 → CUCM TFTP Server IP

اگر Option 150 به Server قدیمی اشاره کند، Phone ممکن است Configuration اشتباه یا هیچ فایلی دریافت نکند.

پیام Enter activation code or service domain را جدی بگیرید

در راهنمای فعلی Cisco 8800 برای سناریوی On-Prem CUCM، یکی از علت‌های این پیام نبودن TFTP Address معرفی شده است.

قبل از واردکردن تصادفی Activation Code، Option 150 و Alternate TFTP را بررسی کنید.

مرحله سوم: Phone در CUCM تعریف شده است؟

CUCM باید Device را بشناسد یا Auto Registration فعال باشد.

در:

Device → Phone

بر اساس MAC Address جست‌وجو کنید.

MAC روی CUCM باید دقیقاً با MAC سخت‌افزاری Phone هماهنگ باشد.

MAC اشتباه چه علامتی دارد؟

اگر Phone در CUCM با MAC دیگری ساخته شده باشد، TFTP ممکن است Configuration مورد انتظار آن Device را نسازد.

Cisco در Status Messageهای فعلی خطایی مشابه:

File not found <Cfg File>

را مستند کرده است.

یکی از علت‌ها این است که Phone در Database CUCM وجود ندارد و Configuration اختصاصی آن ساخته نشده است.

فایل Configuration Enterprise

در CUCM برای Endpoint معمولاً Configuration مخصوص Device بر اساس MAC ایجاد می‌شود.

ساختار متداول نام فایل:

SEP<MAC>.cnf.xml

در Deploymentهای امن ممکن است نسخه Signed یا Encrypted فایل نیز استفاده شود.

TFTP Timeout چه معنی دارد؟

اگر Status Message:

TFTP Timeout

است، اول Credential SIP را بررسی نکنید.

Cisco برای این خطا مواردی مانند:

عدم ارتباط شبکه بین Phone و TFTP، Down بودن TFTP Service یا Network Congestion را مطرح می‌کند.

TFTP Access Error با Timeout فرق دارد

TFTP Access Error می‌تواند به Path یا دسترسی نادرست روی Server مربوط باشد؛ در حالی که Timeout بیشتر به نبود پاسخ یا Connectivity اشاره می‌کند.

این تفاوت در Status Message برای محدودکردن محل خرابی مهم است.

مرحله چهارم Enterprise: DNS

DNS در Enterprise هم مهم است، اما نقش آن با DNS SRV در MPP یکسان نیست.

اگر CUCM یا TFTP با Hostname در Configuration استفاده می‌شوند، Phone باید DNS Server معتبر داشته باشد و نام‌ها را Resolve کند.

در Status Messageهایی مثل:

DNS timeout
DNS unknown host
No DNS server IP

مستقیماً DNS را بررسی کنید.

DNS SRV را بی‌دلیل روی Enterprise دنبال نکنید

این یکی از تفاوت‌های مهم دو شاخه است.

در MPP، DNS SRV می‌تواند مستقیماً برای پیدا کردن SIP Proxy استفاده شود.

اما در Enterprise/CUCM استاندارد، Registration Serverها از مسیر Provisioning و فایل Configuration دستگاه مشخص می‌شوند.

پس مشاهده Enterprise Firmware و سپس صرف چند ساعت برای ساخت `_sip._udp` معمولاً مسیر عیب‌یابی اشتباهی است.

مرحله پنجم Enterprise: CUCM و TFTP Service روشن هستند؟

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

در Cisco Unified Serviceability، سرویس‌های مربوط به:

Cisco CallManager

و TFTP

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

اگر فقط یک Phone مشکل دارد، Device-specific Configuration محتمل‌تر است؛ اما اگر یک Site کامل مشکل دارد، Network/TFTP/CUCM در اولویت قرار می‌گیرند.

مرحله ششم Enterprise: CTL و ITL

در CUCM، Trust Listهای CTL و ITL می‌توانند روی دریافت امن Configuration و اعتماد Phone به Server اثر بگذارند.

Status Messageهایی مثل:

Trust List Update Failed
TFTP Authorization Fails
ITL authentication failed

را نباید با Factory Reset تصادفی پاسخ داد.

اول Trust Relationship و Certificateهای CUCM/TFTP را بررسی کنید.

پاک‌کردن CTL/ITL اولین راه‌حل نیست

در بعضی سناریوها Cisco پاک‌کردن دستی CTL/ITL را به‌عنوان مرحله نهایی Troubleshooting مطرح می‌کند، اما قبل از آن باید:

Network Connectivity،

TFTP،

TVS،

Certificateها،

و Trust List جدید

بررسی شوند.

حذف Trust File بدون شناخت معماری Secure CUCM می‌تواند مشکل جدید ایجاد کند.

مرحله هفتم: TLS و Certificate در Enterprise

در Secure Deployment، CUCM و Phone می‌توانند برای Signaling از TLS استفاده کنند.

Cisco صریحاً می‌گوید در Device Authentication، اگر CUCM نتواند Phone را Authenticate کند، Registration امن انجام نمی‌شود.

در این حالت MIC، LSC، Phone Security Profile، Certificate و Trust باید هماهنگ باشند.

FIPS و Certificate Key Size

یکی از Status Messageهای فعلی Cisco:

Phone failed to register.
Cert key size is not FIPS compliant.

است.

در این حالت مشکل از SIP Password نیست؛ Certificate باید با Policy امنیتی محیط هماهنگ شود.

مرحله هشتم: زمان و Certificate

Cisco در راهنمای Enterprise نیز تأکید می‌کند Certificate-based Authentication به ساعت صحیح Phone وابسته است.

اگر تاریخ دستگاه خارج از بازه اعتبار Certificate باشد، Authentication می‌تواند Fail شود.

در CUCM می‌توان Phone NTP References را به Date/Time Group اختصاص داد و آن Group را از طریق Device Pool به Endpointها اعمال کرد.

اگر بعد از تغییر Certificate تلفن رجیستر نمی‌شود

این موارد را بررسی کنید:

Packet Capture در Enterprise را از کجا بگیریم؟

مسیر MPP را روی Enterprise فرض نکنید.

برای Enterprise می‌توانید بسته به طراحی شبکه از:

Switch SPAN،

Capture روی CUCM/Server،

Capture روی Firewall،

و ابزارهای Diagnostic خود Cisco

استفاده کنید.

هدف این است که Boot Sequence از DHCP تا TFTP و Registration ثبت شود.

PRT را قبل از Reboot جمع کنید

در Cisco 7800/8800 Enterprise، Problem Report Tool یا PRT یکی از ابزارهای اصلی جمع‌آوری Log است.

Cisco هشدار می‌دهد PRT Logها با Restart تلفن پاک می‌شوند.

پس اگر مشکل رخ داده است، قبل از Restart فایل PRT را بگیرید.

در نسخه‌های فعلی CUCM حتی می‌توان از:

Device → Phone → Generate PRT for Selected

برای جمع‌آوری PRT از Phoneهای انتخاب‌شده استفاده کرد.

وقتی Phone اصلاً به شبکه وصل نمی‌شود

اگر Enterprise Phone آن‌قدر مشکل دارد که PRT نیز در دسترس نیست، در بعضی مدل‌های 8800 امکان Collect Console Log از Aux Port مستند شده است.

این مسیر برای مشکل‌های Early Boot و Network Failure مفیدتر از SIP Packet Capture معمولی است.

مقایسه PCAP MPP و Enterprise

یک تست حرفه‌ای: Phone سالم را با Phone خراب مقایسه کنید

اگر دو Cisco هم‌مدل دارید که یکی Register می‌شود و دیگری نه، مقایسه مستقیم بسیار ارزشمند است.

سناریوی اول: MPP روی Asterisk رجیستر نمی‌شود

اول مطمئن شوید واقعاً MPP Firmware دارید.

سپس Proxy، User ID، Auth ID و Password را بررسی کنید.

PCAP بگیرید.

اگر:

REGISTER → 401
REGISTER + Authorization → 200 OK

دارید، Registration سالم است.

سناریوی دوم: Cisco MPP هیچ REGISTER نمی‌فرستد

Account Enabled، Register، Proxy و Provisioning را بررسی کنید.

همچنین DNS Failure را قبل از SIP بررسی کنید؛ اگر Phone نتواند Proxy Name را Resolve کند، REGISTER مقصدی ندارد که به آن ارسال شود.

سناریوی سوم: REGISTER می‌رود ولی Response نداریم

Firewall، SIP Port، NAT، Transport و IP حاصل از DNS را بررسی کنید.

یک Capture سمت PBX بگیرید.

اگر Packet در Cisco PCAP وجود دارد ولی PBX آن را نمی‌بیند، خرابی بین Phone و PBX است.

سناریوی چهارم: UDP کار می‌کند ولی TCP کار نمی‌کند

TCP Listener و Firewall را بررسی کنید.

برخی Firewallها UDP 5060 را Allow کرده‌اند اما TCP همان Port را بسته‌اند.

صرف یکسان بودن شماره Port به معنی یکسان بودن Protocol نیست.

سناریوی پنجم: UDP کار می‌کند ولی TLS 5061 نه

TLS Listener، Certificate، Hostname Validation، CA Trust و NTP را بررسی کنید.

اگر TLS Handshake قبل از REGISTER Fail می‌شود، SIP Credential را تغییر ندهید.

سناریوی ششم: فقط با IP کار می‌کند

DNS A/SRV و Resolver تلفن را بررسی کنید.

اگر TLS استفاده می‌کنید، توجه کنید تست IP ممکن است Hostname Validation را نیز تغییر دهد؛ بنابراین نتیجه HTTP-like «IP کار کرد» به‌تنهایی راه‌حل Production نیست.

سناریوی هفتم: فقط با Domain کار می‌کند و IP نه

در TLS این رفتار می‌تواند کاملاً منطقی باشد چون Certificate برای Domain صادر شده است.

همچنین Provider ممکن است Virtual Host یا SNI/Hostname-based Policy داشته باشد.

سناریوی هشتم: 401 به‌طور دائم تکرار می‌شود

Auth ID، Password و Realm را مقایسه کنید.

یک Account سالم دیگر روی همان Phone تست نکنید مگر اینکه هدف مشخصی داشته باشید؛ بهتر است PBX Log همان Authentication Failure را بررسی کنید.

سناریوی نهم: 403 بعد از REGISTER دوم

Account Policy، IP Allow List، Concurrent Registration Limit و Status User را روی PBX/Provider بررسی کنید.

سناریوی دهم: 423 می‌گیرید

Register Expires و Min-Expires Registrar را هماهنگ کنید.

برای رفع خطا، Registration Interval را تصادفی روی 30 ثانیه قرار ندهید؛ این کار می‌تواند بار غیرضروری روی Registrar ایجاد کند.

سناریوی یازدهم: Enterprise Phone روی Asterisk رجیستر نمی‌شود

اول Firmware Type را بررسی کنید.

اگر واقعاً Enterprise Firmware است، روش استاندارد Cisco استفاده با CUCM است. برای Third-party PBX باید از MPP Phone/Firmware مناسب و فرایند رسمی Migration در مدل واجد شرایط استفاده شود.

Factory Reset، DNS SRV و تغییر SIP Password این تفاوت Firmware را برطرف نمی‌کنند.

سناریوی دوازدهم: MPP را می‌خواهید روی CUCM رجیستر کنید

Cisco صریحاً MPP Firmware را برای CUCM پشتیبانی نمی‌کند.

برای مدل‌های واجد شرایط Migration، فرایند رسمی MPP → Enterprise را بررسی کنید.

Firmware را با فایل تصادفی از اینترنت جایگزین نکنید؛ Migration روی 7800/8800 وابسته به مدل، VID و شرایط Licensing است.

سناریوی سیزدهم: Enterprise Phone IP می‌گیرد ولی CUCM را پیدا نمی‌کند

Option 150، TFTP Server 1 و Route تا TFTP را بررسی کنید.

اگر TFTP Address خالی است، ابتدا DHCP Scope را اصلاح کنید.

سناریوی چهاردهم: File Not Found در Enterprise

MAC Address و وجود Phone در CUCM Database را بررسی کنید.

همچنین مطمئن شوید Phone به TFTP Cluster صحیح متصل شده است.

سناریوی پانزدهم: TFTP سالم است ولی Registration انجام نمی‌شود

Config File، CUCM Service، Device Security Profile و Trust را بررسی کنید.

اگر Secure Cluster دارید، CTL/ITL و Certificate بخش مهم‌تری از عیب‌یابی می‌شوند.

سناریوی شانزدهم: بعد از جابه‌جایی Phone به Site جدید رجیستر نمی‌شود

Voice VLAN، DHCP Option 150، DNS، Routing و Firewall Site جدید را با Site قبلی مقایسه کنید.

در Enterprise ممکن است Phone هنوز TFTP قبلی را در تنظیمات Alternate TFTP داشته باشد.

سناریوی هفدهم: بعد از تغییر ساعت یا NTP TLS خراب شده است

تاریخ دقیق Phone و Certificate را مقایسه کنید.

اگر ساعت به گذشته یا آینده پرش کرده، ابتدا Time Source را اصلاح و بعد TLS را دوباره تست کنید.

Factory Reset چه زمانی انجام شود؟

Factory Reset نباید اولین مرحله Cisco IP Phone Register Failed باشد.

اگر مشکل از:

Firmware Type اشتباه،

DNS،

TFTP،

Proxy،

TLS Certificate،

یا PBX Policy

باشد، Reset علت اصلی را حل نمی‌کند.

حتی در Enterprise ممکن است Trust و Provisioning دستگاه را تغییر دهد و عیب‌یابی را دشوارتر کند.

قبل از Factory Reset چه چیزهایی ذخیره کنیم؟

مسیر نهایی عیب‌یابی Cisco 7800 و 8800

اگر PBX روی سرور اجرا می‌شود، سمت سرور را هم Capture کنید

عیب‌یابی فقط از سمت Phone کافی نیست. اگر Asterisk، FreePBX یا SIP Server شما روی یک سرور مجازی ایران اجرا می‌شود، هم‌زمان Log و در صورت نیاز Packet Capture سمت Server را نیز بگیرید.

مقایسه Capture دو سمت مشخص می‌کند Packet واقعاً از تلفن خارج شده اما در Firewall یا NAT از بین رفته، یا اصلاً به Server رسیده و توسط Application رد شده است.

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

چرا Cisco 7800 یا 8800 رجیستر نمی‌شود؟

اول مشخص کنید Phone روی MPP/3PCC Firmware است یا Enterprise. در MPP باید SIP Proxy، DNS، Transport، Authentication و TLS را بررسی کنید؛ در Enterprise/CUCM باید DHCP، Option 150، TFTP، Device Configuration و Trust را بررسی کنید.

از کجا بفهمیم Cisco Phone مدل MPP است؟

PIDهای دارای 3PCC، 3PC یا 3PW نشانه MPP SKU هستند. برای وضعیت فعلی Firmware، Product Information و Software Version خود دستگاه را بررسی کنید؛ چون بعضی مدل‌های 7800 و 8800 قابل Migration هستند.

آیا Cisco Enterprise روی Asterisk رجیستر می‌شود؟

Enterprise Firmware برای CUCM طراحی شده است. برای استفاده استاندارد با Third-party SIP PBX باید مدل یا Firmware MPP مناسب داشته باشید یا در مدل واجد شرایط از فرایند رسمی Migration Cisco استفاده کنید.

آیا 401 Unauthorized در SIP یعنی رمز اشتباه است؟

نه همیشه. اولین 401 معمولاً Digest Authentication Challenge طبیعی است. اگر Phone دوباره REGISTER همراه Authorization بفرستد و 200 OK دریافت کند، Registration سالم است.

DNS SRV در Cisco MPP چه زمانی لازم است؟

وقتی SIP Infrastructure از SRV برای معرفی Proxyها استفاده می‌کند. Use DNS SRV باید مطابق طراحی فعال باشد و Record متناسب با UDP، TCP یا TLS ساخته شده باشد.

چرا Cisco با UDP رجیستر می‌شود ولی TLS نه؟

در این حالت Credential احتمالاً سالم است و باید TLS Listener، Certificate Chain، Hostname/SAN، CA Trust، NTP و TLS Version بررسی شوند.

چرا Enterprise Phone پیام Enter activation code or service domain نشان می‌دهد؟

در سناریوی On-Prem CUCM، Cisco یکی از علت‌های مهم را نبودن TFTP Address می‌داند. DHCP Option 150 یا Alternate TFTP را بررسی کنید.

TFTP Timeout در Cisco Enterprise یعنی چه؟

Phone از TFTP Server پاسخ نگرفته است. Network Connectivity، Option 150، Route و وضعیت TFTP Service را بررسی کنید.

چرا بعد از تغییر CUCM Certificate تلفن رجیستر نمی‌شود؟

CTL/ITL، Trust، Certificate، Security Profile و ساعت Phone را بررسی کنید. Certificate-based Authentication به زمان صحیح و Trust Chain معتبر وابسته است.

برای Cisco MPP چطور Packet Capture بگیریم؟

در Web Interface وارد Info → Debug Info شوید و در بخش Problem Report Tool، Packet Capture را قبل از بازتولید مشکل Start کنید. بعد از رخداد Capture را متوقف و فایل را در Wireshark بررسی کنید.

اگر SIP روی TLS باشد چرا REGISTER در Wireshark دیده نمی‌شود؟

چون SIP Payload داخل TLS رمزگذاری شده است. در این حالت TLS Handshake را از PCAP و Signaling را با Phone Log و Server Log بررسی کنید.

Factory Reset برای Register Failed توصیه می‌شود؟

به‌عنوان اولین راه‌حل خیر. ابتدا Firmware Type، شبکه، DNS/TFTP، SIP Response، TLS و Logها را بررسی کنید. Reset می‌تواند شواهد و Configuration مفید برای عیب‌یابی را از بین ببرد.

جمع‌بندی

وقتی Cisco IP Phone سری 7800 یا 8800 رجیستر نمی‌شود، اولین مرحله نه DNS است، نه Password و نه Factory Reset؛ اول باید مشخص کنید دستگاه MPP/3PCC است یا Enterprise. این دو Firmware مسیر Registration متفاوتی دارند و عیب‌یابی یکی را نمی‌توان روی دیگری کپی کرد.

در MPP مسیر را از Network و Proxy شروع کنید. اگر Domain استفاده می‌شود، DNS A و در صورت نیاز SRV را بررسی کنید. سپس با Packet Capture ببینید REGISTER از Phone خارج می‌شود یا نه و Server چه Response Codeای برمی‌گرداند. 401 اولیه معمولاً Challenge طبیعی است؛ تکرار 401، پاسخ 403، Timeout یا 423 هرکدام مسیر عیب‌یابی متفاوتی دارند.

اگر Transport روی TLS است، قبل از SIP Authentication خود TLS Handshake را بررسی کنید. Certificate، Hostname Validation، CA Trust و NTP باید سالم باشند. اگر UDP کار می‌کند ولی TLS نه، تغییر SIP Password معمولاً نقطه شروع مناسبی نیست.

در Enterprise/CUCM، تمرکز از SIP Proxy به سمت DHCP Option 150، TFTP، Device MAC، فایل Configuration، CUCM Service و CTL/ITL منتقل می‌شود. پیام‌های TFTP Timeout، File Not Found یا Trust List Update Failed اطلاعات بسیار ارزشمندتری از عبارت کلی Register Failed هستند.

در نهایت هر تغییر را بر اساس مدرک انجام دهید. PCAP، PRT، Status Message و Log سمت PBX یا CUCM را کنار هم قرار دهید. وقتی دقیقاً مشخص باشد خرابی در DNS، TLS، Authentication، TFTP یا Trust رخ داده است، عیب‌یابی Cisco 7800 و 8800 از مجموعه‌ای از حدس‌ها به یک فرایند مرحله‌ای و قابل اثبات تبدیل می‌شود.