چرا ساعت تلفن Cisco IP Phone اشتباه است؟ رفع مشکل NTP و Time Zone

برای مثال ممکن است NTP کاملاً سالم باشد و تلفن زمان UTC را درست دریافت کند، اما Time Zone اشتباه باعث شود ساعت نمایشگر ۳ یا ۴ ساعت اختلاف داشته باشد. برعکس، ممکن است Time Zone کاملاً درست باشد ولی تلفن اصلاً به NTP دسترسی نداشته باشد و بعد از Reboot با تاریخ و ساعت اشتباه بالا بیاید.

در این آموزش مشکل تنظیم ساعت Cisco IP Phone را مرحله‌به‌مرحله تفکیک می‌کنیم: ابتدا مشخص می‌کنیم تلفن از کجا زمان می‌گیرد، سپس NTP و UDP/123 را بررسی می‌کنیم، DHCP Option 42 و Option 2 را می‌بینیم، Time Zone و DST را اصلاح می‌کنیم و در پایان توضیح می‌دهیم چرا اختلاف تاریخ می‌تواند HTTPS Provisioning، TLS و Certificate Authentication را نیز خراب کند.

اول مشخص کنید ساعت Cisco دقیقاً چه نوع خطایی دارد

قبل از تغییر NTP یا DHCP، الگوی خطا را تشخیص دهید.

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

تلفن Cisco MPP زمان را از کجا می‌گیرد؟

در Cisco MPP معمولاً مهم‌ترین منبع زمان NTP است.

ساختار ساده:

NTP Server
    |
    | UTC / GMT Time
    v
Cisco Phone
    |
Time Zone
    |
DST Rule
    |
    v
Local Display Time

پس NTP معمولاً «زمان پایه» را فراهم می‌کند و Time Zone/DST آن را به ساعت محلی تبدیل می‌کنند.

NTP با Time Zone یکی نیست

این اشتباه بسیار رایج است.

NTP Server لازم نیست ساعت تهران را تحویل دهد.

زمان NTP بر پایه UTC/GMT است و خود تلفن بر اساس:

زمان محلی را محاسبه می‌کند.

مرحله ۱: Primary و Secondary NTP Server را بررسی کنید

در Cisco MPP وارد پنل مدیریتی شوید.

مسیر معمول:

Voice → System → Optional Network Configuration

پارامترهای زیر را پیدا کنید:

می‌توانید IP یا Hostname سرور NTP را وارد کنید.

نمونه Provisioning

<Primary_NTP_Server ua="rw">ntp1.example.net</Primary_NTP_Server>
<Secondary_NTP_Server ua="rw">ntp2.example.net</Secondary_NTP_Server>

IP بهتر است یا Hostname؟

برای تشخیص اولیه، IP مستقیم یک متغیر کمتر دارد.

اگر Hostname استفاده کنید، این زنجیره باید کامل سالم باشد:

Phone
  |
DNS Query
  |
NTP Hostname → IP
  |
UDP/123
  |
NTP Server

پس DNS خراب می‌تواند خودش را به شکل «NTP کار نمی‌کند» نشان دهد.

مرحله ۲: NTP Reachability را بررسی کنید

NTP معمولاً از:

UDP Port 123

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

اگر Firewall بین Voice VLAN و NTP Server قرار دارد، باید مسیر لازم را بررسی کنید.

Firewall را برای تست کامل خاموش نکنید

به‌جای خاموش‌کردن Firewall مشخص کنید:

آیا مجاز است یا نه.

تست NTP از یک Linux Host در همان شبکه

اگر یک سیستم Linux در همان VLAN یا مسیر شبکه دارید:

chronyd -Q 'server ntp.example.net iburst'

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

ntpdate -q ntp.example.net

این تست رفتار خود تلفن را اثبات نمی‌کند، ولی مشخص می‌کند مسیر عمومی شبکه تا NTP Server کار می‌کند یا نه.

بهترین تست: Packet Capture

اگر NTP Server تحت کنترل شماست:

sudo tcpdump -ni any udp port 123

سپس تلفن را Reboot یا Resync کنید.

سه حالت مهم در Capture

حالت اول: هیچ Requestی از Phone نمی‌آید

بررسی کنید:

حالت دوم: Request می‌آید ولی Response برنمی‌گردد

مشکل احتمالاً در:

است.

حالت سوم: Request و Response دوطرفه‌اند

اگر NTP Packet سالم است ولی ساعت هنوز اختلاف دارد، تمرکز را از NTP به:

Time Zone → DHCP Time Offset → DST

منتقل کنید.

مرحله ۳: DHCP Option 42 را بررسی کنید

Cisco MPP از:

DHCPv4 Option 42

برای دریافت NTP Server پشتیبانی می‌کند.

در IPv6 نیز:

DHCPv6 Option 56

برای NTP قابل استفاده است.

اولویت مهم Cisco

اگر روی خود Phone:

را صریح تنظیم کرده باشید، این مقادیر نسبت به NTP دریافتی از DHCP اولویت بالاتری دارند.

یعنی ممکن است DHCP Option 42 کاملاً درست باشد ولی Phone همچنان به NTP قدیمی که در Configuration خودش ذخیره شده وصل شود.

این سناریو بسیار رایج است

DHCP Administrator می‌گوید:

«Option 42 را روی NTP جدید گذاشته‌ایم.»

اما Phone همچنان Server قدیمی را استفاده می‌کند.

دلیل:

Primary NTP Server روی Phone/Provisioning قبلاً مقداردهی شده است.

هنگام مهاجرت NTP این مورد را بررسی کنید

اگر می‌خواهید DHCP منبع اصلی NTP باشد، مطمئن شوید Profile Provisioning یک NTP ثابت دیگر را روی Phone Override نمی‌کند.

نمونه DHCP در ISC DHCP Server

ساختار مفهومی:

subnet 192.0.2.0 netmask 255.255.255.0 {
    range 192.0.2.100 192.0.2.200;

    option routers 192.0.2.1;
    option domain-name-servers 192.0.2.53;

    option ntp-servers 192.0.2.20;
}

آدرس‌ها فقط نمونه مستندسازی هستند.

مرحله ۴: DHCP Option 2 را فراموش نکنید

این یکی از مهم‌ترین علت‌های ساعت اشتباه در Cisco MPP است.

DHCP Option 2 = Time Offset

است.

ممکن است NTP زمان صحیح را بدهد اما DHCP Server یک Offset قدیمی یا اشتباه برای تلفن ارسال کند.

پارامتر Ignore DHCP Time Offset

در Cisco MPP زیر تنظیمات Time پارامتری به نام:

Ignore DHCP Time Offset

وجود دارد.

اگر روی:

Yes

باشد، Phone Time Offset دریافتی از DHCP را نادیده می‌گیرد و از Time Zone/Offset تنظیم‌شده روی خودش استفاده می‌کند.

اگر روی:

No

باشد، DHCP Time Offset می‌تواند Time Zone/Offset محلی تلفن را Override کند.

مقدار پیش‌فرض چیست؟

در مستند فعلی Cisco MPP:

Ignore DHCP Time Offset = Yes

است.

اگر همه تلفن‌ها دقیقاً چند ساعت اختلاف دارند

DHCP Option 2 را Capture کنید.

ممکن است Administrator سال‌ها قبل یک Offset گذاشته باشد و هنوز روی Voice Scope فعال باشد.

Capture DHCP روی Linux

sudo tcpdump -ni any \
'(udp port 67 or udp port 68)' \
-w /tmp/cisco-dhcp.pcap

سپس فایل را در Wireshark باز کنید و DHCP Offer/ACK را بررسی کنید.

دنبال چه Optionهایی بگردیم؟

مرحله ۵: Time Zone را بررسی کنید

در پنل Cisco MPP مسیر:

Voice → Regional → Time

را باز کنید.

پارامتر:

Time Zone

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

برای ایران در سال ۲۰۲۶ چه مقدار درست است؟

برای ایران:

GMT+03:30

انتخاب صحیح است.

Cisco MPP در Firmwareهای فعلی گزینه GMT+03:30 را در فهرست Time Zone پشتیبانی می‌کند.

تنظیم نمونه Provisioning برای ایران

<Time_Zone ua="na">GMT+03:30</Time_Zone>

Time Offset را بی‌دلیل همراه Time Zone استفاده نکنید

اگر Time Zone خودش GMT+03:30 است، اضافه‌کردن:

Time Offset = 00/30

می‌تواند ساعت را دوباره ۳۰ دقیقه جابه‌جا کند.

اصل ساده:

اگر Time Zone دقیق شما در فهرست وجود دارد، Time Offset اضافی را فقط وقتی استفاده کنید که واقعاً نیاز دارید.

مرحله ۶: DST را بررسی کنید

DST یا Daylight Saving Time همان تغییر فصلی ساعت است.

اگر Phone دقیقاً یک ساعت جلو یا عقب است، این قسمت را حتماً بررسی کنید.

در Cisco MPP:

Voice → Regional

و سپس:

برای ایران در ۲۰۲۶ DST باید خاموش باشد

ایران از سال ۲۰۲۳ دیگر DST اجرا نمی‌کند و در سال ۲۰۲۶ در تمام سال روی UTC+3:30 باقی می‌ماند.

بنابراین برای تلفنی که در ایران استفاده می‌شود:

Time Zone = GMT+03:30

Daylight Saving Time Enable = No

منطقی است.

چرا این موضوع روی Cisco مهم‌تر شده است؟

برخی Configurationهای قدیمی MPP به‌صورت پیش‌فرض DST Rule دارند.

مثلاً یک Rule شبیه:

start=3/-1/7/2;
end=10/-1/7/2;
save=1

در مستندات Cisco به‌عنوان نمونه/default تاریخی دیده می‌شود.

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

برای ایران Rule را عوض کنیم یا DST را خاموش کنیم؟

وقتی منطقه اصلاً DST ندارد، ساده‌ترین Configuration:

Daylight Saving Time Enable = No

است.

در این حالت Phone نباید Rule قدیمی را اجرا کند.

مرحله ۷: اگر ساعت را دستی تنظیم می‌کنید اما برمی‌گردد

این رفتار لزوماً Bug نیست.

Cisco توضیح می‌دهد که NTP نسبت به Manual Time اولویت دارد.

یعنی شما ساعت را دستی روی:

10:30

می‌گذارید؛ تلفن چند لحظه درست است.

سپس NTP Sync می‌شود و ساعت دوباره:

07:00

می‌شود.

در این حالت مشکل ساعت دستی نیست.

مشکل معمولاً:

است.

Manual Time فقط برای تشخیص موقت مفید است

اگر برای تست ساعت دستی درست می‌شود، می‌فهمیم Display و Clock Function تلفن سالم‌اند.

اما Configuration نهایی باید منبع زمان واقعی را اصلاح کند.

مرحله ۸: Provisioning Server را بررسی کنید

ممکن است تنظیمات را در Web UI اصلاح کنید اما بعد از Resync دوباره مقدار قدیمی برگردد.

این معمولاً یعنی Provisioning Profile پارامتر Time را Override می‌کند.

دنبال این موارد در cfg.xml یا Template بگردید:

Primary_NTP_Server
Secondary_NTP_Server
Time_Zone
Time_Offset__HH_mm_
Ignore_DHCP_Time_Offset
Daylight_Saving_Time_Enable
Daylight_Saving_Time_Rule

یک Configuration نمونه برای تلفن‌های ایران

<Primary_NTP_Server ua="rw">ntp1.example.net</Primary_NTP_Server>
<Secondary_NTP_Server ua="rw">ntp2.example.net</Secondary_NTP_Server>

<Time_Zone ua="na">GMT+03:30</Time_Zone>

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

<Daylight_Saving_Time_Enable ua="na">No</Daylight_Saving_Time_Enable>

<Time_Format ua="na">24hr</Time_Format>

`example.net` را با NTP واقعی خودتان جایگزین کنید.

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

اگر NTP را با Hostname تعریف کرده‌اید:

ntp.example.net

Phone باید DNS Server سالم داشته باشد.

در DHCP معمولاً:

Option 6

DNS را تعیین می‌کند.

اگر IP NTP کار می‌کند ولی Hostname نه

تقریباً مستقیم به سمت DNS بروید.

بررسی کنید:

مرحله ۱۰: تفاوت MPP و Enterprise/CUCM را جدی بگیرید

اگر Cisco 8841 یا 8851 شما Enterprise Firmware دارد و به CUCM متصل است، نباید صرفاً دنبال همان MPP NTP Fieldها بگردید.

در مدل CUCM، تلفن Date/Time را از Cisco Unified Communications Manager دریافت می‌کند و Time Zone نیز به Date/Time Group تلفن مرتبط است.

اگر همه تلفن‌های یک CUCM Site ساعت اشتباه دارند

بررسی کنید:

پس اول Firmware Type را مشخص کنید

دو تلفن ظاهراً یکسان Cisco 8841 می‌توانند رفتار مدیریتی متفاوتی داشته باشند:

8841 MPP

و:

8841 Enterprise/CUCM

مرحله ۱۱: چرا ساعت اشتباه می‌تواند Certificate را خراب کند؟

Certificateها بازه اعتبار دارند.

در ساده‌ترین حالت:

Not Before:
2026-01-01

Not After:
2027-01-01

اگر Phone تصور کند سال:

2024

است، ممکن است Certificate را هنوز معتبر نداند.

اگر Phone تصور کند:

2028

است، ممکن است آن را Expired ببیند.

Cisco نیز این وابستگی را مستند کرده است

در راهنمای امنیت Cisco 8800 Enterprise آمده است که در Certificate-based Authentication، ساعت و تاریخ تلفن باید صحیح باشند و اختلاف Date/Time با اعتبار Certificate می‌تواند باعث شکست Authentication شود.

این مشکل در چه قسمت‌هایی دیده می‌شود؟

بسته به معماری:

سناریوی خطرناک Startup

فرض کنید تلفن Factory Reset شده است.

برای گرفتن Config باید به:

https://provision.example.com/...

وصل شود.

اما ساعت Phone اشتباه است و TLS Certificate معتبر تشخیص داده نمی‌شود.

نتیجه ممکن است ظاهراً شبیه مشکل Provisioning باشد، در حالی که ریشه اصلی:

NTP/Clock

است.

پس در خطای TLS اول Clock را هم ببینید

اگر:

اما Phone هنوز Certificate را Reject می‌کند، Date/Time تلفن را حتماً بررسی کنید.

مرحله ۱۲: Log Phone با ساعت نمایشگر یکی نیست؟

این الزاماً مشکل نیست.

Cisco توضیح می‌دهد که Time Zone تنظیم‌شده روی تلفن ممکن است روی Log و Status Timestampها اعمال نشود و آن‌ها در UTC ثبت شوند.

پس اگر:

صفحه Phone = 14:30

ولی:

Log = 11:00

برای Time Zone +03:30 ممکن است کاملاً طبیعی باشد.

برای Correlation با PBX چه کنیم؟

هنگام عیب‌یابی:

مثلاً:

Phone Display:
14:30 IRST

UTC Log:
11:00 UTC

سناریوی ۱: ساعت دقیقاً ۳ ساعت و نیم عقب است

نشانه: دقیقه و ثانیه تقریباً درست‌اند ولی اختلاف ۳:۳۰ است.

احتمال زیاد: NTP درست است ولی Time Zone روی GMT مانده است.

رفع:

Time Zone را برای ایران روی:

GMT+03:30

قرار دهید.

سناریوی ۲: ساعت دقیقاً یک ساعت جلو می‌رود

مظنون اصلی: DST.

برای ایران در ۲۰۲۶:

Daylight Saving Time Enable = No

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

سناریوی ۳: فقط بعضی تلفن‌ها یک ساعت اشتباه‌اند

ممکن است Template Provisioning آن گروه قدیمی باشد.

یک Phone سالم و خراب را مقایسه کنید:

سناریوی ۴: همه تلفن‌های Voice VLAN ساعت اشتباه دارند

اول DHCP Scope همان VLAN را بررسی کنید.

مخصوصاً:

اگر تلفن‌های Data VLAN مشکلی ندارند ولی Voice VLAN مشکل دارد، این اختلاف سرنخ بسیار مهمی است.

سناریوی ۵: NTP با IP کار می‌کند ولی با Domain نه

علت اصلی: DNS.

به‌جای تغییر Time Zone، DHCP Option 6 و Reachability DNS را بررسی کنید.

سناریوی ۶: بعد از تعویض Router ساعت همه تلفن‌ها خراب شد

Router جدید ممکن است DHCP Option 2 متفاوتی ارسال کند.

اگر:

Ignore DHCP Time Offset = No

باشد، این Option می‌تواند تنظیم محلی Phone را Override کند.

سناریوی ۷: Phone بعد Factory Reset ساعت عجیب دارد و Provision نمی‌شود

ترتیب بررسی:

۱. IP و Gateway گرفته؟

۲. DNS درست است؟

۳. NTP Server گرفته؟

۴. UDP/123 قابل دسترسی است؟

۵. تاریخ Phone منطقی شده؟

۶. سپس HTTPS/TLS Provisioning را بررسی کنید.

سناریوی ۸: ساعت روی نمایشگر درست است ولی Caller ID Time غلط است

Time Zone و DST روی Timestampهای محلی Caller ID اثر دارند.

همچنین بررسی کنید Call History یا Caller ID Date از چه Sourceای در Firmware/PBX شما استفاده می‌کند.

سناریوی ۹: فقط بعد از Reboot ساعت اشتباه است و بعد درست می‌شود

این رفتار می‌تواند نشان دهد Phone ابتدا با Clock داخلی بالا آمده و چند لحظه بعد NTP Sync موفق شده است.

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

اما اگر Sync چند دقیقه طول می‌کشد، DNS یا NTP Reachability را بررسی کنید.

سناریوی ۱۰: ساعت درست است ولی TLS هنوز خطا می‌دهد

Clock فقط یکی از اجزای Certificate Validation است.

بعد از تأیید ساعت، بررسی کنید:

Firmware فعلی Cisco MPP را هم در نظر بگیرید

در زمان بررسی این مقاله، Cisco برای مدل‌های اصلی 7800 MPP و تعدادی از 8800 MPP، Firmware شاخه:

12.0(7)SR5

را به‌عنوان جدیدترین Maintenance Release فهرست کرده است.

اگر Firmware بسیار قدیمی دارید، قبل از نتیجه‌گیری درباره رفتار NTP یا TLS Release Notes همان مدل را بررسی کنید.

اما Upgrade اولین راه‌حل نیست

اگر Capture نشان می‌دهد:

هیچ UDP/123 از Phone خارج نمی‌شود

یا:

DHCP Option 2 ساعت اشتباه تحمیل می‌کند

Firmware Upgrade مشکل اصلی را حل نمی‌کند.

روش استاندارد عیب‌یابی ساعت Cisco در ۱۲ مرحله

مرحله ۱: مقدار اختلاف ساعت را اندازه بگیرید.

مرحله ۲: مشخص کنید Phone MPP است یا Enterprise/CUCM.

مرحله ۳: Primary/Secondary NTP را بررسی کنید.

مرحله ۴: DNS را در صورت استفاده از Hostname تست کنید.

مرحله ۵: UDP/123 را Capture کنید.

مرحله ۶: DHCP Option 42 را بررسی کنید.

مرحله ۷: DHCP Option 2 را بررسی کنید.

مرحله ۸: Ignore DHCP Time Offset را ببینید.

مرحله ۹: Time Zone را اصلاح کنید.

مرحله ۱۰: DST را بررسی کنید.

مرحله ۱۱: Provisioning Override را بررسی کنید.

مرحله ۱۲: اگر TLS/HTTPS مشکل دارد، Certificate Validity را با Clock مقایسه کنید.

جدول عیب‌یابی سریع

چک‌لیست نهایی تنظیم ساعت Cisco MPP در ایران

پرسش‌های رایج

چرا ساعت Cisco IP Phone اشتباه است؟

رایج‌ترین علت‌ها دسترسی نداشتن به NTP، Time Zone اشتباه، DHCP Time Offset نادرست، DST قدیمی یا Provisioning Profile است که تنظیم درست را دوباره Override می‌کند.

پورت NTP در Cisco IP Phone چیست؟

NTP معمولاً از UDP Port 123 استفاده می‌کند. مسیر Voice VLAN تا NTP Server باید برای این ترافیک قابل دسترسی باشد.

DHCP Option 42 در تلفن Cisco چه کاری می‌کند؟

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

DHCP Option 2 چیست؟

Option 2 Time Offset را مشخص می‌کند. اگر Cisco MPP روی استفاده از DHCP Time Offset تنظیم شده باشد، مقدار اشتباه این Option می‌تواند باعث اختلاف چندساعته شود.

Ignore DHCP Time Offset باید Yes باشد یا No؟

اگر می‌خواهید Time Zone و Offset خود Phone ملاک باشند، Yes منطقی است. اگر طراحی شبکه شما عمداً Time Offset را از DHCP توزیع می‌کند، ممکن است No لازم باشد.

Time Zone صحیح برای ایران چیست؟

در سال ۲۰۲۶ ایران روی GMT+03:30 یا UTC+03:30 قرار دارد.

آیا DST در ایران باید فعال باشد؟

خیر. ایران از سال ۲۰۲۳ تغییر ساعت فصلی را اجرا نمی‌کند؛ بنابراین در ۲۰۲۶ DST برای ایران باید غیرفعال باشد.

چرا ساعت را دستی تنظیم می‌کنم ولی دوباره خراب می‌شود؟

NTP یا Provisioning می‌تواند Manual Time را Override کند. باید منبع اصلی زمان را اصلاح کنید، نه اینکه ساعت را هر بار دستی تغییر دهید.

آیا ساعت اشتباه می‌تواند TLS را خراب کند؟

بله. Certificate دارای بازه اعتبار است و اگر تاریخ Phone خارج از این بازه باشد، Certificate Authentication یا اتصال HTTPS/TLS می‌تواند شکست بخورد.

چرا ساعت نمایشگر با Log تلفن فرق دارد؟

برخی Logها و Status Timestampهای Cisco در UTC ثبت می‌شوند و Time Zone نمایشگر روی آن‌ها اعمال نمی‌شود.

در Cisco Enterprise متصل به CUCM هم باید NTP خود Phone را تنظیم کنم؟

معمولاً مسیر متفاوت است. تلفن‌های Enterprise زمان و Time Zone را از CUCM و Date/Time Group مربوط دریافت می‌کنند؛ بنابراین CUCM و NTP Cluster را بررسی کنید.

اگر NTP پاسخ می‌دهد ولی ساعت همچنان غلط است، چه کنم؟

Time Zone، Time Offset، DHCP Option 2، Ignore DHCP Time Offset و DST را بررسی کنید. وقتی NTP دوطرفه سالم است، مشکل معمولاً در تبدیل UTC به زمان محلی است.