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

برای تماس ورودی یک مرحله دیگر لازم است: PBX باید بداند درخواست INVITE را به کدام Contact، IP و Port بفرستد. سپس NAT و Firewall باید اجازه دهند INVITE به Cisco برسد و خود Phone نیز نباید تماس را به‌دلیل DND، Call Forward، وضعیت Line یا Policy رد کند.

اگر Cisco Enterprise روی CUCM دارید، مسیر متفاوت است. ممکن است Phone کاملاً Registered باشد اما SIP Trunk یا Gateway به‌دلیل Calling Search Space نامناسب نتواند Partition داخلی را ببیند، شماره ورودی با DN تطبیق نداشته باشد یا Translation Pattern اشتباه باشد.

در این راهنما به‌جای تغییر تصادفی تنظیمات، تماس را مرحله‌به‌مرحله دنبال می‌کنیم: از Provider و PBX تا Route، Contact، NAT و در نهایت خود Cisco Phone. هدف این است که دقیقاً مشخص شود تماس در کدام نقطه متوقف می‌شود.

Registered بودن دقیقاً چه چیزی را ثابت می‌کند؟

در یک Cisco MPP روی Asterisk یا FreePBX، Registration معمولاً چیزی شبیه این است:

Cisco Phone              PBX
     |                     |
     |----- REGISTER ----->|
     |<---- 401 -----------|
     |                     |
     |-- REGISTER + Auth ->|
     |<---- 200 OK --------|
     |                     |

این روند نشان می‌دهد PBX Registration را پذیرفته است.

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

Caller
   |
   | INVITE
   v
PBX
   |
   | Route lookup
   |
   | Find Contact for 201
   |
   | INVITE
   v
Cisco Phone

اگر هر کدام از این مراحل خراب باشد، Phone می‌تواند Registered باقی بماند اما هیچ Ring دریافت نکند.

اول مشخص کنید مشکل دقیقاً چه نوعی است

درخت تصمیم اصلی عیب‌یابی

برای هر تماس خراب فقط این سؤال‌ها را به ترتیب پاسخ دهید.

شاخه اول: Cisco MPP روی Asterisk یا FreePBX

اگر Cisco 8841، 8851 یا مدل دیگری با MPP/3PCC دارید و روی Asterisk یا FreePBX رجیستر شده است، اولین بخش مهم Contact ثبت‌شده برای Extension است.

Contact چیست و چرا برای تماس ورودی مهم است؟

هنگام REGISTER، تلفن یک Contact URI به PBX معرفی می‌کند.

مثلاً:

Contact: <sip:201@192.168.20.45:5060>

Asterisk این Contact را داخل AoR مربوط به 201 ذخیره می‌کند.

وقتی کسی با 201 تماس می‌گیرد، Asterisk از همین Contact برای پیدا کردن مقصد SIP استفاده می‌کند.

Contact فعلی را روی Asterisk ببینید

asterisk -rx "pjsip show contacts"

یا برای Extension مشخص:

asterisk -rx "pjsip show aor 201"

و Endpoint:

asterisk -rx "pjsip show endpoint 201"

Registered است اما Contact اشتباه است

این یکی از کلاسیک‌ترین سناریوهاست.

Cisco در شبکه Remote این IP را دارد:

192.168.1.50

و پشت NAT با Public IP زیر دیده می‌شود:

203.0.113.25:42816

اما PBX Contact را این‌طور ذخیره کرده است:

sip:201@192.168.1.50:5060

Asterisk روی اینترنت نمی‌تواند INVITE جدید را به 192.168.1.50 ارسال کند.

در نتیجه Phone همچنان Registered دیده می‌شود ولی تماس ورودی به آن نمی‌رسد.

rewrite_contact در PJSIP برای همین مشکل است

Asterisk برای Endpoint پشت NAT گزینه زیر را دارد:

rewrite_contact=yes

این گزینه باعث می‌شود Contact برای درخواست‌های بعدی با IP و Port واقعی مبدأ SIP بازنویسی شود.

برای یک Cisco Remote معمولاً NAT Profile نیازمند بررسی این گزینه‌هاست:

rewrite_contact=yes
force_rport=yes
rtp_symmetric=yes

اما برای مشکل «تماس ورودی اصلاً به Phone نمی‌رسد»، مهم‌ترین مورد از این سه گزینه معمولاً Contact و Signaling است؛ `rtp_symmetric` بیشتر روی Media اثر دارد.

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

فرض کنید Router بعد از مدتی NAT Port تلفن را از:

203.0.113.25:42816

به این مقدار تغییر دهد:

203.0.113.25:51742

اگر AoR چند Contact قدیمی داشته باشد، PBX ممکن است مسیر نامناسبی برای تماس انتخاب کند.

برای یک Cisco معمولاً چند Contact لازم است؟

اگر Extension فقط روی یک Phone استفاده می‌شود، طراحی ساده می‌تواند چنین باشد:

max_contacts=1
remove_existing=yes

Asterisk نیز هشدار می‌دهد هنگام استفاده از `rewrite_contact`، تغییر Source Port می‌تواند Contact جدید ایجاد کند و با Max Contacts تداخل داشته باشد؛ `remove_existing` یا `remove_unavailable` می‌توانند در طراحی مناسب به پاک‌سازی Contactهای قدیمی کمک کنند.

Registration Expires و NAT Mapping را فراموش نکنید

ممکن است Phone هر یک ساعت REGISTER کند ولی Router NAT Binding را زودتر حذف کند.

در این شرایط روی PBX هنوز Registration وجود دارد، ولی INVITE جدید به Mapping منقضی‌شده ارسال می‌شود.

این سناریو معمولاً چنین الگویی دارد:

اگر چنین الگویی دارید، Keepalive، Registration Interval و NAT Timeout را هم‌زمان بررسی کنید.

مرحله بعد: آیا PBX واقعاً INVITE را به Cisco ارسال می‌کند؟

روی Asterisk CLI:

asterisk -rvvv

سپس:

pjsip set logger on

حالا از داخلی دیگری با Cisco تماس بگیرید.

سناریوی سالم

PBX -------- INVITE --------> Cisco
PBX <------- 100 Trying ---- Cisco
PBX <------- 180 Ringing --- Cisco
PBX <------- 200 OK -------- Cisco

اگر 180 Ringing می‌بینید، تماس تا خود Phone رسیده است.

در آن مرحله مشکل دیگر Inbound Route یا Contact نیست.

اگر PBX INVITE می‌فرستد ولی هیچ پاسخی نمی‌گیرد

این وضعیت معمولاً مسیر را به این موارد محدود می‌کند:

Contact اشتباه، NAT، Firewall، Route شبکه، SIP ALG یا بسته‌شدن Mapping.

Packet Capture روی Phone و PBX بگیرید و همان INVITE را در دو سمت مقایسه کنید.

اگر Cisco با 486 Busy Here پاسخ می‌دهد

Phone INVITE را دریافت کرده اما Line را Busy تشخیص داده است.

در این مرحله بررسی کنید:

آیا تماس دیگری فعال است؟

Call Waiting غیرفعال شده؟

حد تماس Line پر شده؟

Call Forward Busy فعال است؟

یا PBX Device State را Busy می‌بیند؟

اگر 480 یا 603 دریافت می‌کنید

بسته به PBX، Firmware و Feature فعال، DND یا Policyهای Call Handling ممکن است پاسخ‌هایی مانند Temporarily Unavailable یا Decline ایجاد کنند.

این Response Codeها را به‌عنوان سرنخ ببینید، نه یک تشخیص قطعی مستقل از Log تلفن.

DND روی Cisco MPP را بررسی کنید

Cisco MPP اجازه می‌دهد Do Not Disturb روی همه Lineها یا فقط یک Line مشخص فعال شود.

اگر DND روشن باشد، کاربر ممکن است هیچ Ring عادی دریافت نکند و تماس بسته به تنظیمات به مقصد دیگری مثل Voicemail هدایت شود.

روی صفحه تلفن دنبال عبارت:

Do not disturb

یا آیکن DND بگردید.

DND مخصوص همان Line را هم بررسی کنید

روی Multiline Phone ممکن است DND فقط برای Extension مشکل‌دار فعال باشد.

در منوی Phone:

User preferences → Call preferences → Do not disturb

Line مربوط را بررسی کنید.

Feature Key Sync می‌تواند وضعیت DND را از PBX بگیرد

در MPP اگر Feature Key Sync یا FKS فعال باشد، وضعیت DND می‌تواند میان Phone و Server همگام شود.

یعنی فقط نگاه‌کردن به یک Setting محلی همیشه کافی نیست؛ PBX نیز ممکن است وضعیت Feature را مدیریت کند.

Call Forward All را بررسی کنید

اگر تماس هرگز روی Cisco Ring نمی‌شود ولی بلافاصله به Voicemail یا Extension دیگری می‌رود، یکی از اولین مظنون‌ها Call Forward All است.

در Cisco MPP:

User Login → Voice → User → Call Forward

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

Cfwd All
Cfwd All Dest
Cfwd Busy
Cfwd Busy Dest
Cfwd No Answer
Cfwd No Ans Dest

FKS و XSI می‌توانند Call Forward محلی را Override کنند

در MPP جدید، Cisco برای Call Forward سه منبع وضعیت دارد:

FKS، XSI و Local Setting.

در مستند Cisco اولویت به این شکل تعریف شده است:

FKS
 ↓
XSI
 ↓
Local

پس ممکن است Local Setting را خاموش ببینید اما Server Sync رفتار تماس را تغییر داده باشد.

Line درست Registered است؟

در Cisco 8841 یا 8851 ممکن است چند Extension داشته باشید.

عبارت Registered روی یک Line ثابت نمی‌کند همان Extensionی که تماس می‌گیرد Registered است.

برای مثال:

اگر تماس برای 202 می‌آید، سبز بودن Line 1 هیچ کمکی نمی‌کند.

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

این یکی از بهترین سرنخ‌هاست.

اگر:

Extension 202 → Cisco 201 = OK
PSTN DID → Cisco 201       = FAIL

خود Cisco، Contact و Line احتمالاً سالم‌اند.

تمرکز را به Trunk و Inbound Route منتقل کنید.

مرحله بعد: آیا Provider اصلاً INVITE را به FreePBX می‌فرستد؟

در Asterisk:

pjsip set logger on

از موبایل با DID تماس بگیرید.

اولین سؤال:

آیا INVITE Provider داخل CLI دیده می‌شود؟

اگر INVITE اصلاً وارد PBX نمی‌شود

در این مرحله Cisco Phone تقریباً از عیب‌یابی خارج است.

بررسی کنید:

Trunk Provider، Public IP، Port Forward، Firewall، Provider ACL و Registration خود Trunk.

اگر INVITE وارد PBX می‌شود، DID واقعی را بخوانید

ممکن است شما Inbound Route را برای این شماره ساخته باشید:

02191302467

اما Provider شماره را این‌طور تحویل دهد:

982191302467

یا:

+982191302467

Route شما در این حالت ممکن است Match نشود.

Inbound Route در FreePBX را بررسی کنید

مسیر معمول:

Connectivity → Inbound Routes

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

FreePBX دقیقاً از Inbound Route برای تعیین مقصد تماس‌هایی استفاده می‌کند که از Trunk وارد PBX شده‌اند.

Any/Any Route فقط برای تشخیص موقت

اگر نمی‌دانید Provider DID را با چه فرمتی ارسال می‌کند، می‌توانید در یک محیط کنترل‌شده موقتاً Route بدون DID Match بسازید و آن را به Extension آزمایشی بفرستید.

اگر تماس ناگهان برقرار شد، مشکل از DID Matching است.

این Route عمومی را روی PBX دارای چند Trunk به‌عنوان راه‌حل دائمی رها نکنید، چون ممکن است تماس‌های دیگر را اشتباه Capture کند.

اگر تماس وارد Asterisk می‌شود ولی Endpoint Match نمی‌شود

برای Trunkهای PJSIP، Asterisk باید بداند INVITE ورودی متعلق به کدام Endpoint است.

این کار می‌تواند بر اساس Source IP انجام شود.

نمونه:

[provider-identify]
type=identify
endpoint=provider
match=203.0.113.50

اگر Provider چند IP دارد، تمام Sourceهای معتبر باید مطابق طراحی Trunk در نظر گرفته شوند.

Registered Trunk هم می‌تواند تماس ورودی نداشته باشد

Registration خروجی PBX به Provider و شناسایی INVITE ورودی دو موضوع جدا هستند.

Asterisk برای Outbound Registration حتی گزینه‌هایی مثل `endpoint` و `line` دارد تا تماس‌های مرتبط با Registration به Endpoint مناسب نسبت داده شوند.

بنابراین دیدن:

Registered

برای Trunk نیز به‌تنهایی تضمین نمی‌کند Inbound Call Routing صحیح است.

اگر Cisco پشت NAT است ولی داخل LAN تماس ورودی دارد

مثلاً:

Cisco in office LAN → OK
Cisco remote behind NAT → FAIL

این مقایسه Contact و NAT را بسیار پررنگ می‌کند.

مقادیر `pjsip show contacts` دو دستگاه را کنار هم قرار دهید و Public Source Address و Port را مقایسه کنید.

SIP ALG می‌تواند Registration را سالم و INVITE را خراب کند

گاهی Router روی REGISTER و Contact Header دخالت می‌کند، ولی رفتار Rewrite آن برای INVITEهای بعدی سازگار نیست.

برای اثبات SIP ALG، Packet Capture در دو سمت Router بگیرید و Contact Header و مقصد INVITE را مقایسه کنید.

به‌جای خاموش‌کردن تصادفی Featureها، مشخص کنید Router دقیقاً چه چیزی را تغییر داده است.

شاخه دوم: Cisco Enterprise روی CUCM Registered است ولی Ring نمی‌خورد

اگر Cisco Enterprise Firmware دارید و Phone در CUCM با Status Registered دیده می‌شود، Contact SIP مشابه MPP اولین نقطه عیب‌یابی شما نیست.

باید مسیر Digit Analysis، DN، Partition، CSS، Translation و Trunk/Gateway را بررسی کنید.

در CUCM اولین سؤال چیست؟

آیا تماس داخلی مستقیم به DN تلفن می‌رسد؟

مثلاً:

Extension 202 → DN 201 = OK

اگر این کار می‌کند ولی PSTN Call نه، Phone و DN احتمالاً سالم‌اند و باید Ingress Trunk/Gateway Routing بررسی شود.

Partition و CSS را درست درک کنید

در CUCM، DN می‌تواند داخل یک Partition قرار داشته باشد.

مثلاً:

DN: 201
Partition: PT_INTERNAL

برای اینکه تماس ورودی از یک SIP Trunk بتواند به این DN برسد، Calling Search Space مورد استفاده تماس باید Partition مربوط را در دسترس داشته باشد.

نمونه CSS صحیح

CSS_PSTN_IN
  └── PT_INTERNAL

اگر PT_INTERNAL داخل CSS تماس ورودی نباشد، CUCM ممکن است DN 201 را برای همان Call Leg قابل دسترس نداند.

Incoming CSS روی SIP Trunk را بررسی کنید

در CUCM Administration وارد SIP Trunk شوید و بخش Inbound Calls را بررسی کنید.

Calling Search Space آن باید متناسب با طراحی Dial Plan بتواند Destination داخلی موردنظر را ببیند.

این تنظیم را بدون فکر روی CSS بسیار باز قرار ندهید؛ CSS بخشی از Class of Service و امنیت Dial Plan است.

چرا تماس داخلی کار می‌کند ولی Trunk نمی‌تواند همان DN را بگیرد؟

چون Phone داخلی ممکن است CSSای داشته باشد که PT_INTERNAL را می‌بیند، اما SIP Trunk ورودی CSS متفاوتی داشته باشد.

پس این دو تماس از نظر CUCM Caller Context یکسان نیستند.

شماره‌ای که Provider تحویل می‌دهد با DN یکی نیست

مثلاً DN تلفن:

201

است، ولی Trunk شماره کامل را می‌فرستد:

02155550201

CUCM باید بداند این Called Number چگونه به DN 201 تبدیل شود.

Translation Pattern در Inbound Routing چه زمانی لازم است؟

اگر شماره ورودی نیاز به حذف Prefix، تبدیل E.164 یا نگاشت DID به Extension دارد، Translation Pattern یکی از ابزارهای مناسب CUCM است.

مثلاً:

Incoming:
02155550201

Translated:
201

Partition خود Translation Pattern نیز باید توسط CSS تماس ورودی قابل مشاهده باشد.

Route Pattern را با Translation Pattern اشتباه نگیرید

Route Pattern معمولاً برای انتخاب مسیر تماس به Gateway، Trunk یا Route List استفاده می‌شود.

اگر PSTN Call وارد CUCM شده و قرار است مستقیم به DN داخلی برسد، مسئله اصلی معمولاً Incoming CSS، Partition و Digit Transformation است، نه ساختن یک Route Pattern تصادفی.

Route Pattern زمانی وارد مسیر می‌شود که Dialed Number پس از Digit Analysis باید دوباره به یک مسیر Off-Net، Trunk یا Route List هدایت شود.

Significant Digits و Called Number Transformation را بررسی کنید

اگر SIP Trunk یا Gateway بخشی از Digits را حذف یا Prefix اضافه می‌کند، Numberی که CUCM واقعاً تحلیل می‌کند ممکن است با چیزی که انتظار دارید متفاوت باشد.

برای عیب‌یابی ابتدا Called Party Number واقعی را از Trace یا SIP INVITE ثبت کنید.

DND روی Cisco Enterprise

Cisco Enterprise نیز DND دارد.

در CUCM می‌توان DND را با رفتارهایی مانند:

Ring Off
Call Reject

تنظیم کرد.

پس Registered بودن Phone باز هم تضمین نمی‌کند Incoming Call روی دستگاه Ring شود.

Call Forward در CUCM را بررسی کنید

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

Call Forward All
Call Forward Busy
Call Forward No Answer
Call Forward Unregistered

اگر CFA فعال باشد، طبیعی است که Cisco زنگ نخورد.

Call Forward Unregistered را با مشکل Registration اشتباه نگیرید

گاهی Phone لحظه‌ای Registration را از دست می‌دهد و CUCM تماس را طبق CFUR به مقصد دیگری هدایت می‌کند.

کاربر ممکن است فقط بگوید «بعضی وقت‌ها Cisco زنگ نمی‌خورد».

در این سناریو Registration History و Eventها را هم بررسی کنید.

Shared Line و Hunt Pilot را هم در نظر بگیرید

اگر DN روی چند Device به‌صورت Shared Line قرار دارد یا تماس از Hunt Pilot وارد می‌شود، رفتار Ring فقط به Phone واحد بستگی ندارد.

Line Group، Distribution Algorithm، RNA Reversion و Login Status اعضای Hunt نیز می‌توانند مسیر تماس را تغییر دهند.

روش حرفه‌ای: پاسخ SIP را در هر مرحله ثبت کنید

برای MPP/SIP، Responseها می‌توانند سریع مشخص کنند مشکل کجاست.

Packet Capture را کجا بگیریم؟

اگر Log به نتیجه نرسید، Capture را در نقاط مختلف بگیرید.

Wireshark Filterهای مفید

فقط SIP:

sip

فقط INVITE:

sip.Method == "INVITE"

IP تلفن:

ip.addr == 192.168.20.45

Call-ID را برای دنبال‌کردن همان تماس استفاده کنید

از INVITE ورودی Call-ID را پیدا کنید.

مثلاً:

sip.Call-ID == "abc123@example.net"

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

سناریوی ۱: Cisco Registered است و تماس خروجی دارد، اما هیچ تماس ورودی داخلی ندارد

اول `pjsip show contacts` را بررسی کنید.

بعد از داخلی دیگر تماس بگیرید و با SIP Logger ببینید Asterisk INVITE را به چه IP و Portی می‌فرستد.

اگر INVITE به Contact قدیمی یا Private IP Remote Phone ارسال می‌شود، NAT/Contact مسئله اصلی است.

سناریوی ۲: فقط بعد از مدتی Idle تماس ورودی از کار می‌افتد

NAT Mapping و Keepalive را در اولویت قرار دهید.

اگر تماس خروجی از Cisco باعث می‌شود Incoming دوباره موقتاً درست شود، این الگو تقریباً مستقیماً به NAT Binding اشاره می‌کند.

سناریوی ۳: تماس داخلی سالم است ولی DID خارجی نمی‌رسد

خود Cisco را فعلاً کنار بگذارید.

INVITE ورودی Provider، DID Format و FreePBX Inbound Route را بررسی کنید.

سناریوی ۴: تماس بیرونی وارد FreePBX می‌شود ولی به Extension دیگری می‌رود

Inbound Route Destination، Time Condition، IVR، Ring Group و DID Matching را بررسی کنید.

ممکن است Route عمومی‌تر قبل از Route موردنظر Match شده باشد.

سناریوی ۵: Cisco Ring نمی‌خورد ولی تماس فوراً Voicemail می‌شود

DND، Call Forward All، Call Forward Busy و وضعیت PBX را بررسی کنید.

در MPP وضعیت FKS/XSI را هم در نظر بگیرید.

سناریوی ۶: فقط یکی از چند Line روی Cisco تماس ورودی ندارد

Registration State همان Line، Extension Mapping، DND per-line و Call Forward مخصوص همان Line را بررسی کنید.

سناریوی ۷: Cisco Enterprise داخلی کار می‌کند ولی PSTN نه

Incoming CSS روی SIP Trunk یا Gateway، Partition مقصد و Digit Transformation را بررسی کنید.

اگر Provider شماره کامل می‌فرستد ولی DN داخلی کوتاه است، Translation Pattern احتمالاً بخشی از راه‌حل است.

سناریوی ۸: CUCM Phone Registered است ولی 404 یا Not Found دریافت می‌کنید

Called Number واقعی، DN، Partition، CSS و Translation Pattern را مقایسه کنید.

Registered بودن Phone ثابت نمی‌کند Digit Analysis تماس ورودی Destination را پیدا می‌کند.

سناریوی ۹: با حذف Partition تماس ناگهان کار می‌کند

این نتیجه معمولاً نشان می‌دهد Call Leg ورودی CSS مناسب برای دیدن Partition مقصد ندارد.

راه‌حل اصولی حذف Partition از DN نیست؛ CSS درست را به تماس ورودی بدهید.

سناریوی ۱۰: Phone پاسخ 180 Ringing می‌دهد ولی صدای زنگ ندارد

در این حالت Routing تا Phone سالم است.

حالا Ringer Volume، Ringtone، DND Mode، Headset Hookswitch و Local Phone Behavior را بررسی کنید.

این سناریو دیگر مشکل Inbound Route نیست.

سناریوی ۱۱: تماس فقط از بعضی شماره‌های PSTN نمی‌آید

CallerID-based Route، Provider Filtering، Translation Rule و Route Patternهای خاص را بررسی کنید.

یک تماس سالم و یک تماس خراب را با هم Capture کنید و Called/Calling Headerها را مقایسه کنید.

سناریوی ۱۲: تماس فقط روی یک اینترنت یا Router خاص نمی‌آید

Contact، NAT Mapping، SIP ALG و Firewall را میان دو شبکه مقایسه کنید.

این تست بسیار باارزش است چون Phone و PBX ثابت می‌مانند و فقط Network Path تغییر می‌کند.

چک‌لیست نهایی MPP / FreePBX

چک‌لیست نهایی Enterprise / CUCM

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

چرا Cisco Registered است ولی تماس ورودی ندارد؟

Registration فقط ارتباط Phone با Registrar را ثابت می‌کند. Contact اشتباه، NAT، Inbound Route، DND، Call Forward یا در CUCM مشکل CSS و Partition می‌توانند مانع تماس ورودی شوند.

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

PBX Contact ثبت‌شده را برای پیدا کردن IP و Port Endpoint استفاده می‌کند. اگر Contact پشت NAT اشتباه یا قدیمی باشد، INVITE ممکن است هرگز به Cisco نرسد.

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

این گزینه Contact ورودی Endpoint را با Source IP و Port واقعی درخواست SIP بازنویسی می‌کند تا درخواست‌های بعدی به مسیر قابل دسترس‌تری ارسال شوند.

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

این رفتار معمولاً می‌تواند نشانه NAT Mapping منقضی‌شده باشد. تماس خروجی Mapping را دوباره ایجاد می‌کند و برای مدتی INVITE ورودی قابل عبور می‌شود.

چرا تماس داخلی Cisco کار می‌کند ولی تماس از بیرون نمی‌آید؟

در این حالت Cisco و Contact احتمالاً سالم‌اند. Trunk، DID Format، Inbound Route و مسیر تماس PSTN را بررسی کنید.

DND می‌تواند باعث شود Cisco اصلاً زنگ نخورد؟

بله. در MPP، DND می‌تواند برای همه Lineها یا یک Line فعال شود و تماس بسته به تنظیمات به مقصدی مانند Voicemail هدایت شود.

چرا Call Forward خاموش است ولی تماس هنوز Redirect می‌شود؟

در بعضی MPPها FKS یا XSI می‌توانند وضعیت Feature را از Server همگام کنند و اولویت آن‌ها از تنظیم Local بیشتر باشد.

در CUCM چرا Phone Registered است ولی PSTN به آن نمی‌رسد؟

Incoming CSS روی Trunk/Gateway ممکن است Partition DN را نبیند یا Called Number ورودی نیاز به Translation داشته باشد.

آیا برای تماس ورودی CUCM باید Route Pattern بسازیم؟

نه همیشه. اگر تماس قرار است مستقیماً به DN داخلی برسد، Incoming CSS، Partition و Translation Pattern معمولاً مهم‌ترند. Route Pattern زمانی لازم می‌شود که Number باید به Trunk، Gateway یا Route List هدایت شود.

چطور بفهمیم INVITE به Cisco می‌رسد؟

روی PBX SIP Logger و در صورت نیاز روی Phone یا Network Packet Capture بگیرید. اگر Phone پاسخ 100 Trying یا 180 Ringing بدهد، INVITE تا Endpoint رسیده است.

اگر PBX INVITE می‌فرستد ولی Cisco هیچ پاسخی ندارد چه؟

Contact، NAT، Firewall، SIP ALG و Route شبکه را بررسی کنید. مقصد IP و Port INVITE را با Source واقعی آخرین REGISTER مقایسه کنید.

Any/Any Inbound Route در FreePBX مناسب است؟

برای تست کوتاه و کنترل‌شده می‌تواند به تشخیص DID Matching کمک کند، اما روی سیستم Production با چند Trunk بهتر است Route دقیق برای DIDها تعریف شود.

جمع‌بندی

وقتی Cisco IP Phone Registered است اما تماس ورودی ندارد، خود Registration را پایان عیب‌یابی ندانید. در MPP ابتدا Contact را بررسی کنید؛ PBX باید INVITE را به IP و Portی بفرستد که واقعاً از سمت Phone قابل دسترس است. برای Endpointهای پشت NAT، `rewrite_contact` و مدیریت Contactهای قدیمی اهمیت زیادی دارند.

بعد بررسی کنید آیا تماس اصلاً وارد PBX می‌شود، DID با Inbound Route تطبیق دارد و Destination به Extension درست اشاره می‌کند. اگر PBX INVITE را به Cisco ارسال می‌کند اما هیچ Response دریافت نمی‌کند، NAT و Firewall را بررسی کنید. اگر Phone 180 Ringing می‌دهد، Routing سالم است و باید سراغ DND، Call Forward یا رفتار محلی Phone بروید.

در Cisco Enterprise روی CUCM مسیر متفاوت است. Registered بودن Device تضمین نمی‌کند SIP Trunk یا Gateway اجازه دسترسی به DN را دارد. Incoming CSS باید Partition مقصد را ببیند و Called Number نیز باید بعد از Digit Manipulation یا Translation با DN قابل Route تطبیق پیدا کند.

مهم‌ترین روش این است که تماس را مرحله‌به‌مرحله دنبال کنید: Provider → Trunk → Route → PBX/CUCM → Contact یا DN → Cisco Phone. اولین نقطه‌ای که INVITE دیگر دیده نمی‌شود معمولاً همان جایی است که باید مشکل را حل کنید.