برای عیب‌یابی صدای یک‌طرفه در SIP، ابتدا مشخص کنید صدای کدام سمت به کدام مقصد نمی‌رسد؛ سپس آدرس و پورت اعلام‌شده در SDP را با جریان واقعی رسانه مقایسه کنید. زنگ خوردن، ثبت داخلی و پاسخ‌گرفتن تماس، به‌تنهایی عبور صدا را ثابت نمی‌کنند. تغییر هم‌زمان NAT، کدک و فایروال نیز علت را پنهان می‌کند.
این راهنما برای مدیر شبکه و پشتیبان مرکز تلفن نوشته شده و مثال‌های دستوری آن بر مبنای Asterisk 22 با PJSIP است. منطق تشخیص در سامانه‌های دیگر نیز کاربرد دارد، اما نام گزینه‌ها و روش اعمال تغییر ممکن است متفاوت باشد. در Issabel و پنل‌های مشابه، ابتدا نسخهٔ واقعی Asterisk و درایور داخلی یا ترانک را شناسایی کنید؛ فایل تولیدشده توسط پنل را مستقیم ویرایش نکنید.
صدای یک‌طرفه را از اختلال کیفیت جدا کنید
اگر کاربر الف صحبت می‌کند و ب هیچ صدایی نمی‌شنود، جهت مورد بررسی «الف به ب» است؛ حتی اگر الف صدای ب را واضح دریافت کند. عبارت مبهم «صدای ورودی نداریم» برای تیم شبکه کافی نیست. نام دو سمت، زمان با منطقهٔ زمانی و وضعیت قبل و بعد از پاسخ را ثبت کنید. شماره‌ها را در گزارش عمومی ناشناس کنید.
صدای بریده، تأخیر یا اکو مسیر بررسی دیگری دارد. مقالهٔ تحول در انتقال صدا مقدمه‌ای برای مفاهیم کیفیت است؛ اینجا پرسش مشخص ما، نرسیدن صدا در یک جهت است. ابتدا mute، میکروفن و هدست را با آزمون محلیِ مجاز کنار بگذارید تا ایراد دستگاه با مسیر شبکه اشتباه نشود.
چرا تماس برقرار است اما صدا نمی‌رسد؟
پیام‌های SIP تماس را کنترل می‌کنند و SDP ویژگی‌های رسانه را توصیف می‌کند. در سناریوی معمول این راهنما، RTP حامل صوت است و می‌تواند مسیر یا پورت متفاوتی داشته باشد. بنابراین موفقیت REGISTER یا مشاهدهٔ پیام پاسخ تماس، تأیید دریافت RTP در مقصد نیست. برای آشنایی با اجزای شبکه می‌توانید راهنمای VoIP چیست را بخوانید.
در مرکز تلفنی که رسانه را عبور می‌دهد، یک تماس دو بخش دارد: گوشی تا مرکز تلفن و مرکز تلفن تا سمت دیگر. اگر رسانه مستقیم میان دو انتها برقرار شود، ممکن است بسته‌ها از مرکز تلفن عبور نکنند. نبودن RTP روی سرور در این حالت الزاماً خطا نیست. ابتدا مسیر مورد انتظار را روی کاغذ مشخص کنید؛ سپس نقطهٔ مشاهده را انتخاب کنید.
گام اول: یک سناریوی بازتولید کوچک بسازید
با هماهنگی کاربران، یک تماس آزمایشی کوتاه و بدون اطلاعات حساس برقرار کنید. مشخص کنید مشکل میان دو داخلی شبکهٔ محلی است، فقط داخلی راه‌دور را درگیر می‌کند یا روی ترانک رخ می‌دهد. سپس یک تماس سالم با شرایط نزدیک انتخاب کنید. مقایسهٔ تماس شعبه با تماس محلی وقتی کدک، مسیر و دستگاه همگی فرق دارند، چند متغیر را مخلوط می‌کند.
| الگوی مشاهده | اولویت بررسی پیشنهادی |
|---|---|
| داخلی محلی سالم؛ داخلی راه‌دور ناموفق | آدرس رسانه، NAT و مسیر دسترسی همان داخلی |
| داخلی‌ها سالم؛ تماس ترانک ناموفق | بخش مرکز تلفن تا ارائه‌دهنده و شبکه‌های رسانهٔ اعلامی او |
| ابتدا سالم؛ پس از hold یا انتقال ناموفق | SDP جدید و تغییر مسیر یا جهت رسانه پس از رویداد |
| فقط یک دستگاه ناموفق | آزمون میکروفن، تنظیم صوت و مسیر همان دستگاه |
این جدول اولویت است، نه تشخیص قطعی. در برگهٔ رخداد، شناسهٔ تماس و نام داخلی آزمایشی را کنار زمان بنویسید؛ ثبت فقط یک عکس از وضعیت Registered برای پیگیری کافی نیست.
گام دوم: SDP را در هر بخش تماس بخوانید
در SDP سادهٔ مبتنی بر RTP، خط c= آدرس اتصال و خط m=audio پورت و قالب‌های رسانه را معرفی می‌کند. اگر بخش رسانه خط اتصال مستقل داشته باشد، مقدار همان بخش بر مقدار سطح نشست مقدم است. این قواعد در RFC 8866، بخش‌های ۵٫۷ و ۵٫۱۴ آمده‌اند.
نمونهٔ زیر فقط قطعه‌ای آموزشی از SDP است؛ یک نشست کامل یا تنظیم قابل نصب نیست. آدرس از محدودهٔ مستندسازی انتخاب شده و به سرور واقعی اشاره نمی‌کند.
c=IN IP4 203.0.113.20
m=audio 18000 RTP/AVP 0
a=sendrecvبرای جریان دریافتِ توصیف‌شده، مقصد اعلامی رسانه را با سمت مقابل تطبیق دهید. این آدرس و پورت لزوماً مبدأ بسته‌های ارسالی همان طرف نیستند. جهت‌های sendonly، recvonly و inactive نیز معنا دارند؛ یک‌طرفه‌شدن رسانه هنگام hold ممکن است بخشی از مذاکره باشد. پس از بازگشت از hold باید تبادل جدید را بررسی کرد. RFC 3264 مبنای این تفسیر است.
SDP گوشی تا مرکز تلفن را با SDP ترانک یکی فرض نکنید. برای هر بخش، مقصد اعلامی و مقصد مشاهده‌شده را جدا بنویسید. در WebRTC، ICE یا SRTP، مسیر انتخاب‌شده و مذاکرهٔ امنیت رسانه نیز اهمیت دارد؛ همین سه خط برای تشخیص همهٔ این سناریوها کافی نیست.
گام سوم: مشاهدهٔ محدود در Asterisk با PJSIP
ابتدا نسخه و دسترس‌پذیری فرمان‌ها را با حساب مجاز بخوانید. دستورهای زیر را روی میزبان یا داخل کانتینری اجرا کنید که واقعاً پردازش Asterisk در آن است. هیچ نام کانتینر و مسیر نصبی از پیش فرض نشده است.
asterisk -rx 'core show version'
asterisk -rx 'core show help pjsip show endpoint'
asterisk -rx 'core show help pjsip set logger'
asterisk -rx 'core show help rtp set debug'سپس با asterisk -rv وارد CLI شوید. برای مشاهدهٔ endpoint از pjsip show endpoint NAME استفاده کنید؛ NAME باید نام واقعیِ کشف‌شده باشد. اگر فرمان وجود ندارد، ابتدا درایور و ماژول را بررسی کنید. راهنمای عیب‌یابی رسمی PJSIP در تفکیک این وضعیت‌ها کمک می‌کند.
در مثال بعد، آدرس ساختگی باید با همتای همان تماس آزمایشی جایگزین شود. همتای SIP ممکن است با مبدأ رسانه متفاوت باشد؛ در آن صورت برای هر فرمان آدرس مناسب خودش را انتخاب کنید. این فرمان‌ها تنظیم مسیریابی را تغییر نمی‌دهند، اما خروجی تشخیصی تولید می‌کنند.
pjsip set logger host 203.0.113.20
rtp set debug ip 203.0.113.20
rtp set debug off
pjsip set logger offدو فرمان پایانی را بلافاصله پس از تماس آزمایشی اجرا کنید. نحو فیلتر همتا در سورس logger شاخهٔ ۲۲ و فیلتر RTP در سورس موتور RTP همان شاخه قابل بررسی است؛ راهنمای binary نصب‌شده اولویت دارد.
حفاظت از داده: لاگ SIP می‌تواند شماره، آدرس و اطلاعات احراز هویت چالش‌ـ‌پاسخ داشته باشد. خروجی را محدود، دسترسی فایل را کنترل و پیش از اشتراک‌گذاری پاک‌سازی کنید. ضبط بسته ممکن است صوت قابل بازسازی داشته باشد؛ فقط با مجوز و برای بازهٔ ضروری انجام شود. پایان آزمون، خاموش‌شدن debug و مقصدهای ذخیرهٔ لاگ را کنترل کنید.
گام چهارم: از مشاهده به فرضیه برسید
| شاهد در مسیر الف به ب | برداشت محتاطانه | بررسی بعدی |
|---|---|---|
| در نقطهٔ دریافت سرور بسته‌ای از الف دیده نمی‌شود | مشکل می‌تواند پیش از سرور یا ناشی از نقطهٔ مشاهده باشد | مبدأ، مسیر شبکه و فیلتر مشاهده را تطبیق دهید |
| سرور دریافت دارد؛ ارسال به مقصد اعلامی ب دیده نمی‌شود | بخش پردازش یا مسیر رسانهٔ سرور نیازمند بررسی است | مسیر مستقیم، کانال و مذاکرهٔ رسانه را بخوانید |
| ارسال از سرور دیده می‌شود؛ دریافت ب تأیید نشده | خروج بسته، رسیدن آن را ثابت نمی‌کند | شاهد سمت ب یا مرز شبکه را دریافت کنید |
| در ب بسته دریافت می‌شود؛ صدایی پخش نمی‌شود | صرف دریافت بسته، صدای قابل پخش را اثبات نمی‌کند | قالب رسانه، امنیت، دستگاه و مسیر پخش را بررسی کنید |
برای هر سطر فقط شاهد موجود را ثبت کنید. «روی سرور ندیدم» بدون ذکر interface، فیلتر و نقش سرور، نتیجهٔ قابل اتکایی نیست. این محدودیت در تماس دارای رسانهٔ مستقیم یا عبور رسانه از واسط دیگر مهم‌تر می‌شود.
گزینه‌های NAT چه مسئله‌ای را حل می‌کنند؟
در PJSIP، گزینهٔ transport به نام external_media_address همراه با تعریف درست local_net بر آدرس رسانهٔ اعلامی اثر دارد. external_signaling_address مربوط به سیگنالینگ است. راهنمای رسمی NAT در PJSIP شرایط بازنویسی را توضیح می‌دهد؛ این گزینه‌ها جای ایجاد مسیر شبکه را نمی‌گیرند.
در endpoint، rtp_symmetric ارسال RTP به مبدأیی را هدف می‌گیرد که رسانه از آن دریافت شده است؛ force_rport و rewrite_contact به رفتار SIP مربوط‌اند. گزینهٔ direct_media اجازهٔ عبور مستقیم رسانه میان انتهاها را کنترل می‌کند. تعریف و دامنهٔ هر گزینه را در مرجع PJSIP نسخهٔ ۲۲ بررسی کنید.
این گزینه‌ها نسخهٔ آمادهٔ «همه yes شوند» نیستند. اگر آدرس اعلامی قابل دسترسی است، تغییر آن بدون شاهد ممکن است تماس‌های سالم را هم مختل کند. پیش از اصلاح، مقدار فعلی و نسخهٔ پشتیبان تنظیم مربوط را نگه دارید، یک تغییر محدود برنامه‌ریزی کنید و روش بازگشت بنویسید. تغییر transport ممکن است مانند تغییر endpoint اعمال نشود؛ روش reload یا restart را برای همان نسخه و پنل بررسی و در پنجرهٔ مجاز اجرا کنید.
اشتباهات رایج و معیار پایان عیب‌یابی
برای آزمون، فایروال را کامل خاموش نکنید و بازهٔ RTP را از یک مقالهٔ عمومی کپی نکنید. بازهٔ واقعیِ تنظیم‌شده و شبکه‌های رسانهٔ معتبر ارائه‌دهنده را مبنا بگیرید. همچنین دربارهٔ SIP ALG حکم عمومی ندهید؛ اگر احتمال دست‌کاری SDP مطرح است، محتوای دو سوی تجهیز را با مجوز مقایسه کنید و فرضیه را با شاهد بیازمایید.
پس از اصلاح مجاز، همان تماس اولیه را در هر دو جهت، سپس hold و انتقال مورد استفادهٔ سازمان تکرار کنید. یک تماس سالمِ مبنا را نیز دوباره بررسی کنید. معیار پذیرش، صدای دوطرفهٔ پایدار در سناریوهای مورد نیاز، نبود خطای حل‌نشده و خاموش‌شدن ابزار تشخیص است؛ تنها یک پاسخ 200 یا وضعیت Registered کافی نیست.
در پایان بنویسید چه چیزی مشاهده شد، چه چیزی هنوز فرضیه است و کدام تغییر نتیجه را عوض کرد. برای بررسی تخصصی، از مسیر پشتیبانی VoIP آسیاپرداز اقدام کنید و زمان رخداد، سناریوی بازتولید و شواهد پاک‌سازی‌شده را آماده داشته باشید. رمز داخلی یا فایل کامل ضبط تماس را در فرم عمومی ارسال نکنید.
محدودهٔ اعتبار: فرمان‌ها با مستندات و سورس شاخهٔ Asterisk 22 و قواعد SDP تطبیق داده شده‌اند؛ اجرای زنده روی مرکز تلفن در این مقاله انجام نشده است. پیش از استفاده، راهنمای نسخهٔ نصب‌شده و سیاست عملیاتی سازمان را کنترل کنید.