برای عیب‌یابی تماس ورودی در Issabel، مسیر را به چهار بخش تقسیم کنید: رسیدن درخواست تماس، شناسایی ترانک، تطبیق شمارهٔ مقصد با مسیر ورودی و اجرای مقصد نهایی. ثبت‌شدن ترانک یا موفقیت تماس خروجی، هیچ‌کدام به‌تنهایی ثابت نمی‌کنند تماس ورودی این چهار مرحله را طی کرده است. از اولین مرحله‌ای شروع کنید که شاهد معتبر برای عبور از آن ندارید.
این راهنما برای مدیران Issabel 5 و پشتیبانان مرکز تلفن است. هدف، رسیدن به تشخیص مستند پیش از تغییر تنظیمات است؛ نه ارائهٔ یک تنظیم ترانک یکسان برای همهٔ اپراتورها. مثال‌ها آموزشی‌اند و نتیجهٔ آزمایش روی شبکهٔ مشتری محسوب نمی‌شوند. برای مرور اصطلاحات پایه، راهنمای مفاهیم و تجهیزات VoIP را ببینید.
پیش از شروع، نسخه و دامنهٔ رخداد را مشخص کنید
اعلامیهٔ رسمی انتشار Issabel 5 در سال ۲۰۲۴، گزینه‌های Asterisk 16 و 18 را معرفی می‌کند؛ این سابقهٔ انتشار، نسخهٔ نصب فعلی شما را تعیین نمی‌کند. نسخهٔ واقعی و درایور ترانک را ثبت کنید. راهنمای رسمی Issabel نیز وجود دو درایور chan_sip و PJSIP را توضیح می‌دهد. فرمان مربوط به یک درایور ممکن است روی نصب دیگری موجود نباشد.
از نشست مدیریتی مجاز، فرمان‌های زیر را در پوستهٔ سیستم اجرا کنید. این فرمان‌ها وضعیت را می‌خوانند:
asterisk -rx 'core show version'
asterisk -rx 'module show like chan_sip.so'
asterisk -rx 'module show like chan_pjsip.so'زمان دقیق با منطقهٔ زمانی، شمارهٔ مقصد، مبدأ ماسک‌شده و نتیجهٔ شنیده‌شده را برای یک تماس نمونه یادداشت کنید. آیا همهٔ شماره‌ها مشکل دارند یا فقط یک DID؟ آیا تماس داخلی به مقصد نهایی موفق است؟ اگر مشکل پس از تغییر اپراتور، ترانک یا شماره رخ داده، آن تغییر فرضیهٔ مهمی است؛ هنوز علت قطعی نیست. تنظیمات مسیر و ترانک را پیش از اصلاح، با ابزار پشتیبان‌گیری معتبر همان نصب ذخیره و امکان بازگشت را بررسی کنید.
چهار مرز تشخیص را از هم جدا کنید
| مرز | شاهد مورد نیاز | پرسش بعدی |
|---|---|---|
| ورود درخواست | مشاهدهٔ INVITE همان تماس در نقطهٔ دریافت | آیا درخواست به سرویس صحیح رسیده است؟ |
| شناسایی ترانک | انتساب درخواست به peer یا endpoint مورد انتظار | آیا تماس از ورودی معتبر پذیرفته می‌شود؟ |
| تطبیق مسیر | شماره و context در اجرای dialplan | کدام قانون DID/CID انتخاب شده است؟ |
| مقصد نهایی | رسیدن اجرا به داخلی، IVR یا صف انتخابی | آیا خود مقصد آمادهٔ پاسخ‌گویی است؟ |
این جدول، ترتیب پیشنهادی تشخیص است. پیام «شماره در دسترس نیست» یا پاسخ SIP به‌تنهایی مرز خرابی را تعیین نمی‌کند؛ باید با مسیر همان تماس تطبیق داده شود. شناسهٔ Call-ID برای دنبال‌کردن پیام‌های یک گفت‌وگوی SIP مفید است؛ در مسیرهای چندبخشی، ارتباط میان بخش‌ها را نیز از زمان و کانال اجرایی دنبال کنید.
گام اول: رسیدن تماس و شناسایی ترانک را بررسی کنید
یک تماس کنترل‌شده از بیرون بگیرید و فقط بازهٔ کوتاه آن را مشاهده کنید. اگر در لاگ Asterisk چیزی دیده نمی‌شود، ابتدا مطمئن شوید ثبت پیام برای درایور و transport درست فعال است؛ نبودن پیام در ابزار نامناسب، نبودن بسته در شبکه را ثابت نمی‌کند. سپس مسیر تحویل اپراتور، تجهیز مرزی، فایروال و درگاه شنود را بر اساس طراحی واقعی بررسی کنید. موفقیت REGISTER فقط یک شاهد دربارهٔ ثبت حساب است؛ قرارداد برخی ترانک‌ها نیز مبتنی بر IP است و اصلاً ثبت حساب ندارند.
در PJSIP، خطای No matching endpoint found به مرحلهٔ شناسایی درخواست مربوط است؛ تغییر DID در فرم Inbound Routes راه‌حل مستقیم آن نیست. مستند Asterisk توضیح می‌دهد که تطبیق درخواست با endpoint می‌تواند بر مبنای سازوکارهای شناسایی مانند کاربر یا IP انجام شود. شیوهٔ درست را از قرارداد اپراتور و تنظیم واقعی ترانک تعیین کنید؛ پذیرش ناشناس یا بازکردن دسترسی عمومی را به‌عنوان راه میان‌بر فعال نکنید.
مشاهدهٔ موقت؛ با فرمان همان درایور
برای مشاهدهٔ زنده، با asterisk -r وارد کنسول شوید. ابتدا راهنمای فرمان را بخوانید و سپس فقط بلوک متناسب با ترانک را اجرا کنید:
; PJSIP — Asterisk CLI
core show help pjsip set logger
pjsip set logger on
; Place one controlled test call, then stop tracing.
pjsip set logger off; chan_sip — Asterisk CLI, only if this driver is loaded
core show help sip set debug
sip set debug on
; Place one controlled test call, then stop tracing.
sip set debug offخط‌های آغازشده با نقطه‌ویرگول در این نمونه توضیح‌اند؛ فرمان کنسول نیستند. ثبت پیام SIP می‌تواند شماره‌ها، هدرهای احراز هویت و مشخصات شبکه را آشکار کند و در سامانهٔ پرترافیک خروجی زیادی بسازد. فقط در بازهٔ مجاز، با دسترسی محدود و نگهداری کوتاه استفاده کنید؛ پیش از اشتراک، داده‌های حساس را پاک‌سازی و در پایان ثبت اضافه را خاموش کنید. سطح debug سراسری و سرویس را برای شروع این تشخیص تغییر ندهید.
گام دوم: DID واقعی را با قانون ورودی تطبیق دهید
DID شمارهٔ مقصدی است که برای مسیریابی تماس ورودی استفاده می‌شود؛ CID شناسهٔ تماس‌گیرنده است. آن‌ها را جابه‌جا نکنید. شماره‌ای که مشتری می‌گیرد ممکن است با قالب تحویلی اپراتور یا مقدار نهاییِ واردشده به منطق مسیریابی تفاوت داشته باشد. به‌جای حدس‌زدن پیش‌شماره، مقدار مشاهده‌شده در اجرای dialplan را با قرارداد تحویل شماره مقایسه کنید.
Request-URI و هدر To را در پیام اولیه ببینید، اما فرض نکنید در همهٔ ترانک‌ها یکی از آن‌ها بدون تبدیل به DID نهایی تبدیل می‌شود. تنظیم ترانک و context می‌تواند در این مسیر نقش داشته باشد. از لاگ اجرای همان تماس، شمارهٔ extension و context را پیدا کنید؛ در صورت نیاز، نحو فرمان مشاهده را روی همان نسخه بپرسید:
asterisk -rx 'core show help dialplan show'
asterisk -rx 'dialplan show'خروجی کامل dialplan ممکن است حجیم و دارای اطلاعات داخلی باشد؛ آن را عمومی منتشر نکنید. context مشاهده‌شده را بررسی کنید؛ نام ثابتی مانند from-trunk را برای همهٔ نصب‌ها فرض نکنید. فایل‌های ساخته‌شده توسط پنل را برای اصلاح مسیر مستقیم ویرایش نکنید؛ تغییر بعدی پنل می‌تواند آن اصلاح را بازنویسی کند.
در بخش PBX → PBX Configuration، فرم Inbound Routes را پیدا کنید؛ گروه‌بندی منوها با نسخه و رابط نصب تفاوت دارد. طبق راهنمای رسمی، فیلد DID معیار شمارهٔ مقصد، Caller ID Number معیار تماس‌گیرنده و Destination مقصد اجراست. اگر محدودیت مبدأ عمداً طراحی نشده، CID را با شمارهٔ خط سازمان پر نکنید. همچنین گزینهٔ Caller ID Priority Route می‌تواند رفتار مسیرهای فقط-CID را تغییر دهد؛ قانون عمومی «اولین ردیف همیشه برنده است» نسازید.
مثال آموزشی: شمارهٔ درست، قالب متفاوت
فرض کنید در فرم مسیر ورودی مقدار ساختگی 21004567 ثبت شده، اما در اجرای تماس مقدار 9821004567 به منطق تطبیق می‌رسد. این اختلاف، نامزد مشخصی برای بررسی است. نخست تأیید کنید هر دو به یک سرویس تعلق دارند و قالب تحویلی ثابت است؛ سپس دربارهٔ اصلاح DID یا تبدیل کنترل‌شده در محل پشتیبانی‌شدهٔ همان نصب تصمیم بگیرید. این اعداد، شمارهٔ واقعی مشتری یا الگوی عمومی شماره‌گذاری ایران نیستند.
ساخت یک مسیر بدون DID و CID ممکن است باعث شود تماس‌های بیشتری به یک مقصد برسند، اما علت اختلاف قالب را برطرف نمی‌کند. روی مرکز چندشماره‌ای، چنین تغییری می‌تواند تماس‌های خطوط دیگر را منحرف کند. اگر آزمون مسیر عمومی ضرورت دارد، آن را به محیط آزمایش یا پنجرهٔ مصوب با طرح بازگشت محدود کنید؛ مسیر دائمی را با معیار روشن بسازید.
گام سوم: مقصد را مستقل از مسیر ورودی آزمایش کنید
وقتی اجرای تماس به Destination درست رسیده، روی همان مقصد تمرکز کنید. داخلی را از یک داخلی دیگر صدا بزنید؛ ثبت دستگاه، حالت مزاحم‌نشدن و انتقال تماس را بررسی کنید. برای IVR، وجود پیام، مقصد خطا و مقصد پایان انتظار را ببینید. برای صف، حضور اعضای قابل پاسخ و رفتار صفِ بدون پاسخ‌گو را مطابق تنظیم واقعی کنترل کنید. اگر Time Condition در زنجیره است، زمان محلی و مسیر هر شاخه را جدا آزمایش کنید.
زنگ‌خوردن داخلی بدون صدای دوطرفه، مرحلهٔ متفاوتی است. پس از اثبات رسیدن تماس به مقصد، برای مسئلهٔ رسانه از راهنمای تشخیص صدای یک‌طرفه با SDP و RTP استفاده کنید. دست‌کاری هم‌زمان کدک، NAT و DID تشخیص را مبهم می‌کند و ممکن است تماس‌های سالم را نیز تحت تأثیر بگذارد.
معیار پایان کار و ثبت نتیجه
اصلاح را با همان سناریوی اولیه تکرار کنید و یک حالت سالم مجاور را نیز بسنجید: شمارهٔ دیگر، مبدأ دیگر یا شاخهٔ زمانی مرتبط. فقط شنیدن بوق آزاد کافی نیست؛ مقصد مورد انتظار باید پاسخ دهد، صدای دوطرفه برقرار باشد و خطوط دیگر منحرف نشده باشند. اگر آزمایش کامل ممکن نیست، همان محدودیت را در گزارش بنویسید.
گزارش نهایی باید نسخه، سناریو، اولین مرز ناموفق، شاهد، تغییر محدود، نتیجهٔ آزمون و روش بازگشت را داشته باشد. فرضیهٔ «احتمال اختلاف قالب DID» را از مشاهدهٔ «مقدار ورودی با قانون برابر نبود» جدا کنید. برای بررسی تخصصی، با تیم آسیاپرداز تماس بگیرید و شرح پاک‌سازی‌شدهٔ رخداد را ارائه کنید؛ رمز ترانک و فایل کامل تنظیمات را همراه درخواست عمومی نفرستید.
منابع و محدودهٔ اعتبار
بررسی منابع در ۴ نوامبر ۲۰۲۶ انجام شد. این مقاله نصب، ارتقا یا پشتیبانی امنیتی نسخه‌های قدیمی Asterisk را توصیه نمی‌کند؛ برای هر نصب، مستندات و وضعیت پشتیبانی نسخهٔ واقعی باید جدا بررسی شود. هیچ تغییر یا تماس آزمایشی روی مرکز تلفن تولیدی در تدوین این مطلب انجام نشده است.