Amir Jabbari
اگر تلفن Cisco در Webex Calling روی Activation می‌ماند، در Control Hub وضعیت مناسبی نمی‌گیرد، شماره داخلی روی صفحه ظاهر نمی‌شود یا بعد از دریافت تنظیمات همچنان Register نمی‌شود، Factory Reset نباید اولین کار شما باشد. خطای Provisioning در Webex Calling می‌تواند از خود Control Hub، Activation Code، DHCP، DNS، Firewall، TLS، Firmware یا حتی یک TFTP قدیمی در شبکه شروع شود.
قاعده مهم: عبارت Webex Calling provisioning failed همیشه به معنی مشکل Webex Cloud نیست. یک DHCP Option قدیمی، DNS خراب، فایروال محدود، Activation Code منقضی یا Firmware قدیمی می‌تواند دقیقاً همان ظاهر را ایجاد کند.
Provisioning و Registration در Webex Calling چه فرقی دارند؟
این دو مرحله را از ابتدا جدا کنید؛ چون روش عیب‌یابی آن‌ها متفاوت است.
Provisioning یعنی تلفن اطلاعات و Configuration لازم را از سرویس Webex/Cisco دریافت کند. بعد از Provision موفق، معمولاً شماره یا Extension و تنظیمات مربوط به Device روی تلفن ظاهر می‌شوند.
Registration مرحله بعدی است؛ تلفن باید با تنظیمات دریافت‌شده، DNS مربوط به سرویس SIP را Resolve کند و اتصال امن SIP-TLS را با Webex Calling برقرار کند.
بنابراین این جریان را در ذهن داشته باشید:
Control Hub Assignment
|
v
DHCP + Network
|
v
Cisco/Webex Activation
|
v
Configuration Download
|
v
DNS / SRV Discovery
|
v
SIP-TLS Registration
|
v
Registered + Callsاگر گوشی هیچ Config مناسبی دریافت نکرده، روی بخش بالایی این مسیر کار کنید. اگر Extension روی صفحه آمده ولی Line هنوز Register نمی‌شود، تمرکز باید روی DNS SRV، SIP-TLS، پورت‌های Signaling و Certificate/Time باشد.
مرحله ۱: وضعیت تلفن را در Control Hub درست تفسیر کنید
قبل از دست‌زدن به شبکه، وارد Control Hub شوید و Device را از روی MAC Address پیدا کنید. مدل تلفن، MAC، User یا Workspace و Location باید همان چیزی باشند که واقعاً در اختیار دارید.
در سناریوی اضافه‌کردن تلفن با MAC Address، Cisco توضیح می‌دهد که دستگاه قبل از Provision شدن می‌تواند در Control Hub با وضعیت Unavailable دیده شود. این وضعیت در آن مرحله به‌تنهایی اثبات خرابی نیست؛ هنوز تلفن Configuration خود را دریافت نکرده است.
اما اگر تلفن Provision شده و شماره/Extension روی صفحه ظاهر شده ولی Registration کامل نشده است، دیگر مسئله فقط Assignment اولیه نیست و باید وارد عیب‌یابی شبکه و SIP شوید.
| وضعیت مشاهده‌شده | مرحله محتمل مشکل | اول چه چیزی را بررسی کنیم؟ |
|---|---|---|
| Device در Control Hub نیست | Assignment | MAC، مدل، User/Workspace و Location |
| Device اضافه شده ولی هنوز Unavailable است | ممکن است هنوز Provision نشده باشد | Activation، DHCP، DNS و دسترسی به سرویس Provisioning |
| Activation Code رد می‌شود | Activation | اعتبار کد، یک‌بارمصرف بودن و دسترسی شبکه |
| شماره/Extension روی Phone نمی‌آید | Provisioning | DHCP Option، TFTP قدیمی، DNS و HTTPS |
| شماره آمده ولی Line Register نمی‌شود | Registration | DNS SRV، SIP-TLS، پورت 8934 و TLS |
| Register شده ولی صدا ندارید | Media | UDP/SRTP و Firewall Media Range |
مرحله ۲: Activation Code را قبل از شبکه مقصر ندانید
Activation Code Onboarding در تلفن‌های MPP برای راه‌اندازی امن طراحی شده است. Cisco برای این فرآیند کد ۱۶ رقمی تعریف کرده است. این کد یک‌بارمصرف است و تاریخ انقضا دارد؛ بنابراین اگر Code قبلاً مصرف شده یا منقضی شده باشد، گوشی می‌تواند پیام Invalid activation code نشان دهد.
اگر کد نامعتبر است، کد تصادفی یا کد متعلق به User دیگری را امتحان نکنید. از Control Hub یا مدیر Webex Calling یک Activation Code جدید برای همان Device/User بگیرید.
اما اگر کد صحیح است و تلفن باز هم جلو نمی‌رود، باید مطمئن شوید مسیر Activation از شبکه شما قابل دسترسی است.
دو نامی که در مستندات Cisco می‌بینید
در مستندات جدید Webex Calling، تلفن‌های جدیدتر در Zero-Touch Provisioning از activate.cisco.com استفاده می‌کنند. در مستند Activation Code برای MPP نیز Cisco صراحتاً تأکید می‌کند که activation.webex.com باید از Firewall قابل دسترسی باشد.
پس بسته به Firmware و نوع Onboarding، فقط یک Domain را Whitelist نکنید و تصور نکنید کل فرآیند پوشش داده شده است. برای دستگاه‌های بسیار قدیمی‌تر نیز ممکن است نام‌های قدیمی‌تری مانند webapps.cisco.com در مسیر Provisioning دیده شوند.
مرحله ۳: DHCP قدیمی می‌تواند Webex را کاملاً دور بزند
یکی از مهم‌ترین یافته‌های راهنمای رسمی Troubleshooting سیسکو این است که MPP Phone ممکن است به‌جای Webex Calling، Config را از TFTP یا DHCP Optionهای قدیمی بگیرد.
Cisco مشخصاً به Optionهای زیر اشاره می‌کند:
🔹 DHCP Option 66
🔹 DHCP Option 150
🔹 DHCP Option 159
🔹 DHCP Option 160
اگر یکی از این Optionها هنوز از پروژه CUCM، BroadWorks، Asterisk یا Provider قبلی باقی مانده باشد، گوشی ممکن است Provisioning را به همان Server بفرستد و هرگز به مسیر درست Webex نرسد.
یک نشانه رایج در PRT شبیه این است:
DHCP-tftpsvr1: 192.168.150.20
Provisioning using DHCP...
Requesting resync tftp://192.168.150.20/PHONE.xmlاگر چنین چیزی می‌بینید، مشکل Webex نیست. ابتدا TFTP یا DHCP Option ناخواسته را از Scope مربوط به Voice VLAN حذف یا اصلاح کنید.
نکته مهم: اگر DHCP Option اشتباه را اصلاح کردید، ممکن است لازم باشد تلفن را بعد از جمع‌آوری Log و اطمینان از آماده‌بودن Control Hub به Factory State برگردانید تا Bootstrap از ابتدا انجام شود. این با «Factory Reset به‌عنوان اولین راه‌حل» فرق دارد.
مرحله ۴: DNS را از همان شبکه‌ای تست کنید که تلفن روی آن است
پس از DHCP، DNS یکی از پرتکرارترین نقاط شکست است. Cisco در TechNote رسمی Webex Calling نمونه‌ای نشان می‌دهد که تلفن تلاش می‌کند activate.cisco.com را Resolve کند و اگر DNS شکست بخورد، Provisioning با خطای Server Connection Failed متوقف می‌شود.
از یک رایانه در همان VLAN یا شبکه تلفن، ابتدا این تست‌ها را انجام دهید:
nslookup activate.cisco.com
nslookup activation.webex.comاگر DNS Server سازمانی دارید، بهتر است همان Serverی را تست کنید که Phone از DHCP دریافت کرده است:
nslookup activate.cisco.com 192.168.10.53آدرس 192.168.10.53 فقط نمونه است و باید DNS واقعی شبکه خودتان را جایگزین کنید.
Resolve شدن روی لپ‌تاپ کافی نیست
اگر لپ‌تاپ Resolve می‌کند ولی Phone نه، سه احتمال مهم وجود دارد: تلفن روی Voice VLAN دیگری است، DNS دیگری از DHCP گرفته یا Firewall/ACL بین همان VLAN و DNS وجود دارد. برای همین PRT و Network Status خود Phone از تست لپ‌تاپ مهم‌تر هستند.
طبق Port Reference فعلی Webex Calling، DNS از UDP و TCP روی پورت ۵۳ استفاده می‌کند. TCP را فراموش نکنید؛ برخی پاسخ‌های DNS اگر در UDP جا نشوند می‌توانند به TCP نیاز داشته باشند.
مرحله ۵: بعد از Provisioning، DNS SRV را برای Registration بررسی کنید
Provisioning موفق لزوماً به معنی Registration موفق نیست. تلفن بعد از دریافت Config باید Hostهای مربوط به Webex Calling را از طریق DNS پیدا کند.
Cisco در TechNote رسمی نمونه‌ای نشان می‌دهد که Phone برای Outbound Proxy رکورد SRV با الگوی زیر را Query می‌کند:
_sips._tcp.REGIONAL-WEBEX-DOMAINبه‌جای حدس‌زدن Domain منطقه، آن را از Configuration یا PRT همان Device بردارید. سپس می‌توانید SRV را تست کنید:
nslookup -type=SRV _sips._tcp.REGIONAL-WEBEX-DOMAINاگر A Recordها درست Resolve می‌شوند ولی SRV نه، تلفن ممکن است Config را بگیرد اما نتواند مقصد SIP-TLS را پیدا کند.
مرحله ۶: Firewall را مرحله‌ای بررسی کنید، نه با یک «پورت 443 باز است»
یکی از خطاهای رایج این است که چون HTTPS روی 443 باز است، تصور می‌کنیم Webex Calling باید کامل کار کند. درحالی‌که Provisioning، Registration، DNS، NTP و Media جریان‌های جداگانه‌اند.
| کاربرد | پروتکل/پورت مهم | اگر بسته باشد چه می‌بینیم؟ |
|---|---|---|
| DNS | UDP/TCP 53 | Domain و SRV Resolve نمی‌شوند |
| NTP | UDP 123 | زمان دستگاه همگام نمی‌شود و بررسی TLS می‌تواند مشکل‌دار شود |
| Device Configuration / Secure Onboarding | TCP 443 | Activation یا Config Download شکست می‌خورد |
| Cloud Upgrader / Migration در سناریوهای مربوط | TCP 6970 و 443 | Upgrade/Migration کامل نمی‌شود |
| SIP-TLS Registration برای Device | TCP مقصد 8934 | Config می‌آید ولی خط Register نمی‌شود |
| Media پس از Registration | UDP/SRTP طبق Range رسمی Webex | تماس برقرار می‌شود اما Audio/Video مشکل دارد |
در Port Reference فعلی، Webex Devices برای Signaling از Source Portهای 5060 تا 5280 به مقصد TCP 8934 استفاده می‌کنند. برای Media نیز Rangeهای UDP جدا وجود دارد. چون IP Rangeها و Domainهای Webex ممکن است در طول زمان تغییر کنند، برای Firewall دائمی از جدول فعلی خود Webex استفاده کنید، نه یک لیست قدیمی کپی‌شده از انجمن‌ها.
تست TCP 443 از ویندوز
برای بررسی اولیه می‌توانید از سیستمی در همان Network Segment استفاده کنید:
Test-NetConnection activate.cisco.com -Port 443این تست فقط نشان می‌دهد همان کامپیوتر می‌تواند TCP 443 را باز کند؛ ثابت نمی‌کند خود تلفن از همان VLAN، DNS، Proxy و ACL استفاده می‌کند. نتیجه نهایی را با PRT و Packet Capture تلفن تطبیق دهید.
مرحله ۷: NTP و ساعت را جدی بگیرید
Webex Calling برای Device Time Synchronization از NTP روی UDP 123 استفاده می‌کند. اگر ساعت تلفن به‌طور واضح اشتباه است، قبل از عیب‌یابی TLS و Certificate مشکل NTP را حل کنید.
TLS Certificateها بازه اعتبار زمانی دارند. بنابراین ساعتی که چند ماه یا چند سال اشتباه است می‌تواند بررسی اعتبار Certificate را مختل کند، حتی اگر DNS و TCP 443 باز باشند.
از خود Phone، Network Status و Time را بررسی کنید و مطمئن شوید NTP Server قابل دسترسی است.
مرحله ۸: TLS را از «فقط باز بودن پورت» جدا کنید
Webex Calling برای Secure SIP از TLS پشتیبانی می‌کند و مستند امنیتی فعلی Cisco، TLS 1.2 و TLS 1.3 را برای Secure SIP فهرست کرده است. اگر اتصال TCP برقرار می‌شود اما Handshake یا Registration شکست می‌خورد، فقط Firewall را مقصر ندانید.
مواردی که باید بررسی شوند:
🔹 ساعت و NTP درست باشد.
🔹 Firmware Phone بیش از حد قدیمی نباشد.
🔹 Trust/Certificate Device سالم باشد.
🔹 Proxy یا TLS Inspection مسیر را تغییر نداده باشد.
🔹 Domain و Destination واقعی همان چیزی باشد که Config Webex به Phone داده است.
یک نکته مهم برای MPPهای قدیمی‌تر
Port Reference فعلی Webex Calling برای MPPهایی با Firmware قدیمی‌تر از 12.0.3، دسترسی به sudirenewal.cisco.com روی پورت 80 را برای تمدید MIC/SUDI ذکر می‌کند. اگر یک Phone قدیمی دارید که DNS و Signaling ظاهراً درست است اما Secure Onboarding یا Trust رفتار غیرعادی دارد، Firmware و وضعیت Certificate را هم بررسی کنید.
مرحله ۹: PRT را قبل از Factory Reset بگیرید
PRT یا Problem Report Tool مهم‌ترین مدرکی است که می‌تواند نشان دهد Phone واقعاً به کجا وصل شده و کجا شکست خورده است.
در بسیاری از MPPها می‌توانید از خود Phone به مسیر زیر بروید:
Applications
→ Status
→ Report Problemبعد از Submit، از Web UI نیز می‌توانید PRT را دریافت کنید. Cisco در TechNote خود مسیر Info → Debug Info را برای Download گزارش نشان می‌دهد.
پس از استخراج PRT، فایل logcat بسیار مهم است. این عبارت‌ها را جست‌وجو کنید:
DHCP-tftpsvr1
DHCP-option160
DHCP-option159
DHCP-option66
Couldn't resolve host
Resync failed
FPRV_ERR_SERVER_CONNECTION_FAILED
_sips._tcpاین جست‌وجو معمولاً خیلی سریع مشخص می‌کند مشکل در DHCP، DNS، Provisioning URL یا Registration Discovery است.
Webex Calling روی Cisco MPP جلو نمی‌رود؟
اگر Device در Control Hub تعریف شده اما Activation یا Registration کامل نمی‌شود، بررسی PRT، DHCP، DNS، Firewall، SIP-TLS و Firmware بسیار سریع‌تر از Resetهای تکراری مشخص می‌کند مشکل واقعاً کجاست.
ایرانیکاسرور می‌تواند در بررسی تلفن‌های Cisco MPP، Webex Calling، Asterisk/FreePBX، Provisioning و شبکه VoIP کمک کند تا پیش از پاک‌کردن دستگاه، مسیر مشکل مشخص شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
مرحله ۱۰: از CScan برای آمادگی شبکه استفاده کنید
Webex ابزار CScan را برای بررسی Network Readiness سرویس Webex Calling ارائه می‌کند. این ابزار می‌تواند برای مشخص‌کردن مشکلات کلی Connectivity، Firewall و کیفیت شبکه مفید باشد.
اما CScan جای PRT تلفن را نمی‌گیرد. ممکن است CScan از لپ‌تاپ موفق باشد ولی Phone به دلیل Voice VLAN، DHCP Option، DNS متفاوت یا ACL مخصوص VLAN همچنان Provision نشود.
چه زمانی Resync یا Reboot کافی است؟
اگر Device قبلاً Provision شده و فقط تغییرات جدید Control Hub اعمال نشده‌اند، قبل از Factory Reset از گزینه‌های مدیریتی سبک‌تر استفاده کنید. Webex در Control Hub امکان Apply Changes و Reboot را برای Device ارائه می‌کند.
Apply Changes از Phone می‌خواهد Config جدید را دریافت و اعمال کند. Reboot دستگاه را راه‌اندازی مجدد می‌کند و Config فعلی را دوباره می‌گیرد. این دو با Factory Reset که Local Configuration را پاک می‌کند یکسان نیستند.
چه زمانی Factory Reset واقعاً توجیه دارد؟
Factory Reset را زمانی انجام دهید که علت قبلی را پیدا کرده‌اید و مطمئن هستید Phone بعد از Reset مسیر سالمی برای Bootstrap دارد.
نمونه قابل دفاع این است:
🔹 Device با MAC صحیح در Control Hub تعریف شده است.
🔹 User/Workspace و Model درست هستند.
🔹 DHCP Option/TFTP قدیمی حذف شده است.
🔹 DNS و NTP درست کار می‌کنند.
🔹 Domainها و Portهای لازم در Firewall مجاز هستند.
🔹 Activation Code جدید یا MAC-based onboarding آماده است.
🔹 PRT قبل از Reset ذخیره شده است.
در همین شرایط است که Factory Reset می‌تواند Phone را وادار کند فرآیند Provisioning را از ابتدا با مسیر درست شروع کند.
چه زمانی Factory Reset احتمالاً فقط وقت تلف می‌کند؟
اگر یکی از شرایط زیر برقرار است، Reset مشکل ریشه‌ای را حل نمی‌کند:
🔹 DNS هنوز activate.cisco.com را Resolve نمی‌کند.
🔹 Firewall هنوز TCP 443 یا 8934 را می‌بندد.
🔹 DHCP هنوز TFTP قبلی را می‌دهد.
🔹 Activation Code منقضی شده است.
🔹 Device در Control Hub با MAC یا User اشتباه تعریف شده است.
🔹 Firmware/Certificate قدیمی مشکل Trust دارد.
بعد از Reset همان مسیر خراب دوباره اجرا می‌شود و شما فقط Logهای قبلی را از دست داده‌اید.
Decision Tree سریع برای Webex Calling provisioning failed
Device در Control Hub وجود دارد؟
🔹 خیر → ابتدا Device/User/Workspace را درست تعریف کنید.
🔹 بله → مرحله بعد.
MAC و Model صحیح هستند؟
🔹 خیر → اصلاح Control Hub.
🔹 بله → مرحله بعد.
Phone Activation/Config می‌گیرد؟
🔹 خیر → DHCP Option، DNS، 443 و Activation Domain را بررسی کنید.
🔹 بله → مرحله بعد.
Extension روی صفحه ظاهر شده است؟
🔹 خیر → Provisioning هنوز کامل نشده است.
🔹 بله → Registration را بررسی کنید.
Line Register می‌شود؟
🔹 خیر → DNS SRV، TCP 8934، NTP و TLS.
🔹 بله → مرحله Media.
تماس هست ولی صدا مشکل دارد؟
🔹 بله → UDP/SRTP و Media Firewall Range را بررسی کنید.
جدول خطاهای رایج و مسیر درست عیب‌یابی
| علامت | علت محتمل | اقدام پیشنهادی |
|---|---|---|
| Invalid activation code | Code مصرف‌شده یا منقضی | کد جدید ایجاد کنید |
| Phone روی Activation می‌ماند | DNS/443/Proxy/Firewall | Activation Domain و PRT را بررسی کنید |
| Provision به TFTP قدیمی می‌رود | DHCP Option 66/150/159/160 | Scope Voice VLAN را اصلاح کنید |
| Couldn’t resolve host | DNS | DNS خود Phone و Port 53 TCP/UDP را بررسی کنید |
| Config دریافت شده ولی Register نیست | DNS SRV یا SIP-TLS | SRV و TCP 8934 را بررسی کنید |
| Certificate/TLS رفتار غیرعادی دارد | NTP، Firmware یا Trust | زمان، Firmware و Certificate را بررسی کنید |
| بعد از Reset همان مشکل برمی‌گردد | Root Cause هنوز در Network/Control Hub است | Reset را تکرار نکنید؛ Log را تحلیل کنید |
پرسش‌های رایج
چرا تلفن Cisco در Control Hub وضعیت Unavailable دارد؟
اگر Device با MAC اضافه شده ولی هنوز Provision نشده است، Unavailable می‌تواند در مرحله اولیه طبیعی باشد. اگر بعد از دریافت Config و راه‌اندازی همچنان مشکل وجود دارد، Provisioning و Registration را جداگانه عیب‌یابی کنید.
Activation Code Webex Calling چند بار قابل استفاده است؟
Activation Code برای Onboarding یک‌بارمصرف است و تاریخ انقضا دارد. اگر Code مصرف شده یا منقضی باشد باید Code جدید تولید شود.
برای Activation تلفن Cisco کدام Domain باید باز باشد؟
در جریان‌های جدید Zero-Touch نام activate.cisco.com دیده می‌شود و مستند Activation Code MPP نیز activation.webex.com را برای Firewall الزامی می‌داند. نوع Firmware و Onboarding تعیین می‌کند Phone دقیقاً کدام Endpointها را استفاده کند.
آیا باز بودن Port 443 برای Webex Calling کافی است؟
خیر. 443 برای Secure Onboarding و Device Configuration مهم است، اما DNS روی 53، NTP روی 123 و SIP-TLS Registration برای Device روی TCP 8934 نیز نقش دارند. Media نیز Range جداگانه UDP دارد.
چرا Phone Config را می‌گیرد ولی Register نمی‌شود؟
در این حالت Provisioning احتمالاً انجام شده و باید DNS SRV، Outbound Proxy، SIP-TLS، TCP 8934، NTP و TLS را بررسی کنید.
آیا DHCP Option می‌تواند مانع Webex Provisioning شود؟
بله. Cisco مستند کرده که Optionهای 66، 150، 159 یا 160 و TFTP Server قدیمی می‌توانند Phone را به Provisioning Server دیگری هدایت کنند و مسیر Webex Calling را دور بزنند.
چه زمانی Factory Reset انجام دهیم؟
بعد از اینکه Assignment، DHCP، DNS، Firewall و Activation را اصلاح کردید و PRT را ذخیره کردید. اگر Root Cause هنوز باقی است، Factory Reset فقط همان خطا را دوباره تولید می‌کند.
PRT چه کمکی به Provisioning Failed می‌کند؟
PRT می‌تواند DHCP Option، TFTP Server، Provisioning URL، DNS Failure، Resync Error و DNS SRV Registration را نشان دهد و مشخص کند Failure دقیقاً در کدام مرحله رخ داده است.
جمع‌بندی
برای رفع Webex Calling provisioning failed از Control Hub شروع کنید، نه Factory Reset. مطمئن شوید Device با MAC، Model و User/Workspace درست تعریف شده است و Unavailable اولیه را با خرابی قطعی اشتباه نگیرید.
بعد مسیر Bootstrap را بررسی کنید: DHCP نباید Phone را به TFTP یا Provisioning Server قدیمی بفرستد؛ DNS باید Activation Domainها را Resolve کند؛ TCP 443 باید برای Secure Onboarding باز باشد و NTP روی UDP 123 زمان Device را درست نگه دارد.
اگر شماره و Config روی Phone آمده اما Line Register نمی‌شود، مسئله از Provisioning عبور کرده است. در این مرحله DNS SRV، SIP-TLS و TCP 8934 مهم‌تر از Factory Reset هستند.
قبل از Reset حتماً PRT بگیرید. فقط وقتی Network و Control Hub آماده‌اند و Phone باید Bootstrap را از ابتدا تکرار کند، Factory Reset یک اقدام منطقی می‌شود.
PRT، DNS و Firewall را قبل از Reset بعدی بررسی کنید
اگر تلفن Cisco MPP در Control Hub دیده می‌شود اما روی Activation، Provisioning یا Registration گیر کرده است، مدل دقیق، MAC، Firmware، وضعیت Control Hub و PRT را آماده کنید. با این اطلاعات می‌توان مشخص کرد مشکل از DHCP، DNS، Firewall، TLS یا خود Assignment است.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)