Amir Jabbari
این مشکل در تلفن‌های Cisco 78xx و 88xx دو شکل مهم دارد. در Firmware سازمانی که معمولاً با CUCM استفاده می‌شود، تلفن اغلب باید TFTP Server را از DHCP Option 150 بگیرد و فایل تنظیمات مخصوص خودش را دانلود کند. در مدل‌های MPP یا 3PCC، Provisioning انعطاف بیشتری دارد و می‌تواند از TFTP، HTTP یا HTTPS و Profile Rule استفاده کند.
در این مقاله از ساده‌ترین بررسی شروع می‌کنیم و تا Packet Capture جلو می‌رویم تا مشخص شود شکست در DHCP Option، DNS، Routing، Firewall، خود TFTP/HTTP(S)، نام فایل یا Profile Rule رخ داده است.
قاعده ساده: وقتی تلفن IP دارد ولی Provisioning انجام نمی‌شود، چهار سؤال را پاسخ دهید: سرور کجاست؟ تلفن آدرس آن را از کجا گرفته؟ آیا مسیر شبکه تا سرور باز است؟ سرور دقیقاً چه فایل یا URLی را باید تحویل دهد؟
اول مشخص کنید تلفن Enterprise است یا MPP/3PCC
قبل از تغییر DHCP، این تفاوت را روشن کنید. بسیاری از خطاهای عیب‌یابی Cisco از جایی شروع می‌شوند که دستور یا DHCP Option مربوط به یک خانواده Firmware روی خانواده دیگر اعمال می‌شود.
تلفن‌های Enterprise معمولاً برای CUCM طراحی شده‌اند. در این حالت DHCP علاوه بر IP و Gateway می‌تواند آدرس TFTP Server را نیز به تلفن بدهد و دستگاه پس از Boot فایل تنظیمات مخصوص خود را از TFTP دریافت می‌کند.
در مقابل، MPP یا Multiplatform Phone برای سرویس‌دهنده‌ها، SIP Serverهای ثالث و Provisioning منعطف‌تر طراحی شده است. سرور Provisioning در این خانواده می‌تواند TFTP، HTTP یا HTTPS باشد و مسیر Profile نیز با Profile Rule تعیین شود.
| حالت | مسیر رایج | نکته مهم |
|---|---|---|
| Enterprise / CUCM | DHCP → TFTP → فایل تنظیمات → CUCM | Option 150 روش پیشنهادی Cisco است و Option 66 می‌تواند جایگزین باشد |
| MPP / 3PCC | DHCP/EDOS/Manual → Profile Rule → TFTP/HTTP/HTTPS | Provisioning الزاماً TFTP نیست و HTTPS در استقرار راه‌دور مناسب‌تر است |
در Enterprise/CUCM تلفن TFTP Server را چگونه پیدا می‌کند؟
در راهنماهای فعلی 7800 و 8800 برای CUCM، Cisco استفاده از DHCP Option 150 را توصیه می‌کند. مقدار این Option آدرس TFTP Server است. اگر Option 150 قابل استفاده نباشد، Option 66 نیز پشتیبانی می‌شود.
در یک DHCP Pool روی Cisco IOS، نمونه ساده می‌تواند به این شکل باشد:
ip dhcp pool VOICE
network 192.0.2.0 255.255.255.0
default-router 192.0.2.1
option 150 ip 198.51.100.20در این مثال، آدرس‌ها فقط نمونه مستندسازی هستند. تلفن باید از Voice VLAN خودش IP بگیرد و DHCP نیز آدرس واقعی TFTP/CUCM محیط شما را در Option 150 برگرداند.
اگر تلفن IP دارد ولی Option 150 دریافت نکرده، داشتن DHCP به‌تنهایی برای Boot کامل Enterprise کافی نیست.
Option 150 با Option 66 چه فرقی دارد؟
Option 150 برای Cisco TFTP طراحی شده و می‌تواند لیستی از آدرس‌های TFTP را در اختیار Endpoint قرار دهد. Option 66 در استاندارد DHCP به‌عنوان نام یا آدرس TFTP Server استفاده می‌شود و Cisco آن را به‌عنوان راه جایگزین نیز پشتیبانی می‌کند.
اگر محیط CUCM دارید، نقطه شروع بهتر Option 150 است. اگر DHCP Server شما Option 150 را پشتیبانی نمی‌کند یا طراحی خاصی دارید، Option 66 می‌تواند مطرح شود.
مهم‌تر از شماره Option این است که در Packet Capture ببینید DHCP ACK واقعاً چه مقداری را به همان تلفن تحویل داده است.
MPP/3PCC فقط با Option 150 کار نمی‌کند
در MPP داستان متفاوت است. تلفن‌های Multiplatform از چند DHCP Option برای پیدا کردن Firmware و Profile پشتیبانی می‌کنند. در مستندات Cisco گزینه‌هایی مانند 66، 159، 160 و 150 در این فرایند دیده می‌شوند.
در این خانواده، Option 66 می‌تواند TFTP Server Name را معرفی کند، Option 159 برای Provisioning Server IP و Option 160 برای Provisioning URL استفاده شود. همچنین Profile Rule می‌تواند مستقیماً URL کامل سرور را مشخص کند.
پس اگر مدل شما 3PCC/MPP است، فقط دیدن Option 150 در DHCP دلیل نمی‌شود تلفن دقیقاً همان مسیر Enterprise را دنبال کند. تنظیمات Voice → Provisioning و Profile Rule را نیز بررسی کنید.
Profile Rule چیست؟
Profile Rule به تلفن MPP می‌گوید فایل تنظیمات را از کجا و با چه پروتکلی دریافت کند.
فرمت کلی می‌تواند چیزی شبیه این باشد:
https://prov.example.net/cisco/$MA.cfg$MA یک Macro است که می‌تواند با MAC Address تلفن جایگزین شود. نام Macro و قالب فایل باید با Provisioning Design واقعی شما سازگار باشد.
اگر Scheme در بعضی Profile Ruleهای MPP حذف شود، TFTP می‌تواند به‌عنوان پروتکل پیش‌فرض در نظر گرفته شود. به همین دلیل یک Profile Rule ناقص ممکن است باعث شود تلفن برخلاف انتظار شما سراغ TFTP برود.
مرحله ۱: روی خود تلفن ببینید TFTP یا Provisioning Server چیست
حدس‌زدن را کنار بگذارید. قبل از تغییر DHCP، Network Configuration تلفن را باز کنید و ببینید TFTP Server، DNS، Default Gateway و VLAN چه مقادیری دارند.
در مدل‌های Enterprise 8800 می‌توان Alternate TFTP Server را نیز به‌صورت دستی فعال کرد. اگر این گزینه قبلاً فعال شده باشد، تلفن ممکن است به‌جای مقداری که DHCP امروز می‌دهد، به آدرس دستی دیگری برود.
اگر تلفن قبلاً روی CUCM دیگری بوده است، این بررسی اهمیت بیشتری دارد. وجود تنظیم قدیمی، Trust List قدیمی یا Alternate TFTP می‌تواند عیب‌یابی را گمراه کند.
مرحله ۲: DHCP ACK را ببینید؛ نه فقط Scope را
ممکن است DHCP Server در پنل درست به نظر برسد ولی Relay، Policy، Vendor Class یا Scope دیگری پاسخ تلفن را ساخته باشد.
بهترین مدرک، خود DHCP ACK است.
در Wireshark می‌توانید از فیلتر زیر استفاده کنید:
dhcp || bootpدر DHCP Offer و ACK دنبال این موارد باشید: IP تلفن، Default Gateway، DNS Server، Option 150 یا 66 و در MPP گزینه‌های Provisioning مرتبط.
اگر Option مورد انتظار اصلاً داخل ACK نیست، مشکل هنوز به TFTP نرسیده است.
مرحله ۳: اگر سرور با نام دامنه تعریف شده، DNS را بررسی کنید
اگر Option 66 یا Profile Rule به‌جای IP از Hostname استفاده می‌کند، تلفن باید DNS معتبر داشته باشد.
در راهنمای عیب‌یابی فعلی Cisco، پیام DNS unknown host به این معناست که تلفن نتوانسته نام TFTP Server یا CUCM را Resolve کند.
پس این سه چیز را کنار هم بررسی کنید: DNS Server دریافت‌شده از DHCP، نام دقیق Provisioning/TFTP Server و رکورد DNS همان نام.
از یک سیستم داخل همان VLAN یا مسیر شبکه می‌توانید بررسی اولیه را انجام دهید:
nslookup prov.example.netموفق‌شدن DNS روی لپ‌تاپ اثبات نمی‌کند خود تلفن همان DNS Server و همان Route را دارد، اما یک مرحله اولیه مفید است.
مرحله ۴: Routing را قبل از Firewall بررسی کنید
گاهی همه تمرکز روی UDP 69 است، در حالی که تلفن اصلاً Route به subnet سرور ندارد.
اگر TFTP یا Provisioning Server در VLAN یا Site دیگری قرار دارد، بررسی کنید Gateway تلفن درست باشد و مسیر رفت و برگشت میان Voice VLAN و Server Network وجود داشته باشد.
از Gateway یا دستگاه لایه ۳ مسیر را بررسی کنید. روی Cisco IOS نمونه ساده می‌تواند این باشد:
show ip route 198.51.100.20اگر Routing نامتقارن، ACL یا VRF دارید، فقط Ping از یک شبکه دیگر کافی نیست. تست باید تا حد ممکن از همان Voice VLAN یا مسیر مشابه تلفن انجام شود.
مرحله ۵: TFTP فقط «UDP 69» نیست
TFTP برای شروع درخواست Read یا Write از UDP Port 69 استفاده می‌کند، اما بعد از شروع Transfer، دو طرف از Transfer IDهای خود که به پورت‌های UDP مربوط می‌شوند استفاده می‌کنند.
این یعنی یک Firewall یا ACL ممکن است اولین درخواست را ببیند اما ادامه انتقال را Drop کند.
اگر روی Firewall فقط یک Rule بسیار ساده برای Destination UDP/69 نوشته‌اید و Session Tracking یا TFTP Inspection وجود ندارد، Capture دو سمت Firewall را مقایسه کنید.
این نکته مخصوصاً زمانی مهم است که تلفن و TFTP Server در دو شبکه متفاوت قرار دارند و میان آن‌ها Firewall قرار گرفته است.
مرحله ۶: تفاوت TFTP Timeout و TFTP Access Error را بفهمید
این دو پیام یک معنی ندارند.
| پیام | برداشت درست | اولین بررسی |
|---|---|---|
| TFTP Timeout | سرور در زمان انتظار پاسخ مناسب نداده است | Routing، Firewall، سرویس TFTP و Capture |
| TFTP Access Error | مسیر یا فایل مورد انتظار روی سرور مشکل دارد | TFTP Root، Directory و نام فایل |
| DNS Unknown Host | Hostname قابل Resolve نیست | DNS Server و رکورد نام |
| Trust List Update Failed | دریافت یا اعتبارسنجی CTL/ITL مشکل دارد | TFTP، فایل‌های Trust و تاریخچه CUCM تلفن |
Cisco در راهنمای مانیتورینگ 8800 نیز TFTP Timeout را بیشتر به نبود پاسخ سرور، قطعی شبکه یا خاموش‌بودن سرویس مرتبط می‌داند؛ در حالی که TFTP Access Error بیشتر به مسیر یا پیکربندی TFTP اشاره دارد.
مرحله ۷: در CUCM فایل تنظیمات تلفن را بررسی کنید
در Enterprise، رسیدن به TFTP Server کافی نیست. فایل دستگاه نیز باید وجود داشته باشد و TFTP بتواند آن را تحویل دهد.
در تلفن‌های SIP جدید Cisco، فایل تنظیمات معمولاً بر اساس Device Name/MAC ساخته می‌شود و نامی در خانواده SEP<MAC>.cnf.xml دارد.
اگر تلفن به TFTP Request می‌فرستد اما Server پاسخ File Not Found می‌دهد، شبکه تقریباً تا خود سرور سالم است. حالا Device Configuration، MAC Address ثبت‌شده و فایل تولیدشده در CUCM مهم‌تر می‌شوند.
MAC را بدون خط تیره یا اشتباه تایپی با Device Name ثبت‌شده مقایسه کنید.
در Packet Capture دقیقاً دنبال چه چیزی بگردیم؟
برای این مشکل، Packet Capture بهترین راه برای جلوگیری از حدس است.
ترتیب طبیعی در Enterprise تقریباً این است:
🔹 DHCP Discover / Offer / Request / ACK
🔹 دریافت Option 150 یا 66
🔹 در صورت Hostname، DNS Query و Response
🔹 TFTP Read Request برای فایل موردنیاز
🔹 پاسخ Data یا Error از TFTP Server
اگر DHCP درست است ولی هیچ TFTP RRQ از تلفن دیده نمی‌شود، باید بررسی کنید خود تلفن چه Serverی را انتخاب کرده، Alternate TFTP فعال است یا نه و Firmware چه مسیر Provisioningی دارد.
اگر RRQ از تلفن خارج می‌شود ولی به Server نمی‌رسد، Routing/ACL/Firewall مشکل دارد.
اگر RRQ به Server می‌رسد و Server پاسخ می‌دهد ولی پاسخ به تلفن برنمی‌گردد، مسیر برگشت یا Firewall را بررسی کنید.
اگر Server پاسخ File Not Found می‌دهد، مشکل دیگر شبکه نیست؛ نام فایل یا محتوای TFTP Root را بررسی کنید.
Capture کاربردی با tcpdump
اگر Provisioning Server لینوکسی است، بهتر است Capture را فقط روی UDP 69 محدود نکنید؛ چون TFTP بعد از شروع از Portهای انتقال دیگری استفاده می‌کند.
یک Capture بر اساس IP تلفن و Server دقیق‌تر است:
sudo tcpdump -ni any 'host 192.0.2.50 or host 198.51.100.20' -w cisco-provisioning.pcapدر این مثال، 192.0.2.50 تلفن و 198.51.100.20 Provisioning/TFTP Server فرضی هستند.
Capture را شروع کنید، تلفن را Reboot یا Resync کنید و بعد فایل را در Wireshark بررسی کنید.
فیلترهای مفید Wireshark
برای DHCP:
dhcp || bootpبرای DNS:
dnsبرای TFTP:
tftpو اگر MPP از HTTP یا HTTPS استفاده می‌کند:
http || tlsاگر MPP از HTTP یا HTTPS Provisioning استفاده می‌کند
در استقرارهای MPP، Cisco استفاده از HTTPS را برای محیط‌های راه‌دور توصیه می‌کند؛ چون HTTP و HTTPS معمولاً پشت NAT و Firewallهای مرزی قابل‌اعتمادتر از TFTP هستند.
در این حالت دیگر UDP 69 موضوع اصلی نیست. باید DNS، TCP Port، URL، Certificate و Path فایل را بررسی کنید.
پورت‌های استاندارد عبارت‌اند از:
🔹 TFTP: UDP 69 برای درخواست اولیه
🔹 HTTP: TCP 80
🔹 HTTPS: TCP 443
اگر URL روی Port سفارشی تعریف شده است، همان Port باید در Routing و Firewall باز باشد.
HTTP 404 با Timeout فرق دارد
اگر تلفن MPP یک HTTP Request می‌فرستد و Server پاسخ 404 می‌دهد، ارتباط شبکه و TCP برقرار شده است؛ مشکل بیشتر در Path یا نام فایل است.
اگر Connection Timeout دارید، ابتدا Routing و Firewall را بررسی کنید.
اگر HTTPS Handshake شکست می‌خورد، Certificate Chain، نام دامنه، ساعت تلفن و Trust Store اهمیت پیدا می‌کنند.
بنابراین نتیجه Capture را به یک عبارت کلی «Provisioning کار نمی‌کند» محدود نکنید. نوع شکست مشخص می‌کند مرحله بعدی کجاست.
یک تست مهم: آیا Server از یک سیستم دیگر فایل را می‌دهد؟
Cisco در راهنمای Provisioning پیشنهاد می‌کند عملکرد Server مستقل از تلفن هم آزمایش شود.
برای HTTP می‌توانید از یک سیستم تست استفاده کنید:
curl -I http://prov.example.net/cisco/test.cfgبرای HTTPS:
curl -Iv https://prov.example.net/cisco/test.cfgموفقیت این تست فقط Server را از دید سیستم آزمایش‌کننده تأیید می‌کند؛ مسیر شبکه و Trust Store خود تلفن همچنان باید جداگانه بررسی شوند.
اگر TFTP Server روی CUCM است، سرویس را هم بررسی کنید
در CUCM، Cisco TFTP Service باید روی Node مناسب فعال و در حال اجرا باشد. اگر DHCP Option 150 به یک Node اشاره کند که TFTP روی آن فعال نیست، تلفن IP می‌گیرد ولی Boot کامل نمی‌شود.
اگر چند TFTP Server دارید، مطمئن شوید آدرس‌هایی که DHCP تحویل می‌دهد همان Nodeهایی هستند که برای این Cluster و Device طراحی شده‌اند.
تلفنی که قبلاً روی CUCM دیگری بوده است
اگر تلفن قبلاً به Cluster دیگری رجیستر بوده، فقط DHCP را بررسی نکنید. ممکن است CTL/ITL و Trust State دستگاه نیز وارد ماجرا شوند.
علائمی مثل Trust List Update Failed با یک TFTP Timeout ساده یکسان نیستند.
در چنین سناریویی اول مطمئن شوید تلفن واقعاً به TFTP جدید می‌رسد و فایل‌های جدید را درخواست می‌کند. بعد Trust List را بررسی کنید. پاک‌کردن Trust List یا Factory Reset بدون شناخت محیط امنیتی نباید اولین حرکت باشد.
اگر IP گرفته ولی حتی یک TFTP/HTTP Request نمی‌بینیم چه؟
این حالت بسیار مهم است.
اگر DHCP کامل شده اما تلفن هیچ درخواست Provisioning ارسال نمی‌کند، یکی از این موارد را بررسی کنید:
🔹 آدرس TFTP/Provisioning واقعاً روی تلفن ثبت شده یا نه
🔹 Alternate TFTP Server آدرس قدیمی ندارد
🔹 در MPP، Provision Enable فعال است
🔹 Profile Rule خالی یا اشتباه نیست
🔹 Resync Trigger واقعاً اجرا شده است
🔹 DHCP Option درست به Firmware فعلی تحویل شده است
این مرحله همان جایی است که دانستن Enterprise یا MPP بودن دستگاه ضروری می‌شود.
چه زمانی Factory Reset انجام دهیم؟
Factory Reset برای مشکل TFTP اولین راه‌حل نیست.
اگر DHCP ACK اشتباه است، Reset کمکی نمی‌کند. اگر Firewall TFTP را Drop می‌کند، Reset کمکی نمی‌کند. اگر DNS خراب است، Reset هم DNS را درست نمی‌کند.
Reset زمانی منطقی‌تر است که تلفن قبلاً Provisioning یا CUCM دیگری داشته، تنظیم دستی قدیمی باقی مانده و بعد از ثبت همه اطلاعات لازم می‌خواهید دستگاه را از وضعیت شناخته‌شده دوباره Provision کنید.
جدول تشخیص سریع
| نشانه | احتمال بیشتر | اولین بررسی |
|---|---|---|
| IP دارد ولی TFTP Server خالی است | DHCP Option | DHCP ACK و Option 150/66 |
| TFTP Server با Hostname نمایش داده می‌شود ولی پیدا نمی‌شود | DNS | Option 6 و DNS Query |
| TFTP Timeout | Routing، Firewall یا سرویس TFTP | Capture دو سمت مسیر |
| File Not Found | نام فایل یا TFTP Root | SEP<MAC> و فایل تولیدشده |
| HTTP 404 | Profile Path اشتباه | Profile Rule و Web Root |
| HTTPS Handshake Failure | Certificate/Trust/Time | Certificate Chain و ساعت تلفن |
| هیچ Request بعد از DHCP دیده نمی‌شود | TFTP/Profile Rule/Provision Enable | وضعیت خود Endpoint |
مسیر پیشنهادی عیب‌یابی از صفر تا نتیجه
مرحله ۱: مدل و نوع Firmware را مشخص کنید: Enterprise یا MPP.
مرحله ۲: روی تلفن IP، Gateway، DNS و TFTP/Provisioning Server را بخوانید.
مرحله ۳: DHCP ACK را Capture کنید و Option واقعی تحویل‌شده را ببینید.
مرحله ۴: اگر Server با نام تعریف شده، DNS را تأیید کنید.
مرحله ۵: Routing و مسیر برگشت میان Voice VLAN و Server را بررسی کنید.
مرحله ۶: Firewall را متناسب با پروتکل واقعی بررسی کنید؛ برای TFTP فقط UDP/69 را معیار کامل ندانید.
مرحله ۷: روی Server ببینید Request تلفن رسیده و چه فایل یا URLی درخواست شده است.
مرحله ۸: اگر Server پاسخ می‌دهد، Response و Error Code را در Packet Capture بررسی کنید.
مرحله ۹: فقط بعد از مشخص‌شدن مشکل به سراغ Reset، تغییر Firmware یا Trust List بروید.
IP گرفته ولی Provisioning هنوز کامل نمی‌شود؟
وقتی تلفن IP دارد اما فایل تنظیمات را پیدا نمی‌کند، نقطه شکست می‌تواند بین DHCP، DNS، Voice VLAN، Firewall، Routing یا خود Provisioning Server باشد. بررسی هم‌زمان Endpoint و Server معمولاً بسیار سریع‌تر از Resetهای مکرر تلفن نتیجه می‌دهد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
چرا Cisco Phone آی‌پی می‌گیرد ولی TFTP را پیدا نمی‌کند؟
گرفتن IP فقط ثابت می‌کند DHCP برای آدرس‌دهی پاسخ داده است. ممکن است Option 150 یا 66 وجود نداشته باشد، TFTP Server اشتباه باشد، DNS نام سرور را Resolve نکند یا مسیر شبکه تا سرور بسته باشد.
برای CUCM از Option 150 استفاده کنیم یا 66؟
Cisco در راهنماهای فعلی 7800 و 8800 برای CUCM، Option 150 را توصیه می‌کند. اگر استفاده از آن ممکن نباشد، Option 66 نیز پشتیبانی می‌شود.
آیا MPP هم حتماً باید از TFTP استفاده کند؟
خیر. MPP می‌تواند Profile و Firmware را با TFTP، HTTP یا HTTPS دریافت کند. Profile Rule و DHCP Provisioning Optionها تعیین می‌کنند تلفن سراغ کدام Server و Protocol برود.
چرا بازکردن UDP 69 مشکل TFTP را حل نکرد؟
UDP 69 برای شروع درخواست TFTP استفاده می‌شود، اما ادامه Transfer از Transfer ID/Portهای UDP دیگری استفاده می‌کند. Firewall باید Session را درست دنبال کند یا سیاست متناسب با TFTP داشته باشد.
TFTP Timeout با File Not Found چه فرقی دارد؟
Timeout معمولاً یعنی پاسخ مناسب از Server دریافت نشده و Routing، Firewall یا خود سرویس مطرح است. File Not Found یعنی درخواست به TFTP Server رسیده اما فایل مورد درخواست پیدا نشده است.
چرا HTTP Provisioning روی MPP کار می‌کند ولی TFTP نه؟
HTTP/TCP معمولاً عبور ساده‌تری از NAT و Firewall دارد. Cisco نیز برای استقرارهای راه‌دور HTTPS را مناسب‌تر می‌داند. اگر TFTP فقط از شبکه راه‌دور خراب است، Firewall و NAT را جدی بررسی کنید.
آیا Factory Reset برای TFTP Timeout لازم است؟
خیر. ابتدا DHCP Option، DNS، Routing، Firewall و Server را بررسی کنید. Reset فقط زمانی ارزش دارد که تنظیم قدیمی Endpoint یا وضعیت Provisioning قبلی واقعاً بخشی از مسئله باشد.
جمع‌بندی
وقتی تلفن Cisco IP می‌گیرد ولی TFTP یا Provisioning Server را پیدا نمی‌کند، مسئله را از «شبکه کار نمی‌کند» به چند مرحله کوچک تبدیل کنید. اول Firmware را مشخص کنید، سپس DHCP Option و Server واقعی روی Endpoint را ببینید. بعد DNS، Routing و Firewall را کنترل کنید و در نهایت با Packet Capture ثابت کنید Request و Response در کدام نقطه متوقف می‌شوند.
در Enterprise/CUCM، Option 150 نقطه شروع اصلی TFTP Discovery است. در MPP، Provisioning می‌تواند با TFTP، HTTP یا HTTPS انجام شود و Profile Rule نقش بسیار مهم‌تری دارد. همین تفاوت از بسیاری از تنظیمات اشتباه جلوگیری می‌کند.
برای بررسی TFTP یا Provisioning تلفن Cisco کمک می‌خواهید؟
اگر تلفن IP می‌گیرد اما Config File، Firmware یا Profile را دریافت نمی‌کند، می‌توانید مسیر DHCP، DNS، Firewall، Routing و Provisioning Server را به‌صورت یکپارچه بررسی کنید تا نقطه قطع ارتباط مشخص شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)