عیب‌یابی DTMF در Asterisk؛ چرا کلیدهای IVR کار نمی‌کنند؟

اگر تماس وصل می‌شود و پیام تلفن گویا شنیده می‌شود اما فشردن کلیدها نتیجه ندارد، عیب‌یابی DTMF را از روش ارسال کلید و دریافت آن در Asterisk شروع کنید؛ سپس منطق IVR را بررسی کنید. شنیدن بوق کلید در گوشی، اثبات رسیدن آن به مرکز تلفن نیست. تغییر تصادفی کدک، زمان انتظار یا تنظیمات NAT نیز بدون شاهد، مرز خرابی را روشن نمی‌کند.

این راهنما برای Asterisk 22 با درایور PJSIP نوشته شده است. نام گزینه‌ها را با نسخهٔ نصب‌شده تطبیق دهید؛ در مراکز تلفن دارای پنل، تغییر باید از رابط یا مسیر سفارشی پشتیبانی‌شده انجام شود. مثال‌ها آموزشی‌اند و روی سرویس مشتری اجرا نشده‌اند. هیچ تستی نباید شامل رمز، اطلاعات بانکی یا کد یک‌بارمصرف واقعی باشد.

۱. مشکل کلید تلفن را به یک سناریوی قابل تکرار تبدیل کنید

DTMF همان علامت‌های شماره‌گیری دوفرکانسی است که برای انتخاب گزینهٔ منو نیز استفاده می‌شود. پیش از تغییر تنظیمات، بنویسید مشکل در کدام مسیر رخ می‌دهد: تماس داخلی به IVR محلی، تماس ورودی از ترانک یا تماس خروجی به منوی سازمان دیگر؟ در هر مسیر فقط یک تلفن، یک مقصد آزمایشی و یک رشتهٔ غیرمحرمانهٔ مشخص انتخاب کنید.

سه زمان را جدا امتحان کنید: هنگام پخش پیام، پس از پایان پیام و بعد از انتقال تماس. تفاوت نتیجه می‌تواند سرنخ منطق دریافت یا تغییر بخش تماس باشد؛ هنوز علت قطعی نیست. اگر حتی تماس به مقصد نمی‌رسد، ابتدا مسیر تماس ورودی و مقصد را بررسی کنید. این مقاله از مرحله‌ای شروع می‌شود که مقصد موردنظر واقعاً پاسخ می‌دهد.

برای هر آزمون، زمان، جهت تماس، نسخه، نام مستعار endpoint و نتیجهٔ موردانتظار را ثبت کنید. شماره‌ها و شناسه‌های واقعی را هنگام اشتراک گزارش حذف کنید. یک تماس موفق از داخلی به IVR، سلامت همان مسیر را نشان می‌دهد؛ نمی‌توان از آن سلامت ترانک یا منوی بیرونی را نتیجه گرفت.

۲. سه روش انتقال DTMF را از هم جدا کنید

در مرجع PJSIP نسخهٔ ۲۲، گزینهٔ dtmf_mode روش endpoint را تعیین می‌کند. مقدار rfc4733 پیش‌فرض  است؛ info و inband روش‌های دیگرند. مقدار auto در نبود پشتیبانی طرف مقابل از RFC 4733 به inband برمی‌گردد؛ auto_info در همان وضعیت INFO را انتخاب می‌کند. پس این دو «خودکار» رفتار یکسانی ندارند.

در پنل بعضی تجهیزات نام قدیمی RFC 2833 دیده می‌شود. RFC 4733 جایگزین آن روش شده است؛ سازگاری عملی را از مستند دستگاه و مذاکرهٔ تماس بررسی کنید. عبارت «خارج از باند صوت» برای رویداد RTP به معنی انتقال روی SIP نیست. برای هر بخش تماس، قرارداد ارائه‌دهنده و تنظیم طرف مقابل را مستقل بخوانید؛ الزاماً روش سمت تلفن و سمت ترانک یکسان نیست.

۳. تنظیم مؤثر و SDP همان تماس را بخوانید

دستورهای زیر در پوستهٔ لینوکس اجرا می‌شوند و تنظیمی را تغییر نمی‌دهند. نام lab-endpoint صرفاً نمونه است؛ آن را با endpoint آزمایشی جایگزین کنید. خروجی ممکن است اطلاعات اتصال داشته باشد و نباید خام منتشر شود.

asterisk -rx 'core show version'
asterisk -rx 'pjsip show endpoint lab-endpoint'
asterisk -rx 'core show application Read'
asterisk -rx 'core show application BackGround'

خواندن فایل کافی نیست؛ خروجی endpoint بارگذاری‌شده را با تنظیمی که پنل تولید کرده مقایسه کنید. اگر فرمان PJSIP شناخته نمی‌شود، ابتدا درایور و ماژول نصب‌شده را مشخص کنید و فرمان مخصوص chan_sip را بدون تطبیق نسخه جایگزین نکنید. طبق راهنمای رسمی عیب‌یابی PJSIP، مشاهدهٔ پیام‌های SIP می‌تواند به تطبیق مذاکره کمک کند.

برای یک تماس آزمایشی کوتاه، در کنسول Asterisk ابتدا راهنمای core show help pjsip set logger را ببینید. با مجوز مسئول سرویس، logger را موقتاً روشن کنید، همان تماس را انجام دهید و بلافاصله خاموش کنید:

pjsip set logger on
; perform one controlled test call
pjsip set logger off

خط میانی توضیح است و فرمان کنسول نیست. این logger می‌تواند پیام‌های تماس‌های دیگر را هم ثبت کند؛ زمان آزمایش را هماهنگ کنید و خروجی را محرمانه نگه دارید. برای مشاهدهٔ DTMF نیازی به خاموش‌کردن TLS یا SRTP نیست. نبود رویداد در یک capture رمز‌شده یا روی رابط اشتباه، نبود ارسال را ثابت نمی‌کند.

در نمونهٔ زیر فقط بخشی از SDP آموزشی آمده است، نه یک SDP کامل. عدد ۱۱۰ از مذاکرهٔ این مثال انتخاب شده است؛ شمارهٔ ثابتی برای همهٔ سامانه‌ها نیست.

m=audio 49170 RTP/AVP 0 110
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15

طبق RFC 4733، نوع payload رویداد به‌صورت پویا تعیین می‌شود. نگاشت rtpmap و فهرست رویدادهای fmtp را در پیشنهاد و پاسخ همان بخش تماس تطبیق دهید؛ به‌جای فرض «همیشه ۱۰۱»، مقدار واقعی را بخوانید. وجود telephone-event در پیشنهاد به‌تنهایی اثبات پذیرش یا رسیدن بسته نیست.

۴. دریافت کلید را از تصمیم IVR ، جدا آزمایش کنید

اگر رویداد به Asterisk می‌رسد اما مقصد اشتباه انتخاب می‌شود، زمان انتظار، context و طول ورودی را بررسی کنید. BackGround هنگام پخش پیام منتظر شمارهٔ مقصد است؛ برای ادامهٔ انتظار پس از پیام، WaitExten مطرح می‌شود. گزینهٔ p در BackGround اجازهٔ قطع پخش با کلید را نمی‌دهد. بنابراین پاسخ‌ندادن حین پیام لزوماً مشکل شبکه نیست.

برای جداکردن دریافت از منوی اصلی، می‌توان روی محیط آزمایش و یک داخلی محدود، نمونهٔ زیر را به dialplan سفارشی افزود. این قطعه مسیر تماس تولیدی را جایگزین نمی‌کند؛ شمارهٔ انتخابی باید آزاد باشد. از ویرایش فایل تولیدشدهٔ پنل خودداری کنید و پیش از تغییر از تنظیمات پشتیبان بگیرید.

[dtmf-lab]
exten => 8890,1,Answer()
 same => n,Read(TEST_DIGITS,,4,,1,5)
 same => n,Verbose(2,DTMF test status=${READSTATUS})
 same => n,Set(TEST_DIGITS=)
 same => n,Hangup()

پس از پاسخ، رشتهٔ آزمایشی ۱۲۳۴ را وارد کنید. در این مثالِ بدون پیام صوتی، Read حداکثر چهار رقم، یک تلاش و timeout پنج‌ثانیه‌ای دارد. طبق مرجع Read نسخهٔ ۲۲، وضعیت در READSTATUS قرار می‌گیرد؛ از جمله OK، TIMEOUT و HANGUP. کلید # به‌صورت پیش‌فرض پایان‌دهنده است، پس آن را مثل رقم عادی چهارم تفسیر نکنید.

عمداً مقدار ورودی در Verbose چاپ نشده است. OK فقط نتیجهٔ دریافت این آزمون است؛ اجرای شاخهٔ درست IVR اصلی را جدا کنترل کنید. این رفتار با پیاده‌سازی رسمی Read در شاخهٔ ۲۲ تطبیق دارد، اما این قطعه در اجرای تحریریه روی PBX زنده آزمایش نشده است. فعال‌سازی و حذف آن باید در مسیر پشتیبانی‌شدهٔ سامانه انجام شود.

۵. از شواهد به فرضیه برسید

در کد دریافت INFO در Asterisk 22، نوع محتوا و مقدار رویداد بررسی می‌شوند؛ حتی بدنهٔ خالی می‌تواند پاسخ 200 بگیرد. پس پاسخ موفق SIP به‌تنهایی اجرای انتخاب منو را ثابت نمی‌کند. در روش RTP نیز چند بسته می‌توانند یک رویداد واحد را توصیف کنند؛ تعداد بسته‌ها را با تعداد فشردن کلید یکی نگیرید.

اگر هم‌زمان صدا یک‌طرفه است، از راهنمای SDP و RTP برای صدای یک‌طرفه کمک بگیرید. اگر مشکل فقط هنگام ازدحام رخ می‌دهد، شواهد را با آزمون QoS هنگام بار تکمیل کنید. هیچ‌یک جای بررسی خود DTMF را نمی‌گیرد.

۶. اصلاح را با آزمون پذیرش و امکان بازگشت تحویل دهید

بعد از مشخص‌شدن مرز مشکل، فقط یک متغیر را تغییر دهید: مثلاً روش DTMF همان endpoint یا تنظیم انتظار همان منو. تغییر را با قرارداد اپراتور و قابلیت دستگاه هماهنگ کنید. نسخهٔ قبلی تنظیم، دلیل انتخاب، روش اعمال و دستور بازگشت را نگه دارید؛ افزایش مدت کلید یا تغییر کدک بدون شاهد، نسخهٔ عمومی حل مشکل نیست.

معیار پذیرش پیشنهادی: انتخاب درست گزینه‌های مجاز، رفتار مشخص ورودی نامعتبر و بی‌ورودی، کارکرد حین و پس از پیام مطابق طراحی و حفظ نتیجه پس از انتقال. مسیر داخلی، ترانک ورودی و منوی بیرونیِ موردنیاز را جدا آزمایش کنید. سپس logger و مقصد موقت را جمع کنید و فقط گزارش پالایش‌شده و شواهد لازم را نگه دارید.

خروجی خوب عیب‌یابی، زنجیرهٔ قابل توضیح «ارسال، دریافت، تصمیم» است. برای بررسی مرکز تلفن سازمان با تیم آسیاپرداز، نسخه، مسیر درگیر، روش DTMF و نتیجهٔ آزمون غیرمحرمانه را آماده کنید؛ ارسال رمز یا فایل خام تماس لازم نیست.