Amir Jabbari
Webex Calling برای راه‌اندازی یک Cisco MPP فقط به «اینترنت داشتن» نیاز ندارد. تلفن باید از شبکه IP بگیرد، DNS و NTP سالم داشته باشد، بتواند سرویس‌های Activation و Device Configuration سیسکو را Resolve و Reach کند، TLS را بدون خطای Trust برقرار کند و در نهایت Configuration و اطلاعات SIP مربوط به Webex Calling را دریافت کند.
در این راهنما از Control Hub شروع می‌کنیم، Activation Code را بررسی می‌کنیم، سپس DNS، Firewall، Proxy، TLS Inspection و Provisioning را آزمایش می‌کنیم و فقط در پایان—اگر شواهد نشان داد Configuration محلی تلفن خراب مانده—به Factory Reset می‌رسیم.
تشخیص سریع: اگر Control Hub روی Activating مانده، ابتدا Code و اتصال تلفن به Cloud را بررسی کنید. اگر Device قبلاً Online بوده و حالا Offline است، Activation Code جدید اولین کار نیست. اگر تلفن Code را قبول می‌کند اما بعد Provision نمی‌شود، DNS، HTTPS/TLS و دسترسی Device Configuration مهم‌تر می‌شوند.
Provisioning در Webex Calling چه مراحلی دارد؟
برای ساده‌شدن عیب‌یابی، مسیر را به این زنجیره تبدیل کنید:
IP/VLAN → DNS/NTP → Activation → Device Configuration → TLS → SIP Registration → Control Hub Online
اگر این مراحل را از هم جدا نکنید، ممکن است یک خطای ساده DNS را با چند Factory Reset، Firmware Downgrade و تغییر Activation Code پیچیده‌تر کنید.
مرحله ۱: وضعیت Device را در Control Hub ببینید
قبل از لمس تلفن، Control Hub را بررسی کنید.
در Control Hub وارد Devices شوید و همان Phone را بر اساس User، Workspace، MAC یا Device Name پیدا کنید.
وضعیت‌هایی که ممکن است ببینید به این شکل تفسیر می‌شوند:
| وضعیت | معنی عملی | مرحله بعد |
|---|---|---|
| Activating | Activation Code ساخته شده اما Device هنوز Onboard نشده | Code، Firmware و Network Path را بررسی کنید |
| Online | SIP Registration و اتصال Webex Platform برقرار است | اگر مشکل تماس است سراغ Provisioning نروید |
| Offline | Device دیگر SIP Registered نیست یا Status به Cloud نرسیده | DNS، Firewall، TLS و Registration |
| Expired | مدت طولانی Status یا Registration دریافت نشده | Assignment، Network و Device Ownership |
در PhoneOSهای جدید ممکن است وضعیت Issues نیز نمایش داده شود و مشخص کند SIP یا Webex Services کدام‌یک مشکل دارند.
مرحله ۲: Activation Code را بررسی کنید
در Webex Calling، برای MPP Phone می‌توانید Activation Code از Control Hub بسازید.
مسیر معمول برای User:
Control Hub → Users → User → Devices → Add Device
و برای Workspace:
Control Hub → Workspaces → Workspace → Add Device
Activation Code فعلی برای MPP یک کد ۱۶ رقمی است.
طبق مستند فعلی Webex، این Code برای MPP Phone تا ۳۰ روز اعتبار دارد.
اگر Activation Code منقضی شده باشد چه می‌شود؟
Code قدیمی را بارها وارد نکنید.
یک Code تازه در Control Hub بسازید و مطمئن شوید برای همان User یا Workspace صحیح تولید شده است.
اگر Device از Organization دیگری آمده باشد، ساخت Code جدید در Organization فعلی لزوماً مشکل Ownership قبلی را حل نمی‌کند؛ ابتدا Device Assignment قبلی را بررسی کنید.
اگر تلفن اصلاً صفحه Activation Code را نشان نمی‌دهد
برای MPP قدیمی، Firmware می‌تواند عامل باشد.
Webex برای نمایش Activation Code Screen روی MPP حداقل Firmware مناسب می‌خواهد؛ در مستندات فعلی، برای بعضی MPPهای سری قدیمی حداقل 11.2.3MSR1 برای این Workflow ذکر شده است.
اگر Phone قدیمی‌تر است، Cisco Cloud Upgrader برای رساندن تلفن به Firmware مناسب Activation Code طراحی شده است.
قبل از Factory Reset، Software Version را بررسی کنید.
Cloud Upgrader چه زمانی لازم است؟
اگر Device MPP است اما Firmware آن برای Webex Calling Onboarding قدیمی است، می‌توانید از Workflow رسمی Cloud Upgrader استفاده کنید.
Cloud Upgrader برای Migration/Upgrade دستگاه و رساندن آن به صفحه Activation Code استفاده می‌شود.
دسترسی به:
cloudupgrader.webex.comو پورت‌های مرتبط باید از شبکه امکان‌پذیر باشد.
مرحله ۳: قبل از Webex مطمئن شوید تلفن شبکه سالم دارد
این موارد را روی Phone بررسی کنید:
🔹 IP Address
🔹 Subnet Mask
🔹 Default Gateway
🔹 DNS Server
🔹 Voice VLAN
🔹 NTP/Time
اگر Phone IP ندارد یا Gateway اشتباه است، Activation Code هیچ کمکی نمی‌کند.
اگر Time به‌شدت اشتباه است، TLS Certificate Validation نیز می‌تواند Fail شود.
مرحله ۴: DNS را جدی بررسی کنید
Webex Calling سرویس Cloud است و بخش بزرگی از Discovery بر اساس Domain و DNS انجام می‌شود.
Cisco برای Webex Calling صریحاً DNS روی:
UDP/TCP 53را برای Name Resolution لازم می‌داند.
این نکته مهم است: فقط UDP/53 کافی نیست. بعضی DNS Responseها به TCP نیاز دارند.
با nslookup چه چیزی را تست کنیم؟
از یک سیستم در همان VLAN یا Network Segment، دامنه‌های Webex/Cisco مرتبط را Resolve کنید.
برای نمونه:
nslookup activate.cisco.com
nslookup cloudupgrader.webex.comاین تست دقیقاً رفتار Phone را تضمین نمی‌کند، اما اگر همین سیستم هم Resolve نمی‌کند، مشکل DNS واضح است.
Webex Calling از DNS SRV هم استفاده می‌کند
در مرحله SIP Service Discovery، Webex Calling می‌تواند از SRV Record استفاده کند.
مستند امنیتی فعلی Webex توضیح می‌دهد Endpoint برای کشف Edge فعال از Prefix:
_sips._tcpدر DNS SRV استفاده می‌کند.
مثال رسمی Cisco برای توضیح فرایند:
nslookup -type=srv _sips._tcp.wxc.edge.bcld.webex.comاین Host فقط مثال مستند Cisco است؛ Endpoint باید Domain و Region واقعی خودش را از Bootstrap/Provisioning بگیرد و نباید یک Host منطقه‌ای را دستی Hardcode کنید.
DNS A Record کار می‌کند ولی SRV Fail است
این یکی از خطاهایی است که در تست‌های ساده پنهان می‌ماند.
ممکن است:
nslookup webex.comجواب بگیرد اما SRV Query توسط DNS Filter، Firewall یا Resolver سازمانی درست پاسخ داده نشود.
برای Webex Calling، فقط Resolve شدن یک دامنه عمومی به معنی سالم‌بودن Service Discovery نیست.
مرحله ۵: Firewall را بر اساس Port Reference رسمی بررسی کنید
برای Provisioning و Registration فقط بازبودن TCP/443 کافی نیست.
در مستند فعلی Webex Calling چند دسته ترافیک جدا وجود دارد.
| کاربرد | پروتکل/پورت مهم |
|---|---|
| DNS | UDP/TCP 53 |
| NTP | UDP 123 |
| Device Configuration / Firmware | TCP 443، 6970 و در بعضی Serviceها 80 |
| SIP TLS برای Webex Calling Device | Current Port Reference: مقصد TCP 8934 |
| Media بعد از Registration | SRTP/UDP طبق Range رسمی Webex Calling |
پورت‌های بالا را به شکل «Any Destination» باز نکنید. Ruleها باید بر اساس Domain، URL، IP Subnet و Purpose رسمی Webex طراحی شوند.
چرا Cisco توصیه می‌کند فقط IP ثابت Whitelist نکنیم؟
Webex Calling یک سرویس Cloud جهانی است و برخی IP Poolها Dynamic هستند.
Cisco اعلام می‌کند Filtering فقط با subset جغرافیایی یا چند IP منتخب می‌تواند باعث اختلال شدید شود.
برای HTTPS Signaling بهتر است Domain/URL Filtering استفاده شود و برای SIP/Media از Port و IP Subnetهای رسمی Webex Calling استفاده کنید.
پس لیست قدیمی IPهای Webex که چند سال است در Firewall مانده، قابل اعتماد نیست.
مرحله ۶: activate.cisco.com باید قابل دسترسی باشد
MPP جدید بعد از Factory State یا وقتی DHCP Provisioning ندارد، می‌تواند با Device Activation Service سیسکو ارتباط بگیرد.
برای دستگاه‌های جدیدتر آدرس:
activate.cisco.comدر Provisioning/Zero-Touch استفاده می‌شود.
اگر DNS آن را Resolve می‌کند ولی HTTPS Connection در Firewall یا Proxy بسته است، Phone می‌تواند روی Activation باقی بماند.
مرحله ۷: Proxy را درست تفسیر کنید
Webex Calling از Proxy برای HTTP/HTTPS Signaling پشتیبانی می‌کند، اما SIP Registration و Media الزاماً از همان Proxy عبور نمی‌کنند.
Cisco صریحاً می‌گوید اگر Proxy تنظیم شده باشد، HTTP/HTTPS Signaling می‌تواند به Proxy برود ولی SIP Client و Media باید مسیر Firewall مستقیم مناسب داشته باشند.
پس سناریوی زیر کاملاً ممکن است:
Activation و Download Configuration روی HTTPS سالم است، اما SIP Registration Fail می‌شود چون Firewall مسیر Calling را بسته است.
TLS Inspection می‌تواند Provisioning را خراب کند
اگر سازمان از Proxy یا Firewall با SSL/TLS Inspection استفاده می‌کند، Certificate اصلی Webex با Certificate ساخته‌شده توسط Proxy جایگزین می‌شود.
Phone باید CA آن Proxy را Trust کند.
Cisco در مستند فعلی Webex Calling اعلام می‌کند MPP Phone از Custom Trusted CA برای TLS Inspection پشتیبانی می‌کند، اما برای نصب CA روی Cisco MPP توصیه شده از TAC استفاده شود.
پس برای تست، قبل از Factory Reset بررسی کنید آیا Network Security Appliance روی Webex Traffic TLS Inspection انجام می‌دهد یا نه.
علائم خطای TLS Inspection چیست؟
ممکن است این الگو را ببینید:
DNS سالم است.
TCP Connection روی 443 ساخته می‌شود.
اما TLS Handshake قطع می‌شود.
Phone Configuration را دانلود نمی‌کند.
روی یک Hotspot یا شبکه بدون Inspection، همان دستگاه Provision می‌شود.
این تفاوت بسیار قوی‌تر از چند Factory Reset برای تشخیص است.
Webex Calling چه نسخه TLS را پشتیبانی می‌کند؟
در مستند امنیتی فعلی Webex Calling، Secure SIP از:
🔹 TLS 1.2
🔹 TLS 1.3
پشتیبانی می‌کند.
اگر Firewall یا Proxy قدیمی TLS Session را Downgrade یا Cipherها را دستکاری می‌کند، Registration/Provisioning امن می‌تواند Fail شود.
مرحله ۸: زمان تلفن را بررسی کنید
قبل از تحلیل Certificate، ساعت و تاریخ Phone را ببینید.
NTP برای Webex Calling روی UDP 123 استفاده می‌شود.
اگر Date/Time به‌شدت اشتباه باشد، Certificate ممکن است از دید Endpoint هنوز معتبر نشده یا منقضی شده به نظر برسد.
به همین دلیل اگر TLS Error همراه ساعت اشتباه دارید، NTP را قبل از تعویض Certificate یا Firmware اصلاح کنید.
Activation موفق شده اما SIP Register نمی‌شود
این مرحله مهم است: قبول‌شدن Activation Code به این معنی نیست که Call Registration هم سالم است.
اگر Phone Configuration را گرفته ولی Control Hub هنوز Online نمی‌شود، SIP Discovery و SIP TLS را بررسی کنید.
در Current Port Reference، Cisco برای Webex Calling Devices ترافیک SIP TLS را از Source Portهای Device در محدوده 5060–5280 به مقصد Webex Calling روی TCP 8934 مستند می‌کند.
در عین حال Edge Host واقعی از DNS/Bootstrap به Device داده می‌شود؛ بنابراین Destination Host را به‌صورت دستی حدس نزنید.
SIP ALG را غیرفعال کنید
اگر Router یا Firewall قابلیت SIP ALG دارد، Cisco برای Webex Calling توصیه می‌کند آن را غیرفعال کنید.
ترافیک Calling رمزگذاری‌شده است و SIP ALGهای مختلف می‌توانند در NAT/Firewall Traversal اختلال ایجاد کنند.
اگر Activation و Provisioning سالم است ولی Registration ناپایدار است، SIP ALG یکی از موارد مهم بررسی است.
NAT Port Preservation می‌تواند Registration را خراب کند
در شبکه‌ای که تعداد زیادی Cisco Phone از یک Public IP استفاده می‌کنند، ممکن است همه Deviceها Source Portهای مشابه SIP داشته باشند.
NAT باید بتواند Source Portها را به مقادیر Unique ترجمه کند.
Cisco هشدار می‌دهد Strict Source-Port Preservation می‌تواند باعث Device Registration Failure شود.
پس اگر یک Phone کار می‌کند ولی با افزایش تعداد Phoneها Registration Fail می‌شود، NAT/PAT را بررسی کنید.
Activation Code درست است اما پیام Invalid Code می‌آید
این موارد را بررسی کنید:
🔹 Code منقضی نشده باشد.
🔹 Code مربوط به همان User/Workspace باشد.
🔹 Organization درست باشد.
🔹 Device قبلاً به User/Workspace دیگری Assign نشده باشد.
🔹 Firmware برای Activation Workflow مناسب باشد.
اگر Device برای Reassignment است، Assignment قبلی را در Control Hub تمیز کنید؛ صرف واردکردن Code جدید روی Device قدیمی همیشه مسیر درستی نیست.
Reassign کردن Phone در Control Hub
برای انتقال یک Phone موجود به User یا Workspace دیگر، Cisco توصیه می‌کند Device قبلی را ابتدا Delete/Reassign کنید.
اگر Device هنگام Delete آنلاین و فعال باشد، روی Firmwareهای جدید Webex Calling می‌تواند Reset خودکار انجام شود.
بعد از Reboot دستگاه آماده Assignment جدید می‌شود.
در Activation Code Screen می‌توانید Code جدید وارد کنید؛ در Workflowهای MAC-based نیز Provisioning بر اساس MAC انجام می‌شود.
Onboarding با MAC چه فرقی با Activation Code دارد؟
Webex Calling اجازه می‌دهد بعضی Phoneها را با MAC Address نیز اضافه کنید.
در MAC-based Onboarding، Device Record از قبل با MAC در Control Hub ساخته می‌شود و Phone از Zero-Touch Provisioning برای پیدا کردن Configuration استفاده می‌کند.
در Activation Code، کاربر Code را مستقیماً روی Device وارد می‌کند.
این تفاوت در Factory Reset مهم است.
بعد از Factory Reset چه اتفاقی برای Onboarding قبلی می‌افتد؟
Cisco برای Webex Calling این تفاوت را صریحاً مستند کرده است:
اگر Phone قبلاً با MAC Address Onboard شده باشد، بعد از Factory Reset می‌تواند دوباره به Webex Calling وصل شود.
اگر Phone قبلاً با Activation Code Onboard شده باشد، بعد از Reset به Activation Code جدید یا Onboarding با MAC نیاز دارد.
بنابراین قبل از Reset باید بدانید روش Onboarding قبلی چه بوده است.
چه زمانی Factory Reset منطقی است؟
Factory Reset را وقتی در نظر بگیرید که:
🔹 Control Hub Assignment درست است.
🔹 Activation Code معتبر است.
🔹 Firmware مناسب است.
🔹 DNS/NTP سالم‌اند.
🔹 Firewall و Proxy مسیرهای لازم را باز دارند.
🔹 TLS Inspection مشکل ندارد.
🔹 Device هنوز Configuration قدیمی یا ناسازگار محلی دارد.
یعنی Factory Reset باید نتیجه تشخیص باشد، نه جایگزین تشخیص.
چه زمانی Factory Reset نکنیم؟
اگر DNS کار نمی‌کند، Reset نکنید.
اگر Firewall پورت‌های Webex را Block کرده، Reset نکنید.
اگر Code منقضی شده، Reset نکنید.
اگر TLS Inspection Certificate مورد اعتماد نیست، Reset نکنید.
اگر Device در Control Hub به User اشتباه Assign است، Reset نکنید.
اگر Phone Enterprise Firmware دارد و هنوز Migration رسمی انجام نشده، Reset به‌تنهایی آن را MPP نمی‌کند.
Packet Capture برای Provisioning از کجا شروع شود؟
Capture را قبل از Boot یا واردکردن Activation Code شروع کنید.
فیلتر اولیه:
dhcp || bootp || dns || ntp || tls || tcpبعد Sequence را بررسی کنید.
یک Boot سالم تقریباً چه الگویی دارد؟
بسته به Firmware و نوع Onboarding جزئیات فرق می‌کند، اما از دید شبکه معمولاً باید این مراحل را ببینید:
۱. DHCP کامل می‌شود.
۲. DNS Queryها جواب می‌گیرند.
۳. NTP Sync انجام می‌شود.
۴. Device به Activation/Provisioning Service وصل می‌شود.
۵. HTTPS/TLS Session ساخته می‌شود.
۶. Configuration/Firmware در صورت نیاز دریافت می‌شود.
۷. SIP Edge Discovery انجام می‌شود.
۸. SIP TLS Registration برقرار می‌شود.
۹. Control Hub Device را Online نشان می‌دهد.
اگر TLS Client Hello می‌رود ولی Server Hello نمی‌آید
Firewall، Proxy و Route را بررسی کنید.
اگر TCP سه‌مرحله‌ای ساخته نشده، هنوز به Certificate نرسیده‌اید.
اگر TCP ساخته شده، TLS شروع شده و Alert دریافت می‌کنید، آن‌وقت Certificate/Trust/Cipher بررسی می‌شود.
این تفکیک جلوی تشخیص اشتباه «SSL مشکل دارد» را می‌گیرد.
اگر فقط روی شبکه شرکت Provision نمی‌شود ولی Hotspot کار می‌کند
این یکی از بهترین تست‌های تفکیکی است.
اگر همان Phone و همان Activation Code روی شبکه جایگزین Provision می‌شوند اما روی LAN سازمانی نه، Phone و Code احتمالاً سالم‌اند.
تمرکز را روی این موارد بگذارید:
🔹 DNS Filtering
🔹 Proxy
🔹 TLS Inspection
🔹 Firewall Egress Rules
🔹 SIP ALG
🔹 NAT Policy
اگر همه Phoneهای یک شعبه Activating مانده‌اند
احتمال خرابی هم‌زمان ده‌ها Phone بسیار کم است.
در این حالت اول شبکه مشترک شعبه را بررسی کنید:
DNS، NTP، Internet Egress، Proxy، Firewall، NAT و VLAN.
اگر Phone دیگری در شعبه مرکزی روی همان Organization سالم است، Control Hub Organization احتمالاً مشکل عمومی ندارد.
اگر فقط یک Phone مشکل دارد
یک Device سالم کنار آن بگذارید و مقایسه کنید:
🔹 Model
🔹 Firmware
🔹 VLAN/IP/DNS
🔹 Activation Method
🔹 Control Hub Assignment
🔹 Proxy Settings
🔹 Certificate/Trust State
این مقایسه معمولاً سریع‌تر از Reset کردن Phone خراب نتیجه می‌دهد.
CScan چه کمکی می‌کند؟
Webex CScan یک ابزار Network Readiness برای بررسی اتصال Webex Calling است.
می‌توانید از آن به‌عنوان تست مکمل استفاده کنید تا مشخص شود شبکه از نظر Port و Path کلی مناسب است یا نه.
اما CScan جای Packet Capture خود Phone را نمی‌گیرد؛ چون Browser و Phone دقیقاً Traffic Pattern یکسانی ندارند.
جدول تشخیص سریع Webex Calling Provisioning Failed
| نشانه | احتمال بیشتر | اولین بررسی |
|---|---|---|
| Control Hub = Activating | Code وارد نشده یا Cloud Reachability | Activation Code و DNS |
| Invalid Activation Code | Code منقضی/اشتباه | Code جدید از Control Hub |
| Code پذیرفته می‌شود ولی Provision نمی‌شود | HTTPS/TLS/Firewall | TCP 443/6970 و Capture |
| DNS A سالم، Registration Fail | SRV/SIP TLS | DNS SRV و TCP 8934 |
| روی Hotspot کار می‌کند، LAN نه | Firewall/Proxy/Inspection | Egress Policy |
| TLS Alert | Trust/Inspection/Time | Certificate Chain و NTP |
| Provision شده ولی Offline است | SIP Registration | DNS SRV، TLS و NAT |
| بعد Reset دوباره Activation می‌خواهد | Activation-Code onboarding قبلی | Code جدید یا MAC onboarding |
مسیر پیشنهادی عیب‌یابی بدون Reset بی‌دلیل
مرحله ۱: Device Record و Assignment را در Control Hub بررسی کنید.
مرحله ۲: وضعیت Activating/Offline/Online را ثبت کنید.
مرحله ۳: Activation Code و تاریخ اعتبار آن را بررسی کنید.
مرحله ۴: Model و Firmware تلفن را ثبت کنید.
مرحله ۵: IP، Gateway، DNS، NTP و VLAN را بررسی کنید.
مرحله ۶: DNS A و SRV را آزمایش کنید.
مرحله ۷: Firewall/Proxy را با Port Reference فعلی Webex مقایسه کنید.
مرحله ۸: TLS Inspection، Trust Store و ساعت دستگاه را بررسی کنید.
مرحله ۹: SIP TLS Registration، NAT و SIP ALG را بررسی کنید.
مرحله ۱۰: Packet Capture Boot/Activation را ذخیره کنید.
مرحله ۱۱: فقط اگر Network و Control Hub سالم‌اند، Factory Reset را انجام دهید.
پرسش‌های رایج
چرا Cisco Phone در Webex Calling روی Activating مانده است؟
Activating یعنی Activation Code ایجاد شده ولی Device هنوز Onboard نشده است. Code، Firmware، DNS، اینترنت خروجی و دسترسی به سرویس‌های Activation/Provisioning را بررسی کنید.
Activation Code در Webex Calling چند رقم است و چقدر اعتبار دارد؟
برای MPP Phone، Code فعلی ۱۶ رقمی است و طبق مستند Webex تا ۳۰ روز اعتبار دارد.
برای Provisioning تلفن Webex فقط TCP 443 کافی است؟
خیر. DNS، NTP، Device Configuration/Firmware، SIP TLS و بعداً Media هرکدام نیازمندی‌های جدا دارند. Port Reference رسمی Webex باید مبنا باشد.
چرا DNS معمولی کار می‌کند ولی Webex Register نمی‌شود؟
Webex Calling برای SIP Discovery از DNS SRV نیز استفاده می‌کند. ممکن است A Record سالم باشد ولی SRV Query یا مسیر SIP TLS مشکل داشته باشد.
آیا TLS Inspection می‌تواند Activation را خراب کند؟
بله. اگر Proxy Certificate جای Certificate اصلی Webex را بگیرد، MPP باید CA آن Proxy را Trust کند. Cisco برای نصب Custom CA روی MPP مسیر TAC را توصیه می‌کند.
چرا Phone روی Hotspot Provision می‌شود ولی روی شبکه شرکت نه؟
این الگو معمولاً به DNS Filtering، Proxy، TLS Inspection، Firewall، SIP ALG یا NAT Policy شبکه شرکت اشاره می‌کند.
بعد از Factory Reset آیا همان Activation Code قبلی کار می‌کند؟
به روش Onboarding بستگی دارد. اگر Phone با Activation Code onboard شده بود، بعد از Reset معمولاً Code جدید یا MAC-based onboarding لازم است. اگر با MAC onboard شده باشد، می‌تواند دوباره به Webex Calling متصل شود.
آیا برای هر خطای Provisioning باید Factory Reset کنیم؟
خیر. Reset باید بعد از تأیید Control Hub، Activation، DNS، Firewall و TLS انجام شود. اگر مشکل شبکه‌ای باشد، Reset هیچ‌چیز را اصلاح نمی‌کند.
جمع‌بندی
در خطای Webex Calling provisioning failed باید مشخص کنید تلفن در کدام مرحله متوقف شده است. Control Hub و Activation Code نقطه شروع‌اند، اما بعد از آن DNS، NTP، HTTPS/TLS، Firewall، Proxy و SIP Registration تعیین می‌کنند Phone واقعاً Online شود یا نه.
Activation Code معتبر با شبکه‌ای که DNS SRV را Block می‌کند یا TLS Inspection ناسازگار دارد، به نتیجه نمی‌رسد. به همین شکل Factory Reset روی شبکه‌ای که Webex Ports را بسته است فقط تلفن را به نقطه شروع برمی‌گرداند.
بهترین روش این است که Boot Sequence و Provisioning را Capture کنید، Fail Point را پیدا کنید و Factory Reset را فقط زمانی انجام دهید که مطمئن هستید Control Hub Assignment و مسیر Cloud سالم‌اند.
Activation Code سالم است اما Cisco Phone هنوز Provision نمی‌شود؟
اگر Control Hub درست تنظیم شده اما Phone روی Activating یا Offline مانده، معمولاً باید مسیر شبکه از خود Voice VLAN تا Webex Cloud بررسی شود؛ از DNS و NTP تا Firewall، Proxy، TLS Inspection و SIP Registration.
ایرانیکاسرور می‌تواند تنظیمات شبکه VoIP، DNS، Firewall و Cisco Endpoint را بررسی کند تا مشخص شود مشکل Provisioning از Device است یا از مسیر ارتباط با Webex Calling. این بررسی مخصوصاً برای شعبی مفید است که چند Phone هم‌زمان روی Activation یا Offline گیر کرده‌اند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)