تلفن یالینک روی بعضی اینترنت‌ها کار نمی‌کند؟ علت و روش رفع مشکل

نکته مهم این است که از روی عبارت «روی اینترنت اول کار می‌کند ولی روی اینترنت دوم نه» نمی‌توان مستقیم نتیجه گرفت ISP پورت SIP را بسته است. برای تشخیص درست باید فقط یک متغیر را در هر مرحله تغییر دهیم و Packetهای دو شبکه را با هم مقایسه کنیم. در پایان باید بتوانیم دقیق بگوییم تلفن در شبکه خراب تا کدام مرحله پیش می‌رود: DNS، TCP، TLS، REGISTER یا دریافت پاسخ از PBX.

در این آموزش یک روش عملی برای مقایسه دو اینترنت می‌سازیم. SIP روی UDP/TCP، TLS روی پورت پیش‌فرض 5061، DNS، CGNAT، SIP ALG، Firewall و MTU را بررسی می‌کنیم و در نهایت با Packet Capture مشخص می‌کنیم تفاوت واقعی شبکه سالم و خراب چیست.

اول ثابت کنید مشکل واقعاً به اینترنت وابسته است

قبل از تغییر تنظیمات Router باید یک تست کنترل‌شده انجام دهید.

همان تلفن را با همان موارد زیر آزمایش کنید:

همان Yealink
همان Firmware
همان SIP Account
همان SIP Server
همان Transport
همان کابل در صورت امکان
همان تنظیمات تلفن

فقط اتصال اینترنت را تغییر دهید.

برای مثال:

Network A
↓
Registered

Network B
↓
Register Failed

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

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

اگر امکان دارد تلفن را موقتاً از طریق Router یا تجهیزی که اینترنت موبایل را به Ethernet می‌دهد آزمایش کنید.

سناریو:

اینترنت شرکت
→ Register Failed

اینترنت موبایل
→ Registered

این تست ثابت نمی‌کند ISP شرکت SIP را Block کرده است، اما نشان می‌دهد مشکل احتمالاً در یکی از اجزای مسیر اینترنت شرکت قرار دارد:

Router، Firewall، DNS، NAT، ISP یا مسیر تا PBX.

ماتریس مقایسه دو شبکه بسازید

اول مشخص کنید مشکل DNS است یا SIP

اگر SIP Server به شکل Domain تنظیم شده باشد:

sip.example.com

Yealink قبل از ارسال REGISTER باید Domain را Resolve کند.

اگر DNS در اینترنت دوم متفاوت باشد، ممکن است تلفن حتی به همان SIP Server اینترنت اول متصل نشود.

در یک سیستم متصل به همان شبکه اجرا کنید:

nslookup sip.example.com

در Linux:

dig A sip.example.com +short

نتیجه دو اینترنت را با هم مقایسه کنید.

اگر IPهای DNS متفاوت هستند لزوماً مشکل ندارید

ممکن است SIP Provider چند Server داشته باشد یا از Load Balancing استفاده کند.

بنابراین هدف این نیست که IP حتماً در هر دو اینترنت یکسان باشد.

سؤال مهم این است:

آیا IP دریافتی واقعاً متعلق به SIP Provider است؟

آیا تلفن می‌تواند به آن IP وصل شود؟

آیا Server روی Port موردنظر پاسخ می‌دهد؟

SRV و NAPTR را فراموش نکنید

بعضی تنظیمات SIP فقط از A Record استفاده نمی‌کنند.

Yealink می‌تواند بسته به تنظیمات DNS از SRV یا NAPTR برای پیدا کردن Transport، Port و Server استفاده کند.

برای UDP:

dig SRV _sip._udp.example.com

برای TCP:

dig SRV _sip._tcp.example.com

و در صورت استفاده از NAPTR:

dig NAPTR example.com

نام Domain را با Domain واقعی SIP Provider جایگزین کنید.

یک DNS خراب می‌تواند فقط روی یکی از اینترنت‌ها مشکل ایجاد کند

فرض کنید اینترنت اول DNS عمومی سالم دارد اما Router اینترنت دوم DNS خودش را به تلفن می‌دهد.

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

Yealink
↓
DNS Query
↓
Router DNS Proxy
↓
Timeout
↓
SIP Server IP پیدا نمی‌شود
↓
Register Failed

در این حالت بازکردن Port 5060 هیچ تأثیری ندارد؛ مشکل قبل از SIP رخ داده است.

با Packet Capture DNS را قطعی بررسی کنید

از خود Yealink Packet Capture بگیرید.

در بسیاری از تلفن‌های Yealink:

Settings → Configuration
→ Pcap Feature → Start

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

Stop → Export

فایل را در Wireshark باز کنید و فیلتر زیر را وارد کنید:

dns

بررسی کنید:

Query ارسال شده؟
Response آمده؟
چه IPی برگشته؟
Timeout وجود دارد؟
NXDOMAIN وجود دارد؟

مرحله بعد: Destination واقعی SIP را پیدا کنید

یکی از مهم‌ترین بررسی‌ها این است که تلفن روی هر دو اینترنت REGISTER را به چه IP و Portی می‌فرستد.

در Wireshark:

sip.Method == "REGISTER"

را وارد کنید.

برای مثال شبکه سالم:

Source:
192.168.1.50:5060

Destination:
203.0.113.20:5060

شبکه خراب:

Source:
192.168.20.50:5060

Destination:
203.0.113.20:5060

اگر Destination یکسان است اما فقط یکی پاسخ نمی‌گیرد، DNS تا حد زیادی از فهرست مظنون‌ها خارج می‌شود و باید مسیر شبکه را بررسی کنیم.

پورت 5060 و 5061 دقیقاً چه هستند؟

در SIP مقادیر پیش‌فرض معمول چنین هستند:

UDP SIP:
5060

TCP SIP:
5060

TLS SIP:
5061

اما این فقط مقدار پیش‌فرض است.

SIP Provider ممکن است مثلاً از:

5080
5160
5070
یا Port اختصاصی دیگر

استفاده کند.

پس Port واقعی Account را از تنظیمات PBX یا Provider بررسی کنید.

TCP را با ابزار مناسب تست کنید

اگر Transport روی TCP است، در Windows:

Test-NetConnection sip.example.com -Port 5060

برای TLS:

Test-NetConnection sip.example.com -Port 5061

اگر نتیجه:

TcpTestSucceeded : True

باشد، TCP Connection تا آن Port برقرار شده است.

اما این تست SIP Registration را تأیید نمی‌کند.

برای UDP از Test-NetConnection نتیجه نگیرید

SIP معمولاً می‌تواند روی UDP کار کند اما UDP Connection به مفهوم TCP ندارد.

بنابراین باز یا بسته بودن واقعی UDP را بهتر است با:

Packet Capture تلفن.

Packet Capture PBX.

یا Log Server.

بررسی کنید.

بهترین تست این است:

Yealink REGISTER را ارسال می‌کند؟

PBX همان Packet را می‌بیند؟

PBX پاسخ می‌دهد؟

پاسخ به Yealink می‌رسد؟

اگر TLS استفاده می‌کنید، Handshake را جداگانه تست کنید

برای SIP TLS:

openssl s_client \
-connect sip.example.com:5061 \
-servername sip.example.com

اگر TLS برقرار شود، باید اطلاعات Certificate و Session را ببینید.

اگر اینترنت اول TLS را برقرار می‌کند ولی اینترنت دوم قبل از ServerHello یا Certificate متوقف می‌شود، مسیر TCP/TLS شبکه دوم را بررسی کنید.

در PCAP تفاوت UDP، TCP و TLS را ببینید

برای UDP ممکن است مستقیم ببینید:

REGISTER
↓
401
↓
REGISTER
↓
200 OK

برای TCP ابتدا:

SYN
SYN/ACK
ACK

و بعد SIP دیده می‌شود.

برای TLS:

TCP Handshake
↓
TLS ClientHello
↓
ServerHello
↓
Certificate
↓
Encrypted SIP

اگر TCP Handshake هم کامل نمی‌شود، هنوز مشکل Certificate یا SIP Account مطرح نیست.

چطور احتمال محدودیت ISP را واقعاً بررسی کنیم؟

نباید صرفاً به دلیل کارنکردن Port 5060 نتیجه بگیرید ISP آن را مسدود کرده است.

برای اثبات باید رفتار چند مسیر را مقایسه کنید.

مثلاً:

UDP 5060 روی اینترنت A:
کار می‌کند

UDP 5060 روی اینترنت B:
پاسخ ندارد

TCP 5060 روی اینترنت B:
کار می‌کند

TLS 5061 روی اینترنت B:
کار می‌کند

این الگو نشان می‌دهد مشکل به UDP 5060 یا پردازش SIP در مسیر اینترنت B نزدیک‌تر شده است.

اما همچنان ممکن است Router و نه ISP مسئول باشد.

برای جداکردن Router از ISP یک تست دیگر لازم است

اگر امکان دارد اینترنت مشکل‌دار را با Router دیگری آزمایش کنید.

ISP B + Router 1
→ Fail

ISP B + Router 2
→ Success

در این حالت Router 1 مظنون بسیار قوی‌تری نسبت به ISP است.

اگر:

ISP B + Router 1
→ Fail

ISP B + Router 2
→ Fail

ولی هر دو Router روی ISP A کار می‌کنند، آن‌وقت ISP یا مسیر بالادستی جدی‌تر بررسی می‌شود.

یک ماتریس واقعی برای تشخیص ISP یا Router

SIP ALG یکی از اولین تنظیمات Router برای بررسی است

SIP ALG یا SIP Helper قابلیتی است که Router تلاش می‌کند Headerهای SIP و NAT را پردازش کند.

این قابلیت ممکن است روی یک Router مشکلی ایجاد نکند و روی Router دیگری Contact، Via یا SDP را به شکل متفاوت بازنویسی کند.

به همین دلیل ممکن است همان Yealink روی اینترنت خانه کار کند ولی پشت Router اداره Register نشود یا تماس ناقص داشته باشد.

SIP ALG را چطور بدون حدس بررسی کنیم؟

اگر امکان Capture در دو سمت Router دارید، REGISTER قبل و بعد از NAT را مقایسه کنید.

به‌خصوص:

Via
Contact
SDP
Source Port

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

اگر تلفن ارسال کرده:

Contact: <sip:201@192.168.1.50:5060>

و Router آن را به مقدار دیگری بازنویسی کرده، ابتدا بررسی کنید مقدار جدید با NAT واقعی سازگار است یا خیر.

SIP ALG را فقط به‌عنوان تست کنترل‌شده تغییر دهید

قبل از خاموش یا روشن‌کردن SIP ALG از تنظیمات Router Backup بگیرید.

بعد:

1. PCAP قبل از تغییر بگیرید
2. SIP ALG را تغییر دهید
3. Yealink را Re-register کنید
4. دوباره PCAP بگیرید
5. رفتار را مقایسه کنید

اگر مشکل به شکل تکرارپذیر فقط با تغییر ALG رفع می‌شود، Evidence بهتری برای نقش Router دارید.

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

Carrier-Grade NAT یا CGNAT یعنی چند مشترک ISP از یک یا چند Public IPv4 مشترک استفاده می‌کنند و یک لایه NAT در شبکه خود ISP وجود دارد.

RFC 6598 محدوده زیر را برای Shared Address Space مربوط به CGN اختصاص داده است:

100.64.0.0/10

یعنی:

100.64.0.0
تا
100.127.255.255

چطور بفهمیم احتمالاً پشت CGNAT هستیم؟

وارد Router شوید و WAN IP را ببینید.

مثلاً:

WAN IP:
100.72.18.25

اگر Public IP اینترنت شما در یک سرویس بیرونی عدد دیگری است:

Public IP:
203.0.113.70

یک NAT بالادستی وجود دارد و آدرس WAN داخل محدوده 100.64.0.0/10 نشانه قوی استفاده از Shared CGN Space است.

WAN IP خصوصی هم می‌تواند Double NAT باشد

اگر WAN Router چیزی مانند:

192.168.x.x

10.x.x.x

172.16.x.x تا 172.31.x.x

است، یک NAT دیگر بالاتر از Router شما وجود دارد.

این می‌تواند مودم دوم، تجهیزات ساختمان یا NAT شبکه ISP باشد.

اما صرف دیدن RFC1918 به‌تنهایی ثابت نمی‌کند ISP از CGNAT استاندارد 100.64.0.0/10 استفاده می‌کند.

CGNAT الزاماً SIP را خراب نمی‌کند

این نکته بسیار مهم است.

اگر Yealink از داخل شبکه به SIP Server REGISTER می‌فرستد، CGNAT می‌تواند کاملاً کار کند.

بنابراین:

CGNAT = SIP حتماً خراب است

نتیجه درستی نیست.

مشکل زمانی بیشتر می‌شود که NAT چندلایه، Mapping کوتاه‌مدت، Port Translation شدید یا مسیر برگشت نامناسب وجود داشته باشد.

در CGNAT Keep Alive اهمیت بیشتری پیدا می‌کند

Yealink برای NAT از Keep Alive و RPort پشتیبانی می‌کند.

اگر Mappingهای NAT در شبکه دوم سریع‌تر منقضی می‌شوند، تلفن ممکن است لازم داشته باشد با تنظیم صحیح Keep Alive مسیر ارتباط را فعال نگه دارد.

اما Interval را فقط بعد از مشاهده رفتار NAT تغییر دهید.

RPort را در دو شبکه مقایسه کنید

در REGISTER ممکن است:

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

وجود داشته باشد.

Server می‌تواند پاسخ دهد:

received=203.0.113.70
rport=48215

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

اگر Source Port مرتب تغییر می‌کند یا PBX پاسخ‌ها را به Mapping قدیمی می‌فرستد، NAT یکی از مظنون‌های اصلی است.

Double NAT را هم بررسی کنید

سناریوی رایج:

Yealink
↓
Router داخلی
↓
مودم ISP
↓
CGNAT ISP
↓
Internet
↓
PBX

در این حالت سه لایه ترجمه می‌تواند وجود داشته باشد.

هرچه تعداد NATها بیشتر شود، عیب‌یابی Contact، Source Port و Timeout اهمیت بیشتری پیدا می‌کند.

برای تست، Double NAT را کاهش دهید

اگر Router اصلی پشت مودم دیگری قرار دارد و امکان فنی دارید، به‌صورت کنترل‌شده بررسی کنید آیا:

Bridge Mode.

IP Passthrough.

یا اتصال مستقیم Router اصلی به WAN.

مشکل را تغییر می‌دهد.

این تغییرات را فقط با Backup تنظیمات و آگاهی از نحوه اتصال ISP انجام دهید؛ ممکن است اطلاعات PPPoE یا VLAN لازم باشد.

Firewall Router را بررسی کنید

Routerهای مختلف ممکن است Policyهای متفاوتی برای:

UDP Session
SPI Firewall
DoS Protection
SIP Inspection
Outbound Filtering
Connection Tracking

داشته باشند.

اگر SIP فقط پشت یک Router خراب است، Event Log یا Firewall Log همان Router را بررسی کنید.

Port Forwarding معمولاً برای Registration خروجی اولین راه‌حل نیست

اگر Yealink از داخل LAN یک REGISTER خروجی به PBX اینترنتی می‌فرستد، NAT State معمولاً مسیر پاسخ را می‌سازد.

بنابراین بازکردن تصادفی Port 5060 از اینترنت به سمت تلفن نباید اولین راه‌حل باشد.

این کار حتی می‌تواند تلفن را بیشتر در معرض SIP Scan قرار دهد.

ابتدا ثابت کنید مسیر برگشت به دلیل نبود Mapping مشکل دارد.

برای TLS پورت 5061 را بررسی کنید، اما فقط اگر Server از آن استفاده می‌کند

RFC 3261 مقدار پیش‌فرض TLS را 5061 تعریف می‌کند و Yealink نیز در تنظیمات SIP/TLS از پورت‌های پیش‌فرض 5060 و 5061 پشتیبانی می‌کند.

اما اگر Provider شما TLS را روی:

5065

ارائه می‌دهد، تست 5061 هیچ اطلاعاتی درباره سرویس واقعی نمی‌دهد.

همیشه Destination واقعی را از تنظیمات Account یا DNS SRV پیدا کنید.

اگر UDP خراب ولی TLS سالم است چه نتیجه‌ای بگیریم؟

مثلاً:

UDP 5060:
Register Failed

TCP/TLS 5061:
Registered

این یک سرنخ قوی است که مشکل به مسیر UDP، SIP ALG یا Policy شبکه نزدیک‌تر است.

اما تغییر دائمی Transport فقط زمانی مناسب است که PBX یا Provider رسماً همان Transport را پشتیبانی کند.

MTU چگونه می‌تواند روی Yealink اثر بگذارد؟

MTU حداکثر اندازه Frame/Packet قابل انتقال در یک بخش از مسیر است.

در بسیاری از شبکه‌های Ethernet مقدار رایج:

1500 bytes

است.

اما مسیرهایی مانند PPPoE، Tunnel و VPN می‌توانند MTU کوچک‌تری داشته باشند.

چرا MTU در TLS مهم‌تر به نظر می‌رسد؟

TLS Handshake می‌تواند Certificate Chain نسبتاً بزرگی منتقل کند.

اگر Path MTU Discovery درست کار نکند یا ICMP لازم در مسیر Drop شود، Packetهای بزرگ‌تر ممکن است مشکل پیدا کنند.

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

TCP Connect موفق
↓
TLS ClientHello
↓
بخشی از Handshake
↓
Timeout

در حالی که Packetهای کوچک‌تر بدون مشکل عبور می‌کنند.

MTU را با Ping دارای DF آزمایش کنید

در Windows برای IPv4:

ping sip.example.com -f -l 1472

اگر پیام مربوط به Fragmentation دریافت کردید، اندازه را کاهش دهید:

ping sip.example.com -f -l 1464

ping sip.example.com -f -l 1452

ping sip.example.com -f -l 1400

عدد 1472 از:

1500 - 20 bytes IPv4 header - 8 bytes ICMP

به‌دست می‌آید.

در Linux

ping -M do -s 1472 sip.example.com

در صورت Failure اندازه را کاهش دهید.

اما این تست قطعی نیست؛ بعضی Serverها یا Firewallها ICMP را محدود می‌کنند.

MTU دو اینترنت را با هم مقایسه کنید

اگر اینترنت سالم تا:

1472

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

1372

کار می‌کند، یک تفاوت مسیر مهم پیدا کرده‌اید.

حالا باید Router، PPPoE، VPN و WAN MTU را بررسی کنید.

MTU Router را بی‌دلیل روی عدد کوچک قرار ندهید

اگر MTU واقعی مسیر مشخص نشده است، تغییر تصادفی از 1500 به 1300 می‌تواند Performance شبکه را کاهش دهد و علت اصلی را پنهان کند.

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

بهترین روش: PCAP شبکه سالم و خراب را کنار هم بگذارید

برای این مشکل Packet Comparison از هر حدسی ارزشمندتر است.

از همان تلفن دو Capture بگیرید.

Capture اول:

Yealink + Internet A
→ Registration Successful

Capture دوم:

Yealink + Internet B
→ Registration Failed

هر دو Capture را از قبل از اتصال شبکه یا شروع Registration آغاز کنید.

چه چیزهایی را در دو PCAP مقایسه کنیم؟

سناریوی اول: در اینترنت خراب DNS Query جواب نمی‌گیرد

Network A:
DNS Query
↓
DNS Response
↓
REGISTER
↓
200 OK

Network B:
DNS Query
↓
No Response

نتیجه:

هنوز SIP، NAT و Port 5060 را متهم نکنید.

DNS Router یا ISP را اصلاح کنید.

سناریوی دوم: DNS سالم است ولی REGISTER پاسخی ندارد

DNS → OK
REGISTER → Sent
Response → None

حالا باید Capture سمت PBX را بررسی کنید.

اگر PBX REGISTER را دریافت نکرده:

Router
Firewall
ISP Path
NAT
SIP ALG

مطرح هستند.

اگر PBX REGISTER را دریافت می‌کند ولی Yealink پاسخ را نمی‌بیند

مثلاً در Server:

REGISTER received
401 sent

اما روی تلفن فقط:

REGISTER
REGISTER Retransmission
REGISTER Retransmission

می‌بینید.

این الگو روی مسیر برگشت تمرکز ایجاد می‌کند.

NAT Mapping، Firewall State و Source Port را بررسی کنید.

سناریوی سوم: روی اینترنت خراب 403 می‌گیرید

اگر PBX پاسخ:

403 Forbidden

می‌دهد، ارتباط شبکه برقرار است.

در این وضعیت «ISP پورت SIP را بسته» تقریباً با Evidence شما سازگار نیست، چون درخواست به Server رسیده و Server پاسخ SIP داده است.

باید Authentication، IP Policy، Geo/IP Restriction، Provider Policy یا Ban را بررسی کنید.

ممکن است PBX فقط بعضی Public IPها را اجازه دهد

در برخی محیط‌های سازمانی SIP Server فقط IPهای مشخص را Allowlist می‌کند.

در این حالت:

Internet A Public IP:
Allowed

Internet B Public IP:
Not Allowed

نتیجه ممکن است 403 یا حتی Drop کامل توسط Firewall باشد.

Firewall و PBX Access Policy را بررسی کنید.

اگر Provider شما IP Authentication دارد

بعضی SIP Trunkها Account Registration معمول ندارند و IP Address بخشی از Authentication است.

اگر اینترنت عوض شود، Public IP نیز تغییر می‌کند.

در این حالت سرویس ممکن است فقط از IP قبلی تماس را قبول کند.

این سناریو را با SIP Extension معمولی اشتباه نگیرید.

سناریوی چهارم: TCP SYN می‌رود ولی SYN/ACK برنمی‌گردد

Yealink → SYN
Server  → no response

در این حالت هنوز SIP Registration شروع نشده است.

موارد زیر را بررسی کنید:

Destination IP.

Destination Port.

Firewall خروجی.

Firewall Server.

ISP Path.

ACL.

سناریوی پنجم: TLS روی شبکه دوم در Handshake متوقف می‌شود

اگر:

TCP = OK

TLS ClientHello = Sent

ServerHello = No Response

ممکن است Firewall یا Middlebox در مسیر TLS دخالت داشته باشد.

اگر ServerHello می‌آید ولی بعد TLS Alert می‌بینید، Certificate، Hostname، CA و TLS Version را نیز بررسی کنید.

سناریوی ششم: Registration سالم ولی تماس خراب است

اگر Yealink روی هر دو اینترنت Registered می‌شود اما فقط روی یکی تماس ورودی یا صدا مشکل دارد، دیگر با «مشکل Registration» روبه‌رو نیستید.

در این حالت:

RTP
SDP
NAT
SIP ALG
Media Ports

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

Registration سبز فقط سالم‌بودن Signaling اولیه را نشان می‌دهد.

Public IP دو اینترنت را ثبت کنید

هنگام Capture این اطلاعات را در کنار فایل ذخیره کنید:

Network A:
WAN IP:
Public IP:
DNS:
Gateway:
Transport:

Network B:
WAN IP:
Public IP:
DNS:
Gateway:
Transport:

بعداً هنگام مقایسه Contact و Via این اطلاعات بسیار مفید است.

یک تست مهم با Softphone انجام دهید

همان Account SIP را روی یک Softphone در همان اینترنت مشکل‌دار آزمایش کنید.

مثلاً:

Yealink:
Fail

Softphone:
Success

در این وضعیت اینترنت به‌طور کامل SIP را مسدود نکرده است.

باید تفاوت Yealink و Softphone را بررسی کنید:

Transport
Source Port
DNS
User-Agent
RPort
TLS
SIP ALG interaction

اگر Softphone هم Fail شود

احتمال مشکل مشترک شبکه بیشتر می‌شود.

اما باز هم مشخص کنید Failure در کدام مرحله است.

اگر هر دو:

REGISTER → no response

دارند، Router/ISP/PBX Policy جدی‌تر می‌شود.

برای تست، Source SIP Port را تصادفی تغییر ندهید

Yealink اجازه تنظیم Local SIP Port و TLS SIP Port را می‌دهد.

پورت‌های پیش‌فرض:

SIP:
5060

TLS:
5061

هستند.

گاهی تغییر Local Source Port می‌تواند رفتار NAT یا ALG را تغییر دهد، اما قبل از تغییر PCAP بگیرید.

اگر تغییر Port مشکل را حل کرد، این فقط یک سرنخ است؛ باید بفهمید Router با Port قبلی چه رفتاری داشته است.

آیا ISP می‌تواند SIP را محدود کند؟

از نظر فنی بله، شبکه بالادستی می‌تواند Port، Protocol یا ترافیک خاصی را Filter یا Rate Limit کند.

اما تشخیص باید با Evidence انجام شود.

شواهد قوی‌تر عبارت‌اند از:

همان Router روی ISP دیگر سالم است

چند SIP Client روی ISP مشکل‌دار Fail می‌شوند

Destination صحیح است

Packet از Router خارج می‌شود

Server آن Packet را دریافت نمی‌کند

Transport دیگر روی همان ISP کار می‌کند

با مجموعه این شواهد می‌توان موضوع را دقیق‌تر با ISP مطرح کرد.

چه اطلاعاتی برای پشتیبانی ISP آماده کنیم؟

به‌جای گفتن «VoIP کار نمی‌کند»، این اطلاعات را بدهید:

Source Public IP
Destination IP
Destination Port
Protocol
Timestamp
PCAP
Traceroute
Working ISP comparison

مثلاً:

UDP from:
203.0.113.70

to:
198.51.100.20:5060

at:
13:42:15

No packet observed on destination server.

این گزارش بسیار قابل بررسی‌تر از شرح کلی مشکل است.

Traceroute چه چیزی نشان می‌دهد؟

در Windows:

tracert sip.example.com

در Linux:

traceroute sip.example.com

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

اما Timeout یک Hop الزاماً مشکل نیست؛ Routerهای مسیر ممکن است ICMP را پاسخ ندهند و همچنان Traffic را Forward کنند.

Traceroute را کنار PCAP استفاده کنید، نه به‌جای آن.

IPv6 را نیز در شبکه‌های متفاوت بررسی کنید

ممکن است یک اینترنت IPv6 فعال داشته باشد و دیگری فقط IPv4.

اگر Domain SIP دارای AAAA Record است، ببینید Yealink یا Resolver چه آدرسی انتخاب می‌کند.

در Wireshark:

dns

و سپس Destination Address را بررسی کنید.

اگر مسیر IPv6 خراب است ولی IPv4 سالم، تفاوت دو اینترنت ممکن است از انتخاب Address Family ناشی شده باشد.

یک تست مرحله‌ای استاندارد

برای جلوگیری از آزمون‌وخطا، این ترتیب را دنبال کنید:

1. همان تلفن و Account روی دو اینترنت

2. DNS Comparison

3. Destination IP Comparison

4. SIP Transport و Port

5. TCP/TLS Handshake

6. REGISTER Request

7. REGISTER Response

8. Via / Contact / RPort

9. WAN IP و Public IP

10. CGNAT / Double NAT

11. SIP ALG

12. Firewall

13. MTU

14. Capture سمت PBX

از روی آخرین Packet سالم تصمیم بگیرید

چه کارهایی را در شروع انجام ندهیم؟

Factory Reset تلفن.

بازکردن تمام Portهای Router.

DMZ کردن IP تلفن.

خاموش‌کردن کامل Firewall.

تغییر هم‌زمان DNS، SIP ALG، NAT و MTU.

تغییر Firmware بدون دلیل.

این کارها Evidence را از بین می‌برند و تشخیص را سخت‌تر می‌کنند.

اگر مجبور به تغییر تنظیم Router شدیم، هر بار فقط یک مورد

مثلاً:

Baseline PCAP

↓
فقط SIP ALG تغییر کند

↓
Test

↓
PCAP جدید

↓
نتیجه ثبت شود

بعد سراغ تغییر بعدی بروید.

با این روش دقیقاً می‌دانید کدام تغییر اثر داشته است.

پرسش‌های متداول درباره مشکل Yealink با یک اینترنت خاص

چرا Yealink با اینترنت موبایل کار می‌کند ولی با اینترنت شرکت نه؟

این رفتار نشان می‌دهد تلفن و SIP Account احتمالاً سالم هستند و باید تفاوت مسیر دو شبکه بررسی شود. DNS، Router، NAT، SIP ALG، Firewall، CGNAT، Port و Packet Capture مهم‌ترین موارد هستند.

آیا ممکن است ISP پورت 5060 را بسته باشد؟

از نظر فنی ممکن است، اما نباید بدون Packet Capture و تست مقایسه‌ای نتیجه گرفت. ابتدا مشخص کنید REGISTER از شبکه خارج می‌شود، Server آن را می‌بیند یا نه و آیا TCP یا TLS روی همان اینترنت رفتار متفاوتی دارد.

آیا TLS همیشه روی پورت 5061 است؟

5061 پورت پیش‌فرض SIP TLS است، اما Provider می‌تواند Port دیگری استفاده کند. Destination واقعی Account یا DNS SRV را بررسی کنید.

از کجا بفهمیم اینترنت ما CGNAT دارد؟

WAN IP Router را با Public IP مقایسه کنید. اگر WAN در محدوده 100.64.0.0/10 باشد و Public IP متفاوت باشد، استفاده از Shared Address Space مربوط به CGN محتمل است. WAN خصوصی نیز می‌تواند نشان‌دهنده Double NAT باشد.

آیا CGNAT باعث می‌شود Yealink اصلاً Register نشود؟

نه لزوماً. Registration یک ارتباط خروجی است و می‌تواند پشت CGNAT نیز کار کند. مشکل بیشتر زمانی ایجاد می‌شود که NAT Mapping، Port Translation یا مسیر برگشت با SIP Server سازگار نباشد.

SIP ALG را خاموش کنیم؟

فقط به‌عنوان تست کنترل‌شده. ابتدا PCAP بگیرید، تنظیم Router را Backup کنید، ALG را تغییر دهید و دوباره همان تست را انجام دهید. اگر رفتار قابل تکرار تغییر کرد، نقش ALG قابل اثبات‌تر است.

MTU واقعاً می‌تواند SIP را خراب کند؟

بله، مخصوصاً در مسیرهای دارای PPPoE، VPN یا Tunnel و در TLS که Handshake می‌تواند Packetهای بزرگ‌تری داشته باشد. MTU را با تست Path MTU و Packet Capture بررسی کنید، نه با تغییر تصادفی.

چرا Softphone روی همان اینترنت کار می‌کند ولی Yealink نه؟

ممکن است Transport، Source Port، RPort، TLS، DNS یا نحوه تعامل دستگاه با SIP ALG متفاوت باشد. PCAP هر دو Client را روی همان شبکه مقایسه کنید.

بهترین روش برای پیدا کردن علت چیست؟

از Yealink روی اینترنت سالم و خراب PCAP بگیرید و از DNS شروع کنید. Destination IP، Transport، TCP/TLS Handshake، REGISTER، پاسخ Server، Via، Contact و Source Port را مرحله‌به‌مرحله مقایسه کنید.

جمع‌بندی

وقتی Yealink روی یک اینترنت کار می‌کند و روی اینترنت دیگری نه، سریعاً ISP یا خود تلفن را مقصر ندانید. بهترین روش این است که همان دستگاه و همان Account را روی هر دو شبکه آزمایش کنید و فقط مسیر اینترنت را تغییر دهید.

از DNS شروع کنید و ببینید تلفن در هر دو شبکه به چه SIP Server و Portی می‌رسد. سپس TCP یا TLS Handshake و خود REGISTER را مقایسه کنید. اگر REGISTER از Yealink خارج می‌شود ولی PBX آن را نمی‌بیند، Router، Firewall، NAT و مسیر ISP مطرح می‌شوند. اگر PBX پاسخ می‌دهد ولی پاسخ به تلفن نمی‌رسد، مسیر برگشت و NAT اهمیت بیشتری دارند.

CGNAT، SIP ALG و MTU همگی می‌توانند تفاوت بین دو اینترنت ایجاد کنند، اما هیچ‌کدام را فقط بر اساس حدس تغییر ندهید. PCAP دو شبکه را کنار هم قرار دهید و آخرین مرحله سالم را پیدا کنید. وقتی تفاوت دقیق مشخص شد، می‌توانید به‌جای Reset و Port Forwarding تصادفی، همان بخش واقعی شبکه را اصلاح کنید.