چرا رجیستر تلفن یالینک در طول روز قطع و وصل می‌شود؟ رفع ناپایداری SIP

Restart معمولاً علت را برطرف نمی‌کند؛ فقط وضعیت شبکه را از نو می‌سازد. تلفن دوباره DHCP می‌گیرد، DNS را Resolve می‌کند، NAT Mapping جدید ایجاد می‌شود و REGISTER تازه‌ای به PBX می‌فرستد. به همین دلیل ممکن است همه چیز برای چند ساعت خوب باشد و بعد مشکل دوباره برگردد.

در این آموزش به‌جای Restart کردن مداوم دستگاه، یک Timeline واقعی از خرابی می‌سازیم و Registration Expiry، NAT Timeout، Keep Alive، DHCP Lease، DNS، Packet Loss، PBX Contact، سیستم‌های Ban و Firewall Conntrack را مرحله‌به‌مرحله بررسی می‌کنیم تا دقیقاً مشخص شود رجیستر Yealink در چه نقطه‌ای قطع می‌شود.

قطع رجیستر Yealink دقیقاً چه حالتی است؟

در حالت Intermittent Registration تلفن حداقل بخشی از زمان کاملاً Registered است.

برای مثال:

08:00  Registered
10:15  Registered
11:02  Register Failed
11:05  Restart
11:06  Registered
14:47  Register Failed
14:50  دوباره Registered

این الگو با تلفنی که از ابتدا هیچ‌وقت Register نمی‌شود متفاوت است.

سؤال اصلی در این مقاله این نیست که «چرا SIP کار نمی‌کند؟» بلکه این است:

چه اتفاقی درست قبل از از دست رفتن Registration رخ می‌دهد؟

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

هنگام Restart چند اتفاق هم‌زمان رخ می‌دهد:

Interface شبکه دوباره بالا می‌آید.

DHCP ممکن است Lease را Refresh کند.

DNS دوباره Resolve می‌شود.

TCP یا TLS Connection دوباره ساخته می‌شود.

UDP NAT Mapping جدید ایجاد می‌شود.

Yealink REGISTER تازه ارسال می‌کند.

PBX Contact جدید ثبت می‌کند.

بنابراین اینکه Restart مشکل را حل می‌کند، به‌تنهایی ثابت نمی‌کند Firmware تلفن خراب است.

اول یک Timeline واقعی از مشکل بسازید

قبل از تغییر تنظیمات، حداقل زمان دو یا سه بار قطع‌شدن Registration را ثبت کنید.

مثلاً:

قطع اول:
10:02:13

قطع دوم:
11:02:14

قطع سوم:
12:02:12

اگر مشکل تقریباً هر ۳۶۰۰ ثانیه رخ دهد، Registration Expiry و Refresh بسیار مهم می‌شوند.

اگر همیشه بعد از حدود ۳۰ تا ۱۲۰ ثانیه Idle بودن اتفاق می‌افتد، NAT و Conntrack را جدی‌تر بررسی کنید.

اگر دقیقاً حوالی تغییر IP یا DHCP Renew رخ می‌دهد، مسیر DHCP اهمیت پیدا می‌کند.

اگر زمان‌ها تصادفی هستند و هم‌زمان Packet Loss دیده می‌شود، کیفیت شبکه و مسیر SIP مطرح است.

نقشه سریع تشخیص از روی زمان خرابی

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

SIP Registration دائمی نیست. REGISTER یک Binding موقت در Registrar می‌سازد و این Binding باید قبل از پایان مدت اعتبار Refresh شود.

در RFC 3261 نیز Registration به‌صورت Soft State تعریف شده است؛ یعنی اگر تمدید نشود، منقضی می‌شود.

Yealink برای SIP Server گزینه Expires دارد.

در مدل‌های فعلی مسیر معمول آن می‌تواند چیزی شبیه این باشد:

Account → Register → SIP Server → Server Expires

پارامتر متداول:

account.X.sip_server.Y.expires

در مستندات فعلی برخی خانواده‌های Yealink مقدار پیش‌فرض:

3600 seconds

ذکر شده است.

اما مقدار واقعی را از تلفن و پاسخ Registrar بررسی کنید؛ آن را برای همه مدل‌ها و همه PBXها ثابت فرض نکنید.

مقداری که تلفن درخواست می‌کند با مقدار نهایی Registrar یکی نیست

Yealink ممکن است در REGISTER درخواست کند:

Expires: 3600

اما Registrar می‌تواند بر اساس Policy خودش مدت دیگری انتخاب کند.

در پاسخ 200 OK به REGISTER ممکن است ببینید:

Contact: <sip:201@203.0.113.50:42015>;expires=600

یعنی Registration واقعی فقط ۶۰۰ ثانیه اعتبار دارد.

برای عیب‌یابی باید مقدار داخل پاسخ Server را ببینید، نه فقط عددی که در Web UI تلفن نوشته شده است.

با Packet Capture چرخه REGISTER را ببینید

Diagnostic تلفن را قبل از زمان خرابی فعال کنید.

در Wireshark:

sip.Method == "REGISTER"

را وارد کنید.

یک جریان سالم معمولاً چنین است:

REGISTER
↓
401 Unauthorized
↓
REGISTER + Authorization
↓
200 OK
↓
...
Renewal REGISTER
↓
200 OK

مهم است ببینید قبل از تمام‌شدن Lease، Renewal REGISTER واقعاً ارسال می‌شود یا خیر.

اگر Renewal ارسال می‌شود ولی پاسخ نمی‌گیرد

در این حالت تلفن کار خودش را انجام داده و مشکل بعد از خروج Packet از Yealink قرار دارد.

بررسی کنید:

REGISTER از LAN خارج شده است یا خیر.

Firewall آن را Drop کرده است یا نه.

PBX آن را دریافت کرده است یا خیر.

Server پاسخ داده است یا نه.

پاسخ Server دوباره به تلفن رسیده است یا خیر.

Register Expires Overlap در Yealink

در مدل‌های فعلی Yealink پارامتری با عنوان:

account.X.register_expires_overlap

وجود دارد.

این مقدار مشخص می‌کند Renewal چه مقدار قبل از پایان Registration Lease انجام شود.

هدف این است که تمدید دقیقاً به آخرین لحظه موکول نشود.

اما مقدار آن را بدون مشاهده REGISTER Trace تغییر ندهید.

اول ببینید Server چه Expire واقعی داده و تلفن چه زمانی Renewal را ارسال کرده است.

Expiry خیلی کوتاه همیشه بهتر نیست

گاهی برای حل NAT پیشنهاد می‌شود Server Expires را روی ۳۰ یا ۶۰ ثانیه قرار دهید.

این کار تعداد REGISTERها را شدیداً افزایش می‌دهد و علت واقعی NAT را پنهان می‌کند.

Yealink نیز در مستندات جدید خود اشاره می‌کند Registration Expiry بسیار کوتاه باعث Refreshهای مکرر می‌شود و مقدارهای بزرگ‌تری مثل ۳۶۰۰ ثانیه در شرایط عادی رایج‌تر هستند.

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

اگر Yealink پشت Router قرار دارد، SIP UDP معمولاً از NAT عبور می‌کند.

مثلاً تلفن از:

192.168.10.50:5060

REGISTER می‌فرستد.

Router آن را به چیزی شبیه این تبدیل می‌کند:

185.10.20.30:43218

PBX این Public IP و Port را می‌بیند.

اگر NAT Mapping حذف شود و Server هنوز Packet را به Port قبلی بفرستد، ارتباط Signaling می‌تواند موقتاً خراب شود.

Keep Alive برای همین سناریو است

Yealink می‌تواند Keep Alive ارسال کند تا Port مربوط به NAT باز بماند.

در مدل‌های فعلی مسیر معمول:

Account → Advanced
→ Keep Alive Type
→ Keep Alive Interval

پارامترهای متداول:

account.X.nat.udp_update_enable
account.X.nat.udp_update_time

Yealink در مستندات فعلی مقدار پیش‌فرض Keep Alive Interval را در بسیاری از تلفن‌ها:

30 seconds

ذکر می‌کند.

Keep Alive را تصادفی کم نکنید

هدف این است که Keep Alive کمی زودتر از NAT Mapping Timeout ارسال شود.

اگر Mapping روتر برای مثال چند دقیقه زنده می‌ماند، ارسال Packet هر یک ثانیه ضرورتی ندارد.

اول Timeout واقعی را اندازه‌گیری کنید.

Restart چگونه مشکل NAT را موقتاً حل می‌کند؟

Restart باعث ایجاد REGISTER تازه می‌شود.

در نتیجه Router نیز NAT Mapping جدیدی می‌سازد:

Phone Restart
↓
REGISTER
↓
New NAT Mapping
↓
PBX learns new source
↓
Registered

اگر چند دقیقه یا چند ساعت بعد Mapping دوباره منقضی شود، مشکل بازمی‌گردد.

این دقیقاً یکی از دلایلی است که Restart می‌تواند به‌ظاهر «درمان» باشد.

Rport را هم بررسی کنید

Yealink از Rport برای NAT Traversal پشتیبانی می‌کند.

Rport به Server اجازه می‌دهد پاسخ SIP را به Source IP و Source Port واقعی درخواست برگرداند.

در رابط وب:

Account → Advanced → RPort

قرار دارد.

اگر PBX یا Provider استفاده از Rport را توصیه می‌کند، رفتار Via و پاسخ REGISTER را در PCAP بررسی کنید.

در پاسخ SIP دنبال received و rport باشید

Via ممکن است شبیه این باشد:

Via: SIP/2.0/UDP 192.168.10.50:5060;rport

Server می‌تواند پاسخ را با اطلاعاتی مانند:

received=185.10.20.30
rport=43218

برگرداند.

این اطلاعات نشان می‌دهد PBX تلفن را از چه Public IP و Portی دیده است.

اگر rport بین REGISTERها تغییر می‌کند

تغییر Source Port می‌تواند نشان دهد NAT Mapping جدید ساخته شده است.

مثلاً:

REGISTER 1:
185.10.20.30:43218

REGISTER 2:
185.10.20.30:51742

خود تغییر Port الزاماً خطا نیست، اما اگر PBX همچنان Contact قدیمی را نگه دارد یا Firewall State با Mapping جدید هماهنگ نشود، Registration ناپایدار می‌شود.

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

اگر Router، SBC یا Firewall شما Linux است، Netfilter Connection Tracking می‌تواند روی UDP Sessionها Timeout اعمال کند.

مقادیر فعلی را فقط بخوانید:

sysctl net.netfilter.nf_conntrack_udp_timeout

sysctl net.netfilter.nf_conntrack_udp_timeout_stream

در Kernel فعلی Linux مقادیر پیش‌فرض مستندشده عبارت‌اند از:

nf_conntrack_udp_timeout = 30
nf_conntrack_udp_timeout_stream = 120

این اعداد را به همه Routerها تعمیم ندهید؛ Firewall Applianceها و Vendorهای مختلف Policy متفاوت دارند.

چرا عدد ۳۰ ثانیه Conntrack مهم است؟

فرض کنید Yealink از UDP استفاده می‌کند و Keep Alive خاموش است.

اگر Firewall یک UDP Flow غیرفعال را بعد از ۳۰ ثانیه حذف کند، Packet بعدی ممکن است Mapping تازه‌ای ایجاد کند.

اگر Server هنوز اطلاعات قبلی را دارد، Signaling می‌تواند تا REGISTER بعدی ناپایدار شود.

قبل از تغییر Conntrack مقدار فعلی را ذخیره کنید

اگر تصمیم دارید برای تست روی یک Firewall لینوکسی Timeout را تغییر دهید، ابتدا مقدارها را ثبت کنید:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream

تغییر این مقادیر روی تمام ترافیک UDP آن Host اثر می‌گذارد.

بنابراین روی Firewall عملیاتی بدون Maintenance Window و Rollback Plan مقدارها را تغییر ندهید.

در بسیاری از مواقع اصلاح Keep Alive بهتر از افزایش کورکورانه Timeout است

اگر فقط SIP Endpointهای پشت NAT مشکل دارند، ممکن است تنظیم درست Keep Alive و Rport راه‌حل تمیزتری باشد.

افزایش Conntrack Timeout به مقدار بسیار بالا می‌تواند تعداد Entryهای زنده را افزایش دهد.

پس ابتدا علت را با Capture ثابت کنید.

مرحله چهارم: DHCP Lease را با زمان قطعی مقایسه کنید

اگر Yealink IP خودش را با DHCP می‌گیرد، خرابی DHCP یا تغییر IP می‌تواند ارتباط SIP را مختل کند.

به‌خصوص بررسی کنید آیا قطع رجیستر تقریباً هم‌زمان با Renew یا Rebind اتفاق می‌افتد.

در PCAP:

dhcp

را فیلتر کنید.

به دنبال:

DHCP Request
DHCP ACK
DHCP NAK
DHCP Discover

باشید.

اگر تلفن وسط روز DHCP Discover جدید می‌فرستد

این می‌تواند نشانه‌ای باشد که Lease قبلی از دست رفته یا Interface شبکه دوباره بالا آمده است.

بررسی کنید:

DHCP Server در دسترس است.

Address Pool پر نشده است.

IP Conflict ندارید.

Voice VLAN تغییر نکرده است.

Switch Port Link Flap ندارد.

802.1X دوباره Authentication نمی‌شود.

IP Conflict می‌تواند شبیه مشکل SIP دیده شود

اگر دو دستگاه از یک IP استفاده کنند، ممکن است تلفن بعضی لحظات شبکه داشته باشد و بعضی لحظات Packetها به MAC دیگری برسند.

در این شرایط Restart نیز ممکن است موقتاً مشکل را تغییر دهد.

ARP Table روی Gateway یا Switch را بررسی کنید و مطمئن شوید IP Yealink مرتب بین دو MAC جابه‌جا نمی‌شود.

برای تلفن‌های ثابت بهتر است DHCP Reservation داشته باشیم؟

در بسیاری از شبکه‌های VoIP، استفاده از DHCP همراه Reservation مدیریت را ساده‌تر می‌کند.

تلفن همچنان Gateway، DNS، NTP و Optionهای موردنیاز را از DHCP می‌گیرد اما IP آن قابل پیش‌بینی باقی می‌ماند.

این الزام SIP نیست، اما برای عیب‌یابی و مدیریت چند ده تلفن مفید است.

مرحله پنجم: DNS را فقط هنگام راه‌اندازی بررسی نکنید

اگر SIP Server به‌صورت Domain تنظیم شده است:

sip.example.com

DNS بخشی از Registration است.

Yealink در مستندات عیب‌یابی Registration نیز DNS Resolver Failure را یکی از علت‌های Register نشدن می‌داند.

مشکل DNS می‌تواند دوره‌ای باشد؛ برای مثال Primary DNS بعضی ساعات پاسخ ندهد یا یک Record به IP اشتباه برگردد.

در زمان سالم و خراب DNS را مقایسه کنید

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

dig A sip.example.com

اگر از SRV استفاده می‌کنید:

dig SRV _sip._udp.example.com

dig SRV _sip._tcp.example.com

برای NAPTR:

dig NAPTR example.com

دامنه‌ها را با مقادیر واقعی سرویس خود جایگزین کنید.

Yealink می‌تواند از NAPTR و SRV استفاده کند

در حالت DNS-NAPTR، تلفن می‌تواند NAPTR، SRV و سپس A Query انجام دهد تا Transport، Port و IP SIP Server را پیدا کند.

اگر یکی از این Recordها دوره‌ای یا ناسازگار باشد، یک Endpoint ممکن است بین Serverهای مختلف جابه‌جا شود.

در PCAP زمان خرابی فیلتر:

dns

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

اگر DNS Resolver Fail در Syslog دیده می‌شود

Yealink در راهنمای رسمی Registration نمونه‌ای شبیه:

DNS resolver fail
unknown destination

را به خرابی Resolution نسبت می‌دهد.

در این حالت:

DNS دریافتی از DHCP را بررسی کنید.

Primary و Secondary DNS را مقایسه کنید.

Domain واقعی SIP Server را بررسی کنید.

و Packet Capture بگیرید تا معلوم شود Query فرستاده شده و چه پاسخی گرفته است.

اگر مشکل DNS در سمت سرور لینوکسی هم وجود دارد، راهنمای رفع مشکل DNS و systemd-resolved در Ubuntu می‌تواند برای بررسی Resolver سمت سرور مفید باشد.

مرحله ششم: Packet Loss را از Registration Failure جدا نکنید

SIP UDP تحویل Packet را تضمین نمی‌کند.

اگر مسیر شبکه Packet Loss یا Jitter شدید داشته باشد، Renewal REGISTER یا پاسخ 200 OK ممکن است گم شود.

در حالت دوره‌ای این مسئله مهم‌تر است؛ چون تلفن ممکن است ساعت‌ها سالم باشد و فقط هنگام یک Burst کوتاه از Packet Loss، Renewal از بین برود.

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

یک Ping پنج‌ثانیه‌ای در زمانی که تلفن سالم است، چیزی درباره ساعت خرابی ثابت نمی‌کند.

بهتر است Monitoring را در بازه طولانی‌تر انجام دهید.

روی Linux:

ping -D sip.example.com

یا در صورت نصب mtr:

mtr sip.example.com

اما نتیجه ICMP را معادل SIP ندانید. ممکن است ICMP محدود شود ولی SIP سالم باشد یا برعکس.

Packet Capture خود SIP معیار اصلی است.

سه Capture بهترین نتیجه را می‌دهند

اگر امکان دارید هم‌زمان Capture بگیرید:

1. روی Yealink
2. روی Firewall / Router
3. روی PBX

با این روش Renewal REGISTER را از ابتدا تا انتها دنبال می‌کنید.

مثلاً:

Yealink:
REGISTER ارسال شد

Firewall WAN:
REGISTER دیده شد

PBX:
REGISTER دیده نشد

حالا محدوده مشکل بین Firewall و PBX است.

سناریوی دیگر

Yealink:
REGISTER ارسال شد

PBX:
REGISTER دریافت شد
200 OK ارسال شد

Yealink:
200 OK دریافت نشد

در این حالت مسیر برگشت، NAT، Firewall State یا Source Port را بررسی کنید.

مرحله هفتم: PBX Contact را در زمان خرابی بررسی کنید

اگر از Asterisk PJSIP استفاده می‌کنید:

pjsip show endpoints

و برای مشاهده Contactها:

pjsip show contacts

را اجرا کنید.

در لحظه‌ای که تلفن سالم است و لحظه‌ای که Register Failed شده، خروجی را مقایسه کنید.

چه اطلاعاتی مهم است؟

به این موارد توجه کنید:

Contact URI
Status
Expiration
Source IP
Source Port
RTT
User-Agent

Asterisk در PJSIP اطلاعاتی مانند Expiration Time، Via Address، Via Port، RTT و Contact Status را برای Contact نگه می‌دارد.

اگر Contact ناگهان Unavailable می‌شود

این وضعیت با «Registration Expired» دقیقاً یکسان نیست.

Asterisk می‌تواند با Qualify و SIP OPTIONS Reachability Endpoint را بررسی کند.

اگر OPTIONS پاسخ نگیرد، Contact ممکن است Unavailable شود؛ در حالی که Binding Registration هنوز اطلاعات دیگری داشته باشد.

بنابراین Log را ببینید و فقط به چراغ Status اکتفا نکنید.

Qualify را در Asterisk بررسی کنید

در PJSIP پارامترهای مهم شامل:

qualify_frequency
qualify_timeout

هستند.

Asterisk از OPTIONS برای بررسی Reachability Contact استفاده می‌کند.

اگر تلفن پشت NAT است و پاسخ OPTIONS به Port منقضی‌شده می‌رود، Contact ممکن است Unavailable شود.

برای یک Endpoint تست Qualify بگیرید

از CLI وضعیت Endpoint و Contact را بررسی کنید:

pjsip show endpoint 201

pjsip show contacts

عدد ۲۰۱ را با Endpoint واقعی جایگزین کنید.

برای دیدن Signaling:

pjsip set logger on

مشکل را بازتولید کنید و بعد:

pjsip set logger off

را اجرا کنید.

403 دوره‌ای ممکن است مشکل max_contacts باشد

اگر Asterisk PJSIP دارید و Account ابتدا Register می‌شود اما بعد Registration جدید با 403 Fail می‌شود، AoR را بررسی کنید.

Asterisk در مستندات عیب‌یابی خودش اشاره می‌کند اگر Registration جدید باعث شود تعداد Contactها از:

max_contacts

بیشتر شود، Server می‌تواند 403 برگرداند.

این اتفاق زمانی مهم است که NAT Mapping تغییر کرده و Registration جدید با Contact دیگری دیده می‌شود.

remove_existing چه زمانی اهمیت دارد؟

اگر طراحی شما اجازه فقط یک Contact برای داخلی را می‌دهد و Registration جدید باید Contact قدیمی را جایگزین کند، گزینه:

remove_existing

در AoR اهمیت پیدا می‌کند.

Asterisk نیز برای Registrationهایی که ابتدا کار می‌کنند و بعد به سقف Contact می‌رسند، بررسی این گزینه را پیشنهاد می‌کند.

این مقدار را بدون درک سناریوی Multi-Device تغییر ندهید؛ اگر یک داخلی عمداً روی چند تلفن ثبت می‌شود، حذف Contact قبلی می‌تواند رفتار موردنظر را خراب کند.

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

اگر Password اشتباه، Authentication Retry زیاد یا Scanner روی همان Public IP وجود داشته باشد، سیستم امنیتی ممکن است IP را موقتاً Ban کند.

علامت مهم این است که:

REGISTER در PCAP تلفن خارج می‌شود
اما PBX هیچ پاسخ SIP نمی‌دهد

و هم‌زمان Firewall یا Ban Log نشان می‌دهد همان IP Drop شده است.

اگر Fail2Ban نصب است ابتدا نام Jail را پیدا کنید

sudo fail2ban-client status

نام Jail در سرورها یکسان نیست.

اگر مثلاً Jail مربوط به Asterisk وجود داشت:

sudo fail2ban-client status JAIL_NAME

را اجرا کنید.

به‌جای JAIL_NAME نام واقعی Jail را قرار دهید.

قبل از Unban علت Ban را پیدا کنید

اگر یک تلفن واقعاً Password اشتباه دارد، Unban کردن بدون اصلاح Credentials باعث می‌شود چند دقیقه بعد دوباره Ban شود.

ابتدا:

SIP Username.

Auth Name.

Password.

Realm.

و Log مربوط به 401/403 را بررسی کنید.

Public IP مشترک یک نکته مهم است

اگر چند تلفن پشت یک NAT هستند، همه ممکن است از یک Public IP دیده شوند.

یک دستگاه یا نرم‌افزار خراب می‌تواند باعث Ban شدن همان Public IP شود و در نتیجه چند Yealink سالم نیز هم‌زمان Registration را از دست بدهند.

اگر چند تلفن دقیقاً در یک لحظه Offline می‌شوند، این سناریو را جدی بگیرید.

مرحله نهم: Firewall ACL را بررسی کنید

Yealink در راهنمای رسمی Registration نیز توصیه می‌کند ACLهای Firewall و Router بررسی شوند.

روی Firewall لینوکسی می‌توانید Ruleها را بدون تغییر مشاهده کنید.

برای nftables:

sudo nft list ruleset

برای iptables:

sudo iptables -S

دنبال Ruleهایی باشید که SIP Server، Source IP، Port یا Rate Limit را محدود می‌کنند.

Firewall Rule را هنگام عیب‌یابی کورکورانه پاک نکنید

اگر Rule امنیتی باعث مشکل شده، اول مشخص کنید چرا ایجاد شده است.

حذف یک Rule ممکن است SIP Server را در معرض Scan و Brute Force قرار دهد.

اصلاح Source Range، Rate Limit یا NAT Rule باید کنترل‌شده و با نسخه پشتیبان Configuration انجام شود.

مرحله دهم: Transport را با الگوی مشکل مقایسه کنید

رفتار UDP، TCP و TLS یکسان نیست.

در UDP بیشتر با NAT Mapping و Conntrack سروکار داریم.

در TCP و TLS Connection State اهمیت بیشتری دارد.

اگر مشکل فقط روی UDP دیده می‌شود اما همان Account روی TCP یا TLS پایدار است، NAT/UDP یکی از مظنون‌های مهم می‌شود.

اما تغییر Transport را راه‌حل قطعی تلقی نکنید؛ از آن به‌عنوان تست مقایسه‌ای استفاده کنید.

اگر TCP یا TLS هر چند ساعت Disconnect می‌شود

در PCAP بررسی کنید:

TCP FIN
TCP RST
Retransmission
TLS Alert

را می‌بینید یا خیر.

اگر Connection توسط Firewall یا Server بسته می‌شود، مشکل متفاوت از UDP NAT Timeout است.

DNS، NAT و Expiry را هم‌زمان قاطی نکنید

برای عیب‌یابی منظم هر بار یک فرضیه را با Evidence بررسی کنید.

مثلاً اگر تلفن در زمان خرابی Renewal REGISTER را می‌فرستد و PBX آن را دریافت می‌کند، DNS و مسیر خروج تلفن تا PBX تا حد زیادی کار کرده‌اند.

اگر PBX 200 OK می‌دهد ولی تلفن آن را نمی‌بیند، تمرکز روی مسیر برگشت و NAT منطقی‌تر است.

یک Timeline کامل چه شکلی است؟

13:00:00
REGISTER

13:00:01
401 Unauthorized

13:00:01
REGISTER + Authorization

13:00:01
200 OK
expires=3600

13:59:20
Renewal REGISTER

13:59:20
No response

13:59:24
REGISTER Retry

13:59:24
No response

14:00:01
Registration expires

14:00:05
Account = Register Failed

این Trace می‌گوید مشکل Authentication اولیه نیست؛ مشکل در لحظه Renewal رخ داده است.

حالا Capture سمت PBX تعیین‌کننده است

اگر Renewal روی PBX دیده نشده:

Phone / NAT / Firewall / Route

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

اگر دیده شده و Server پاسخ داده:

Return Path / NAT / Firewall

مهم می‌شود.

اگر Server 403 داده:

Authentication / Ban / max_contacts / Server Policy

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

اگر مشکل دقیقاً هم‌زمان روی همه تلفن‌ها رخ می‌دهد

احتمال خرابی تک‌تک Yealinkها پایین است.

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

PBX
Firewall
Internet
SBC
DNS
DHCP
Voice VLAN
Switch
Public IP
Fail2Ban
Provider

یک مشکل مشترک معمولاً اثر هم‌زمان ایجاد می‌کند.

اگر فقط یک تلفن مشکل دارد

آن تلفن را با یک دستگاه سالم مقایسه کنید.

موارد مهم:

Model
Firmware
Account Settings
Expires
Keep Alive
RPort
IP Address
DNS
VLAN
Switch Port
Provisioning Config

حتی می‌توانید Port شبکه دو تلفن را موقتاً در یک Maintenance کنترل‌شده جابه‌جا کنید.

اگر مشکل همراه تلفن جابه‌جا شد، Endpoint مشکوک‌تر است.

اگر مشکل روی همان Switch Port باقی ماند، شبکه را بررسی کنید.

اگر فقط تلفن‌های یک شعبه مشکل دارند

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

Router شعبه.

NAT Timeout.

SIP ALG.

Public IP.

DHCP.

DNS.

Packet Loss مسیر WAN.

این سناریو برای شناسایی NAT Mapping بسیار مفید است.

اگر رجیستر فقط شب‌ها قطع می‌شود

Jobهای زمان‌بندی‌شده را بررسی کنید.

ممکن است در ساعت مشخص:

WAN دوباره Connect شود.

Public IP تغییر کند.

Router Reboot شود.

Firewall Policy Reload شود.

Backup ترافیک شبکه را اشباع کند.

DHCP Service Restart شود.

Correlation زمانی در این نوع مشکل بسیار ارزشمند است.

چک‌لیست عملی عیب‌یابی قطع رجیستر Yealink

چه زمانی باید Diagnostic کامل Yealink بگیریم؟

برای Intermittent Registration گرفتن Diagnostic فقط بعد از خرابی کافی نیست.

Capture باید قبل از رخداد شروع شود.

Yealink برای مشکلات Registration که با بررسی‌های معمول حل نمی‌شوند، جمع‌آوری این موارد را توصیه می‌کند:

PCAP
Level 6 Syslog
config.bin

ترتیب مناسب:

Start Diagnostic
↓
صبر تا Registration قطع شود
↓
حداقل یک Retry ثبت شود
↓
Stop
↓
Export

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

register
registration
DNS
SUA
timeout
network
TLS
401
403
408
500
503

Timestamp Syslog را با PCAP، PBX Log و Firewall Log یکسان کنید.

این کار معمولاً دقیق‌ترین روش برای پیدا کردن نقطه شکست است.

پرسش‌های متداول درباره قطع رجیستر Yealink

چرا رجیستر Yealink در طول روز قطع و دوباره وصل می‌شود؟

علت می‌تواند Renewal ناموفق Registration، NAT Mapping منقضی‌شده، DHCP، DNS، Packet Loss، محدودیت PBX، سیستم Ban یا Firewall Conntrack باشد. زمان دقیق خرابی و Packet Capture مشخص می‌کند کدام عامل واقعی است.

چرا Restart تلفن مشکل را موقتاً حل می‌کند؟

Restart باعث ساخت دوباره Interface شبکه، DHCP، DNS، NAT Mapping و SIP Registration می‌شود. بنابراین بسیاری از مشکلات State موقتاً پاک می‌شوند اما اگر علت اصلی باقی باشد مشکل دوباره برمی‌گردد.

Server Expires در Yealink چیست؟

مدتی است که تلفن برای اعتبار Registration درخواست می‌کند. Registrar می‌تواند بر اساس Policy خودش مقدار واقعی دیگری برگرداند؛ بنابراین پاسخ 200 OK به REGISTER باید بررسی شود.

Keep Alive چه ارتباطی با قطع رجیستر دارد؟

Keep Alive می‌تواند NAT Mapping را فعال نگه دارد تا Server همچنان بتواند پاسخ‌های SIP را به IP و Port صحیح تلفن برگرداند. Interval آن باید با رفتار NAT شبکه هماهنگ باشد.

آیا DHCP Lease می‌تواند رجیستر را قطع کند؟

اگر هنگام Renew ارتباط شبکه قطع شود، IP عوض شود، DHCP NAK دریافت شود یا IP Conflict وجود داشته باشد، Registration نیز می‌تواند از بین برود. DHCP Packetها را در زمان خرابی بررسی کنید.

چطور بفهمیم Fail2Ban تلفن را Block کرده است؟

اگر REGISTER از تلفن خارج می‌شود اما PBX هیچ پاسخ SIP نمی‌دهد، وضعیت Jailهای Fail2Ban و Firewall Log را بررسی کنید. قبل از Unban ابتدا علت Authentication Failure را اصلاح کنید.

Conntrack چه ارتباطی با SIP UDP دارد؟

Firewallهای Stateful برای UDP Entryهای موقت نگه می‌دارند. اگر Timeout از فاصله Keep Alive کوتاه‌تر باشد، Mapping یا State می‌تواند قبل از Packet بعدی حذف شود و مسیر پاسخ SIP ناپایدار شود.

اگر همه تلفن‌ها هم‌زمان رجیستر را از دست بدهند مشکل از Yealink است؟

احتمال مشکل مشترک بیشتر است. PBX، Firewall، DNS، DHCP، Voice VLAN، WAN، Public IP و سیستم‌های امنیتی را قبل از بررسی جداگانه ده‌ها تلفن کنترل کنید.

برای تشخیص دقیق قطع رجیستر چه فایل‌هایی لازم است؟

PCAP و Syslog سطح 6 Yealink را همراه با PBX SIP Log و در صورت امکان Firewall Log در همان بازه زمانی جمع‌آوری کنید. مهم‌ترین نکته ثبت لحظه‌ای است که Registration از حالت سالم به خراب تغییر می‌کند.

جمع‌بندی

قطع و وصل شدن رجیستر Yealink در طول روز را با Restartهای مکرر دنبال نکنید. Restart فقط State شبکه و SIP را از نو می‌سازد و می‌تواند علت اصلی را برای مدتی پنهان کند.

اول زمان دقیق خرابی را ثبت کنید و آن را با Registration Expiry، Renewal REGISTER، NAT Keep Alive، DHCP Lease و DNS مقایسه کنید. سپس Packet Capture را در دو سمت تلفن و PBX بررسی کنید تا معلوم شود Renewal کجا از بین می‌رود.

اگر REGISTER به PBX می‌رسد، پاسخ Server و وضعیت Contact را بررسی کنید. اگر 403 می‌گیرید، max_contacts، Authentication و سیستم‌های Ban را ببینید. اگر Packet از Yealink خارج می‌شود اما به Server نمی‌رسد، NAT، Firewall و Conntrack اهمیت پیدا می‌کنند. با این روش مشکل «هر چند ساعت یک بار رجیستر قطع می‌شود» از یک خطای مبهم به یک Timeline قابل اندازه‌گیری تبدیل می‌شود.