چرا تماس ورودی تلفن یالینک نمی‌آید؟ رفع مشکل NAT و SIP ALG

چرا تماس خروجی کار می‌کند اما تماس ورودی نه؟

این حالت در شبکه‌های NAT بسیار رایج است. تلفن داخل شبکه خصوصی مثلاً با IP زیر قرار دارد:

192.168.1.50

تلفن خودش یک اتصال SIP به سرور عمومی ایجاد می‌کند، بنابراین تماس خروجی می‌تواند از NAT عبور کند. اما برای تماس ورودی، PBX باید بداند تلفن را از چه IP و پورتی پیدا کند.

اگر PBX آدرس اشتباه ذخیره کرده باشد، NAT Mapping از بین رفته باشد یا روتر بسته INVITE ورودی را نپذیرد، تلفن همچنان ممکن است در ظاهر Registered باشد ولی زنگ نخورد.

اول این سه سناریو را از هم جدا کنید

مرحله اول: مطمئن شوید DND فعال نیست

قبل از واردشدن به NAT و PCAP، یک مورد ساده را بررسی کنید. Yealink در مستندات رسمی خود اشاره می‌کند اگر حساب Registered باشد ولی کاربر DND را فعال کرده باشد، تماس‌های ورودی رد می‌شوند.

روی نمایشگر تلفن به علامت DND توجه کنید و آن را غیرفعال کنید.

اگر بعد از خاموش‌کردن DND تماس ورودی برگشت، نیازی به تغییر NAT و Firewall نیست.

مرحله دوم: از PBX شروع کنید؛ آیا INVITE ساخته می‌شود؟

از سمت PBX یک تماس آزمایشی به داخلی Yealink بگیرید و هم‌زمان SIP Trace را فعال کنید.

اگر Asterisk با PJSIP دارید:

pjsip set logger on

سپس تماس ورودی را تکرار کنید.

باید چیزی شبیه این ببینید:

INVITE sip:201@PUBLIC_IP:PORT SIP/2.0

اگر هیچ INVITE مربوط به داخلی ساخته نمی‌شود، تلفن Yealink هنوز متهم اصلی نیست. DID، Inbound Route، Context و مقصد تماس را در PBX بررسی کنید.

بعد از پایان تست:

pjsip set logger off

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

یکی از مهم‌ترین قسمت‌های تماس ورودی، Contact Header است. طبق SIP، REGISTER می‌تواند Contactی را به Registrar بدهد که نشان می‌دهد این کاربر در چه آدرسی قابل دسترسی است.

مثلاً Yealink ممکن است REGISTER زیر را بفرستد:

REGISTER sip:pbx.example.com SIP/2.0
Contact: <sip:201@192.168.1.50:5060>

این Contact داخل شبکه محلی معتبر است، اما PBX اینترنتی نمی‌تواند مستقیماً به 192.168.1.50 دسترسی پیدا کند.

در یک سیستم NAT-aware، Registrar یا PBX باید بتواند مسیر واقعی را بر اساس IP و Port منبع Registration تشخیص دهد یا Contact را بازنویسی کند.

چرا Contact اشتباه باعث از دست رفتن تماس ورودی می‌شود؟

فرض کنید تلفن از این مسیر Register شده است:

Yealink:
192.168.1.50:5060

NAT Public Mapping:
185.10.20.30:42817

اگر PBX بعداً INVITE را به Contact خصوصی زیر ارسال کند:

sip:201@192.168.1.50:5060

تماس هرگز از اینترنت به تلفن نمی‌رسد.

اما اگر PBX آدرس NAT دیده‌شده را ذخیره کند:

sip:201@185.10.20.30:42817

شانس رسیدن INVITE به NAT Mapping صحیح بسیار بیشتر است.

در Asterisk Contact واقعی را چگونه ببینیم؟

اگر Asterisk و PJSIP دارید، این دستور بسیار مفید است:

pjsip show aor 201

به‌جای 201 نام AOR داخلی خود را قرار دهید.

خروجی می‌تواند چیزی شبیه این باشد:

Contact: 201/sip:201@185.10.20.30:42817

اگر Contact آدرس خصوصی یا یک Port قدیمی را نشان می‌دهد، علت تماس ورودی می‌تواند همین باشد.

rewrite_contact در Asterisk چه کاری انجام می‌دهد؟

در PJSIP، گزینه rewrite_contact برای Endpointهای پشت NAT اهمیت زیادی دارد.

طبق مستندات رسمی Asterisk، این گزینه باعث می‌شود درخواست‌های بعدی به IP و Port منبعی فرستاده شوند که درخواست SIP واقعاً از آن رسیده است، نه الزاماً آدرسی که Endpoint داخل Contact نوشته است.

نمونه:

[201]
type=endpoint
aors=201
auth=201-auth
rewrite_contact=yes
force_rport=yes
rtp_symmetric=yes

این تنظیمات را کورکورانه روی همه Endpointها اعمال نکنید. ابتدا Contact و Trace را بررسی کنید و سپس NAT Configuration را متناسب با معماری خود تنظیم کنید.

force_rport چه تفاوتی با rewrite_contact دارد؟

این دو تنظیم یک کار واحد انجام نمی‌دهند.

rewrite_contact به PBX کمک می‌کند مقصد درخواست‌های بعدی را بر اساس IP و Port واقعی منبع اصلاح کند.

force_rport باعث می‌شود پاسخ SIP به همان IP و پورتی برگردد که درخواست از آن دریافت شده است.

مفهوم Rport در RFC 3581 تعریف شده و برای عبور پاسخ‌های SIP از NAT کاربرد دارد.

Rport در خود Yealink

Yealink نیز قابلیت Rport دارد. در بسیاری از مدل‌ها مسیر آن به شکل زیر است:

Account → Advanced → RPort

طبق مستندات Yealink، Rport به تلفن اجازه می‌دهد از Server درخواست کند پاسخ‌ها را به IP و Port واقعی مبدأ ارسال کند.

این قابلیت به‌خصوص در Symmetric NAT مفید است، اما به پشتیبانی SIP Server نیز وابسته است.

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

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

در این وضعیت احتمال NAT Timeout زیاد است.

تلفن هنگام REGISTER یک Mapping در روتر ایجاد می‌کند:

192.168.1.50:5060
→
185.10.20.30:42817

اگر برای مدتی ترافیکی وجود نداشته باشد، روتر ممکن است این Mapping را حذف کند.

PBX هنوز تصور می‌کند تلفن روی Port قبلی قابل دسترسی است و INVITE را به همان Mapping منقضی‌شده می‌فرستد.

Keep Alive دقیقاً برای همین مشکل است

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

در بسیاری از مدل‌ها:

Account → Advanced → Keep Alive Type
Account → Advanced → Keep Alive Interval (Seconds)

Yealink برای Keep Alive حالت‌هایی مانند Default، SIP OPTIONS و SIP NOTIFY دارد.

پارامترهای رایج Provisioning نیز عبارت‌اند از:

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

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

چطور NAT Timeout را عملاً تشخیص دهیم؟

این آزمایش ساده معمولاً بسیار گویاست:

تلفن را Reboot یا Account را Re-register کنید.

بلافاصله تماس ورودی بگیرید.

اگر تماس می‌رسد، ۵ تا ۱۵ دقیقه صبر کنید و دوباره امتحان کنید.

اگر تماس دوم نمی‌رسد، NAT Timeout یا Keep Alive به یکی از مظنون‌های اصلی تبدیل می‌شود.

یک تست بهتر: تماس خروجی بگیرید و فوراً ورودی را امتحان کنید

اگر تماس ورودی خراب است، ابتدا از Yealink یک تماس خروجی برقرار کنید و بلافاصله تماس ورودی بگیرید.

اگر بعد از تماس خروجی ناگهان تماس ورودی کار کرد، این رفتار می‌تواند نشان دهد NAT Mapping با ترافیک خروجی دوباره تازه شده است.

در این حالت Keep Alive و NAT State را دقیق‌تر بررسی کنید.

SIP ALG چیست و چرا می‌تواند دردسرساز شود؟

SIP ALG یا Application Layer Gateway قابلیتی در برخی Routerها و Firewallها است که محتوای SIP را بررسی و حتی بازنویسی می‌کند.

هدف آن معمولاً کمک به عبور SIP و RTP از NAT است. برای مثال می‌تواند Contact یا SDP را تغییر دهد و برای Media پورت باز کند.

اما اگر SIP ALG با رفتار PBX یا Endpoint شما هماهنگ نباشد، ممکن است Contact Header یا Portها را به شکلی تغییر دهد که تماس ورودی به مقصد اشتباه ارسال شود.

آیا SIP ALG را همیشه باید خاموش کنیم؟

خیر. جمله «SIP ALG همیشه بد است» از نظر فنی دقیق نیست.

بعضی Firewallها SIP ALG را عمداً برای NAT، SIP Inspection و ساخت Pin-hole استفاده می‌کنند و با تنظیم درست می‌تواند کاملاً کار کند.

اما اگر Provider یا PBX خودش NAT Traversal را مدیریت می‌کند و ALG نیز هم‌زمان Contact یا SDP را بازنویسی کند، تداخل ممکن است ایجاد شود.

پس ابتدا PCAP قبل و بعد از Router را مقایسه کنید و ببینید ALG چه چیزی را تغییر داده است.

چگونه بفهمیم SIP ALG Contact را تغییر داده؟

REGISTER را در سمت LAN و WAN Router مقایسه کنید.

مثلاً سمت LAN:

Contact: <sip:201@192.168.1.50:5060>

و سمت WAN:

Contact: <sip:201@185.10.20.30:5060>

اگر Router Header را بازنویسی کرده، SIP ALG یا یک NAT Helper در مسیر فعال است.

خود این تغییر الزاماً اشتباه نیست؛ باید بررسی کنید IP و Port نهایی واقعاً با Mapping فعال هماهنگ هستند یا خیر.

یک مشکل رایج SIP ALG: Port اشتباه

گاهی ALG آدرس Public را درست قرار می‌دهد اما Portی را در Contact قرار می‌دهد که با NAT Mapping واقعی یکسان نیست.

مثلاً:

Contact advertised:
185.10.20.30:5060

Actual NAT mapping:
185.10.20.30:42817

در این حالت PBX ممکن است INVITE را به 5060 بفرستد، در حالی که تلفن پشت Mapping شماره 42817 قرار دارد.

مرحله پنجم: Firewall State را بررسی کنید

Stateful Firewallها برای ارتباطات UDP وضعیت موقت نگه می‌دارند. برخلاف TCP، UDP Connection دائمی ندارد و State آن معمولاً بعد از مدت مشخص حذف می‌شود.

اگر State مربوط به SIP حذف شود، یک بسته INVITE جدید از اینترنت ممکن است Drop شود، حتی اگر تلفن روی PBX هنوز Registered نمایش داده شود.

بنابراین Registered بودن سمت Server الزاماً ثابت نمی‌کند NAT State همین لحظه سالم است.

روی Firewall چه چیزهایی را بررسی کنیم؟

Session Table را برای IP و SIP Port تلفن بررسی کنید.

ببینید Source Port عمومی که PBX ذخیره کرده هنوز در Session Table وجود دارد یا خیر.

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

بررسی کنید ACL فقط Responseها را اجازه نداده باشد و INVITE جدید Drop نشود.

اگر Serverهای SIP متعدد دارید، Firewall نباید فقط یک IP خاص را برای برگشت مجاز کرده باشد مگر اینکه معماری شما همین را ایجاب کند.

اگر تماس ورودی از یک Server دیگر می‌آید چه؟

بعضی سرویس‌دهندگان Registration را روی یک IP دریافت می‌کنند اما تماس ورودی را از SBC یا Proxy دیگری ارسال می‌کنند.

در این حالت Firewall بسیار محدود ممکن است INVITE را Drop کند، چون Source IP آن با Registrar متفاوت است.

فهرست رسمی SIP Serverها و SBCهای Provider را بررسی کنید و ACL را بر همان اساس بسازید.

مرحله ششم: PCAP تلفن را بگیرید

Yealink در مستندات رسمی خود برای تماس ورودی ناموفق پیشنهاد می‌کند PCAP بررسی شود تا مشخص شود تلفن INVITE را دریافت کرده یا خیر.

در بسیاری از مدل‌ها:

Settings → Configuration → Export All Diagnostic Files

Capture را Start کنید، تماس ورودی ایجاد کنید و سپس Stop و Export را بزنید.

در Wireshark:

sip.Method == "INVITE"

اگر هیچ INVITE دیده نمی‌شود، مشکل قبل از تلفن قرار دارد.

اگر INVITE در PBX هست ولی در PCAP Yealink نیست

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

مقصد INVITE در PBX Trace را بخوانید:

INVITE sip:201@185.10.20.30:42817

سپس بررسی کنید این Public IP و Port هنوز NAT Mapping فعال تلفن هستند یا خیر.

اگر Mapping تغییر کرده باشد، Contact قدیمی است.

اگر Mapping درست باشد اما Packet روی WAN دیده شود و روی LAN دیده نشود، Router یا Firewall بسته را Drop می‌کند.

اگر INVITE به Yealink می‌رسد ولی تلفن زنگ نمی‌خورد

در این حالت NAT تقریباً کار خود را انجام داده است. اکنون Response تلفن را بررسی کنید.

ممکن است Yealink پاسخ خطایی مانند:

486 Busy Here
488 Not Acceptable Here
603 Decline

برگرداند.

اگر INVITE دریافت شده اما Response خطا است، تنظیمات DND، Codec، SRTP و سیاست تماس ورودی را بررسی کنید.

SDP هم می‌تواند تماس ورودی را خراب کند

طبق مستندات Yealink، یکی از سناریوهای تماس ورودی ناموفق این است که INVITE به تلفن می‌رسد اما SDP Negotiation شکست می‌خورد.

مثلاً اگر تلفن و PBX Codec مشترک نداشته باشند یا یکی SRTP اجباری و دیگری RTP معمولی بخواهد، تلفن ممکن است پاسخ 488 بدهد.

این وضعیت با سناریویی که INVITE اصلاً به تلفن نمی‌رسد متفاوت است.

Contact در REGISTER را در Wireshark چگونه پیدا کنیم؟

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

sip.Method == "REGISTER"

REGISTER موفق را باز کنید و Contact را پیدا کنید.

نمونه:

Contact: <sip:201@192.168.1.50:5060>;expires=3600

سپس Response سرور را بررسی کنید. Headerهای Via می‌توانند پارامترهایی مانند received و rport داشته باشند.

این اطلاعات به شما نشان می‌دهد Server درخواست را از چه IP و Portی دیده است.

received و rport را چگونه تفسیر کنیم؟

مثلاً:

Via: SIP/2.0/UDP 192.168.1.50:5060;
received=185.10.20.30;
rport=42817

این یعنی تلفن خودش را با IP خصوصی 192.168.1.50 معرفی کرده، اما Server بسته را از Public IP و Port دیگری دیده است.

این تفاوت در شبکه NAT طبیعی است.

مشکل زمانی ایجاد می‌شود که Server برای INVITE بعدی از آدرس اشتباه استفاده کند.

Registration Expire هم مهم است

REGISTER معمولاً مدت اعتبار دارد. اگر Refresh Registration دیر انجام شود یا سرور Binding قدیمی را نگه دارد، تماس ممکن است به Contact قدیمی ارسال شود.

در Trace بررسی کنید REGISTERهای دوره‌ای واقعاً انجام می‌شوند و پاسخ 200 OK دریافت می‌کنند.

اگر Public Source Port در هر Registration تغییر می‌کند، PBX باید Contact جدید را جایگزین کند.

TCP و TLS نسبت به UDP چه تفاوتی دارند؟

مشکل NAT Timeout بیشتر در SIP روی UDP دیده می‌شود، چون TCP و TLS اتصال Connection-Oriented دارند.

اما TCP و TLS هم می‌توانند در Firewall یا NAT به دلیل Idle Timeout قطع شوند.

اگر حساب Yealink روی TLS Registered است ولی تماس ورودی بعد از مدتی قطع می‌شود، Session TCP/TLS و Keep Alive سمت Server را نیز بررسی کنید.

سرور چند Contact قدیمی برای یک داخلی نگه نداشته باشد

در بعضی PBXها یک داخلی می‌تواند چند Contact داشته باشد.

اگر Yealink چند بار با Public Portهای مختلف Register شده باشد و Contactهای قدیمی حذف نشده باشند، PBX ممکن است تماس را به Contact اشتباه نیز ارسال کند.

در Asterisk:

pjsip show aor 201

تعداد Contactها را بررسی کنید.

اگر فقط یک تلفن باید وجود داشته باشد اما چند Contact فعال دیده می‌شود، تنظیمات max_contacts، remove_existing و NAT را بررسی کنید.

راه تست سریع: تلفن را روی اینترنت دیگری قرار دهید

Yealink را موقتاً روی یک Router یا اینترنت دیگر قرار دهید.

اگر بدون تغییر Account تماس ورودی درست شد، احتمال مشکل در Router، SIP ALG، NAT Timeout یا Firewall شبکه اول بسیار بالا می‌رود.

این تست قبل از تغییر گسترده تنظیمات PBX ارزش زیادی دارد.

یک تست دیگر: SIP ALG را کنترل‌شده مقایسه کنید

اگر Router اجازه می‌دهد، از تنظیمات فعلی Backup بگیرید.

وضعیت SIP ALG را یادداشت کنید.

یک تماس ورودی و PCAP ثبت کنید.

سپس طبق مستندات همان Router و توصیه Provider، ALG را تغییر دهید و دوباره Register و تماس را آزمایش کنید.

فقط اگر نتیجه قابل تکرار تغییر کرد، می‌توان SIP ALG را علت دانست.

چرخه کامل تماس ورودی سالم

در یک سناریوی سالم تقریباً چنین اتفاقی می‌افتد:

Yealink → REGISTER
PBX     → 200 OK

PBX Contact Database:
201 → Public-IP:Mapped-Port

Caller → PBX

PBX → INVITE → Public-IP:Mapped-Port
NAT → Yealink

Yealink → 100 Trying
Yealink → 180 Ringing
Yealink → 200 OK

اگر مسیر در هر مرحله قطع شود، همان نقطه محل اصلی عیب‌یابی است.

نقشه نهایی عیب‌یابی

پرسش‌های متداول درباره تماس ورودی Yealink

چرا Yealink رجیستر است اما تماس ورودی ندارد؟

Registered بودن فقط نشان می‌دهد تلفن توانسته حساب SIP را ثبت کند. تماس ورودی هنوز به Contact صحیح، NAT Mapping فعال، مسیر Firewall و INVITE قابل دسترسی نیاز دارد.

چرا بعد از Reboot تماس ورودی کار می‌کند ولی چند دقیقه بعد قطع می‌شود؟

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

Contact Header چه نقشی در تماس ورودی دارد؟

Contact مشخص می‌کند User Agent در چه SIP URI قابل دسترسی است. اگر PBX یک Contact خصوصی یا Port قدیمی ذخیره کند، INVITE تماس ورودی ممکن است به مقصد اشتباه برود.

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

نه به‌صورت پیش‌فرض. ALG در بعضی شبکه‌ها برای NAT و Pin-hole استفاده می‌شود. اگر Provider یا PBX خودش NAT را مدیریت می‌کند و ALG Headerها را اشتباه بازنویسی می‌کند، ممکن است لازم باشد طبق مستندات Router آن را غیرفعال کنید.

Keep Alive روی Yealink چه کاری انجام می‌دهد؟

Keep Alive ترافیک دوره‌ای ارسال می‌کند تا NAT Mapping مربوط به SIP در Router منقضی نشود. Yealink امکان استفاده از Default، OPTIONS یا NOTIFY را برای این کار دارد.

Rport چه کاری انجام می‌دهد؟

Rport به SIP Server اجازه می‌دهد پاسخ را به همان IP و Portی ارسال کند که درخواست واقعاً از آن رسیده است و در برخی NATهای متقارن مفید است.

چطور بفهمیم INVITE به تلفن می‌رسد؟

از Yealink PCAP بگیرید و در Wireshark فیلتر sip.Method == “INVITE” را وارد کنید. اگر PBX INVITE را ارسال کرده ولی در PCAP تلفن وجود ندارد، مشکل در مسیر شبکه است.

اگر INVITE به تلفن رسید ولی زنگ نخورد چه کنیم؟

DND و تنظیمات تماس ورودی را بررسی کنید و پاسخ SIP تلفن را ببینید. پاسخ‌هایی مانند 486 یا 488 می‌توانند نشان دهند تماس در خود Endpoint رد شده یا SDP Negotiation شکست خورده است.

جمع‌بندی

وقتی Yealink تماس خروجی دارد ولی تماس ورودی نمی‌رسد، دوباره رمز SIP و تنظیمات Register را تصادفی تغییر ندهید. اول با PBX Trace مشخص کنید INVITE ساخته می‌شود یا خیر.

اگر INVITE ساخته می‌شود، Contact ثبت‌شده و Public IP/Port مقصد را با NAT Mapping واقعی مقایسه کنید. اگر تماس بلافاصله بعد از Register کار می‌کند ولی بعداً قطع می‌شود، Keep Alive و NAT Timeout را بررسی کنید. اگر Router SIP ALG دارد، با PCAP مشخص کنید آیا Contact و Port را بازنویسی کرده است.

در نهایت بهترین روش این است که Trace PBX، Capture سمت WAN و PCAP خود Yealink را کنار هم بگذارید. هر جا INVITE از مسیر ناپدید شد، همان نقطه محدوده واقعی مشکل است.