خطاهای رایج هنگام راه‌اندازی SIP Trunk از چالش‌های همیشگی مدیران شبکه، پشتیبان‌های سیستم‌های تلفنی و متخصصان ویپ به شمار می‌روند. ارتباط ترانک ستون فقرات ارتباطی سازمان با دنیای خارج و ارائه‌دهندگان سرویس مخابراتی (ITSP/Telco) است و کوچک‌ترین ناسازگاری در آدرس‌دهی شبکه، پورت‌های سیگنالینگ، تنظیمات کدک یا اعتبارسنجی می‌تواند موجب قطعی کامل خطوط ارتباطی سازمان شود. در این مقاله به آموزش گام‌به‌گام عیب‌یابی SIP Trunk، رفع خطاهای SIP Trunk و حل ریشه‌ای مشکل اتصال SIP Trunk می‌پردازیم تا بتوانید منشأ مشکلات راه‌اندازی SIP Trunk و خطاهای رایج VoIP را بدون سردرگمی شناسایی کرده و ارتباطی پایدار برقرار سازید.
برای اطلاعات بیشتر در مورد خدمات نصب و راه اندازی ویپ سرور ایزابل شایگان کلیک کنید.
قبل از عیب‌یابی SIP Trunk چه مواردی را بررسی کنیم؟
پیش از آنکه وارد لایه‌های عمیق لاگ و دستکاری فایل‌های پیکربندی شوید، باید چند پیش‌نیاز حیاتی زیرساخت شبکه را به دقت ارزیابی کنید؛ چرا که بسیاری از قطعی‌ها ناشی از خطاهای فیزیکی یا مسدودی‌های بیرونی هستند:
- ارتباط لایه ۳ شبکه و مسیریابی: مطمئن شوید سرور استریسک یا ایزابل به آدرس IP یا نام دامنه پرووایدر ترانک دسترسی بدون وقفه دارد. اگر خطوط ترانک روی مودم اختصاصی، اینترانت سازمانی، فیبر نوری اختصاصی (سیپ‌فون‌های تلکام) یا VLAN مجزا ارائه شده‌اند، حتماً با دستورهایی نظیر ip route show از درستی جدول روتینگ سیستم‌عامل اطمینان حاصل کنید تا ترافیک ترانک به جای اینترنت عادی، از گیت‌وی صحیح خارج شود.
- باز بودن پورت‌های فایروال محلی و مرزی: پورت‌های پیش‌فرض پروتکل SIP (معمولاً ۵۰۶۰ در حالت‌های UDP یا TCP و پورت ۵۰۶۱ برای TLS) و محدوده گسترده پورت‌های مدیا (RTP Ports که عموماً بین ۱۰۰۰۰ تا ۲۰۰۰۰ تعریف می‌شوند) نباید توسط فایروال لینوکس (iptables/firewalld) یا فایروال‌های لبه شبکه نظیر میکروتیک و فورتینت مسدود یا محدود شده باشند.
- بررسی سرویس و زیرساخت ارائه‌دهنده: در مواقعی بروز اختلال یا عملیات تعمیر و نگهداری در دیتاسنتر یا سوییچ‌های ارائه‌دهنده خط تلفن باعث بروز قطعی می‌شود؛ بنابراین قبل از تغییر اساسی تنظیمات سیستم، از فعال بودن وضعیت حساب کاربری، اعتبار مالی خط و پایداری شبکه مخابراتی مطمئن شوید.
چرا SIP Trunk Register نمی‌شود؟
Register نشدن SIP Trunk یا مشکل Registration در SIP Trunk معمولاً به دلیل ناهماهنگی در معماری پیاده‌سازی و مکانیزم برقراری ارتباط با سرور ارائه‌دهنده رخ می‌دهد. ترانک‌های ویپ عموماً به دو دسته کلی مبتنی بر احراز هویت (User/Pass Registration) و مبتنی بر آدرس آی‌پی (IP-Based یا IP Authentication) تقسیم می‌شوند:
اگر پرووایدر مخابراتی، ترانک شما را بر پایه آدرس IP سرور تعریف کرده باشد، سرور شما اصولاً نباید بسته REGISTER ارسال کند؛ در این ساختار هویت شما از روی IP ثابت شناخته می‌شود و تلاش سرور برای ثبت دوره‌ای نه‌تنها بی‌پاسخ می‌ماند، بلکه ممکن است در پنل وب به اشتباه وضعیت «Unregistered» نمایش داده شود، در حالی که ترانک در واقعیت فعال و آماده مکالمه است.
از سوی دیگر، در ترانک‌های نیازمند نام کاربری و رمز، مواردی مانند تایم‌اوت‌های شبکه (خطای ۴۰۸)، اشتباه در آدرس هاست رجیستری یا فعال بودن قابلیت مخرب SIP ALG روی مودم لبه شبکه، باعث تغییر ناخواسته در سرآیند بسته‌های ارسالی شده و مانع از ثبت موفق ترانک در سامانه اپراتور می‌گردد.
خطای Authentication در SIP Trunk
خطای Authentication در SIP Trunk زمانی رخ می‌دهد که مرکز تلفن شما بسته‌های درخواست تماس (INVITE) یا ثبت (REGISTER) را ارسال می‌کند، اما سرور مخابرات با پاسخ‌هایی نظیر 401 Unauthorized یا 403 Forbidden دسترسی سیستم را متوقف می‌سازد.
علل اصلی بروز این تضاد عبارت‌اند از:
- تنظیمات اشتباه SIP Trunk در مقادیر کاربری و کلمه عبور: اشتباه تایپی در مقادیر Username، Secret یا فیلد Realm یکی از رایج‌ترین موارد است. به‌ویژه در درایورهای مدرن نظیر PJSIP، تفکیک دقیق فیلدهای username و auth_username اهمیت بسیار بالایی دارد و اشتباه در آن‌ها مستقیماً به رد اعتبار منجر می‌شود.
- تطابق نداشتن From Domain یا From User: بسیاری از سوییچ‌های مخابراتی برای اعتبارسنجی تماس‌های خروجی اصرار دارند که هدر From بسته SIP دقیقاً معادل شماره سرشماره خط، شناسه کاربری یا دامنه رسمی ثبت‌شده باشد؛ ارسال آدرس IP محلی، نام دامنه ناشناخته یا شماره فرعی در این هدر فوراً با خطای عدم احراز هویت رد خواهد شد.
- اعمال محدودیت‌های IP و Whitelist در سمت اپراتور: اگر رمز عبور کاملاً صحیح است اما پیوسته خطای ۴۰۳ دریافت می‌کنید، احتمالاً آدرس IP Public سرور شما به دلیل قطعی اینترنت تغییر یافته یا در پنل مدیریتی اپراتور مخابراتی تعریف نشده است.
چرا تماس ورودی از طریق SIP Trunk دریافت نمی‌شود؟
در سناریوهایی که ترانک با موفقیت به اپراتور متصل شده و تماس‌های خروجی بدون هیچ مشکلی برقرار می‌شوند، عدم دریافت تماس‌های ورودی نشان‌دهنده نقص در زنجیره هدایت تماس در مرکز تلفن است:
- نبود یا تنظیم اشتباه مسیر ورودی (Inbound Route): استریسک بر اساس DID (شماره مقصدی که اپراتور در بسته ورودی درج می‌کند) تصمیم می‌گیرد تماس را به کدام منوی صوتی یا داخلی وصل کند. اگر اپراتور شماره را با فرمت بین‌المللی ارسال کند اما شما مسیر ورودی را برای شماره محلی ۸ رقمی تعریف کرده باشید، تماس رد می‌شود. استفاده از کاراکتر any یا بررسی دقیق هدر To در لاگ‌ها این مسئله را برطرف می‌کند.
- تنظیم نبودن Context ترانک: در فایل‌های تنظیماتی ترانک، باید کانتکست ورودی دقیقاً روی from-trunk یا کانتکست‌های پیش‌فرض پردازش ورودی مرکز تلفن قرار داشته باشد؛ اگر این پارامتر تصادفاً روی from-internal تنظیم شده باشد، استریسک تماس ورودی را به عنوان یک تماس خروجی ناقص تلقی کرده و آن را قطع می‌کند.
- مسدود شدن بسته‌های ورودی پورت ۵۰۶۰ در فایروال: هنگامی که سرور پشت روتر و مکانیزم NAT قرار دارد، روتر باید بداند بسته‌های غیرمنتظره ورودی از سمت سرورهای مخابرات باید دقیقاً به آدرس IP محلی سرور ایزابل هدایت شوند؛ عدم ایجاد قوانین Port Forwarding موجب گم شدن این بسته‌ها در ورودی شبکه می‌شود.
چرا تماس قطع می‌شود؟
قطع شدن مکالمه درست پس از چند ثانیه مشخص (معمولاً در ثانیه‌های ۵ الی ۶ یا ۳۰ الی ۳۲) یکی از شناخته‌شده‌ترین نشانه‌های شکست در چرخه ارسال بسته ACK در پروتکل SIP است:
هنگامی که تماس از سوی مخاطب پاسخ داده می‌شود، طرف دریافت‌کننده پیام وضعیت 200 OK را ارسال می‌کند و سمت تماس‌گیرنده موظف است بسته تأییدیه ACK را بازگرداند تا برقراری جریان صوت تأیید شود. چنانچه به دلیل تنظیمات نادرست ترجمه آدرس شبکه (NAT)، بسته ACK به جای ارسال به آدرس عمومی به یک آدرس نامعتبر محلی ارسال گردد، سوییچ مقصد پس از اتمام تایم‌اوت قانونی پروتکل تصور می‌کند ارتباط از دست رفته و با ارسال بسته BYE تماس را قطع می‌نماید. بررسی دقیق تنظیمات External IP سرور و همگام‌سازی زمان (NTP) این اختلال را برطرف می‌کند.
مشکل یک‌طرفه بودن صدا در SIP Trunk
مشکل یک‌طرفه بودن صدا (One-way Audio) از قدیمی‌ترین سناریوهای آزاردهنده در راه‌اندازی خطوط ویپ است که طی آن تنها یکی از طرفین تماس قادر به شنیدن صدای طرف دیگر است.
ریشه اصلی این پدیده در جداسازی لایه کنترل از لایه رسانه است؛ تبادل سیگنال و زنگ خوردن تلفن از طریق پروتکل SIP هدایت می‌شود، اما بسته‌های محتوای صدا به طور مستقل و بر بستر پروتکل RTP انتقال می‌یابند. هنگامی که تماس برقرار می‌شود، مشخصات آدرس IP و پورت‌های صوتی درون بدنه پیام تحت پروتکل SDP مبادله می‌گردد. اگر سرور شما آدرس IP محلی (نظیر 192.168.x.x) را در بخش کالبد SDP ارسال کند، سرور اپراتور بسته‌های صوتی را به این آدرس نامعتبر فرستاده و صدا در یک جهت مسدود می‌گردد. همچنین بسته بودن پورت‌های RTP در فایروال مبدأ یا مقصد می‌تواند جریان صوتی بازگشتی را فیلتر کند.
چرا در تماس SIP Trunk هیچ صدایی منتقل نمی‌شود؟
سکوت مطلق در مکالمه (No Audio) نشان می‌دهد که جریان انتقال صوت به کلی شکل نگرفته و هیچ داده‌ای در کانال‌های صوتی ردوبدل نمی‌شود:
- مسدودی پورت‌های RTP در فایروال‌ها: در این حالت، هماهنگی‌های اولیه روی پورت ۵۰۶۰ به درستی پیش رفته و تماس در پنل متصل ثبت می‌شود، اما تمام بسته‌های UDP حامل صوت به علت بسته بودن محدوده پورت‌های ۱۰ هزار تا ۲۰ هزار در فایروال سرور یا فایروال لبه شبکه مسدود می‌گردند.
- مداخله قابلیت مخرب SIP ALG در تجهیزات شبکه: قابلیت SIP Application Layer Gateway که در اکثر مودم‌ها و روترهای تجاری به‌صورت پیش‌فرض فعال است، سعی می‌کند با بررسی بسته‌های SIP پورت‌های درون SDP را بازنویسی کند؛ این بازنویسی خودکار عموماً با خطاهای محاسباتی همراه بوده و به هدایت ترافیک صوت به پورت‌های غیرفعال می‌انجامد. خاموش کردن فوری این گزینه در کنسول مودم گام نخست رفع سکوت کامل تماس است.
خطاهای Codec در SIP Trunk
برای تبدیل امواج صوتی آنالوگ به داده‌های دیجیتال روی شبکه، دو طرف ارتباط باید بر سر یک الگوریتم فشرده‌سازی و کدگذاری صوتی یکسان به توافق برسند. کدک‌های استاندارد خطوط مخابراتی در اکثر کشورها شامل alaw (G.711a)، ulaw (G.711u) و G.729 هستند.
اگر در تنظیمات ترانک خود کدک‌های مجاز را به گونه‌ای محدود کرده باشید که با کدک‌های فعال ارائه‌دهنده سرویس همخوانی نداشته باشد، هسته استریسک خطایی مشابه عبارت زیر در لاگ صادر می‌کند:
NOTICE[…]: chan_sip.c: No compatible codecs, not accepting this offer!
در پی این عدم تفاهم در بدنه پیام SDP، سرور اپراتور با ارسال کد خطای 488 Not Acceptable Here فرایند برقراری مکالمه را لغو می‌کند. برای حل این مشکل، همواره در تنظیمات ترانک ابتدا با دستور disallow=all تمام فرمت‌های پیش‌فرض را لغو کرده و سپس گزینه‌های استاندارد را با خطوط allow=alaw و allow=ulaw فعال نمایید.
خطاهای NAT در SIP Trunk
قرار گرفتن سرور استریسک در پشت روترها و انجام ترجمه آدرس شبکه (NAT) یکی از بزرگ‌ترین چالش‌های راه‌اندازی خطوط ویپ است؛ سرور شما برای آنکه بتواند در شبکه جهانی یا شبکه اختصاصی مخابرات بسته‌ها را صحیح تبادل کند، باید آدرس عمومی و دامنه‌های محلی خود را بشناسد.
برای رفع ناسازگاری‌های مربوط به NAT، در درایور سنتی chan_sip تنظیم صحیح پارامترهای زیر الزامی است:
- nat=force_rport,comedia جهت پاسخ‌دهی به پورت مبدأ بسته‌ها
- externip=YOUR_PUBLIC_IP جهت معرفی آدرس عمومی سرور در هدر بسته‌ها
- localnet=192.168.1.0/255.255.255.0 جهت تشخیص بسته‌های درون‌سازمانی از بسته‌های اینترنتی
در صورتی که از درایور مدرن PJSIP استفاده می‌کنید، این پیکربندی از طریق فیلدهای external_media_address و external_signaling_address در بخش تنظیمات Transport کنترل می‌شود تا هویت بسته‌ها در جریان عبور از روتر دچار نقص نگردد.
چگونه خطاهای SIP Trunk را از طریق لاگ‌ها پیدا کنیم؟
سریع‌ترین و کارآمدترین شیوه برای عیب‌یابی SIP Trunk، پایش زنده هدرهای سیگنالینگ ردوبدل‌شده در کنسول استریسک (Asterisk CLI) و ابزارهای ترافیک‌سنجی تحت لینوکس است:
- فعال‌سازی لاگ در درایور chan_sip: با ورود به کنسول استریسک (asterisk -rvvv) دستور sip set debug on را اجرا کنید تا تمام هدرهای مبادله‌شده، وضعیت بسته‌ها و علت رد درخواست‌ها به وضوح چاپ شوند.
- فعال‌سازی لاگ در درایور PJSIP: با اجرای دستور pjsip set logger on در کنسول، جزئیات بسته‌های ترافیکی ارسالی و دریافتی این پروتکل نمایش داده می‌شود.
- استفاده از ابزار مانیتورینگ sngrep: نرم‌افزار متنی و تحت کنسول sngrep با ترسیم یک دیاگرام بصری از توالی بسته‌های INVITE، پاسخ‌های 40X، پیام‌های 200 OK و بسته‌های ACK، به شما امکان می‌دهد در چند ثانیه محل دقیق توقف تماس را شناسایی کنید.
علاوه بر این ابزارها، مطالعه استانداردهای رسمی خطاهای ارتباطی بر پایه مستندات مرجع پروتکل SIP در RFC 3261 و رهنمودهای تشخیصی موجود در تالار گفتگوی فنی جامعه استریسک به درک عمیق‌تر جزئیات این جریان‌ها کمک می‌کند.
کدهای خطای رایج SIP Trunk و معنی آن‌ها
| کد خطا | عنوان انگلیسی | علل اصلی بروز خطا | اقدام و راهکار پیشنهادی |
|---|---|---|---|
| 401 | Unauthorized | درخواست اولیه برای دریافت کلید چالش احراز هویت (روند عادی ثبت) | در تعامل اولیه طبیعی است؛ تکرار مداوم آن نشانه نامعتبر بودن رمز عبور است. |
| 403 | Forbidden | اشتباه در مشخصات کاربری، مسدود بودن حساب یا مجاز نبودن آدرس IP سرور | بررسی مقادیر احراز هویت و اطمینان از ثبت IP سرور در لیست سفید اپراتور. |
| 404 | Not Found | ارسال شماره مقصد نامعتبر، تنظیم اشتباه روت خروجی یا خطای دایال‌پلن | بررسی قوانین Outbound Routes و تطابق نحوه ارسال شماره با الگوهای اپراتور. |
| 408 | Request Timeout | عدم دریافت هیچ‌گونه پاسخ از سمت سرور مقصد به دلیل قطعی فایروال یا شبکه | بررسی پورت UDP 5060 در فایروال، پینگ سرور مقصد و غیرفعال کردن SIP ALG. |
| 486 | Busy Here | اشغال بودن شماره مقصد یا تکمیل بودن ظرفیت کانال‌های هم‌زمان ترانک | ارتقای سقف کانال‌های ترانک در اپراتور یا بررسی وضعیت داخلی پاسخ‌دهنده. |
| 488 | Not Acceptable Here | عدم انطباق کدک‌های صوتی انتخاب‌شده یا ناسازگاری در تنظیمات مدیا (SDP) | تنظیم کدک‌های پایه نظیر alaw و ulaw در بخش گزینه‌های ترانک و همگام‌سازی با مخابرات. |
| 503 | Service Unavailable | خرابی سرور مخابرات، بار پردازشی بیش از حد یا نقص در گیت‌وی اپراتور | گزارش وضعیت به تیم فنی ارائه‌دهنده سرویس و تعریف مسیرهای پشتیبان (Failover). |
سوالات متداول
خطای 403 در SIP Trunk به چه معناست؟
خطای 403 Forbidden نشان می‌دهد که سرور ارائه‌دهنده خط بسته درخواستی سرور شما را دریافت کرده و متوجه هویت ارائه‌شده شده است، اما بنا به الزامات امنیتی یا اداری مانع از دسترسی می‌شود. این خطا غالباً ناشی از اشتباه بودن اطلاعات احراز هویت، عدم تطابق پارامتر From User با سرشماره تخصیص‌یافته، پایان اعتبار ریالی خط یا مسدود شدن آدرس IP سرور شما در فایروال دیتاسنتر اپراتور است.
خطای 503 در SIP Trunk چیست؟
خطای 503 Service Unavailable معمولاً خطایی از سمت زیرساخت سرور مقصد یا گیت‌وی اپراتور مخابراتی است. این پیام بیانگر آن است که سوییچ‌های اپراتور موقتاً با کمبود ظرفیت پردازشی مواجه شده‌اند، سامانه‌های بالادستی آن‌ها در حال به‌روزرسانی هستند یا گیت‌وی‌های ارتباطی با اختلال فنی مواجه شده‌اند؛ برای مصون ماندن از چنین مسائلی، تعریف ترانک‌های پشتیبان روی اپراتورهای ثانویه در استریسک ضروری است.
چگونه از روی SIP Log مشکل Trunk را تشخیص دهیم؟
با بررسی جریان توالی پیام‌ها در لاگ استریسک یا ابزار sngrep می‌توان مرحله دقیق وقوع عیب را کشف کرد؛ اگر بعد از ارسال درخواست اولیه هیچ پیامی بازنگردد مشکل از قطعی فیزیکی یا مسدودی فایروال است؛ دریافت کدهای سری 4xx از اشتباه در اعتبارسنجی، فرمت شماره‌گیری یا عدم تطابق کدک‌ها خبر می‌دهد؛ و قطع سریع تماس پس از اتصال، از وجود تداخل در عبور بسته‌های ACK از روترهای NAT حکایت دارد.
