چرا تماس تلفن یالینک بعد از ۳۰ ثانیه قطع می‌شود؟ رفع مشکل ACK و NAT

در این آموزش به‌جای تغییر تصادفی NAT، SIP ALG و پورت‌ها، Packet Capture را بررسی می‌کنیم تا مشخص شود ACK اصلاً ساخته شده است یا نه، 200 OK چند بار تکرار می‌شود، ACK به چه IP و Portی ارسال می‌شود و Contact، Record-Route یا NAT Mapping در کدام نقطه مسیر را خراب کرده‌اند.

اول مطمئن شوید واقعاً با مشکل ۳۰ ثانیه‌ای SIP روبه‌رو هستید

هر تماسی که بعد از حدود ۳۰ ثانیه قطع می‌شود الزاماً مشکل ACK ندارد. قبل از هر نتیجه‌گیری، زمان را دقیق اندازه بگیرید و PCAP را ببینید.

الگوی کلاسیک Missing ACK معمولاً چنین است:

INVITE
↓
100 Trying
↓
180 Ringing
↓
200 OK
↓
ACK  ← نمی‌رسد یا مسیر اشتباه دارد
↓
200 OK دوباره
↓
200 OK دوباره
↓
...
حدود 32 ثانیه
↓
BYE / قطع Session

اگر در Capture هیچ تکرار 200 OK وجود ندارد، باید سناریوهای دیگری مثل RTP Timeout، Session Timer، Re-INVITE، Firewall Timeout یا سیاست PBX را هم بررسی کنید.

چرا نبود ACK باعث قطع تماس می‌شود؟

در SIP، پاسخ موفق به INVITE با 200 OK پایان کار نیست. طرفی که INVITE را فرستاده باید دریافت 200 OK را با ACK تأیید کند.

برای تماس موفق:

Yealink  →  INVITE
Server   →  200 OK
Yealink  →  ACK

بعد از ACK، Dialog از نظر SIP کامل شده و تماس ادامه پیدا می‌کند.

اگر طرفی که 200 OK را ارسال کرده ACK نبیند، فرض می‌کند شاید 200 OK به مقصد نرسیده یا ACK در مسیر گم شده است. بنابراین پاسخ 200 OK را دوباره ارسال می‌کند.

طبق RFC 3261، اگر 2xx برای مدت 64×T1 بدون دریافت ACK تکرار شود، Session باید خاتمه پیدا کند.

چرا معمولاً عدد ۳۲ ثانیه دیده می‌شود؟

مقدار پیش‌فرض T1 در SIP برابر است با:

T1 = 500 ms

پس:

64 × 500 ms = 32000 ms

یعنی:

32 seconds

به همین دلیل کاربر معمولاً می‌گوید «تماس بعد از ۳۰ ثانیه قطع می‌شود»، در حالی که اگر PCAP را با Timestamp بررسی کنید ممکن است زمان واقعی نزدیک به ۳۲ ثانیه باشد.

مرحله اول: از Yealink یک Packet Capture کامل بگیرید

برای تشخیص این مشکل Capture باید قبل از شماره‌گیری شروع شود. اگر فقط چند ثانیه آخر تماس را ثبت کنید، INVITE و اولین 200 OK را از دست می‌دهید.

در بسیاری از تلفن‌های Yealink می‌توانید از رابط وب به بخش زیر بروید:

Settings → Configuration

سپس Diagnostic یا Packet Capture را Start کنید.

یک تماس ایجاد کنید و اجازه دهید خودش بعد از حدود ۳۰ ثانیه قطع شود.

بعد Capture را Stop و Export کنید.

Capture مناسب باید این بخش‌ها را پوشش دهد:

شروع INVITE
180 Ringing
200 OK
ACK یا نبود ACK
تکرارهای 200 OK
BYE یا پایان تماس

در Wireshark از Telephony → VoIP Calls شروع کنید

Wireshark ابزار مناسبی برای دیدن کل Call Flow دارد.

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

Telephony → VoIP Calls

تماس موردنظر را انتخاب کنید و Flow Sequence را باز کنید.

اگر مشکل ACK باشد، معمولاً در نمودار یک الگوی غیرعادی بسیار واضح دیده می‌شود: 200 OK چند بار تکرار شده ولی ACK مورد انتظار در سمت دیگر دیده نمی‌شود.

فیلتر ساده برای بررسی SIP

sip

برای پیدا کردن INVITE:

sip.Method == "INVITE"

برای ACK:

sip.Method == "ACK"

برای پاسخ‌های 200:

sip.Status-Code == 200

به Timestamp بسته‌ها دقت کنید تا ببینید فاصله بین اولین 200 OK و قطع تماس چقدر است.

سناریوی اول: 200 OK به Yealink می‌رسد ولی ACK ساخته نمی‌شود

اگر در PCAP خود Yealink، 200 OK را می‌بینید ولی هیچ ACK بعد از آن تولید نمی‌شود، مشکل باید در خود Endpoint یا اطلاعات Dialog بررسی شود.

موارد مهم عبارت‌اند از:

Contact Header داخل 200 OK.

Record-Route.

Route Set.

Request-URI مقصد ACK.

Firmware.

Transport.

در این شرایط ابتدا ببینید ACK باید بر اساس چه Remote Target و Route Set ساخته شود.

Contact در 200 OK چه نقشی دارد؟

در پاسخ موفق به INVITE، Contact یکی از اطلاعات مهم برای درخواست‌های بعدی داخل Dialog است.

مثلاً PBX می‌فرستد:

Contact: <sip:203.0.113.20:5060>

Yealink ممکن است برای ACK و درخواست‌های بعدی از این مقصد استفاده کند؛ البته اگر Proxy با Record-Route وارد Route Set شده باشد، مسیر می‌تواند از Proxy عبور کند.

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

مثال Contact اشتباه پشت NAT

فرض کنید PBX داخل دیتاسنتر روی IP خصوصی زیر است:

10.10.20.15

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

203.0.113.20

اگر 200 OK چنین Contactی داشته باشد:

Contact: <sip:10.10.20.15:5060>

یک Yealink در اینترنت نمی‌تواند ACK را مستقیماً به 10.10.20.15 بفرستد.

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

PBX → 200 OK
Yealink → ACK به 10.10.20.15
ACK هرگز به PBX نمی‌رسد
PBX → تکرار 200 OK
حدود 32 ثانیه
PBX → قطع تماس

Record-Route چیست و چرا برای ACK مهم است؟

وقتی SIP Proxy می‌خواهد در مسیر تمام درخواست‌های بعدی Dialog باقی بماند، می‌تواند Headerای به نام Record-Route به پیام اضافه کند.

مثلاً:

Record-Route: <sip:proxy.example.com;lr>

Endpoint بر اساس این Header یک Route Set می‌سازد.

ACK برای پاسخ 2xx به INVITE یک درخواست داخل Dialog است و باید Route Set و Remote Target صحیح را دنبال کند.

اگر SIP ALG، Proxy یا SBC مقدار Record-Route را اشتباه بازنویسی کند، ACK می‌تواند از مسیر متفاوتی نسبت به INVITE حرکت کند.

یکی از نشانه‌های واضح مشکل Record-Route

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

Yealink
↓
Proxy A
↓
PBX

اما ACK به دلیل Route اشتباه چنین مسیری پیدا کند:

Yealink
↓
IP اشتباه
↓
Timeout

در این شرایط Registration و حتی RTP ممکن است کاملاً سالم باشند ولی Signaling Dialog بعد از حدود ۳۰ ثانیه از بین برود.

مرحله دوم: Capture سمت PBX را هم بگیرید

فقط PCAP Yealink همیشه کافی نیست.

ممکن است روی Yealink ببینید ACK ارسال شده است؛ سؤال بعدی این است که آیا PBX هم همان ACK را دریافت کرده است یا خیر.

سه حالت مهم داریم:

اگر ACK از Yealink خارج می‌شود ولی PBX آن را نمی‌بیند

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

IP مقصد ACK را در Capture تلفن بررسی کنید.

مثلاً:

Source:
192.168.1.50:5060

Destination:
203.0.113.20:5060

سپس روی Firewall یا PBX Capture بگیرید.

اگر ACK روی WAN Router دیده می‌شود ولی PBX دریافت نمی‌کند، Firewall یا NAT سمت Server را بررسی کنید.

اگر ACK حتی از WAN شبکه تلفن خارج نمی‌شود، NAT یا Firewall سمت Client مطرح است.

NAT Mapping چطور ACK را خراب می‌کند؟

تلفن Yealink ممکن است از:

192.168.1.50:5060

ارسال کند ولی Router آن را به:

185.10.20.30:42317

ترجمه کند.

اگر SIP Server یا Proxy فرض کند Client هنوز روی Public Port دیگری در دسترس است، بعضی پیام‌های Dialog می‌توانند به Mapping قدیمی یا اشتباه بروند.

همچنین اگر NAT State وسط تماس تغییر کند، مسیر پیام‌های SIP داخل Dialog ممکن است خراب شود.

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

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

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

Account → Advanced → Keep Alive Type
Account → Advanced → Keep Alive Interval

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

مقدار پیش‌فرض Interval در مستندات بسیاری از مدل‌های Yealink برابر ۳۰ ثانیه است.

اما Keep Alive را بدون مشاهده NAT Timeout تغییر ندهید. هدف این است که Interval کمی کوتاه‌تر از زمان حذف Mapping در NAT باشد.

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

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

درخواست SIP می‌تواند این پارامتر را در Via داشته باشد:

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

Server می‌تواند پاسخ را به همان Public IP و Port واقعی که Packet از آن رسیده برگرداند.

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

Account → Advanced → RPort

اما Rport همه مشکلات NAT را حل نمی‌کند؛ مخصوصاً وقتی مشکل مربوط به Contact یا Record-Route باشد.

force_rport و rewrite_contact در Asterisk

اگر PBX مبتنی بر Asterisk و PJSIP است و Yealink پشت NAT قرار دارد، دو گزینه زیر اهمیت دارند:

force_rport=yes
rewrite_contact=yes

force_rport پاسخ‌ها را به IP و Port واقعی مبدأ برمی‌گرداند.

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

این تنظیمات را فقط بعد از مشاهده Trace و معماری NAT خود فعال یا اصلاح کنید.

SIP ALG یکی از متهمان مهم است

SIP ALG در Router یا Firewall می‌تواند Headerهای SIP را بخواند و تغییر دهد.

در بعضی شبکه‌ها این قابلیت مفید است و NAT مربوط به SIP و RTP را مدیریت می‌کند.

اما اگر PBX یا SBC خودش NAT Traversal را مدیریت کند و Router نیز هم‌زمان Contact، Via یا SDP را بازنویسی کند، ممکن است Signaling خراب شود.

SIP ALG می‌تواند Contact را بازنویسی کند

برای مثال پیام اصلی:

Contact: <sip:201@192.168.1.50:5060>

ممکن است توسط ALG به شکل زیر تغییر کند:

Contact: <sip:201@185.10.20.30:5060>

اصل بازنویسی لزوماً اشتباه نیست.

مشکل زمانی است که IP یا Port جدید با NAT Mapping واقعی تطابق نداشته باشد یا ALG بخشی از Dialog را تغییر دهد ولی بقیه مسیر از اطلاعات دیگری استفاده کند.

SIP ALG و Record-Route

بعضی ALGها رفتار Contact را بر اساس وجود Record-Route تغییر می‌دهند.

به همین دلیل هنگام عیب‌یابی باید PCAP قبل و بعد از Firewall را مقایسه کنید، نه اینکه صرفاً وجود SIP ALG را دلیل قطعی بدانید.

سه Header را کنار هم قرار دهید:

Via
Contact
Record-Route

اگر یکی از آن‌ها بین LAN و WAN به شکل غیرمنتظره تغییر کرده است، ALG یا SIP Helper را بررسی کنید.

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

خیر. ابتدا ثابت کنید ALG دخالت مخرب دارد.

Routerها و Firewallهای مختلف رفتار متفاوتی دارند. برخی SIP ALGها NAT و Pin-hole را درست مدیریت می‌کنند.

روش درست:

از تنظیمات Router نسخه پشتیبان بگیرید.

یک PCAP در وضعیت فعلی بگیرید.

Contact، Via و Record-Route را یادداشت کنید.

طبق مستندات همان Router وضعیت ALG را تغییر دهید.

Sessionهای SIP قبلی را پاک یا Endpoint را Re-register کنید.

دوباره تماس و PCAP بگیرید.

فقط اگر رفتار ۳۰ ثانیه‌ای به شکل تکرارپذیر تغییر کرد، ALG را علت بدانید.

چطور بفهمیم 200 OK تکرار می‌شود؟

در Wireshark پاسخ‌های 200 را فیلتر کنید:

sip.Status-Code == 200

حالا Call-ID و CSeq را بررسی کنید.

اگر چند 200 OK با:

Call-ID یکسان
CSeq یکسان
روش INVITE

می‌بینید، احتمالاً همان پاسخ نهایی INVITE در حال Retransmit شدن است.

Timestampها معمولاً الگویی افزایشی نشان می‌دهند.

نمونه Call Flow خراب

00.000  Yealink → PBX   INVITE
00.120  PBX → Yealink   100 Trying
02.250  PBX → Yealink   180 Ringing
05.100  PBX → Yealink   200 OK

05.600  PBX → Yealink   200 OK
06.600  PBX → Yealink   200 OK
08.600  PBX → Yealink   200 OK
12.600  PBX → Yealink   200 OK
16.600  PBX → Yealink   200 OK
20.600  PBX → Yealink   200 OK
...

37.xxx  PBX → Yealink   BYE

عددها در پیاده‌سازی‌ها و شرایط شبکه می‌توانند متفاوت باشند، اما نکته اصلی تکرار 200 OK و نبود ACK است.

اگر Yealink 200 OK دوم را هم می‌گیرد چه باید بشود؟

طبق RFC 3261، وقتی UAC یک Retransmission از همان 2xx دریافت می‌کند، ACK باید دوباره ارسال شود.

پس اگر تلفن چند 200 OK تکراری را دریافت می‌کند ولی هیچ ACK در Capture دیده نمی‌شود، این رفتار برای عیب‌یابی اهمیت زیادی دارد.

اگر ACK هست ولی مقصد آن اشتباه است

ACK را در Wireshark باز کنید.

Request-URI را ببینید:

ACK sip:203.0.113.20:5060 SIP/2.0

سپس Route Header را بررسی کنید:

Route: <sip:proxy.example.com;lr>

حالا مشخص کنید Packet در عمل به کدام IP ارسال شده است.

اگر Request-URI صحیح است اما Route Header تلفن را به Proxy اشتباه هدایت می‌کند، Record-Route پاسخ اولیه را بررسی کنید.

Contact و Record-Route را با هم اشتباه نگیرید

Contact معمولاً Remote Target داخل Dialog را مشخص می‌کند.

Record-Route مشخص می‌کند کدام Proxyها باید در مسیر درخواست‌های بعدی Dialog باقی بمانند.

پس وجود Record-Route می‌تواند باعث شود ACK مستقیماً به Contact نرود و ابتدا از Proxy عبور کند.

در شبکه‌های دارای SBC و چند Proxy این نکته بسیار مهم است.

چرا تماس‌های داخلی سالم‌اند ولی تماس Trunk بعد ۳۰ ثانیه قطع می‌شود؟

اگر تماس داخلی Yealink به Yealink سالم است اما تماس از طریق SIP Trunk بعد از ۳۰ ثانیه قطع می‌شود، بخش مشترک تلفن تا PBX تا حد زیادی سالم است.

تمرکز را روی سمت Trunk قرار دهید:

Contact Provider.

Record-Route Provider.

SBC.

NAT PBX.

Firewall بین PBX و Provider.

SIP ALG.

بررسی کنید کدام طرف 200 OK می‌دهد و کدام طرف باید ACK را بفرستد.

جهت تماس مهم است

در تماس خروجی ممکن است Yealink UAC اولیه باشد.

در تماس ورودی Yealink معمولاً UAS تماس ورودی است و بسته به معماری، ACK باید از سمت PBX یا Caller برسد.

بنابراین صرفاً نگویید «ACK گم شده است». مشخص کنید:

چه کسی INVITE فرستاد؟
چه کسی 200 OK فرستاد؟
چه کسی باید ACK بفرستد؟
ACK در کدام Capture ناپدید شد؟

اگر فقط تماس ورودی بعد از ۳۰ ثانیه قطع می‌شود

در این حالت Contact و Route مربوط به سمت Yealink اهمیت بیشتری پیدا می‌کند.

بررسی کنید PBX هنگام تماس ورودی ACK را به کدام IP و Port ارسال می‌کند.

اگر Yealink پشت NAT است، ACK باید از NAT Mapping صحیح عبور کند.

همچنین SIP ALG ممکن است Contact مربوط به Yealink را هنگام عبور REGISTER یا INVITE تغییر داده باشد.

اگر فقط تماس خروجی بعد از ۳۰ ثانیه قطع می‌شود

در این حالت Yealink INVITE را ارسال کرده است.

وقتی مقصد 200 OK می‌دهد، Yealink باید ACK را بر اساس Dialog Routing ارسال کند.

اگر ACK به Server نمی‌رسد، Contact و Record-Route داخل 200 OK را بررسی کنید.

اگر Yealink اصلاً ACK تولید نمی‌کند، Capture تلفن و Syslog آن اهمیت بیشتری پیدا می‌کند.

اگر ACK صحیح است، دنبال چه چیز دیگری بگردیم؟

اگر در Capture هر دو سمت:

INVITE
200 OK
ACK

را به‌صورت سالم می‌بینید و تماس همچنان حدود ۳۰ ثانیه قطع می‌شود، روی ACK متوقف نشوید.

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

RTP inactivity timeout.

Session Timer.

Re-INVITE یا UPDATE.

Firewall Session Timeout.

Media Proxy.

SBC Policy.

RTP Timeout می‌تواند شبیه همین مشکل باشد

بعضی PBXها اگر RTP دریافت نکنند، تماس را بعد از مدت مشخص قطع می‌کنند.

ممکن است این Timeout روی ۳۰ ثانیه تنظیم شده باشد.

در این سناریو ACK کاملاً سالم است، اما PBX هیچ RTP در یک جهت نمی‌بیند.

پس PCAP را فقط به SIP محدود نکنید.

در Wireshark:

Telephony → RTP → RTP Streams

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

اگر Stream یک جهت وجود ندارد، مقاله مربوط به تشخیص RTP و صدای یک‌طرفه را باید دنبال کنید.

Session Timer با Missing ACK فرق دارد

SIP Session Timer معمولاً از Headerهای:

Session-Expires:
Min-SE:
Supported: timer

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

اگر Session Refresh انجام نشود، تماس می‌تواند در زمان مشخصی قطع شود.

اما این زمان لزوماً ۳۲ ثانیه نیست.

اگر ACK سالم است ولی درست در یک Interval مشخص تماس پایان می‌یابد، Session Timer را بررسی کنید.

Re-INVITE بعد از اتصال را بررسی کنید

گاهی تماس اولیه موفق است اما چند ثانیه بعد PBX برای تغییر Media یا Session یک Re-INVITE ارسال می‌کند.

اگر Re-INVITE پاسخ صحیح نگیرد، تماس ممکن است قطع شود.

در Flow Sequence فقط اولین INVITE را نبینید؛ کل ۳۰ تا ۴۰ ثانیه تماس را بررسی کنید.

Packet Capture روی Asterisk

اگر PBX مبتنی بر Asterisk است، هم‌زمان با PCAP تلفن SIP Logger را نیز فعال کنید.

pjsip set logger on

تماس آزمایشی را انجام دهید.

بعد از پایان:

pjsip set logger off

اکنون بررسی کنید Asterisk:

200 OK را چند بار ارسال یا دریافت کرده است.

ACK را دریافت یا ارسال کرده است یا خیر.

Request-URI ACK چیست.

Route Header وجود دارد یا خیر.

Contact چه آدرسی دارد.

یک PCAP روی Server از لاگ هم ارزشمندتر است

لاگ SIP نشان می‌دهد Application چه چیزی پردازش کرده است، اما Packet Capture نشان می‌دهد واقعاً چه Packetی روی Interface شبکه عبور کرده است.

روی Linux می‌توانید با tcpdump Capture بگیرید:

sudo tcpdump -i any -s 0 -w sip-call.pcap port 5060

اگر TLS یا Port دیگری استفاده می‌کنید، فیلتر را متناسب با شبکه خود تغییر دهید.

برای Capture کامل‌تر در زمان عیب‌یابی می‌توانید Host طرف مقابل را محدود کنید:

sudo tcpdump -i any -s 0 -w yealink-call.pcap host 185.10.20.30

فایل را بعداً در Wireshark باز کنید.

SIP روی TLS چه تغییری ایجاد می‌کند؟

اگر Yealink از SIP TLS استفاده کند، محتوای SIP در Packet Capture معمولی رمزگذاری شده است.

در نتیجه INVITE، Contact، Record-Route و ACK را مستقیم در PCAP نمی‌بینید.

در این حالت:

Syslog Yealink.

PBX SIP Log.

SBC Trace.

Log سمت Provider.

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

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

Re-register می‌تواند NAT Mapping را تازه کند و Contact جدیدی روی Server ثبت کند.

اگر تماس بعد از Re-register مدتی سالم می‌شود، NAT State، Contact و Keep Alive را بررسی کنید.

اما اگر هر تماس دقیقاً بعد از ۳۲ ثانیه قطع می‌شود، حتی بلافاصله بعد از Register، Missing ACK یا Dialog Routing محتمل‌تر است.

آیا تغییر Transport از UDP به TCP مشکل را حل می‌کند؟

گاهی استفاده از TCP یا TLS می‌تواند بعضی مشکلات NAT مربوط به UDP را کاهش دهد، اما تغییر Transport بدون یافتن علت راه‌حل اصولی نیست.

اگر SIP Server رسماً TCP یا TLS را پشتیبانی می‌کند، می‌توانید به‌عنوان تست کنترل‌شده بررسی کنید.

اگر مشکل فقط روی UDP وجود دارد، NAT Mapping، Rport و Firewall State اهمیت بیشتری پیدا می‌کنند.

تست Softphone برای تفکیک مشکل

همان SIP Account را روی یک Softphone در همان شبکه Yealink تنظیم کنید.

اگر Softphone هم دقیقاً بعد از حدود ۳۲ ثانیه قطع می‌شود، مشکل احتمالاً فقط مربوط به Yealink نیست.

در این حالت:

Router.

SIP ALG.

NAT.

PBX.

Provider.

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

اگر Softphone سالم است ولی Yealink همیشه بعد از ۳۲ ثانیه قطع می‌شود، Capture و تنظیمات Yealink را با Softphone مقایسه کنید.

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

Yealink را موقتاً به اینترنت دیگری متصل کنید.

مثلاً Router دوم یا Hotspot.

اگر بدون تغییر SIP Account مشکل ۳۰ ثانیه‌ای ناپدید شد، شبکه قبلی یکی از مظنون‌های اصلی است.

SIP ALG، NAT Mapping، UDP State و Firewall را در شبکه اول بررسی کنید.

چک‌لیست دقیق Packet Capture

نقشه سریع تشخیص

پرسش‌های متداول درباره قطع تماس Yealink بعد از ۳۰ ثانیه

چرا تماس Yealink تقریباً بعد از ۳۰ ثانیه قطع می‌شود؟

یکی از علت‌های کلاسیک نرسیدن ACK بعد از 200 OK است. با T1 پیش‌فرض ۵۰۰ میلی‌ثانیه، 64×T1 حدود ۳۲ ثانیه می‌شود و طرف پاسخ‌دهنده می‌تواند Session را پس از دریافت‌نکردن ACK خاتمه دهد.

چطور بفهمیم ACK گم شده است؟

در Wireshark جریان SIP را بررسی کنید. اگر 200 OK برای همان INVITE چند بار تکرار می‌شود ولی ACK مناسب دیده نمی‌شود، Missing ACK بسیار محتمل است.

اگر ACK روی Yealink دیده شود ولی روی PBX نباشد چه؟

مسیر بین تلفن و PBX را بررسی کنید. NAT، Firewall، SIP ALG، Route و IP یا Port مقصد ACK از مظنون‌های اصلی هستند.

Contact Header چگونه باعث قطع تماس می‌شود؟

اگر Contact داخل 200 OK به IP یا Port غیرقابل دسترسی اشاره کند، Endpoint ممکن است ACK را به مقصد اشتباه ارسال کند.

Record-Route چه نقشی دارد؟

Record-Route تعیین می‌کند Proxyهای SIP در مسیر درخواست‌های بعدی Dialog باقی بمانند. Route Set اشتباه می‌تواند ACK را به مسیر نادرست هدایت کند.

آیا SIP ALG می‌تواند باعث قطع تماس بعد از ۳۰ ثانیه شود؟

بله، اگر Contact، Via یا Record-Route را به شکلی ناسازگار با NAT واقعی بازنویسی کند. برای اثبات آن PCAP قبل و بعد از Router را مقایسه کنید.

اگر INVITE، 200 OK و ACK همگی سالم باشند چه کنیم؟

در این حالت روی Missing ACK تمرکز نکنید. RTP Timeout، Session Timer، Re-INVITE، UPDATE، Firewall Timeout و سیاست SBC یا PBX را بررسی کنید.

چرا تماس دقیقاً ۳۲ ثانیه و نه ۳۰ ثانیه قطع می‌شود؟

RFC 3261 از 64×T1 استفاده می‌کند. با T1 پیش‌فرض ۵۰۰ میلی‌ثانیه، این مدت ۳۲ ثانیه است. کاربران معمولاً آن را به‌صورت تقریبی «۳۰ ثانیه» گزارش می‌کنند.

جمع‌بندی

وقتی تماس Yealink حدود ۳۰ ثانیه پس از برقراری قطع می‌شود، اولین کار Reset تلفن یا تغییر Codec نیست. Capture را از قبل از INVITE شروع کنید و بررسی کنید بعد از 200 OK آیا ACK واقعاً به طرف مقابل رسیده است.

اگر 200 OK چند بار تکرار می‌شود و ACK وجود ندارد، Contact و Record-Route را بررسی کنید. اگر Yealink ACK را ارسال کرده ولی PBX آن را نمی‌بیند، NAT، Firewall و SIP ALG بین دو سمت مطرح می‌شوند. اگر ACK در هر دو Capture سالم است، باید از فرض Missing ACK خارج شوید و RTP Timeout، Session Timer یا Re-INVITE را بررسی کنید.

مهم‌ترین مزیت PCAP این است که مشکل «تماس بعد از ۳۰ ثانیه قطع می‌شود» را از یک حدس مبهم به یک مسیر قابل اندازه‌گیری تبدیل می‌کند: دقیقاً می‌بینید 200 OK کجا بوده، ACK کجا ساخته شده و در کدام نقطه از شبکه ناپدید شده است.