Amir Jabbari
در این آموزش مسیر عیب‌یابی را به همان ترتیبی پیش می‌بریم که بسته SIP طی می‌کند: ابتدا IP و شبکه تلفن، سپس DNS، آدرس و پورت SIP Server، نوع ارتباط UDP/TCP/TLS، پاسخ‌های 401 و 403 و 408، NAT و Rport، گواهی TLS و در نهایت PCAP و مقایسه با Softphone. هدف این است که در پایان بتوانید مشخص کنید مشکل دقیقاً در تلفن، شبکه، DNS، فایروال یا سمت سرور VoIP قرار دارد.
رجیستر SIP در تلفن Yealink چگونه کار می‌کند؟
تلفن برای رجیسترشدن باید ابتدا بداند SIP Server کجاست. اگر سرور به‌صورت IP وارد شده باشد، مستقیماً به همان مقصد متصل می‌شود. اگر نام دامنه وارد شده باشد، تلفن باید آن را با DNS به مقصد قابل دسترسی تبدیل کند.
در حالت DNS-NAPTR، تلفن می‌تواند از رکوردهای NAPTR و SRV برای پیدا کردن Transport، پورت و سرور مناسب استفاده کند. مستندات Yealink نیز برای Transport گزینه‌های UDP، TCP، TLS و DNS-NAPTR را در نظر گرفته است.
بعد از پیدا کردن مقصد، REGISTER ارسال می‌شود. اگر احراز هویت لازم باشد، سرور معمولاً 401 می‌دهد و تلفن درخواست دوم را با Authorization ارسال می‌کند. بعد از قبول درخواست، رجیستر با 200 OK تکمیل می‌شود.
نقشه سریع تشخیص مشکل
| چیزی که می‌بینید | احتمال قوی‌تر | قدم بعدی |
|---|---|---|
| تلفن IP ندارد | DHCP، VLAN، کابل یا پورت شبکه | ابتدا شبکه محلی را درست کنید |
| نام SIP Server حل نمی‌شود | DNS | A / SRV / NAPTR را بررسی کنید |
| REGISTER از تلفن خارج نمی‌شود | DNS، تنظیم حساب، Transport یا TLS | Syslog و تنظیمات Account را ببینید |
| REGISTER خارج می‌شود اما پاسخی نیست | مسیر شبکه، ACL، فایروال، پورت یا سرور | PCAP دو سمت و مسیر شبکه را مقایسه کنید |
| 401 سپس 200 OK | رفتار طبیعی احراز هویت | مشکلی وجود ندارد |
| 401 پشت سر هم | نام کاربری، Auth Name، رمز یا ناسازگاری احراز هویت | REGISTER دوم و Authorization را بررسی کنید |
| 403 Forbidden | ردشدن حساب از سمت سرور | رمز، قفل حساب، ACL و محدودیت User-Agent را بررسی کنید |
| 408 Request Timeout | Timeout در مسیر یا سرور | مقصد، فایروال، NAT و پاسخ سرور را بررسی کنید |
| TLS Handshake شکست می‌خورد | CA، تاریخ تلفن، CN/SAN یا نسخه TLS | گواهی و ساعت تلفن را بررسی کنید |
مرحله اول: مطمئن شوید خود تلفن شبکه دارد
روی بسیاری از تلفن‌های Yealink با فشردن کلید OK می‌توانید اطلاعات شبکه را ببینید. اولین چیزی که باید بررسی شود این است که تلفن واقعاً IP، Gateway و DNS Server گرفته باشد.
اگر IP به شکل 0.0.0.0 است یا تلفن IP معتبر شبکه شما را ندارد، هنوز وارد عیب‌یابی SIP نشوید. در این حالت مشکل قبل از SIP قرار دارد.
کابل، پورت سوئیچ، DHCP، Voice VLAN و تنظیم VLAN تلفن را بررسی کنید. اگر تلفن از PoE روشن می‌شود، روشن‌شدن آن به معنی درست‌بودن VLAN یا دریافت IP نیست.
مرحله دوم: اطلاعات حساب SIP را دوباره تطبیق دهید
در رابط وب تلفن وارد تنظیمات Account شوید. نام منو در مدل‌ها و نسخه‌های مختلف Firmware ممکن است کمی فرق داشته باشد، اما اطلاعات اصلی مشابه هستند.
Register Name یا نام رجیستر همان شناسه‌ای است که Registrar برای ثبت حساب انتظار دارد.
User Name ممکن است با Register Name یکی باشد یا نباشد.
Password رمز SIP است؛ لزوماً همان رمز پنل PBX یا رابط وب تلفن نیست.
Server Host باید IP یا نام دامنه Registrar صحیح باشد.
Port باید با پورت واقعی سرویس هماهنگ باشد.
Transport باید با چیزی که سرور ارائه می‌دهد یکسان باشد؛ UDP، TCP، TLS یا DNS-NAPTR.
اگر Outbound Proxy در سناریوی شما لازم نیست، آن را تصادفی فعال نکنید. اگر ارائه‌دهنده VoIP یا PBX مشخصاً Outbound Proxy داده است، آدرس و پورت آن را دقیق وارد کنید.
مرحله سوم: DNS را قبل از دست‌زدن به رمز و NAT بررسی کنید
اگر SIP Server را به شکل دامنه وارد کرده‌اید، خرابی DNS می‌تواند باعث شود تلفن حتی یک REGISTER هم ارسال نکند. Yealink در راهنمای رسمی خود خطای DNS resolver fail, unknown destination را یکی از علل مستقیم Register Failed معرفی می‌کند.
برای تست، از یک کامپیوتر در همان شبکه تلفن استفاده کنید.
تست A Record در ویندوز
nslookup sip.example.comبه‌جای sip.example.com دامنه واقعی SIP Server را قرار دهید. باید یک IP معتبر دریافت کنید.
تست A Record در لینوکس
dig A sip.example.com +shortاگر هیچ IP برنمی‌گردد، قبل از هر تغییر SIP باید DNS اصلاح شود.
چه زمانی SRV و NAPTR مهم می‌شوند؟
SIP فقط به A Record محدود نیست. استاندارد SIP می‌تواند با NAPTR و SRV مشخص کند چه Transport و چه پورت و چه سروری باید استفاده شود.
Yealink در حالت DNS-NAPTR می‌تواند در صورتی که پورت مشخص نشده باشد، NAPTR و SRV را برای پیدا کردن سرویس انجام دهد.
تست SRV برای UDP
nslookup -type=SRV _sip._udp.example.comتست SRV برای TCP
nslookup -type=SRV _sip._tcp.example.comتست SRV برای TLS
nslookup -type=SRV _sips._tcp.example.comتست NAPTR
nslookup -type=NAPTR example.comدر لینوکس می‌توانید همین بررسی را با dig SRV و dig NAPTR انجام دهید.
dig SRV _sip._udp.example.com
dig SRV _sip._tcp.example.com
dig SRV _sips._tcp.example.com
dig NAPTR example.comاگر PBX شما روی Ubuntu قرار دارد و مشکل DNS در خود سرور دیده می‌شود، آموزش رفع مشکلات DNS و systemd-resolved در Ubuntu نیز می‌تواند برای بررسی سمت سرور مفید باشد.
مرحله چهارم: UDP، TCP و TLS را با حدس عوض نکنید
Yealink سه Transport اصلی UDP، TCP و TLS را برای SIP پشتیبانی می‌کند. DNS-NAPTR نیز می‌تواند انتخاب Transport را بر اساس DNS انجام دهد.
پورت رایج SIP روی UDP و TCP برابر 5060 و پورت رایج TLS برابر 5061 است، اما این‌ها فقط مقادیر متداول هستند. PBX یا سرویس‌دهنده می‌تواند پورت دیگری تعیین کرده باشد.
اگر سرور فقط TLS روی 5061 گوش می‌دهد و تلفن روی UDP 5060 تنظیم شده، تغییر رمز عبور هیچ مشکلی را حل نمی‌کند.
تست TCP از ویندوز
Test-NetConnection sip.example.com -Port 5060تست TLS Port از ویندوز
Test-NetConnection sip.example.com -Port 5061این تست فقط برقراری TCP را بررسی می‌کند و ثابت نمی‌کند SIP یا TLS به‌طور کامل صحیح است.
تست TCP از لینوکس
nc -vz sip.example.com 5060تست TLS واقعی‌تر
openssl s_client -connect sip.example.com:5061 -servername sip.example.com -showcertsدر خروجی OpenSSL به زنجیره گواهی، تاریخ اعتبار و خطاهای Verify توجه کنید.
401 Unauthorized همیشه نشانه خرابی نیست
این یکی از مهم‌ترین اشتباه‌ها در عیب‌یابی SIP است. طبق RFC 3261، پاسخ 401 Unauthorized یعنی سرور از کلاینت احراز هویت می‌خواهد.
جریان سالم می‌تواند به این شکل باشد:
Yealink → REGISTER
Server → 401 Unauthorized
Yealink → REGISTER + Authorization
Server → 200 OKبنابراین اگر در Wireshark یک 401 می‌بینید، ادامه Packetها را هم ببینید.
اگر 401 مدام تکرار می‌شود چه کنیم؟
اگر تلفن REGISTER دوم را می‌فرستد ولی دوباره 401 دریافت می‌کند، دیگر باید روی احراز هویت تمرکز کنید.
Register Name، User Name و Auth Name را با تنظیمات PBX مقایسه کنید. در بعضی سیستم‌ها این سه مقدار یکسان‌اند و در بعضی دیگر Auth Name متفاوت است.
رمز SIP را دوباره وارد کنید؛ مخصوصاً اگر از Copy/Paste استفاده شده، وجود Space ابتدا یا انتهای مقدار را در نظر بگیرید.
Realm و تنظیمات احراز هویت سمت سرور را نیز بررسی کنید.
Yealink همچنین یک حالت خاص 401 را مستند کرده که بعضی پارامترهای Challenge در نسخه‌های قدیمی Firmware باعث رجیستر مجدد بدون اطلاعات صحیح Authentication می‌شدند؛ برای همین در چنین مواردی Firmware رسمی جدید نیز باید بررسی شود.
403 Forbidden چه می‌گوید؟
403 Forbidden با 401 فرق دارد. در 403 سرور درخواست را فهمیده اما آن را رد کرده است.
طبق راهنمای رسمی Yealink، از علل رایج می‌توان به رمز اشتباه، قفل‌بودن حساب و محدودیت‌های سمت سرور مانند User-Agent یا Domain اشاره کرد.
ACL سمت PBX را بررسی کنید. ممکن است رجیستر فقط از IP مشخصی مجاز باشد.
بررسی کنید یک داخلی هم‌زمان روی دستگاه دیگری رجیستر نشده باشد؛ بعضی سیستم‌ها چند Registration هم‌زمان برای یک حساب را محدود می‌کنند.
اگر سرور MAC Address، IP یا User-Agent را Whitelist می‌کند، Yealink باید در همان سیاست مجاز باشد.
408 Request Timeout را چگونه تحلیل کنیم؟
408 Request Timeout یعنی تراکنش در زمان مناسب به پاسخ نهایی نرسیده است. در این وضعیت به‌جای تغییر رمز، روی مسیر ارتباط تمرکز کنید.
ابتدا IP مقصدی را که تلفن REGISTER را به آن می‌فرستد بررسی کنید. اگر DNS چند IP برمی‌گرداند، ممکن است تلفن به سروری برسد که سالم نیست.
سپس بررسی کنید آیا REGISTER روی PBX دیده می‌شود یا نه.
اگر در PCAP تلفن REGISTER وجود دارد ولی روی سرور اثری نیست، مشکل احتمالاً بین تلفن و سرور است: Route، ACL، فایروال، NAT یا ISP.
اگر REGISTER به سرور می‌رسد و سرور پاسخ می‌دهد اما پاسخ به تلفن برنمی‌گردد، مسیر برگشت، NAT و فایروال را بررسی کنید.
فایروال را بر اساس Transport بررسی کنید
برای UDP باید اجازه عبور UDP روی پورت SIP واقعی سرور وجود داشته باشد. برای TCP و TLS باید همان پورت در TCP قابل دسترسی باشد.
اگر PBX پشت فایروال قرار دارد، ACL ورودی و خروجی را هر دو بررسی کنید.
اگر روی سرور IP Whitelist دارید، Public IP شبکه‌ای که تلفن پشت آن قرار دارد باید مطابق سیاست شما مجاز باشد.
همچنین توجه کنید که SIP Signaling و RTP دو موضوع متفاوت هستند. ممکن است رجیستر کاملاً موفق باشد ولی صدا قطع یا یک‌طرفه باشد؛ آن مشکل دیگر در مسیر RTP بررسی می‌شود، نه Registration.
NAT و Rport چه نقشی دارند؟
اگر تلفن در یک شبکه خصوصی قرار دارد و PBX در اینترنت است، NAT وارد مسیر می‌شود.
Yealink قابلیت Rport دارد. Rport به کلاینت اجازه می‌دهد از سرور بخواهد پاسخ SIP را به IP و پورتی برگرداند که درخواست واقعاً از آن رسیده است. این قابلیت به‌خصوص در بعضی سناریوهای NAT متقارن مفید است.
در رابط وب بسیاری از مدل‌ها می‌توانید Rport را از مسیر زیر پیدا کنید:
Account → Advanced → RPortاما Rport باید با رفتار SIP Server سازگار باشد. آن را صرفاً به‌عنوان یک کلید جادویی روشن نکنید.
Yealink همچنین بسته به مدل از روش‌هایی مانند STUN و Manual NAT برای NAT Traversal پشتیبانی می‌کند.
بهترین تست NAT: همان تلفن را روی یک اینترنت دیگر امتحان کنید
اگر امکان دارید، تلفن را موقتاً به یک شبکه مستقل مانند اینترنت دیگر یا Hotspot متصل کنید.
اگر بدون هیچ تغییر حساب روی شبکه دوم رجیستر شد، احتمال مشکل در روتر، DNS، فایروال یا NAT شبکه اول بسیار بیشتر می‌شود.
اگر روی هر دو شبکه همان خطا باقی ماند، دوباره به تنظیم Account، Server و Authentication برگردید.
TLS؛ وقتی TCP وصل است ولی Yealink رجیستر نمی‌شود
ممکن است پورت 5061 باز باشد اما TLS Handshake کامل نشود. در این حالت TCP Connectivity سالم است ولی لایه TLS مشکل دارد.
Yealink چند خطای مهم برای این وضعیت مستند کرده است.
certificate not trusted یعنی تلفن نمی‌تواند زنجیره گواهی سرور را با CAهای مورد اعتماد خود تأیید کند.
certificate is not yet valid می‌تواند ناشی از تاریخ و ساعت اشتباه تلفن یا واقعاً نامعتبر بودن گواهی باشد.
connect SSL Verify host به خطای اعتبارسنجی نام میزبان اشاره می‌کند؛ یعنی نامی که تلفن به آن متصل شده با هویت گواهی هماهنگ نیست.
برای TLS ابتدا ساعت تلفن را بررسی کنید
اگر تاریخ تلفن اشتباه باشد، یک گواهی کاملاً سالم هم می‌تواند نامعتبر تشخیص داده شود.
NTP Server، Time Zone و تاریخ نمایش‌داده‌شده روی تلفن را بررسی کنید.
سپس نام SIP Server را با نام موجود در Certificate مقایسه کنید. اگر گواهی برای sip.example.com صادر شده ولی تلفن با IP یا نام دیگری متصل می‌شود، ممکن است Host Verification شکست بخورد.
CA Certificate را به‌جای خاموش‌کردن امنیت درست کنید
Yealink اجازه واردکردن Trusted Certificate را می‌دهد. اگر CA مورد استفاده سرور در فهرست داخلی تلفن نیست، CA صحیح را وارد کنید.
در برخی راهنماهای عیب‌یابی گزینه غیرفعال‌کردن بررسی Trusted Certificate نیز ذکر شده است، اما برای محیط واقعی بهتر است علت اصلی یعنی CA، نام میزبان یا ساعت اصلاح شود. خاموش‌کردن اعتبارسنجی گواهی را به راه‌حل دائمی تبدیل نکنید.
نسخه TLS کلاینت و سرور را مقایسه کنید
مدل‌ها و Firmwareهای جدید Yealink می‌توانند نسخه‌های مختلف TLS از جمله TLS 1.2 و در بعضی مدل‌ها TLS 1.3 را پشتیبانی کنند.
اگر PBX فقط یک نسخه خاص را اجازه می‌دهد و تلفن در مذاکره TLS به توافق نمی‌رسد، رجیستر قبل از ارسال SIP شکست می‌خورد.
در این حالت OpenSSL و Syslog تلفن معمولاً اطلاعات بیشتری از یک Ping ساده می‌دهند.
مقایسه با Softphone؛ سریع‌ترین راه برای جداکردن تلفن از شبکه
Yealink در راهنمای رسمی خود پیشنهاد می‌کند فرایند Registration با یک SIP Client دیگر مانند Linphone مقایسه شود.
همان SIP Server، User Name، Auth Name، Password، Port و Transport را روی Softphone تنظیم کنید.
اگر Softphone روی همان شبکه رجیستر می‌شود ولی Yealink نمی‌شود، تمرکز را روی تنظیمات تلفن، Firmware، TLS Certificate و تفاوت Headerهای SIP قرار دهید.
اگر Softphone هم رجیستر نمی‌شود، احتمال Account، Server، DNS، فایروال یا مسیر شبکه قوی‌تر است.
اگر هر دو روی Hotspot رجیستر می‌شوند ولی روی شبکه شرکت نه، تقریباً باید شبکه شرکت را بررسی کنید.
PCAP؛ جایی که حدس‌زدن تمام می‌شود
وقتی تنظیمات ظاهراً درست هستند، Packet Capture بهترین راه برای فهمیدن این است که واقعاً چه اتفاقی می‌افتد.
Yealink در رابط وب بسیاری از تلفن‌ها امکان گرفتن فایل Diagnostic شامل PCAP، Syslog و فایل تنظیمات را دارد.
در مدل‌های رایج وارد رابط وب تلفن شوید و به مسیر زیر بروید:
Settings → Configurationبخش Export All Diagnostic Files را پیدا کنید.
Capture را Start کنید، مشکل Register Failed را دوباره ایجاد کنید، سپس Stop و Export را بزنید.
در بسیاری از Firmwareهای جدید، سطح Log هنگام Diagnostic به‌صورت خودکار روی 6 قرار می‌گیرد. در مدل‌های قدیمی‌تر ممکن است لازم باشد Module Log Level یا Syslog Level را دستی روی 6 بگذارید.
در Wireshark چه فیلترهایی بزنیم؟
برای رجیستر UDP یا TCP ابتدا این فیلتر ساده را امتحان کنید:
sipبرای دیدن REGISTERها:
sip.Method == "REGISTER"برای DNS:
dnsبرای TLS:
tcp.port == 5061یا در صورت تشخیص TLS توسط Wireshark:
tlsدر TLS محتوای SIP رمزگذاری شده است؛ بنابراین معمولاً REGISTER و Responseهای SIP را مستقیم در PCAP نمی‌بینید. در این وضعیت TCP/TLS Handshake و Syslog خود Yealink اهمیت بیشتری دارند.
سناریوی اول: هیچ REGISTER از تلفن خارج نمی‌شود
اگر PCAP هیچ REGISTERی نشان نمی‌دهد، ابتدا DNS را ببینید. شاید تلفن مقصد را پیدا نمی‌کند.
اگر DNS درست است، Account Enable، Server Host، Port و Transport را بررسی کنید.
اگر Transport روی TLS است، Syslog را برای خطای Certificate و TLS Handshake بررسی کنید.
اگر تلفن چند SIP Server دارد، بررسی کنید Primary و Secondary به شکل مورد انتظار فعال باشند.
سناریوی دوم: REGISTER خارج می‌شود ولی هیچ پاسخی برنمی‌گردد
در این حالت اطلاعات حساب هنوز متهم اول نیست. درخواست از تلفن خارج شده ولی Response ندارید.
IP مقصد را از PCAP بخوانید و مطمئن شوید همان سروری است که انتظار دارید.
PCAP یا Log سمت PBX را بررسی کنید. اگر درخواست به سرور نمی‌رسد، مسیر بین دو طرف مشکل دارد.
اگر سرور درخواست را دریافت کرده و Response ارسال کرده، بررسی کنید پاسخ در NAT یا Firewall گم نشده باشد.
سناریوی سوم: 401 پشت سر هم می‌بینیم
REGISTER اول را با REGISTER دوم مقایسه کنید.
اگر REGISTER دوم Authorization ندارد، تلفن Challenge را به شکل مورد انتظار پردازش نکرده یا ناسازگاری Firmware وجود دارد.
اگر Authorization وجود دارد ولی 401 ادامه پیدا می‌کند، Auth Name، Password، Realm و تنظیم حساب سمت PBX را بررسی کنید.
سناریوی چهارم: 403 دریافت می‌کنیم
در اینجا سرور پاسخ می‌دهد و شبکه تا Registrar سالم است. تمرکز را از DNS و Ping بردارید و روی سیاست سرور بروید.
Account Lock، رمز، Domain، ACL، IP Restriction، User-Agent Restriction و محدودیت رجیستر هم‌زمان را بررسی کنید.
سناریوی پنجم: تلفن بعد از چند دقیقه Unregistered می‌شود
اگر رجیستر اولیه موفق است ولی بعداً قطع می‌شود، Registration Expiry، NAT Mapping و Keep-Alive را بررسی کنید.
Yealink برای حساب SIP مقدار Server Expires دارد و پس از پایان زمان رجیستر دوباره ثبت را تازه می‌کند.
اگر NAT Mapping زودتر از Refresh از بین برود، Rport یا Keep-Alive مناسب می‌تواند اهمیت پیدا کند.
در این حالت PCAP باید حداقل یک چرخه کامل از زمان رجیستر موفق تا لحظه قطع را پوشش دهد.
خطاهای دیگری که در PCAP ممکن است ببینید
| کد | معنی عملی | چه چیزی بررسی شود؟ |
|---|---|---|
| 401 | درخواست احراز هویت | آیا REGISTER دوم با Authorization و سپس 200 OK می‌آید؟ |
| 403 | سرور درخواست را رد کرده است | Account، Password، ACL و سیاست سرور |
| 404 | کاربر یا Domain موردنظر پیدا نشده | User/Domain و Request-URI |
| 408 | Timeout | مسیر شبکه، سرور، NAT و Firewall |
| 420 | Bad Extension | Headerهای SIP و Proxy-Require |
| 422 | Session Interval Too Small | مقدار Interval مورد انتظار سرور |
| 5xx | خطای سمت سرور | Log PBX یا SIP Provider |
چک نهایی بدون آزمون‌وخطای تصادفی
اگر تلفن IP ندارد، مشکل را در شبکه محلی حل کنید.
اگر SIP Server دامنه است و DNS شکست می‌خورد، DNS را حل کنید.
اگر DNS درست است ولی REGISTER ارسال نمی‌شود، Transport، Account و TLS را بررسی کنید.
اگر REGISTER ارسال می‌شود ولی Response نیست، مسیر شبکه، Firewall و Server را بررسی کنید.
اگر 401 یک بار و سپس 200 OK دارید، Authentication طبیعی است.
اگر 401 تکرار می‌شود، Credential و Digest Authentication را بررسی کنید.
اگر 403 دارید، سرور درخواست را عمداً رد کرده است.
اگر TLS شکست می‌خورد، ساعت، CA، نام گواهی و نسخه TLS را بررسی کنید.
اگر هنوز نتیجه نگرفتید، PCAP و Level 6 Syslog را از همان لحظه وقوع مشکل بگیرید و با Softphone مقایسه کنید.
پرسش‌های متداول درباره رجیستر نشدن تلفن Yealink
آیا 401 Unauthorized در Yealink یعنی رمز اشتباه است؟
نه لزوماً. در SIP اولین 401 می‌تواند بخشی طبیعی از Digest Authentication باشد. مشکل زمانی است که تلفن REGISTER دوم را با Authorization ارسال نکند یا 401 بدون رسیدن به 200 OK تکرار شود.
چرا Yealink پیام No Service نشان می‌دهد؟
No Service می‌تواند نتیجه رجیستر نبودن حساب SIP باشد. ابتدا IP و شبکه، سپس Server Host، DNS، Port، Transport و پاسخ‌های SIP را بررسی کنید.
403 Forbidden در رجیستر Yealink معمولاً از چیست؟
403 یعنی سرور درخواست را فهمیده ولی آن را رد کرده است. رمز یا حساب اشتباه، قفل‌شدن داخلی، ACL، محدودیت IP، Domain یا User-Agent از مواردی هستند که باید بررسی شوند.
چرا با IP رجیستر می‌شود ولی با Domain نه؟
این وضعیت معمولاً DNS را مشکوک می‌کند. A Record و در صورت استفاده از DNS-NAPTR، رکوردهای SRV و NAPTR را از همان شبکه تلفن بررسی کنید.
چرا UDP کار می‌کند ولی TLS رجیستر نمی‌شود؟
در TLS علاوه بر دسترسی شبکه، TLS Handshake و اعتبار گواهی نیز باید موفق باشند. CA، تاریخ تلفن، Hostname گواهی، Port و نسخه TLS را بررسی کنید.
آیا روشن‌کردن Rport همیشه مشکل NAT را حل می‌کند؟
خیر. Rport در برخی سناریوهای NAT کمک می‌کند، اما رفتار SIP Server نیز باید با آن سازگار باشد. ابتدا با PCAP مشخص کنید پاسخ‌ها در چه مرحله‌ای گم می‌شوند.
برای PCAP تلفن Yealink از کجا شروع کنیم؟
در بسیاری از مدل‌ها از رابط وب به Settings → Configuration بروید، Export All Diagnostic Files را Start کنید، خطا را بازتولید کنید، سپس Stop و Export را بزنید.
اگر Softphone رجیستر می‌شود ولی Yealink نه، مشکل کجاست؟
در این وضعیت حساب و مسیر کلی شبکه تا حد زیادی تأیید می‌شوند و باید تفاوت تنظیمات تلفن، Transport، TLS، Firmware و Headerهای SIP را بررسی کنید.
جمع‌بندی
برای رفع Register Failed در Yealink، از پایین‌ترین لایه شروع کنید و فقط زمانی به مرحله بعد بروید که مرحله قبلی تأیید شده باشد. تلفن باید IP داشته باشد، DNS باید مقصد صحیح را پیدا کند، Transport و Port باید با Registrar هماهنگ باشند و REGISTER واقعاً از دستگاه خارج شود.
پس از آن پاسخ سرور تعیین می‌کند کجا جست‌وجو کنید. 401 اول می‌تواند طبیعی باشد، 403 شما را به سمت Account و سیاست سرور می‌برد و نبود Response یا 408 بیشتر مسیر شبکه، Firewall، NAT یا خود Server را مطرح می‌کند. در TLS نیز بدون بررسی Certificate و ساعت دستگاه، تغییر رمز و پورت معمولاً فقط زمان تلف می‌کند.
اگر با بررسی تنظیمات به نتیجه نرسیدید، PCAP و Syslog سطح 6 را بگیرید. از آن نقطه به بعد دیگر لازم نیست حدس بزنید؛ مشخص می‌شود REGISTER ارسال شده، کجا رفته و چه پاسخی دریافت کرده است.
برای راه‌اندازی یا عیب‌یابی سرور VoIP کمک می‌خواهید؟
اگر رجیستر SIP، فایروال، NAT، DNS یا ارتباط تلفن‌ها با سرور شما با مشکل روبه‌رو شده است، می‌توانید برای بررسی زیرساخت و انتخاب سرویس مناسب با ایرانیکاسرور در ارتباط باشید.
تماس با پشتیبانی ایرانیکاسرور
دیدگاه‌ها (۰)