برای عیب‌یابی ضبط مکالمه در Issabel، چهار پرسش را به‌ترتیب پاسخ دهید: آیا این تماس باید ضبط می‌شد؟ آیا موتور ضبط روی کانال مناسب اجرا شد؟ آیا فایل نهایی روی دیسک سالم است؟ آیا پنل همان فایل را پیدا می‌کند؟ نبود دکمهٔ پخش، نبود فایل و فایل بی‌صدا سه نشانهٔ متفاوت‌اند و الزاماً راه‌حل یکسانی ندارند.
این راهنما برای مدیر مرکز تلفن است و با بررسی‌های فقط‌خواندنی آغاز می‌شود. تماس آزمایشی را با هماهنگی طرفین و محتوای غیرمحرمانه انجام دهید. فایل صوتی و گزارش تماس را در سرویس عمومی بارگذاری نکنید؛ برای اشتراک شواهد، شناسه‌ها و شماره‌ها را پاک‌سازی کنید. تغییر سیاست ضبط، دسترسی و نگهداری باید مسئول مشخص و تأیید سازمان داشته باشد.
۱. نسخه و یک تماس نمونه را مشخص کنید
عنوان Issabel 5 به‌تنهایی نسخهٔ Asterisk را تعیین نمی‌کند. اعلام انتشار Issabel 5 انتخاب Asterisk 16 و 18 را ذکر می‌کند؛ این خبر مربوط به انتشار اولیه است و جای بررسی بستهٔ نصب‌شدهٔ امروز را نمی‌گیرد. نام و گزینه‌های فرم‌ها نیز ممکن است میان بسته‌ها متفاوت باشند.
asterisk -rx 'core show version'
asterisk -rx 'core show application MixMonitor'
asterisk -rx 'core show application StopMixMonitor'این فرمان‌ها نسخه و راهنمای محلی را می‌خوانند. اگر برنامه پیدا نشد، ابتدا روش ضبط و ماژول‌های همان نصب را مشخص کنید؛ نصب یا بارگذاری عجولانهٔ ماژول مرحلهٔ تشخیص نیست. طبق راهنمای رسمی CLI، دسترس‌بودن فرمان‌ها به اجزای بارگذاری‌شده وابسته است و راهنمای برنامه از کنسول قابل دریافت است.
برای نمونه، زمان آغاز با منطقهٔ زمانی، جهت تماس، مقصد، پاسخ‌داده‌شدن و شناسهٔ موجود در گزارش را یادداشت کنید. روشن کنید ایراد برای همهٔ تماس‌هاست یا فقط صف، انتقال یا یک مسیر مشخص. اگر تماس اصلاً به مقصد نمی‌رسد، ابتدا مسیر تماس ورودی را بررسی کنید؛ جست‌وجوی فایل ضبط، مسئلهٔ مسیریابی را حل نمی‌کند.
۲. سیاست مؤثر ضبط را دنبال کنید
از تنظیم همان مسیر، صف و داخلی عبور کنید و مقدار هرکدام را ثبت کنید. مستندات رسمی ضبط Issabel برای داخلی‌ها سیاست‌های ضبط و اولویت تعارض، برای صف زمان شروع ضبط، و برای مسیرها رفتارهای متفاوت ضبط را توضیح می‌دهد. نام گزینه را همراه نسخه و متن راهنمای فرم بخوانید؛ فعال‌بودن یک گزینه، نتیجهٔ تمام زنجیره را به‌تنهایی اثبات نمی‌کند.
در صف، شروع ضبط از ورود به صف با شروع پس از پاسخ عضو متفاوت است. بنابراین نبود موسیقی انتظار در فایل می‌تواند با سیاست انتخابی سازگار باشد. برای تشخیص، زمان ورود، پاسخ و پایان را جدا یادداشت کنید. اگر مسئلهٔ اصلی انتظار یا خروج بدون پاسخ است، راهنمای عیب‌یابی صف Issabel مسیر مستقل آن را توضیح می‌دهد.
پیشنهاد عملی این است که پیش از تغییر، یک جملهٔ قابل آزمون بنویسید: «تماس ورودی این مسیر پس از پاسخ باید شامل صدای دو طرف باشد». سپس تماس بی‌پاسخ و تماس منتقل‌شده را سناریوهای جدا بدانید. این کار از اصلاحی جلوگیری می‌کند که فقط دکمهٔ ضبط را ظاهر می‌کند اما رفتار موردنیاز تیم را تحویل نمی‌دهد.
۳. اجرای ضبط را از وجود ردیف گزارش جدا کنید
ردیف گزارش تماس ثابت نمی‌کند فایل صوتی نهایی تولید شده است. برای همان نمونه، در گزارش موجود Asterisk دنبال اجرای برنامهٔ ضبط، نام کانال، مسیر خروجی و خطای بازکردن فایل بگردید. اگر سطح ثبت فعلی جزئیات کافی ندارد، نبود خط در لاگ را دلیل اجرا‌نشدن ندانید؛ مشاهدهٔ موقت دقیق‌تر باید با بازه و روش بازگرداندن سطح ثبت قبلی برنامه‌ریزی شود.
در کد و راهنمای همراه MixMonitor در شاخهٔ 18، ضبط به کانال جاری متصل است. گزینهٔ b صوت را هنگام bridged بودن کانال ذخیره می‌کند. برای پردازش فایل در ادامهٔ dialplan، مستندات بر StopMixMonitor جهت اطمینان از آماده‌بودن فایل تأکید دارند. نام واقعی خروجی از متغیر MIXMONITOR_FILENAME قابل شناسایی است؛ پسوند wav49 نیز می‌تواند به WAV تبدیل شود.
این نکته مجوز افزودن StopMixMonitor به مسیر زنده نیست؛ توقف ضبط در محل نامناسب بخشی از مکالمه را از دست می‌دهد. ابتدا پایان همان تماس آزمایشی را منتظر بمانید و رفتار موجود را بخوانید. در انتقال تماس هم یک شناسهٔ گزارش را نمایندهٔ همهٔ کانال‌ها فرض نکنید؛ قطعهٔ قبل و بعد از انتقال را با زمان و شواهد کانال تطبیق دهید.
۴. مسیر، ظرفیت و مشخصات فایل را بخوانید
مستندات Issabel مسیر متداول /var/spool/asterisk/monitor را ذکر می‌کنند، اما محل واقعی می‌تواند تغییر کرده باشد. در MixMonitor، مسیر مطلق مستقیماً استفاده می‌شود و نام نسبی به دایرکتوری تنظیم‌شده وابسته است. بنابراین مسیر را از تنظیم و اجرای همان تماس استخراج کنید؛ جست‌وجوی بی‌هدف کل دیسک هم پرهزینه است و هم فایل‌های نامرتبط را وارد بررسی می‌کند.
نمونهٔ زیر برای فایل‌سیستم دارای ابزارهای GNU است. دو مسیر آموزشی را با دایرکتوری تأییدشده و فایل پایان‌یافتهٔ همان تماس عوض کنید. فرمان‌ها چیزی را حذف یا تغییر نمی‌دهند و برای اجرا به حساب مجاز مدیریت سامانه نیاز دارید.
record_dir='/path/to/verified-recordings'
record_file='/path/to/verified-recordings/test-call.wav'
df -h -- "$record_dir"
df -i -- "$record_dir"
stat --format='bytes=%s owner=%U group=%G mode=%a modified=%y' -- "$record_file"خروجی نخست ظرفیت و خروجی دوم inode را نشان می‌دهد؛ فضای آزاد به‌تنهایی برای رد همهٔ مشکلات ذخیره‌سازی کافی نیست. stat اندازه، مالکیت و زمان فایل را می‌خواند. نام کاربری ثابت را برای همهٔ نصب‌ها فرض نکنید. خطای مجوز، مسیر ناموجود یا فایل‌سیستم فقط‌خواندنی را با خطای ثبت‌شده تطبیق دهید؛ از روی مالکیت یک فایل، حکم اصلاح کل درخت ندهید.
فایل صفر بایتی را از فایل دارای سربرگ ولی بدون صوت قابل شنیدن جدا کنید. اندازهٔ غیرصفر، صدای سالم را تضمین نمی‌کند. فایل پایان‌یافته را با ابزار صوتی مجاز و سازگار با قالب روی نسخهٔ کپی بررسی کنید. صرف تغییر پسوند، تبدیل قالب نیست. برای بازکردن دسترسی نیز دستور فراگیر chmod 777 یا خاموش‌کردن کنترل امنیتی راه‌حل قابل قبول محسوب نمی‌شود.
۵. میان فایل گمشده، بی‌صدا و پخش‌نشدن تصمیم بگیرید
| شاهد | مسیر بررسی بعدی |
|---|---|
| اجرای ضبط در شواهد تأیید نشده | سیاست مؤثر، مسیر طی‌شده و کافی‌بودن سطح ثبت |
| اجرای ضبط همراه خطای ایجاد فایل | همان مسیر، ظرفیت، مجوز و وضعیت فایل‌سیستم |
| فایل نهایی هست ولی صوت ناقص است | کانال ضبط، زمان شروع و پایان، انتقال و رسانه |
| نسخهٔ محلی پخش می‌شود ولی پنل پیدا نمی‌کند | نگاشت گزارش به فایل، مسیر پنل و دسترسی خواندن |
اگر دو طرف هنگام تماس یکدیگر را نمی‌شنوند، مسئلهٔ رسانه هم مطرح است؛ راهنمای SDP و RTP برای آن مرحله مناسب است. اگر مکالمهٔ زنده سالم ولی فایل ناقص است، شواهد مربوط به ضبط و کانال را هم حفظ کنید. این دو نتیجه نباید خودکار به تغییر NAT منجر شوند.
برای حالتی که فایل سالم است ولی پنل آن را نشان نمی‌دهد، تفاوت مسیرها اهمیت دارد. در تغییر رسمی ماژول monitoring در اوت ۲۰۲۶ بررسی پوشهٔ جایگزین با نام records_dir دیده می‌شود. این شاهد وجود رفتار وابسته به نسخه است؛ ثابت نمی‌کند بستهٔ شما همین تغییر را دارد. نسخهٔ نصب‌شده و مسیر مورد استفادهٔ پنل را پیش از هر اصلاح تطبیق دهید.
۶. اصلاح را با آزمون پذیرش و امکان بازگشت تمام کنید
مثال آموزشی: فایل یک تماس پاسخ‌داده‌شده روی دیسک موجود و محلی قابل پخش است، ولی پنل آن را پیدا نمی‌کند. فرضیهٔ اولیه، اختلاف مسیر یا نگاشت نام است؛ پاک‌کردن گزارش یا فعال‌کردن مجدد ضبط شاهدی برای حل آن نمی‌سازد. این سناریو فرضی است و گزارش نتیجهٔ واقعی مشتری نیست.
پیش از اصلاح تأییدشده، تنظیم مرتبط و یک نمونهٔ مجاز را با دسترسی محدود پشتیبان بگیرید. مقدار قبلی و روش بازگرداندن را ثبت کنید. فایل تولیدشدهٔ dialplan را بدون شناخت سازوکار تولید آن ویرایش نکنید. هر بار یک فرضیه را آزمایش کنید تا رابطهٔ تغییر و نتیجه قابل پیگیری بماند.
پذیرش پیشنهادی شامل تماس تازه، پایان کامل، شنیدن صدای هر دو طرف و بازیابی همان فایل از پنل با نقش مجاز است. انتقال و بی‌پاسخ را در صورت قرارداشتن در دامنه جدا بیازمایید. یک فایل قدیمی هم باید همچنان قابل بازیابی بماند. اگر تغییر به دسترسی مربوط است، حسابی که نباید صوت را ببیند نیز بررسی شود.
نتیجه را با نسخه، شاهد، علت تأییدشده و محدودیت بنویسید. زمان نگهداری و حذف فایل‌ها تصمیم مستقلی است؛ برای رفع کمبود فضا، پیش از روشن‌شدن سیاست آرشیو و بازیابی، حذف گروهی نکنید. نام فایل و پارامتر پردازش را هم از ورودی اعتمادناپذیر تماس‌گیرنده نسازید؛ مستندات MixMonitor دربارهٔ خطر تزریق فرمان هشدار می‌دهند.
اقدام بعدی: برای یک تماس مجاز، چهار مرز این راهنما را با شواهد پر کنید. برای بررسی تخصصی ضبط مکالمه و طراحی آزمون پذیرش می‌توانید از پشتیبانی آسیاپرداز کمک بگیرید؛ نسخه، نشانه و گزارش پاک‌سازی‌شده کافی است و نیازی به ارسال رمز یا صوت محرمانه نیست.
منابع رسمی پیوندشده در متن در ۱۳ نوامبر ۲۰۲۶ بررسی شدند. جزئیات MixMonitor با شاخهٔ 18 تطبیق یافته‌اند؛ راهنمای محلی نسخهٔ نصب‌شده مقدم است. چک‌لیست، نمودار و سناریو پیشنهاد تحریریه‌اند و فرمان‌های نمونه روی مرکز تلفن تولیدی اجرا نشده‌اند.