Amir Jabbari
در این مقاله وضعیت FreePBX 17 در سال ۲۰۲۶ را بررسی می‌کنیم، می‌بینیم Debian 12 و Asterisk 22 چه چیزی را تغییر داده‌اند، کدام بخش‌های مهاجرت پرریسک‌ترند و چطور از FreePBX 16 به 17 برویم بدون اینکه در زمان Cutover راه بازگشت نداشته باشیم.
خلاصه برای مدیر سیستم: برای نصب جدید، ترکیب Debian 12 + FreePBX 17 + Asterisk 22 در حال حاضر انتخاب منطقی و رسمی است. برای مهاجرت از FreePBX 16، روی Upgrade درجا حساب نکنید؛ یک سرور جدید بسازید، Backup را Restore و تست کنید، سرور قبلی را برای Rollback نگه دارید و فقط پس از تست واقعی تماس‌ها Cutover انجام دهید.
وضعیت FreePBX 17 و Asterisk 22 در اکتبر ۲۰۲۶
در اسکریپت رسمی فعلی FreePBX 17، متغیرهای اصلی نصب به‌صورت زیر تعریف شده‌اند:
ASTVERSION=${ASTVERSION:-22}
PHPVERSION="8.2"یعنی نصب رسمی امروز FreePBX 17 روی Debian 12، به‌طور پیش‌فرض Asterisk 22 و PHP 8.2 را هدف می‌گیرد.
آخرین نسخه پایدار Asterisk 22 در زمان بررسی این مقاله:
Asterisk 22.11.0است.
Asterisk 22 یک نسخه LTS محسوب می‌شود و طبق جدول رسمی پروژه، پشتیبانی کامل آن تا اکتبر ۲۰۲۸ و دوره Security Fix تا اکتبر ۲۰۲۹ ادامه دارد.
آیا Asterisk 22 جدیدترین Asterisk است؟
نه؛ و این تفاوت مهمی است.
در اکتبر ۲۰۲۶ Asterisk 23 نیز به‌عنوان Standard Release وجود دارد و Asterisk 24 وارد چرخه Release Candidate شده است.
اما «جدیدترین نسخه» لزوماً بهترین انتخاب برای PBX تولیدی نیست.
| شاخه | نوع | وضعیت در اکتبر ۲۰۲۶ | مناسب Production FreePBX |
|---|---|---|---|
| Asterisk 20 | LTS | هنوز پشتیبانی می‌شود | بله، مخصوص سیستم‌های موجود |
| Asterisk 21 | Standard | فقط Security Fix | برای نصب جدید انتخاب اول نیست |
| Asterisk 22 | LTS | فعال و پایدار | بله، انتخاب مناسب |
| Asterisk 23 | Standard | فعال | پس از تست Compatibility |
| Asterisk 24 | LTS بعدی | در زمان بررسی RC | هنوز Baseline تولیدی این مقاله نیست |
برای سیستمی که چند سال باید پایدار بماند، Asterisk 22 LTS در حال حاضر تعادل مناسبی بین تازگی، پشتیبانی و ریسک دارد.
تغییر بزرگ اول: FreePBX از خانواده CentOS به Debian 12 آمده است
تا نسل‌های قبلی FreePBX Distro، بسیاری از مدیران به محیط CentOS/RHEL-derived عادت داشتند.
FreePBX 17 این مسیر را تغییر داده و سیستم رسمی را روی:
Debian GNU/Linux 12
Codename: bookwormقرار داده است.
این تغییر چند نتیجه مهم دارد.
🔹 Package Management از yum/dnf به apt منتقل می‌شود.
🔹 Dependencyها به اکوسیستم Debian نزدیک‌تر شده‌اند.
🔹 Security Updateهای سیستم‌عامل مستقیماً از چرخه Debian استفاده می‌کنند.
🔹 نصب روی VPS و Cloud Image استاندارد Debian ساده‌تر شده است.
🔹 اسکریپت‌ها و Automationهای قدیمی CentOS باید بازبینی شوند.
آیا می‌توان FreePBX 17 را فعلاً روی Debian 13 نصب کرد؟
برای Production توصیه نمی‌شود.
هدف رسمی نصب فعلی FreePBX 17 همچنان Debian 12 است و Install Script نیز Bookworm را مبنا قرار داده است.
حتی در سال ۲۰۲۶ گزارش‌هایی از کاربرانی وجود داشته که سیستم ناخواسته به Debian 13 رفته و مجبور شده‌اند برای داشتن محیط Supported دوباره Debian 12 را Restore کنند.
بنابراین روی یک PBX تولیدی، بدون اعلام رسمی پشتیبانی، Major Upgrade سیستم‌عامل را انجام ندهید.
تغییر بزرگ دوم: PHP 8.2
FreePBX 17 به PHP 8.2 منتقل شده است.
این تغییر برای خود FreePBX مزایای Performance، Security و Compatibility با کتابخانه‌های جدید دارد، اما مهم‌ترین ریسک آن برای مدیر سیستم:
ماژول‌های قدیمی یا سفارشی است.
کدی که سال‌ها روی PHP 7.x بدون خطا اجرا می‌شده، ممکن است در PHP 8.2 Warning یا Error تولید کند.
قبل از Migration همه Moduleها را موجودی‌برداری کنید
روی سرور قدیمی:
fwconsole ma listخروجی را ذخیره کنید.
به‌خصوص این Moduleها را جدا کنید:
🔹 Moduleهای Third-Party
🔹 Moduleهای Commercial
🔹 Moduleهای قدیمی که دیگر Update نمی‌شوند
🔹 Moduleهای نوشته‌شده توسط شرکت یا برنامه‌نویس داخلی
Compatibility هرکدام با FreePBX 17 و PHP 8.2 باید قبل از Cutover مشخص باشد.
چرا Restore موفق به معنی Migration موفق نیست؟
ممکن است Backup بدون Error جدی Restore شود اما بخشی از یک Module بعداً در Runtime خراب شود.
مثلاً:
🔹 صفحه GUI یک Module باز نشود.
🔹 Cron Job خطا دهد.
🔹 CDR ثبت نشود.
🔹 Certificate Management خطا دهد.
🔹 یک Module تجاری به License قبلی وابسته باشد.
پس تست Migration فقط «صفحه FreePBX باز شد» نیست.
تغییر بزرگ سوم: Asterisk 22 و Dialplan جدیدتر
یکی از تغییرهای مهمی که از FreePBX 17 آغاز شد، کنارگذاشتن ساختارهای قدیمی Dialplan مبتنی بر Macro است.
Asterisk در نسل‌های جدید app_macro را کنار گذاشته و FreePBX Dialplan خود را به Gosub منتقل کرده است.
برای کاربران عادی این تغییر تقریباً نامرئی است.
اما اگر فایل‌های Custom Dialplan دارید، اهمیت زیادی پیدا می‌کند.
اگر custom dialplan شما Macro دارد باید آن را بررسی کنید
مثلاً Custom Code قدیمی ممکن است ساختاری شبیه این داشته باشد:
Macro(custom-routing,...)در معماری جدید باید منطق آن بررسی و در صورت نیاز به Gosub تبدیل شود.
فقط Search & Replace کردن Macro با Gosub کافی نیست؛ نحوه Argument، Return و Variable Scope تفاوت دارد.
تغییر مهم دیگر: تمرکز روی PJSIP
FreePBX 17 در معماری رسمی جدید روی chan_pjsip متمرکز شده است.
این موضوع برای Migration از سیستم‌های قدیمی بسیار مهم است، زیرا بسیاری از FreePBXهای قدیمی هنوز Trunk یا Extensionهایی با chan_sip دارند.
اگر سرور فعلی شما مواردی مثل:
🔹 chan_sip Extensions
🔹 SIP Trunkهای قدیمی
🔹 تنظیمات nat=force_rport,comedia قدیمی
🔹 bindport سفارشی chan_sip
دارد، Migration را صرفاً Database Restore نبینید.
PJSIP چه تفاوت عملی ایجاد می‌کند؟
نام و ساختار بعضی پارامترها با chan_sip متفاوت است.
مفاهیمی مانند:
🔹 Endpoint
🔹 AOR
🔹 Auth
🔹 Identify
🔹 Transport
در PJSIP تفکیک بیشتری دارند.
بنابراین یک Trunk که سال‌ها روی chan_sip پایدار بوده باید بعد از Migration تماس ورودی، خروجی، DTMF، Caller ID، NAT و Codec آن دوباره تست شود.
تغییر بزرگ چهارم: Asterisk از Package Repository رسمی نصب می‌شود
در Debian 12، Sangoma Repository رسمی برای FreePBX ارائه کرده است.
Asterisk 22 نیز به شکل Package در همین اکوسیستم قابل نصب است.
این موضوع نگهداری Asterisk را نسبت به Build دستی از Source قابل‌کنترل‌تر می‌کند.
Packageهای اصلی Asterisk 22 در Repository شامل مواردی مشابه:
asterisk22
asterisk22-core
asterisk22-configsهستند.
چطور نسخه Asterisk را بررسی کنیم؟
asterisk -rx "core show version"نسخه PHP
php -vنسخه Debian
cat /etc/os-releaseنسخه FreePBX
fwconsole --versionآیا باید FreePBX 17 را مستقیماً روی سرور قبلی نصب کنیم؟
برای مهاجرت از FreePBX 16، پیشنهاد اصلی خیر است.
FreePBX به‌صورت رسمی اعلام کرده به دلیل تغییر سیستم‌عامل، مسیر Scripted In-place Upgrade از FreePBX 16 به 17 وجود ندارد.
مدل مهاجرت صحیح:
Old PBX → Backup → New Debian 12 → FreePBX 17 → Restore → Test → Cutover
معماری پیشنهادی Migration
به‌جای ارتقای ماشین فعلی، یک VPS یا VM جدید بسازید.
برای نمونه:
🔹 سرور قدیمی: FreePBX 16
🔹 سرور جدید: Debian 12 + FreePBX 17 + Asterisk 22
🔹 IP آزمایشی جدا
🔹 دسترسی محدود به SIP Provider تا زمان Cutover
تا پایان تست، سرور قدیمی را حذف نکنید.
چرا Migration موازی بهتر است؟
چون اگر Restore یا Module Compatibility مشکل داشته باشد، تلفن سازمان همچنان روی PBX قبلی کار می‌کند.
همچنین فرصت دارید بدون فشار Downtime این موارد را بررسی کنید:
🔹 Extensions
🔹 Trunks
🔹 Inbound Routes
🔹 Outbound Routes
🔹 IVR
🔹 Queues
🔹 Ring Groups
🔹 Voicemail
🔹 Call Recording
🔹 CDR
🔹 UCP
🔹 Certificates
🔹 Custom Dialplan
قبل از Backup چه چیزی را ثبت کنیم؟
فقط Backup File کافی نیست.
یک Inventory مستقل تهیه کنید.
نسخه‌ها:
fwconsole --version
asterisk -rx "core show version"
php -v
fwconsole ma listهمچنین جداگانه ذخیره کنید:
🔹 Screenshot Trunkها
🔹 SIP Provider Credentialها در Password Manager امن
🔹 Public IP و NAT Rules
🔹 Firewall Allowlist Provider
🔹 DNS/FQDN
🔹 TLS Certificateها
🔹 فایل‌های Custom
🔹 Recordingها
🔹 Commercial Module Licenseها
فایل‌های Custom را فراموش نکنید
بزرگ‌ترین خطر Migration همیشه Database نیست.
ممکن است سال‌ها قبل کسی فایل‌هایی مثل:
/etc/asterisk/extensions_custom.conf
/etc/asterisk/pjsip_custom.conf
/etc/asterisk/pjsip_custom_post.confرا تغییر داده باشد.
بررسی کنید Backup شما دقیقاً کدام فایل‌ها را شامل می‌شود و کدام تغییرها باید دستی منتقل شوند.
Module Compatibility را قبل از Restore بررسی کنید
پس از نصب تمیز FreePBX 17:
fwconsole ma listرا اجرا کنید و Disabled/Broken/Unsigned Moduleها را بررسی کنید.
در صورت نیاز و بعد از Backup:
fwconsole ma upgradeall
fwconsole reloadCommercial Moduleها یک ریسک جدا هستند
اگر System Admin، Endpoint Manager یا Moduleهای تجاری دیگری دارید، License/Deployment ID را قبل از مهاجرت بررسی کنید.
جابجایی به VM یا Hardware جدید ممکن است نیازمند Deactivation، Hardware Reset یا انتقال License باشد.
این مرحله را به شب Cutover موکول نکنید.
Migration در ۲۰۲۶ بدون تست قبلی توصیه نمی‌شود
هرچند مسیر رسمی همان Backup → New Install → Restore است، در Community طی سال ۲۰۲۶ گزارش‌هایی از Restore ناقص، Missing Extension و مشکلات Module Backup دیده شده است.
این گزارش‌ها به معنی خراب‌بودن عمومی Backup & Restore نیستند؛ اما نشان می‌دهند یک Production Migration را نباید اولین بار در پنجره Downtime آزمایش کرد.
حداقل یک Dry Run کامل انجام دهید.
Dry Run یعنی چه؟
یک Clone از Migration واقعی بسازید.
مثلاً:
مرحله ۱: Backup جدید از PBX 16.
مرحله ۲: Debian 12 VM جدید.
مرحله ۳: FreePBX 17 نصب شود.
مرحله ۴: Backup Restore شود.
مرحله ۵: تمام Moduleها بررسی شوند.
مرحله ۶: حداقل دو Extension آزمایشی Register شوند.
مرحله ۷: تماس داخلی تست شود.
مرحله ۸: یک Trunk آزمایشی یا Provider Route در صورت امکان تست شود.
بعد از Restore چه چیزهایی را حتماً تست کنیم؟
| بخش | تست لازم |
|---|---|
| Extension | Register، تماس داخلی، DTMF |
| Outbound | موبایل، ثابت، بین‌الملل در صورت استفاده |
| Inbound | DID → Route → Destination |
| IVR | Prompt و DTMF |
| Queue | Agent، Ring Strategy، Recording |
| Voicemail | Record، Playback، MWI |
| CDR | ثبت تماس واقعی |
| Recording | ایجاد و Playback فایل |
| TLS/SRTP | Registration و تماس امن |
| Fail2Ban/Firewall | Rule و Allowlist |
| UCP | Login و Featureها |
| Backup | Backup جدید روی v17 واقعاً تولید شود |
Asterisk 22 چه مزیتی برای FreePBX 17 دارد؟
مهم‌ترین مزیت برای Production، LTS بودن است.
در PBX معمولاً Stability مهم‌تر از داشتن آخرین Feature آزمایشی است.
Asterisk 22 چند سال Window پشتیبانی دارد و هم‌زمان از Stack جدیدتر PJSIP، Security Fixهای جدید و بهبودهای Runtime بهره می‌برد.
همچنین در سال ۲۰۲۶ نسخه 22.11.0 شامل مجموعه جدیدی از Fixها و Performance Improvementها منتشر شده است.
آیا بلافاصله بعد از هر Asterisk Release آپدیت کنیم؟
در PBX تولیدی بهتر است Change Management داشته باشید.
قبل از Update:
🔹 Snapshot یا Backup معتبر بگیرید.
🔹 Release Notes را بخوانید.
🔹 Module Compatibility را بررسی کنید.
🔹 در صورت امکان روی Staging تست کنید.
🔹 Maintenance Window داشته باشید.
«LTS» به معنی «هر Update را بدون تست نصب کن» نیست.
استفاده از asterisk-version-switch
در اکوسیستم جدید FreePBX، ابزار:
asterisk-version-switchبرای جابه‌جایی بین نسخه‌های Packageشده Asterisk استفاده می‌شود.
اما روی Production آن را فقط برای «امتحان یک نسخه» اجرا نکنید.
قبل از Switch باید Compatibility و Rollback Plan مشخص باشد.
Roll Back را قبل از Migration طراحی کنید، نه بعد از خرابی
Rollback واقعی یعنی بتوانید در چند دقیقه PBX قدیمی را دوباره به مدار برگردانید.
بهترین روش این است که سرور قدیمی را در Migration Window نابود نکنید.
ساختار:
PBX16 حفظ شود + PBX17 جدا ساخته شود.
قبل از Cutover Snapshot بگیرید
اگر روی VPS یا Hypervisor هستید، حداقل در دو نقطه Snapshot داشته باشید:
Snapshot A: Debian 12 + FreePBX 17 سالم قبل از Restore.
Snapshot B: بعد از Restore و Test، درست قبل از Cutover.
این Snapshotها جای Backup FreePBX را نمی‌گیرند؛ مکمل آن هستند.
هنگام Cutover هر دو PBX را هم‌زمان فعال نگذارید
اگر PBX قدیمی و جدید هر دو با Credential یکسان به SIP Provider Register شوند، ممکن است:
🔹 Registration یکدیگر را Override کنند.
🔹 تماس ورودی بین دو IP جابه‌جا شود.
🔹 Provider Account موقتاً Block شود.
🔹 NAT و Contact Header رفتار غیرقابل پیش‌بینی ایجاد کنند.
در لحظه Cutover، PBX قدیمی را Controlled Stop کنید و بعد Trunk جدید را فعال کنید.
یک Rollback عملی چه شکلی است؟
اگر بعد از Cutover مشکل جدی پیدا شد:
مرحله ۱: Asterisk/Network روی PBX17 را متوقف کنید.
مرحله ۲: NAT/Public IP/DNS یا Provider Route را به PBX16 برگردانید.
مرحله ۳: PBX16 را دوباره فعال کنید.
مرحله ۴: Registration Trunkها را بررسی کنید.
مرحله ۵: یک تماس ورودی و خروجی تست کنید.
اگر Commercial License را به PBX جدید منتقل کرده‌اید، Rollback ممکن است به هماهنگی License نیاز داشته باشد؛ به همین دلیل این موضوع باید قبل از Maintenance Window حل شود.
Rollback با Restore Backup روی همان سرور، Rollback خوبی نیست
اگر تنها راه برگشت شما این باشد که FreePBX17 را پاک کنید، سیستم قدیمی را از نو نصب و Backup را Restore کنید، Downtime شما قابل پیش‌بینی نیست.
برای سرویس تلفنی سازمانی، Old PBX باید تا تأیید کامل New PBX آماده بازگشت بماند.
FreePBX 17 را می‌توان روی VPS ایران اجرا کرد؟
بله. Debian 12 و FreePBX 17 به‌راحتی روی VPS مناسب اجرا می‌شوند و معماری جدید FreePBX نیز نصب روی Cloud Image استاندارد Debian را ساده‌تر کرده است.
برای PBX ابری علاوه بر CPU و RAM به این موارد بیشتر دقت کنید:
🔹 IP ثابت
🔹 Latency پایین کاربران تا VPS
🔹 Firewall دقیق برای SIP/RTP
🔹 Backup خارج از همان VPS
🔹 Snapshot قبل از Update
🔹 مانیتورینگ Disk و Recordingها
منابع سخت‌افزاری پیشنهادی
FreePBX در راهنمای شروع خود برای نصب پایه Debian 12 حداقل ۲ گیگابایت RAM و حدود ۲۰ گیگابایت Disk را مطرح می‌کند.
اما برای Production ظرفیت واقعی به تعداد Extension، تماس هم‌زمان، Recording، Transcoding، Queue و CDR بستگی دارد.
برای یک سیستم سازمانی کوچک، تخصیص فقط حداقل منابع معمولاً انتخاب خوبی برای Growth آینده نیست.
PHP 8.2 را دستی به نسخه‌های دیگر تغییر ندهید
Install Script رسمی فعلی FreePBX 17 صریحاً PHP 8.2 را بررسی می‌کند.
اگر بدون بررسی Compatibility سیستم را به PHP 8.3 یا نسخه دیگری ببرید، ممکن است Moduleها یا Commercial Packageها دچار مشکل شوند.
PBX محیط مناسبی برای Upgrade آزمایشی Runtime نیست.
بعد از Migration این Health Check را اجرا کنید
ماژول‌ها:
fwconsole ma listوضعیت Asterisk:
systemctl status asterisk --no-pager
asterisk -rx "core show uptime"PJSIP:
asterisk -rx "pjsip show endpoints"
asterisk -rx "pjsip show registrations"دیسک:
df -hچه کسانی باید سریع‌تر به FreePBX 17 مهاجرت کنند؟
سیستم‌هایی که هنوز روی Distro و OS قدیمی بدون Security Support مانده‌اند، بیشترین دلیل را برای برنامه‌ریزی Migration دارند.
اما «نیاز به مهاجرت» با «مهاجرت فوری بدون تست» فرق دارد.
اگر PBX حیاتی است، چند روز Staging ارزش بسیار بیشتری از چند ساعت Downtime غیرمنتظره دارد.
چه کسانی باید قبل از Migration بیشتر احتیاط کنند؟
اگر یکی از این موارد را دارید، Migration را پیچیده‌تر در نظر بگیرید:
🔹 Custom Dialplan زیاد
🔹 chan_sip Trunkهای قدیمی
🔹 Third-Party Module
🔹 Commercial Module متعدد
🔹 تلفن‌های Provision شده با Endpoint Manager
🔹 Recording چندساله و حجیم
🔹 Integration با CRM
🔹 AMI/ARI Script سفارشی
🔹 Call Center با Queueهای حساس
چک‌لیست Migration پیشنهادی
مرحله ۱: Inventory کامل FreePBX16 تهیه کنید.
مرحله ۲: Moduleها را Update و Backup سالم تولید کنید.
مرحله ۳: Backup را از سرور دانلود و خارج از PBX نگهداری کنید.
مرحله ۴: Debian 12 جدید بسازید.
مرحله ۵: FreePBX17 رسمی را نصب کنید.
مرحله ۶: Asterisk22 و PHP8.2 را Verify کنید.
مرحله ۷: Snapshot قبل از Restore بگیرید.
مرحله ۸: Backup را Restore کنید.
مرحله ۹: Moduleها، Custom Dialplan و Licenseها را بررسی کنید.
مرحله ۱۰: Extension و Trunk آزمایشی تست کنید.
مرحله ۱۱: Backup جدید روی FreePBX17 بگیرید.
مرحله ۱۲: Snapshot قبل از Cutover بگیرید.
مرحله ۱۳: PBX16 را متوقف و PBX17 را وارد مدار کنید.
مرحله ۱۴: تماس‌های حیاتی را تست کنید.
مرحله ۱۵: PBX16 را چند روز به‌عنوان Rollback خاموش ولی دست‌نخورده نگه دارید.
پرسش‌های رایج
FreePBX 17 در سال ۲۰۲۶ روی چه سیستم‌عاملی نصب می‌شود؟
سیستم رسمی FreePBX 17 بر Debian 12 یا Bookworm بنا شده است. نصب رسمی فعلی نیز Debian 12 را هدف می‌گیرد.
نسخه پیش‌فرض Asterisk برای FreePBX 17 چیست؟
اسکریپت رسمی فعلی FreePBX 17 در اکتبر ۲۰۲۶ به‌صورت پیش‌فرض Asterisk 22 را نصب می‌کند.
آخرین نسخه پایدار Asterisk 22 چیست؟
در زمان بررسی این مقاله، آخرین نسخه پایدار LTS شاخه 22 برابر Asterisk 22.11.0 است.
چرا Asterisk 22 به‌جای Asterisk 24 پیشنهاد می‌شود؟
Asterisk 22 یک LTS پایدار و کاملاً پشتیبانی‌شده است؛ Asterisk 24 در زمان بررسی هنوز در مرحله Release Candidate قرار دارد.
آیا می‌توان FreePBX 16 را مستقیم به 17 Upgrade کرد؟
برای Distro رسمی قدیمی مسیر In-place Upgrade وجود ندارد. روش رسمی نصب تازه Debian 12/FreePBX17 و انتقال داده از Backup است.
آیا Backup FreePBX 16 مستقیماً روی FreePBX 17 Restore می‌شود؟
این مسیر برای Migration استفاده می‌شود، اما باید قبل از Production با Backup واقعی خودتان آزمایش شود؛ Moduleهای سفارشی، Commercial License و Custom Fileها ممکن است نیاز به بررسی جدا داشته باشند.
مهم‌ترین مشکل Moduleها در FreePBX 17 چیست؟
تغییر به PHP 8.2 و تغییرهای Asterisk می‌توانند Moduleهای قدیمی یا Third-Party را تحت تأثیر قرار دهند. Compatibility را پیش از Migration بررسی کنید.
آیا chan_sip هنوز انتخاب مناسبی برای FreePBX 17 است؟
معماری FreePBX 17 روی PJSIP متمرکز است. Trunkها و Extensionهای قدیمی مبتنی بر chan_sip باید هنگام Migration بازبینی شوند.
بهترین روش Rollback چیست؟
سرور FreePBX16 را دست‌نخورده نگه دارید، FreePBX17 را روی VM/VPS جدا بسازید و در صورت مشکل، PBX17 را متوقف و Routing/NAT/Provider را به PBX16 برگردانید.
جمع‌بندی
تفاوت اصلی FreePBX 17 با نسل قبلی در ظاهر پنل نیست؛ لایه زیرین آن عوض شده است. Debian 12 جای Distro قدیمی را گرفته، PHP 8.2 به Runtime اصلی تبدیل شده و Asterisk 22 LTS امروز پایه مناسبی برای نصب جدید است.
این معماری به‌روزتر، نگهداری Packageها و Security Updateها را ساده‌تر می‌کند؛ اما برای Migration از FreePBX16 باید Module Compatibility، PJSIP، Custom Dialplan و Commercial Licensing را جدی بگیرید.
مهم‌ترین توصیه این است که FreePBX17 را روی سرور جدید بسازید و Restore را قبل از Maintenance Window آزمایش کنید. PBX قدیمی را تا چند روز بعد از Cutover نگه دارید تا Rollback واقعی داشته باشید.
برای یک سیستم تلفنی سازمانی، «Backup دارم» کافی نیست؛ باید ثابت کرده باشید که همان Backup روی Debian 12 و FreePBX17 واقعاً Restore می‌شود و تماس‌های واقعی را بدون مشکل عبور می‌دهد.
FreePBX 17 را روی یک Debian 12 تمیز و IP ثابت راه‌اندازی کنید
اگر قصد دارید PBX قدیمی را به FreePBX 17 و Asterisk 22 منتقل کنید، بهترین معماری این است که سرور جدید را جدا از سیستم فعلی بسازید، Backup را بدون ایجاد Downtime Restore و آزمایش کنید و فقط در زمان Cutover مسیر SIP را جابه‌جا کنید.
برای این سناریو می‌توانید از سرور مجازی ایران با IP ثابت استفاده کنید تا FreePBX 17 روی Debian 12 نصب شود و قبل از انتقال تماس‌های اصلی، Extensionها، Trunkها، NAT، RTP و Backup روی محیط جدید تست شوند.
برای بررسی Migration یا انتخاب منابع مناسب: 021-91302467
دیدگاه‌ها (۰)