آخرین ویرایش نوامبر 11, 2026 حامد کوه فلاح

بهبود مدیریت ترانک‌های PJSIP در Issabel؛ قابلیت جدید Identify By و پشتیبانی از پورت SIP

یکی از مشکلاتی که ممکن است هنگام راه‌اندازی چند ترانک PJSIP در Asterisk و Issabel با آن مواجه شوید، تشخیص صحیح ترانک ورودی و اعمال پورت مقصد SIP در تنظیمات Registration است.

برای مثال، فرض کنید چند سرویس مختلف روی یک سرور به Asterisk متصل هستند و همگی از آدرس 127.0.0.1 استفاده می‌کنند. در چنین شرایطی، اگر شناسایی ترانک صرفاً بر اساس IP انجام شود، ممکن است درخواست‌های ورودی به ترانک اشتباهی نسبت داده شوند.

از طرف دیگر، در فرم تنظیم ترانک PJSIP در Issabel فیلدی برای واردکردن پورت سرور SIP وجود دارد؛ اما پیش از این تغییر، مقدار این فیلد در بخش‌هایی از تنظیمات تولیدشده، از جمله آدرس‌های AOR و Registration، به‌درستی استفاده نمی‌شد.

در یک به‌روزرسانی جدید در پروژه IssabelPBX، این دو موضوع مورد توجه قرار گرفته‌اند. در این مقاله تغییرات Pull Request شماره 57 را بررسی می‌کنیم و توضیح می‌دهیم این اصلاحات چه تأثیری بر پیکربندی ترانک‌های PJSIP دارند و چگونه می‌توان آن‌ها را دریافت کرد.

این تغییر دقیقاً چه مشکلی را حل می‌کند؟

این تغییر دو قابلیت اصلی را بهبود می‌دهد:

1. امکان انتخاب روش شناسایی ترانک PJSIP با گزینه Identify By
2. استفاده صحیح از پورت SIP Server در آدرس‌های AOR و Registration

این موضوع به‌خصوص برای سناریوهایی اهمیت دارد که چند سرویس داخلی، چند ترانک یا چند مقصد SIP با تنظیمات متفاوت روی یک سرور وجود دارند.

۱. مشکل شناسایی ترانک‌های PJSIP بر اساس IP

در PJSIP، یکی از روش‌های شناسایی Endpointهای ورودی، استفاده از IP Address است.

برای این کار Asterisk از بخش identify استفاده می‌کند. یک نمونه ساده از این تنظیمات به شکل زیر است:

[provider-trunk-identify]
type=identify
endpoint=provider-trunk
match=192.168.1.100

در این مثال، درخواست SIP که از آدرس IP مشخص‌شده دریافت شود، به Endpoint با نام provider-trunk نسبت داده می‌شود.

این روش در بسیاری از سناریوها کاملاً مناسب است؛ اما همیشه بهترین انتخاب نیست.

مشکل زمانی ایجاد می‌شود که چند سرویس از یک IP مشترک استفاده کنند

فرض کنید روی یک سرور Issabel چند سرویس مختلف در حال اجرا هستند:

• یک سرویس داخلی که به Asterisk متصل می‌شود
• یک نرم‌افزار ارتباطی دیگر
• یک سرویس واسط یا Gateway محلی
• یک یا چند ترانک PJSIP

اگر چند سرویس از آدرس Loopback یعنی 127.0.0.1 استفاده کنند، شناسایی صرفاً بر اساس IP ممکن است باعث ابهام شود.

در چنین شرایطی ممکن است درخواست ورودی قبل از اینکه اطلاعات احراز هویت بتواند Endpoint موردنظر را مشخص کند، به ترانک دیگری نسبت داده شود.

این همان مسئله‌ای است که در توضیحات Pull Request به آن اشاره شده است.

۲. قابلیت جدید Identify By چیست؟

در تغییر جدید، یک گزینه با عنوان Identify By به فرم تنظیم ترانک PJSIP اضافه شده است.

این گزینه به مدیر سیستم اجازه می‌دهد مشخص کند Asterisk برای شناسایی Endpoint از چه روشی استفاده کند.

گزینه‌های اضافه‌شده عبارت‌اند از:

بنابراین دیگر لازم نیست در تمام سناریوها از روش IP-based Identification استفاده شود.

تفاوت Authentication Username و From Username

این دو گزینه از نظر فنی یکسان نیستند.

Authentication Username

به نام کاربری مورد استفاده در فرآیند احراز هویت SIP اشاره دارد. این روش می‌تواند در سناریوهایی مفید باشد که چند درخواست از یک IP مشترک ارسال می‌شوند اما اطلاعات احراز هویت آن‌ها متفاوت است.

From Username

به نام کاربری موجود در هدر From پیام SIP مربوط است. این مقدار الزاماً با نام کاربری احراز هویت یکسان نیست و نباید این دو را با یکدیگر اشتباه گرفت.

نکته مهم: استفاده از روش auth_username به تنظیم سراسری Asterisk نیز وابسته است. در Pull Request تأکید شده که auth_username باید در ترتیب شناسایی Endpointها در تنظیمات سراسری Asterisk فعال باشد. این تغییر به‌صورت خودکار آن تنظیم سراسری را تغییر نمی‌دهد و کنترل آن همچنان در اختیار مدیر سیستم است.

۳. مشکل اعمال‌نشدن SIP Server Port

موضوع دوم این تغییر، مربوط به فیلد SIP Server Port در تنظیم ترانک‌های PJSIP است.

در فرم تنظیم ترانک، مدیر سیستم می‌تواند آدرس سرور SIP و پورت آن را وارد کند.

برای مثال:

SIP Server: 192.168.10.20
SIP Server Port: 5070

انتظار داریم Asterisk برای ارتباط با مقصد از پورت 5070 استفاده کند.

اما طبق توضیحات Pull Request، مقدار این فیلد در نسخه قبلی مولد تنظیمات، در بعضی از آدرس‌های تولیدشده مانند AOR Contact و Registration URI اعمال نمی‌شد.

این مسئله می‌توانست باعث شود تنظیمات تولیدشده با اطلاعات واردشده در فرم یکسان نباشند.

در تغییر جدید چه اتفاقی افتاده است؟

در تابع تولید تنظیمات PJSIP، مقدار پورت خوانده و اعتبارسنجی می‌شود.

اگر پورت معتبر باشد، در آدرس مقصد مورد استفاده قرار می‌گیرد.

برای مثال، اگر اطلاعات ترانک به شکل زیر باشد:

Server: 192.168.10.20
Port: 5070

آدرس مقصد می‌تواند به شکل زیر تولید شود:

sip:192.168.10.20:5070

این اصلاح در بخش‌های زیر اعمال شده است:

• AOR Contact
• Registration server_uri
• Registration client_uri

در نتیجه مقدار پورت واردشده در فرم، در مسیرهای بیشتری از تنظیمات تولیدشده مورد استفاده قرار می‌گیرد.

۴. بهبودهای تکمیلی در مدیریت پورت

این تغییر فقط اضافه‌کردن پورت به انتهای آدرس نیست و چند حالت مهم نیز در کد در نظر گرفته شده است.

جلوگیری از تکرار پورت

اگر آدرس مقصد از قبل شامل پورت باشد، کد جدید از اضافه‌کردن مجدد پورت جلوگیری می‌کند.

برای مثال:

192.168.10.20:5060

در چنین حالتی نباید پورت دیگری به انتهای آدرس اضافه شود.

اعتبارسنجی محدوده پورت

مقدار پورت باید یک عدد صحیح در محدوده معتبر 1 تا 65535 باشد.

اگر مقدار واردشده خالی یا نامعتبر باشد، رفتار قبلی حفظ می‌شود.

پشتیبانی از IPv6

برای آدرس‌های IPv6، قالب‌بندی مقصد نیز در نظر گرفته شده است.

برای نمونه، یک آدرس IPv6 همراه با پورت باید در قالب استاندارد زیر قرار بگیرد:

[2001:db8::10]:5070

استفاده از براکت برای جداکردن آدرس IPv6 از شماره پورت ضروری است.

۵. آیا تنظیمات ترانک‌های قبلی تغییر می‌کند؟

یکی از نکات مهم این تغییر، توجه به سازگاری با تنظیمات قبلی است.

طبق توضیحات Pull Request:

• ترانک‌هایی که گزینه Identify By برای آن‌ها تعیین نشده باشد، رفتار قبلی IP Matching را حفظ می‌کنند.
• اگر پورت خالی یا نامعتبر باشد، مقصد قبلی حفظ می‌شود.
• اگر مقصد از قبل شامل پورت باشد، پورت دیگری به آن اضافه نمی‌شود.

بنابراین هدف این تغییر، بهبود قابلیت‌های تنظیم ترانک است و قرار نیست رفتار پیش‌فرض تمام ترانک‌های موجود را به‌صورت ناخواسته تغییر دهد.

با این حال، بعد از به‌روزرسانی ماژول، بهتر است تنظیمات ترانک‌های حساس و خروجی فایل‌های تولیدشده بررسی شوند.

۶. این تغییر برای چه سناریوهایی کاربرد دارد؟

سناریوی اول: چند سرویس داخلی روی 127.0.0.1

فرض کنید چند نرم‌افزار روی یک سرور Issabel به Asterisk متصل هستند.

در چنین شرایطی ممکن است همه درخواست‌ها از IP زیر دریافت شوند:

127.0.0.1

در این حالت می‌توان از روش‌های دیگر شناسایی Endpoint، مانند Authentication Username، استفاده کرد؛ البته به شرط پشتیبانی و فعال‌بودن مکانیزم مربوط در Asterisk.

سناریوی دوم: اتصال به SIP Server روی پورت غیراستاندارد

بعضی از سرویس‌دهندگان SIP از پورت‌هایی غیر از 5060 استفاده می‌کنند.

برای مثال:

SIP Server: 10.10.10.5
Port: 5070

با اصلاح جدید، مقدار پورت در آدرس‌های مرتبط با AOR و Registration نیز اعمال می‌شود.

سناریوی سوم: استفاده از چند ترانک با مقصدهای متفاوت

در سیستم‌هایی که چند ترانک PJSIP با تنظیمات مختلف دارند، امکان تعیین روش شناسایی و پورت مقصد، انعطاف‌پذیری بیشتری در پیکربندی فراهم می‌کند.

البته این تغییر به‌تنهایی جایگزین طراحی صحیح Endpointها، تنظیمات Authentication یا مدیریت مسیرهای SIP نیست.

۷. جزئیات فنی تغییرات در GitHub

این تغییر در مخزن رسمی IssabelFoundation و در قالب Pull Request شماره 57 ثبت شده است.

عنوان Pull Request:

Add PJSIP trunk identification selection and destination ports

وضعیت: Merged

تاریخ Merge: 10 November 2026

شاخه مقصد: 2.13.0.0

Commit نهایی:

b41d282578dbadf0ed5270fa0d236845c145f688

دو فایل اصلی تغییرکرده عبارت‌اند از:

فایل اول: core/page.trunks.php

در این فایل، گزینه Identify By به فرم تنظیم ترانک PJSIP اضافه شده است.

همچنین مقدار انتخاب‌شده از طریق سازوکار موجود تنظیمات pjsip_* ذخیره می‌شود.

فایل دوم: core/functions.inc.php

در این فایل، تابع تولید تنظیمات PJSIP اصلاح شده است.

مهم‌ترین تغییرات:

• خواندن مقدار پورت سرور
• اعتبارسنجی مقدار پورت
• ساخت آدرس مقصد با پورت معتبر
• جلوگیری از تکرار پورت
• مدیریت قالب IPv6
• تولید بخش Identify بر اساس انتخاب Identify By
• استفاده از مقصد اصلاح‌شده در AOR و Registration URI

برای مشاهده جزئیات کد و تغییرات می‌توانید Pull Request را بررسی کنید:

https://github.com/IssabelFoundation/issabelPBX/pull/57

۸. چگونه تغییرات جدید را در Issabel دریافت کنیم؟

این Pull Request در تاریخ ۱۰ نوامبر ۲۰۲۶ Merge شده است. برای دریافت تغییرات، در صورتی که بسته اصلاح‌شده در مخازن فعال Issabel منتشر شده باشد، می‌توانید سیستم را با دستور زیر به‌روزرسانی کنید:

yum update

این دستور بسته‌های نصب‌شده را بر اساس مخازن فعال سیستم به‌روزرسانی می‌کند.

پس از پایان عملیات، توصیه می‌شود نسخه بسته IssabelPBX و تنظیمات تولیدشده PJSIP را بررسی کنید تا مطمئن شوید تغییرات مربوط به Identify By و SIP Server Port در نسخه نصب‌شده وجود دارند.

نکته مهم: Merge شدن Pull Request به‌تنهایی به معنی انتشار فوری بسته در مخازن نیست. اگر پس از اجرای yum update تغییرات را دریافت نکردید، ممکن است بسته جدید هنوز در مخازن فعال سیستم منتشر نشده باشد.

برای سیستم‌های عملیاتی نیز بهتر است پیش از به‌روزرسانی، از تنظیمات و اطلاعات مهم نسخه پشتیبان تهیه کنید و تغییرات را در یک محیط آزمایشی بررسی کنید.

۹. جمع‌بندی

تغییر جدید Issabel در مدیریت ترانک‌های PJSIP دو نیاز کاربردی را پوشش می‌دهد:

1. انتخاب روش شناسایی ترانک به‌جای وابستگی همیشگی به IP
2. اعمال صحیح پورت SIP Server در آدرس‌های AOR و Registration

این اصلاح به‌خصوص برای سیستم‌هایی که چند سرویس داخلی، چند ترانک یا سرورهای SIP با پورت‌های غیراستاندارد دارند، اهمیت دارد.

برای دریافت تغییرات، در صورت انتشار بسته جدید در مخازن Issabel، می‌توانید از دستور yum update استفاده کنید.

این تغییر به معنی حل تمام مشکلات شناسایی ترانک در PJSIP نیست؛ بلکه ابزارهای بیشتری برای کنترل روش شناسایی و تولید صحیح تنظیمات در اختیار مدیر سیستم قرار می‌دهد.

درباره VOIPIRAN

VOIPIRAN بزرگ‌ترین مرجع فارسی‌زبان آموزش و محصولات VoIP است.

در VOIPIRAN می‌توانید آموزش‌های تخصصی Asterisk و Issabel، مطالب فنی، راهکارهای ارتباطی، محصولات نرم‌افزاری و ابزارهای موردنیاز مهندسان VoIP را دنبال کنید.

اگر در زمینه سیستم‌های تلفنی تحت شبکه فعالیت می‌کنید، مطالب آموزشی و محصولات VOIPIRAN می‌توانند در مسیر یادگیری، پیاده‌سازی و توسعه پروژه‌های VoIP همراه شما باشند.

🌐 وب‌سایت: https://voipiran.io

منابع و لینک‌های مرتبط

• Pull Request شماره 57 در GitHub
• Commit نهایی تغییرات
• دانلود Issabel 5 از SourceForge
• صفحه رسمی دریافت Issabel
• مرکز دانلود VOIPIRAN

برای مشاهده سایر آموزش‌ها و مطالب تخصصی به وب‌سایت VOIPIRAN مراجعه کنید:

https://voipiran.io