Amir Jabbari
برای تماس ورودی یک مرحله دیگر لازم است: 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 نمی‌رسد | Contact، Extension Route، DND و PBX |
| داخلی کار می‌کند ولی PSTN نه | Trunk، DID، Inbound Route یا CUCM Routing |
| فقط بعضی شماره‌ها نمی‌رسند | DID Pattern، Translation، Provider یا CSS |
| فقط Cisco Remote مشکل دارد | NAT، Contact، Firewall و Port Mapping |
| Phone زنگ نمی‌زند ولی Voicemail فعال می‌شود | DND، Call Forward یا Line State |
| INVITE به Phone می‌رسد ولی رد می‌شود | Response Code و تنظیمات خود Cisco |
درخت تصمیم اصلی عیب‌یابی
برای هر تماس خراب فقط این سؤال‌ها را به ترتیب پاسخ دهید.
| سؤال | اگر پاسخ خیر است |
|---|---|
| INVITE از Provider به PBX رسیده؟ | Provider، NAT، Firewall یا Trunk |
| PBX DID درست را دیده؟ | DID Format یا Provider |
| Inbound Route مقصد صحیح دارد؟ | Route را اصلاح کنید |
| Cisco Contact معتبر است؟ | Registration/NAT/Contact |
| PBX برای Cisco INVITE ارسال می‌کند؟ | Dialplan یا Endpoint Mapping |
| INVITE به خود Phone می‌رسد؟ | NAT، Firewall یا Contact |
| Phone پاسخ 180 Ringing می‌دهد؟ | DND، Forward، Busy یا Line State |
شاخه اول: 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:5060Asterisk روی اینترنت نمی‌تواند 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=yesAsterisk نیز هشدار می‌دهد هنگام استفاده از `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 منقضی‌شده ارسال می‌شود.
این سناریو معمولاً چنین الگویی دارد:
| رفتار | نتیجه |
|---|---|
| بلافاصله بعد از Register | تماس ورودی کار می‌کند |
| بعد از چند دقیقه Idle | تماس ورودی قطع می‌شود |
| بعد از تماس خروجی | مدتی دوباره درست می‌شود |
اگر چنین الگویی دارید، 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 DestFKS و 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 است.
برای مثال:
| Line | Extension | Status |
|---|---|---|
| Line 1 | 201 | Registered |
| Line 2 | 202 | Not 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یا:
+982191302467Route شما در این حالت ممکن است Match نشود.
Inbound Route در FreePBX را بررسی کنید
مسیر معمول:
Connectivity → Inbound Routes
در Route بررسی کنید:
| فیلد | بررسی |
|---|---|
| DID Number | با فرمت واقعی Provider یکسان باشد |
| CallerID Number | اگر نیاز ندارید بی‌دلیل محدود نشده باشد |
| Destination | Extension صحیح Cisco باشد |
| Time Conditions | تماس به مسیر دیگری هدایت نشود |
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 شماره کامل را می‌فرستد:
02155550201CUCM باید بداند این Called Number چگونه به DN 201 تبدیل شود.
Translation Pattern در Inbound Routing چه زمانی لازم است؟
اگر شماره ورودی نیاز به حذف Prefix، تبدیل E.164 یا نگاشت DID به Extension دارد، Translation Pattern یکی از ابزارهای مناسب CUCM است.
مثلاً:
Incoming:
02155550201
Translated:
201Partition خود 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ها می‌توانند سریع مشخص کنند مشکل کجاست.
| Response | برداشت اولیه |
|---|---|
| 100 Trying | Phone یا PBX درخواست را پردازش کرده |
| 180 Ringing | تماس تا Endpoint رسیده و Ring شده |
| 200 OK | تماس Answer شده |
| 404 Not Found | Destination یا Routing را بررسی کنید |
| 480 Temporarily Unavailable | Endpoint/Feature State بررسی شود |
| 486 Busy Here | Line Busy یا Call Handling |
| 603 Decline | Call Rejection یا Policy محتمل است |
| بدون Response | Contact/NAT/Firewall بسیار محتمل‌تر است |
Packet Capture را کجا بگیریم؟
اگر Log به نتیجه نرسید، Capture را در نقاط مختلف بگیرید.
| محل | سؤالی که پاسخ می‌دهد |
|---|---|
| Provider-facing Firewall | INVITE وارد شبکه شده؟ |
| PBX | Route و INVITE خروجی چیست؟ |
| Remote Router | INVITE از NAT عبور کرده؟ |
| Cisco Phone | Phone واقعاً INVITE را دریافت کرده؟ |
Wireshark Filterهای مفید
فقط SIP:
sipفقط INVITE:
sip.Method == "INVITE"IP تلفن:
ip.addr == 192.168.20.45Call-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
| بررسی | نتیجه مطلوب |
|---|---|
| Registration | Line صحیح Registered |
| AoR Contact | IP/Port قابل دسترس |
| rewrite_contact | متناسب با NAT |
| Stale Contact | وجود نداشته باشد |
| DND | خاموش |
| Call Forward | طبق طراحی |
| Inbound Route | DID صحیح و Destination درست |
| Trunk INVITE | وارد PBX شود |
| PBX → Cisco INVITE | به Contact واقعی ارسال شود |
| Phone Response | 100/180 یا Response قابل تحلیل |
چک‌لیست نهایی Enterprise / CUCM
| بررسی | نتیجه مطلوب |
|---|---|
| Phone Registration | Registered |
| DN | روی Device صحیح |
| Partition | در Dial Plan صحیح |
| Inbound CSS | Partition مقصد را ببیند |
| Called Digits | با DN/Pattern هماهنگ |
| Translation Pattern | در صورت نیاز صحیح |
| Route Pattern | فقط اگر مسیر تماس واقعاً به آن نیاز دارد |
| DND | رفتار مورد انتظار |
| Call Forward | مقصد ناخواسته نداشته باشد |
| Trace | Digit Analysis مسیر را تأیید کند |
پرسش‌های متداول درباره نرسیدن تماس ورودی 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 دیگر دیده نمی‌شود معمولاً همان جایی است که باید مشکل را حل کنید.
Contact، NAT، PBX و مسیر تماس را بر اساس Log بررسی کنید
اگر تلفن Cisco شما Registered است اما تماس ورودی روی MPP، FreePBX، Asterisk یا CUCM به مقصد نمی‌رسد، می‌توانید درخواست بررسی کانفیگ ثبت کنید تا مسیر تماس از Trunk تا Endpoint به‌صورت مرحله‌ای بررسی شود.
تماس با پشتیبانی ایرانیکاسرور
دیدگاه‌ها (۰)