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

از طرف دیگر، اگر تماس نه در ۳۲ ثانیه بلکه دقیقاً بعد از چند دقیقه مشخص مانند ۱۵، ۲۰ یا ۳۰ دقیقه قطع می‌شود، باید Session-Expires، نقش refresher، re-INVITE یا UPDATE و timeout تجهیزات میانی را نیز بررسی کرد.

در این راهنما با Packet Capture و SIP Trace مشخص می‌کنیم تماس به‌دلیل ACK قطع شده، Session Timer منقضی شده یا Firewall/NAT وضعیت Dialog را از دست داده است.

اول زمان قطع تماس را دقیق اندازه بگیرید

به‌جای اینکه بگویید «بعد از چند ثانیه تماس قطع می‌شود»، زمان را با کرنومتر یا Timestamp لاگ اندازه بگیرید.

چرا ۳۲ ثانیه عدد مهمی در SIP است؟

طبق RFC 3261، وقتی یک SIP User Agent پاسخ موفق 2xx به INVITE را ارسال می‌کند، تا زمانی که ACK متناظر را دریافت نکند باید پاسخ را دوباره ارسال کند.

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

INVITE  ----------------------->

        <---------------- 200 OK
ACK     ----------------------->

RTP     <=====================>

اگر ACK نرسد:

INVITE  ----------------------->

        <---------------- 200 OK

        <---------------- 200 OK
        <---------------- 200 OK
        <---------------- 200 OK
        <---------------- 200 OK

        ...

        approximately 64 × T1

        <---------------- BYE

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

64×T1 چگونه به حدود ۳۲ ثانیه می‌رسد؟

مقدار معمول T1 در SIP:

T1 = 500 ms

پس:

64 × 0.5 = 32 seconds

Cisco نیز در راهنمای MPP سری 8800 مقدار پیش‌فرض SIP T1 را 0.5 ثانیه اعلام کرده است.

پس هر تماس ۳۲ ثانیه‌ای مشکل ACK دارد؟

نه صددرصد، اما این یکی از قوی‌ترین سرنخ‌هاست.

قبل از تغییر تنظیمات فقط کافی است SIP Trace بگیرید. اگر بعد از Answer چند نسخه تکراری از همان 200 OK دیده می‌شود، تقریباً مشخص است ارسال‌کننده 200 OK، ACK صحیح را دریافت نکرده است.

الگوی واضح ACK Failure در Packet Capture

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

10:15:00.100  INVITE
10:15:01.020  180 Ringing
10:15:03.200  200 OK

10:15:03.700  200 OK
10:15:04.700  200 OK
10:15:06.700  200 OK
10:15:10.700  200 OK
10:15:14.700  200 OK
...

10:15:35.xxx  BYE

تکرار 200 OK بعد از برقراری تماس مهم‌ترین علامت است.

ACK را در Wireshark پیدا کنید

فقط ACK:

sip.Method == "ACK"

فقط BYE:

sip.Method == "BYE"

فقط 200 OKها:

sip.Status-Code == 200

بهترین روش: Call-ID همان تماس را جدا کنید

Call-ID را از INVITE بردارید و تمام Packetهای همان Dialog را ببینید.

sip.Call-ID == "YOUR_CALL_ID"

اگر PBX به‌صورت B2BUA کار می‌کند ممکن است سمت Cisco و سمت Trunk دو Call-ID متفاوت داشته باشند؛ در این حالت Timestamp، Calling Number و Called Number را نیز مقایسه کنید.

ACK وجود دارد؛ اما آیا به مقصد درست می‌رود؟

وجود ACK در Capture مبدأ به‌تنهایی کافی نیست.

ممکن است Cisco ACK را ارسال کرده باشد اما NAT یا Firewall آن را به مقصد اشتباه بفرستد یا در بین راه Drop کند.

بنابراین باید ACK را در حداقل دو نقطه ببینید:

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

ACK برای پاسخ 2xx یک Request داخل Dialog است و مقصد آن بر اساس Route Set و Contact مربوط به Dialog تعیین می‌شود.

اگر یکی از این اطلاعات داخل SIP به IP یا Port اشتباه اشاره کند، مسیر ACK می‌تواند با مسیر INVITE اولیه فرق کند.

مثلاً 200 OK شامل:

Contact: <sip:202@192.168.10.50:5060>

است، در حالی که Endpoint واقعاً پشت NAT و از اینترنت فقط از Public IP دیگری قابل دسترسی است.

ACK ممکن است به همان Private IP غیرقابل‌دسترس هدایت شود.

Record-Route و Route را هم بررسی کنید

اگر SIP Proxy، SBC یا Firewall SIP-aware در مسیر وجود دارد، Record-Route تعیین می‌کند درخواست‌های بعدی Dialog از چه مسیری عبور کنند.

اگر یک Proxy خودش را با IP اشتباه داخل Record-Route قرار داده باشد، ACK، BYE و re-INVITE ممکن است بعد از برقراری اولیه تماس به مسیر اشتباه بروند.

SIP ALG یکی از مظنون‌های مهم ACK است

SIP ALG می‌تواند Contact، Via، Record-Route، SDP یا Portها را Rewrite کند.

گاهی INVITE اولیه با وجود ALG عبور می‌کند اما اطلاعاتی که داخل پاسخ 200 OK بازنویسی می‌شود باعث می‌شود ACK مسیر اشتباهی پیدا کند.

بهترین تست این نیست که فوراً ALG را خاموش کنید؛ Capture قبل و بعد Router بگیرید و ببینید دقیقاً چه فیلدی تغییر کرده است.

نمونه مقایسه قبل و بعد SIP ALG

قبل از Router:

Contact: <sip:201@192.168.1.50:5060>

بعد از Router:

Contact: <sip:201@203.0.113.20:42818>

صرف تغییرکردن لزوماً بد نیست؛ سؤال این است که آیا مقصد جدید واقعاً قابل دسترس و پایدار است یا خیر.

اگر Cisco پشت NAT به Asterisk وصل است

در Endpointهای PJSIP معمولاً این تنظیمات باید متناسب با توپولوژی بررسی شوند:

rewrite_contact=yes
force_rport=yes
rtp_symmetric=yes

`rewrite_contact` و `force_rport` به Signaling و مسیر برگشت Requestها مرتبط‌اند؛ `rtp_symmetric` بیشتر برای Media استفاده می‌شود.

این مقادیر را بدون شناخت معماری روی همه Endpointها کپی نکنید.

اگر خود Asterisk پشت NAT است

Transport باید Local Network و Public Address واقعی را بشناسد.

نمونه مفهومی:

local_net=192.168.20.0/24
external_signaling_address=203.0.113.10
external_media_address=203.0.113.10

IPها فقط نمونه هستند.

مرحله مهم: چه کسی تماس را قطع کرده است؟

هرگز فقط از روی صفحه تلفن نگویید Cisco تماس را قطع کرده است.

در SIP Trace اولین BYE را پیدا کنید.

مثلاً:

203.0.113.50  ---- BYE ---->  192.168.20.10

این نشان می‌دهد سمت 203.0.113.50 فرایند قطع را شروع کرده است.

اما همچنان باید علت ارسال BYE را از Packetهای قبل از آن پیدا کنید.

Reason Header را هم ببینید

برخی تجهیزات در BYE یک Reason Header می‌فرستند.

مثلاً:

Reason: SIP;cause=408;text="Request Timeout"

وجود Reason می‌تواند مسیر بررسی را کوتاه کند، اما همه تجهیزات آن را ارسال نمی‌کنند.

Session Timer چیست؟

Session Timer مکانیزمی متفاوت از ACK اولیه تماس است.

RFC 4028 برای Sessionهای طولانی یک Refresh دوره‌ای تعریف می‌کند تا تجهیزات بدانند Dialog هنوز فعال است.

Header اصلی:

Session-Expires: 1800;refresher=uac

یعنی Session Interval برابر ۱۸۰۰ ثانیه است و UAC مسئول Refresh است.

Min-SE چیست؟

Header زیر حداقل Session Interval مورد قبول را مشخص می‌کند:

Min-SE: 90

در RFC 4028 مقدار Min-SE نمی‌تواند کمتر از ۹۰ ثانیه باشد.

پس Session-Expires=30 نباید داشته باشیم؟

در Session Timer استاندارد RFC 4028، مقدار Session-Expires کمتر از ۹۰ ثانیه معتبر نیست.

این نکته کمک می‌کند یک اشتباه رایج را تشخیص دهیم: در Cisco MPP گزینه‌ای به نام ReINVITE Expires وجود دارد که مقدار پیش‌فرض آن در راهنمای Cisco برابر ۳۰ ثانیه است.

اما:

ReINVITE Expires ≠ Session-Expires

این دو پارامتر را با هم اشتباه نگیرید.

ReINVITE Expires در Cisco چه می‌کند؟

Cisco MPP در:

Voice → SIP → SIP Timer Values

پارامتری به نام ReINVITE Expires دارد.

این مقدار برای Expires Header درخواست re-INVITE استفاده می‌شود و خودش Session Timer سی‌ثانیه‌ای برای قطع عادی تماس نیست.

بنابراین دیدن مقدار 30 در این قسمت دلیل کافی برای یک Call Drop بعد از 30 ثانیه نیست.

Session Refresh چگونه انجام می‌شود؟

طرفی که به‌عنوان Refresher انتخاب شده است، قبل از پایان Session باید یک درخواست جدید داخل Dialog ارسال کند.

معمولاً:

re-INVITE

یا:

UPDATE

ارسال می‌شود.

مثال Session Timer سالم

INVITE
Session-Expires: 1800;refresher=uac

200 OK
Session-Expires: 1800;refresher=uac

ACK

...

approximately 900 seconds

re-INVITE / UPDATE
200 OK

چرا تماس دقیقاً بعد از ۱۵ دقیقه قطع می‌شود؟

اگر Session-Expires برابر 1800 ثانیه باشد، Refresh معمولاً قبل از پایان Interval انجام می‌شود و در بسیاری از پیاده‌سازی‌ها حوالی نیمه بازه رخ می‌دهد.

Cisco در یک راهنمای عیب‌یابی خود برای تماس‌های CUCM مثال می‌زند که با Session Expires برابر 1800 ثانیه، Refresh حدود 900 ثانیه یا 15 دقیقه انجام می‌شود و اگر پیام Refresh نتواند از Firewall عبور کند، تماس می‌تواند در همین حوالی دچار مشکل شود.

اگر تماس ۱۵ دقیقه‌ای قطع می‌شود چه چیزی ببینیم؟

در Wireshark:

sip.Method == "UPDATE"

و:

sip.Method == "INVITE"

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

INVITE دوم همان re-INVITE است و باید CSeq بالاتری نسبت به INVITE اولیه داشته باشد.

Session-Expires را از INVITE و 200 OK بخوانید

در Packet Details دنبال:

Session-Expires
Min-SE
Supported: timer
Require: timer
refresher=uac
refresher=uas

بگردید.

اگر Session-Expires اصلاً وجود ندارد چه؟

طبق RFC 4028، نبودن Session-Expires یعنی مکانیزم Session Expiration تعریف‌شده در همان RFC برای آن Dialog فعال نشده است.

البته تجهیزات هنوز ممکن است Timerهای داخلی دیگری داشته باشند؛ بنابراین نبود Session-Expires همه Timeoutها را رد نمی‌کند، اما Session Timer استاندارد RFC 4028 دیگر مظنون اصلی نیست.

422 Session Interval Too Small چیست؟

اگر Client Session-Expires پایین‌تر از حد مورد قبول Server پیشنهاد کند، Server می‌تواند پاسخ:

422 Session Interval Too Small
Min-SE: 1800

برگرداند.

Client باید درخواست را با Interval قابل قبول تکرار کند.

Firewall State چگونه تماس را قطع می‌کند؟

حتی اگر SIP Dialog از نظر Protocol صحیح باشد، Firewall یا Router می‌تواند State مرتبط با مسیر Signaling را زودتر از عمر تماس حذف کند.

این موضوع به‌خصوص در TCP/TLS مهم است.

مثلاً:

SIP Session Refresh: 900 seconds
Firewall TCP Idle Timeout: 600 seconds

ممکن است اتصال Signaling قبل از رسیدن Refresh بعدی از State Table حذف شود.

چرا تماس ممکن است تا زمان Refresh سالم بماند؟

RTP ممکن است همچنان در حال عبور باشد، اما Session Timer به Signaling وابسته است.

در لحظه Refresh، re-INVITE یا UPDATE باید از همان مسیر SIP عبور کند.

اگر Firewall State دیگر وجود نداشته باشد، Refresh Fail می‌شود و Session در نهایت بسته خواهد شد.

TCP/TLS و UDP را یکسان عیب‌یابی نکنید

در UDP مسئله معمولاً NAT Binding و UDP State Timeout است.

در TCP یا TLS علاوه بر NAT، خود Connection State و Idle Timeout اهمیت بیشتری پیدا می‌کند.

اگر تماس با UDP سالم است ولی با TLS قطع می‌شود

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

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

TCP Connection باز مانده است؟

Firewall TCP Idle Timeout چقدر است؟

re-INVITE/UPDATE روی همان Connection عبور می‌کند؟

آیا تجهیز میانی TLS Connection را Reset می‌کند؟

Firewall Log را دقیقاً در لحظه قطع بررسی کنید

در Log دنبال مواردی مانند این بگردید:

session timeout
connection reset
aged out
policy deny
SIP inspection drop
invalid state

آیا RTP Timeout هم می‌تواند تماس را قطع کند؟

بله. بعضی PBXها و SBCها اگر برای مدت مشخص RTP دریافت نکنند تماس را خاتمه می‌دهند.

این سناریو با ACK Failure متفاوت است.

در ACK Failure معمولاً در ابتدای تماس چند 200 OK تکراری می‌بینید.

در RTP Timeout ممکن است Signaling اولیه کاملاً سالم باشد اما قبل از BYE برای مدت مشخصی RTP یک یا هر دو جهت غایب شده باشد.

برای تشخیص RTP Timeout چه کنیم؟

در Wireshark:

Telephony → RTP → RTP Streams

را باز کنید.

Timeline RTP را با Timestamp BYE مقایسه کنید.

اگر Media مثلاً ۳۰ ثانیه قبل از BYE متوقف شده، RTP Timeout Policy روی PBX/SBC یکی از مظنون‌هاست.

در Asterisk SIP Trace بگیرید

وارد CLI شوید:

asterisk -rvvv

سپس:

pjsip set logger on

یک تماس کوتاه ایجاد کنید و تا زمان قطع صبر کنید.

بعد:

pjsip set logger off

در Trace Asterisk دنبال چه بگردیم؟

به ترتیب:

INVITE
100 Trying
180 Ringing
200 OK
ACK
re-INVITE / UPDATE
BYE

اگر Asterisk ACK را دریافت نمی‌کند

مقصد ACK را با Contact و Route Header مقایسه کنید.

همچنین Capture سمت Cisco و Asterisk را کنار هم قرار دهید.

اگر Cisco ACK را تولید کرده ولی Asterisk آن را نمی‌بیند، مشکل بین این دو Endpoint قرار دارد.

اگر Asterisk ACK را دارد ولی Trunk ندارد

به یاد داشته باشید Asterisk معمولاً B2BUA است و دو Dialog جدا دارد.

ممکن است ACK در Leg زیر سالم باشد:

Cisco <----> Asterisk

اما Leg بعدی مشکل داشته باشد:

Asterisk <----> SIP Provider

پس هر دو Leg را جدا بررسی کنید.

Capture مستقیم از Cisco MPP

در Cisco MPP می‌توانید از ابزارهای Diagnostic یا Packet Capture خود Phone استفاده کنید.

Capture را قبل از تماس Start کنید، تماس را برقرار کنید و صبر کنید تا مشکل رخ دهد. سپس بلافاصله Stop کنید.

Capture کوتاه ۴۰ تا ۶۰ ثانیه‌ای برای یک خطای ۳۲ ثانیه‌ای بسیار مفیدتر از فایل چندساعته است.

SIP Timerهای Cisco را بدون دلیل تغییر ندهید

Cisco MPP در بخش Voice → SIP پارامترهای مختلفی مانند T1، T2، T4، Timer B، F، H، D و J دارد.

صرف اینکه تماس در زمان مشخص قطع می‌شود دلیل نمی‌شود این Timerها را تغییر دهید.

اگر ACK گم شده باشد، افزایش Timer فقط خرابی را دیرتر نشان می‌دهد و مسیر اشتباه ACK را اصلاح نمی‌کند.

مقدار T1 پیش‌فرض Cisco MPP

طبق راهنمای فعلی سری 8800 MPP:

SIP T1 = 0.5 seconds
SIP T2 = 4 seconds
SIP T4 = 5 seconds

این همان T1 نیم‌ثانیه‌ای است که در محاسبه کلاسیک 64×T1 به حدود ۳۲ ثانیه می‌رسد.

سناریوی اول: تماس دقیقاً ۳۲ ثانیه بعد از Answer قطع می‌شود

اولین بررسی:

آیا 200 OK چند بار تکرار می‌شود؟

اگر بله، ACK را پیدا کنید.

اگر ACK در مبدأ وجود دارد ولی در مقصد نیست، NAT، Firewall، SIP ALG و Route Set را بررسی کنید.

سناریوی دوم: تماس حدود ۳۰ ثانیه قطع می‌شود ولی 200 OK تکراری نداریم

این‌جا دیگر نباید فقط به ACK بچسبیم.

اول BYE را پیدا کنید و ببینید چه دستگاهی آن را ایجاد کرده است.

بعد بررسی کنید آیا قبل از BYE:

RTP قطع شده،

re-INVITE Fail شده،

TCP Reset آمده،

یا Policy داخلی PBX فعال شده است.

سناریوی سوم: تماس همیشه ۱۵ دقیقه قطع می‌شود

Session Timer و Firewall State را در اولویت بگذارید.

در INVITE و 200 OK دنبال:

Session-Expires: 1800

بگردید.

سپس حوالی دقیقه ۱۵ دنبال re-INVITE یا UPDATE باشید.

سناریوی چهارم: re-INVITE ارسال می‌شود ولی پاسخی نمی‌گیرد

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

Firewall State، NAT Binding، TLS/TCP Session و Route را بررسی کنید.

سناریوی پنجم: UPDATE ارسال می‌شود ولی 481 دریافت می‌کنید

481 معمولاً یعنی طرف مقابل Dialog متناظر را پیدا نمی‌کند.

Call-ID، From Tag، To Tag و Route Set را بررسی کنید.

ممکن است Proxy یا B2BUA State را زودتر پاک کرده باشد.

سناریوی ششم: تماس فقط از طریق یک Firewall خاص قطع می‌شود

یک تماس را با همان Cisco و همان PBX از مسیر دیگری تست کنید.

اگر:

Internet A = call stable
Internet B = drop after 32 seconds

Phone و PBX ثابت مانده‌اند و Network Path مظنون اصلی است.

سناریوی هفتم: فقط تماس ورودی قطع می‌شود

Offer/Answer و ACK Direction تماس ورودی را با تماس خروجی سالم مقایسه کنید.

ممکن است Contact یا Route مربوط به یکی از Directionها متفاوت باشد.

سناریوی هشتم: فقط تماس خروجی قطع می‌شود

Trunk Leg را جدا از Cisco Leg بررسی کنید.

ممکن است Cisco کاملاً ACK خود را با Asterisk مبادله کند ولی Provider هیچ ACK صحیحی از Asterisk نگیرد.

سناریوی نهم: تماس روی LAN سالم است ولی Cisco Remote مشکل دارد

این الگو NAT را بسیار پررنگ می‌کند.

Source IP/Port تلفن، Contact Header، Via، rport و مسیر ACK را مقایسه کنید.

سناریوی دهم: فقط بعد از Hold یا Transfer تماس قطع می‌شود

در این حالت مشکل احتمالاً INVITE اولیه نیست.

Hold و Transfer معمولاً باعث re-INVITE یا Signaling جدید داخل Dialog می‌شوند.

Capture را تا لحظه Hold/Transfer ادامه دهید و re-INVITE، REFER، Replaces و ACKهای جدید را بررسی کنید.

سناریوی یازدهم: RTP سالم است اما تماس در ۳۲ ثانیه قطع می‌شود

این رفتار کاملاً ممکن است.

RTP و SIP مستقل‌اند؛ Audio می‌تواند کاملاً دوطرفه باشد در حالی که SIP Dialog به‌دلیل ACK گم‌شده معتبر نگه داشته نمی‌شود.

بنابراین وجود صدای سالم ACK Failure را رد نمی‌کند.

سناریوی دوازدهم: Audio قطع می‌شود ولی SIP Call باقی می‌ماند

این سناریو برعکس است.

اگر Phone همچنان Connected نشان می‌دهد اما Audio از بین می‌رود، ابتدا RTP، NAT Media، Firewall UDP و SDP را بررسی کنید؛ نه ACK اولیه.

یک جدول تشخیص سریع

چک‌لیست حرفه‌ای Packet Capture

چه چیزی را اول تغییر ندهیم؟

برای تماس ۳۲ ثانیه‌ای اولین کار این موارد نیست:

تعویض Codec،

تغییر RTP Range،

افزایش تصادفی SIP Timerها،

Factory Reset Cisco،

یا غیرفعال‌کردن TLS.

اول Trace بگیرید. اگر 200 OK تکراری و ACK گم‌شده دارید، علت تقریباً مشخص است.

آیا افزایش T1 راه‌حل است؟

معمولاً خیر.

افزایش T1 ممکن است مدت زمان قبل از Timeout را تغییر دهد، اما ACK را به مقصد صحیح نمی‌رساند.

اگر Route یا NAT اشتباه است، باید همان مسیر اصلاح شود.

آیا کاهش Session-Expires راه‌حل است؟

بدون شناخت مشکل خیر.

Session Interval کوتاه‌تر تعداد re-INVITE یا UPDATEها را افزایش می‌دهد و می‌تواند بار اضافی ایجاد کند.

RFC 4028 نیز مقدار بسیار کوتاه را توصیه نمی‌کند و ۱۸۰۰ ثانیه را مقدار پیشنهادی معرفی می‌کند.

اگر Cisco روی سرور مجازی خارج از شبکه دفتر رجیستر است

در این معماری احتمال NAT و Firewall بیشتر است.

اگر Asterisk یا FreePBX روی سرور مجازی ایران اجرا می‌شود، بهتر است هم‌زمان Capture سمت Server و Router دفتر را بگیرید.

اگر ACK در Capture دفتر وجود دارد ولی روی Server دیده نمی‌شود، محل خرابی بین این دو نقطه قرار دارد.

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

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

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

چطور بفهمم ACK به مقصد نرسیده است؟

Packet Capture دو سمت تماس را مقایسه کنید. اگر ACK در سمت Cisco وجود دارد اما در PBX یا Endpoint مقابل دیده نمی‌شود، NAT، Firewall، SIP ALG یا Route مسیر را بررسی کنید.

آیا Session Timer می‌تواند تماس را بعد از ۳۰ ثانیه قطع کند؟

Session-Expires استاندارد RFC 4028 نمی‌تواند کمتر از ۹۰ ثانیه باشد. بنابراین قطع حدود ۳۰ تا ۳۲ ثانیه بیشتر به ACK و Transaction Timing مربوط است تا Session Timer استاندارد.

ReINVITE Expires=30 در Cisco یعنی تماس بعد از ۳۰ ثانیه قطع می‌شود؟

خیر. ReINVITE Expires با Session-Expires متفاوت است. این پارامتر مربوط به Expires Header درخواست re-INVITE است و نباید با Session Timer تماس اشتباه گرفته شود.

چرا تماس دقیقاً بعد از ۱۵ دقیقه قطع می‌شود؟

اگر Session-Expires برابر ۱۸۰۰ ثانیه باشد، Refresh می‌تواند حوالی نیمه Interval رخ دهد. Fail شدن re-INVITE یا UPDATE به‌دلیل Firewall یا ازبین‌رفتن TCP/NAT State می‌تواند باعث قطع دوره‌ای تماس شود.

Session-Expires و Min-SE چه تفاوتی دارند؟

Session-Expires مدت اعتبار Session تا Refresh بعدی را تعیین می‌کند؛ Min-SE پایین‌ترین Interval قابل قبول برای Session Timer را مشخص می‌کند.

چطور بفهمم چه دستگاهی تماس را قطع کرده است؟

اولین BYE را در SIP Trace پیدا کنید. Source آن نشان می‌دهد کدام SIP Leg فرایند پایان تماس را آغاز کرده است.

آیا Firewall می‌تواند تماس را با وجود صدای سالم قطع کند؟

بله. ممکن است RTP سالم باشد اما Firewall State مربوط به Signaling از بین برود و re-INVITE یا UPDATE بعدی عبور نکند.

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

بله، اگر Contact، Via، Record-Route یا مسیر ACK را اشتباه Rewrite کند. برای اثبات باید Packetهای قبل و بعد Router مقایسه شوند.

چرا تماس داخل LAN سالم است ولی Cisco Remote قطع می‌شود؟

این الگو NAT، Contact، Firewall و SIP ALG را در اولویت قرار می‌دهد، چون Phone و PBX یکسان مانده‌اند و فقط مسیر شبکه تغییر کرده است.

وجود RTP دوطرفه مشکل ACK را رد می‌کند؟

خیر. SIP Signaling و RTP مستقل هستند. تماس می‌تواند تا لحظه قطع صدای کاملاً سالم داشته باشد ولی ACK اولیه Dialog به مقصد نرسیده باشد.

جمع‌بندی

اگر تماس Cisco تقریباً ۳۰ تا ۳۲ ثانیه بعد از Answer قطع می‌شود، اولین مظنون باید ACK باشد. طبق رفتار تعریف‌شده در SIP، پاسخ 200 OK تا دریافت ACK دوباره ارسال می‌شود و با T1 نیم‌ثانیه‌ای بازه 64×T1 تقریباً ۳۲ ثانیه است.

به‌جای تغییر Timerها، Packet Capture بگیرید. اگر 200 OKهای تکراری دیده می‌شوند، ACK را از Cisco تا PBX یا Provider دنبال کنید. Contact، Via، Record-Route، NAT، SIP ALG و Firewall مهم‌ترین نقاط بررسی هستند.

اگر تماس دقیقاً بعد از چند دقیقه مانند ۱۵ یا ۳۰ دقیقه قطع می‌شود، Session Timer جدی‌تر می‌شود. Session-Expires، Min-SE و refresher را بخوانید و حوالی زمان Refresh دنبال re-INVITE یا UPDATE بگردید.

در کنار آن State Table تجهیزات شبکه را بررسی کنید. Firewall یا NAT می‌تواند SIP Connection را قبل از Refresh از بین ببرد؛ در چنین شرایطی RTP ممکن است تا لحظه Refresh کاملاً سالم باشد ولی Signaling بعدی Fail شود.

در نهایت همیشه اولین BYE، آخرین SIP Request موفق و آخرین Packetهای قبل از قطع را بررسی کنید. زمان قطع به شما سرنخ می‌دهد، اما Packet Trace مشخص می‌کند علت واقعی ACK، Session Timer، NAT یا Firewall بوده است.