Amir Jabbari
مهاجرت FreePBX 16 به 17 را نباید مثل یک آپدیت معمولی انجام دهید. در FreePBX 17 پایه سیستم به Debian 12 منتقل شده، Asterisk 22 در Installer رسمی پیش‌فرض است و Restore می‌تواند Trunkها و Extensionهای قدیمی chan_sip را به PJSIP تبدیل کند. بنابراین روش کم‌ریسک این است که FreePBX 17 را روی یک سرور جدا بسازید، Backup نسخه 16 را Restore کنید، همه تماس‌ها و قابلیت‌ها را آزمایش کنید و فقط در آخر Cutover انجام دهید.
مسیر رسمی و کم‌ریسک: FreePBX 16 را دست‌نخورده نگه دارید، روی Debian 12 یک FreePBX 17 جدید نصب کنید، Backup را Restore کنید و بعد از پایان Test Plan، مسیر SIP/NAT/DNS/Provisioning را به سرور جدید منتقل کنید. FreePBX برای مهاجرت به 17، Upgrade درجا را مسیر رسمی نمی‌داند.
قبل از مهاجرت؛ بدانید FreePBX 17 چه چیزی را تغییر می‌دهد
مهاجرت FreePBX 16 به 17 فقط تغییر GUI نیست. FreePBX 17 روی Debian 12 بنا شده و Installer رسمی فعلی Asterisk 22 را به‌صورت پیش‌فرض نصب می‌کند. در سمت Application نیز PHP 8.2 وارد محیط اصلی شده است.
سه تغییر بیشترین اثر را روی Restore دارند:
🔹 سیستم‌عامل از خانواده SNG/CentOS به Debian 12 تغییر کرده است.
🔹 Asterisk 22 در مسیر پیش‌فرض FreePBX 17 از chan_sip استفاده نمی‌کند و PJSIP محور اصلی است.
🔹 Custom Moduleها و Scriptهای PHP باید با PHP 8.2 سازگار باشند.
به همین دلیل، مهاجرت امن باید روی یک سرور جدید انجام شود تا FreePBX 16 تا لحظه Cutover دست‌نخورده باقی بماند.
مرحله ۱: قبل از Backup یک Inventory واقعی بسازید
بزرگ‌ترین خطای Migration این است که فقط Backup بگیرید و تصور کنید هر چیزی که روی PBX وجود دارد داخل فایل Backup رفته است. ابتدا Inventory بسازید تا بعداً بتوانید نسخه 16 و 17 را مقایسه کنید.
حداقل این موارد را ثبت کنید:
🔹 تعداد Extensionها و نوع هرکدام؛ PJSIP یا chan_sip.
🔹 تمام SIP Trunkها، Hostها، Portها و Registration Stringها.
🔹 Inbound Route و Outbound Routeها.
🔹 IVR، Ring Group، Queue، Time Condition و Announcementها.
🔹 Voicemail و Greetingهای اختصاصی.
🔹 Call Recordingها و مسیر ذخیره آن‌ها.
🔹 Certificateهای HTTPS، SIP TLS و Certificateهای سفارشی.
🔹 Moduleهای Commercial، Third-party و Custom.
🔹 Custom Dialplan، AGI، Cron Job و Scriptهای خارج از FreePBX.
🔹 Firewall Zone، NAT، Public IP و Port Forwardهای فعلی.
نسخه‌ها را قبل از Migration ثبت کنید
fwconsole --version
asterisk -V
php -v
fwconsole ma listخروجی `fwconsole ma list` را ذخیره کنید تا بعد از Restore بتوانید Moduleهای Missing، Disabled یا متفاوت را سریع پیدا کنید.
مرحله ۲: Moduleها را قبل از Backup به‌روز و دسته‌بندی کنید
FreePBX 17 می‌تواند Backup نسخه 16 را Restore کند، اما این به معنی سازگاری همه Moduleهای جانبی نیست. پروژه FreePBX در FAQ رسمی نیز توصیه می‌کند قبل از Migration وضعیت Moduleها مشخص باشد.
Moduleها را به سه گروه تقسیم کنید:
| نوع Module | ریسک | اقدام |
|---|---|---|
| Core/Standard FreePBX | کم | قبل از Backup به نسخه پایدار فعلی بروزرسانی شود |
| Commercial | متوسط | License، Deployment ID و نسخه سازگار 17 بررسی شود |
| Third-party / Custom | زیاد | سازگاری PHP 8.2 و FreePBX 17 جداگانه تست شود |
اگر Module تجاری دارید، FAQ رسمی FreePBX پیشنهاد می‌کند FreePBX 17 جدید را ابتدا با Deployment ID مناسب فعال کنید و سپس Restore را انجام دهید تا داده Moduleهای Commercial درست‌تر برگردند. اگر فقط Moduleهای Open Source دارید، Activation می‌تواند بعد از Restore انجام شود.
مرحله ۳: Full Backup بگیرید؛ اما محتویات آن را هم بررسی کنید
مسیر رسمی FreePBX برای انتقال از 16 به 17 استفاده از Backup & Restore است. از GUI به مسیر زیر بروید:
Admin
→ Backup & Restore
→ New Backup
→ Full Backupاگر System Audio، Voicemail یا فایل‌های دیگری جدا از Template اصلی دارید، آن‌ها را هم در Backup Job وارد کنید. FreePBX امکان اضافه‌کردن Moduleها، Templateها و Pathهای سفارشی به Backup را دارد.
Backup را فقط از روی نام فایل تأیید نکنید
بعد از ساخته‌شدن فایل، Manifest را بخوانید:
fwconsole bu --manifest=/path/to/freepbx16-backup.tar.gzبرای دیدن لیست فایل‌ها نیز می‌توانید Archive را بدون Extract کامل بررسی کنید:
tar -tvzf /path/to/freepbx16-backup.tar.gzاین مرحله بسیار مهم است چون Custom Directory یا Integrationهایی که Backup/Restore Class ندارند ممکن است خودکار وارد Backup نشوند.
مرحله ۴: Recordingها را جداگانه اندازه‌گیری و راستی‌آزمایی کنید
Call Recordingها می‌توانند چند ده یا چند صد گیگابایت باشند. نباید فرض کنید چون Configuration Backup موفق شده، تمام Recordingها هم منتقل شده‌اند.
اول فضای مصرفی مسیر Recording فعلی را ببینید:
du -sh /var/spool/asterisk/monitorبعد بررسی کنید Backup Job واقعاً این داده‌ها را شامل می‌شود یا خیر. اگر حجم Recordingها زیاد است، بهتر است آن‌ها را با یک Copy جدا و قابل Resume منتقل کنید و Backup Application را برای Configuration نگه دارید.
نمونه Copy جداگانه با حفظ ساختار فایل‌ها:
rsync -aHAX --info=progress2 /var/spool/asterisk/monitor/ root@NEW-PBX:/var/spool/asterisk/monitor/قبل از استفاده از این دستور، مسیر واقعی Recording در سیستم خودتان را تأیید کنید و Permission/Ownership مقصد را بعد از Copy بررسی کنید.
مرحله ۵: Certificateها را فقط Restore نکنید؛ دوباره Verify کنید
FreePBX ممکن است Certificateهای مدیریت‌شده را از طریق Module مربوطه Restore کند، اما برای Migration کم‌ریسک نباید صرفاً به وجود نام Certificate در GUI اکتفا کنید.
برای هر Certificate مهم ثبت کنید:
🔹 Certificate برای HTTPS است یا SIP TLS؟
🔹 FQDN فعلی سرور چیست؟
🔹 Certificate از Let’s Encrypt است یا CA سفارشی؟
🔹 Private Key روی سرور جدید در دسترس است؟
🔹 Certificate بعد از تغییر IP/FQDN هنوز معتبر است؟
بعد از Restore، HTTPS و SIP TLS را جداگانه تست کنید. اگر Certificate به Hostname قبلی وابسته است و DNS قرار است در Cutover تغییر کند، Renewal و Challenge را قبل از خاموش‌کردن سیستم قدیمی طراحی کنید.
مرحله ۶: FreePBX 17 جدید را با IP جدا نصب کنید
سرور جدید را روی Debian 12 و یک IP داخلی جدا بسازید. تا زمان Cutover، Public NAT یا SIP Provider را به آن منتقل نکنید.
Installer رسمی FreePBX 17:
wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh
bash /tmp/sng_freepbx_debian_install.shInstaller رسمی فعلی برای Debian 12 طراحی شده و Asterisk 22 را به‌صورت پیش‌فرض نصب می‌کند.
مرحله ۷: Backup نسخه 16 را روی FreePBX 17 Restore کنید
برای Backupهای معمولی می‌توانید Restore را از GUI انجام دهید. برای Archiveهای بزرگ، CLI قابل‌اعتمادتر است چون Browser Timeout روی Jobهای طولانی محتمل است.
نمونه Restore از CLI:
sudo -u asterisk TMPDIR=/var/spool/asterisk/tmp fwconsole backup --restore=/path/to/freepbx16-backup.tar.gzقبل از Restore، Disk Space مقصد را بررسی کنید و اگر Backup بزرگ است فضای `/var/spool/asterisk/tmp` را هم در نظر بگیرید.
مرحله ۸: تبدیل chan_sip به PJSIP را با دقت مدیریت کنید
FreePBX 17 هنگام Restore Backup حاوی chan_sip می‌تواند Extensionها و Trunkها را به PJSIP تبدیل کند. این قابلیت مفید است، اما FAQ رسمی FreePBX صریحاً هشدار می‌دهد که به‌دلیل تنوع تنظیمات Providerها، Trunk تبدیل‌شده باید قبل از Production کاملاً تست شود.
همچنین FreePBX توضیح می‌دهد که پس از Conversion، Portهای chan_sip الزاماً حفظ نمی‌شوند و تنظیمات PJSIP مقصد می‌توانند Portهای جدید را تعیین کنند.
بعد از Restore، Endpointها را ببینید
asterisk -rx "pjsip show endpoints"و Registrationهای PJSIP را بررسی کنید:
asterisk -rx "pjsip show registrations"مرحله ۹: داخلی‌ها را قبل از Trunkها تست کنید
اول تست داخلی انجام دهید تا PBX، Dialplan، Codec و Endpoint Registration مستقل از Provider تأیید شوند.
برای دو Extension آزمایشی این موارد را انجام دهید:
🔹 هر دو Extension Register شوند.
🔹 تماس داخلی دوطرفه برقرار شود.
🔹 Hold و Resume کار کند.
🔹 Blind Transfer و Attended Transfer تست شود.
🔹 Voicemail و MWI کار کند.
🔹 DTMF در IVR داخلی تست شود.
اگر همین مرحله مشکل دارد، هنوز سراغ Provider و NAT نروید.
مرحله ۱۰: Trunkها را یکی‌یکی Verify کنید
برای هر Trunk یک Test Case مستقل بسازید. فقط Status سبز کافی نیست.
| تست | چه چیزی را ثابت می‌کند؟ |
|---|---|
| Registration | Credential، Registrar و Transport |
| Outbound Call | Dial Pattern، Caller ID و Route |
| Inbound Call | DID، NAT، Provider Route و Inbound Route |
| DTMF | RFC4733/INFO و سازگاری Provider |
| Two-way Audio | RTP، NAT و Firewall |
| Long Call | Session Timer و NAT State |
اگر Provider بر اساس Source IP احراز هویت می‌کند، تا زمان Cutover ممکن است نتوانید Trunk را روی هر دو PBX هم‌زمان فعال کنید. در این حالت یک Maintenance Window کوتاه یا هماهنگی با Provider لازم است.
مرحله ۱۱: Recordingها، Voicemail و فایل‌های صوتی را با Sample واقعی تست کنید
وجود فایل‌ها در Disk کافی نیست. چند Recording قدیمی را از GUI باز کنید، یک تماس جدید Record کنید و Permission فایل جدید را بررسی کنید.
برای Recordingها سه تست انجام دهید:
🔹 یک Recording قدیمی از تاریخ قبل از Migration پخش شود.
🔹 یک تماس جدید Record شود.
🔹 CDR جدید به فایل Recording درست Link شود.
برای Voicemail نیز Greeting، Message قدیمی و ثبت Message جدید را تست کنید.
مرحله ۱۲: Certificate و TLS را بعد از Restore دوباره تست کنید
این موارد را از روی GUI و Trace بررسی کنید:
🔹 HTTPS پنل با Certificate مورد انتظار باز شود.
🔹 FQDN جدید/قدیم با SAN Certificate سازگار باشد.
🔹 SIP TLS Trunk یا Endpoint در صورت استفاده Register شود.
🔹 Let’s Encrypt Renewal روی سیستم جدید قابل اجرا باشد.
اگر Cutover شامل تغییر DNS است، TTL را از قبل کاهش دهید تا بازگشت به سرور قدیمی در Rollback سریع‌تر باشد.
مرحله ۱۳: Test Plan کامل قبل از Cutover
| بخش | تست الزامی | نتیجه قابل قبول |
|---|---|---|
| Extension | Register + تماس داخلی | دوطرفه و بدون خطا |
| Outbound | موبایل/ثابت/بین‌الملل در صورت استفاده | Route و Caller ID صحیح |
| Inbound | تمام DIDهای مهم | Route مقصد صحیح |
| IVR | همه گزینه‌ها + Timeout | DTMF و مقصدها صحیح |
| Queue | Agent Login و Failover | Ring Strategy درست |
| Voicemail | Record/Playback/MWI | بدون خطا |
| Recording | قدیمی + جدید | Playback و Link صحیح |
| TLS | HTTPS/SIP TLS | Certificate معتبر |
| DTMF | IVR Provider | تمام Digitها صحیح |
| RTP | تماس طولانی | بدون One-Way Audio و Drop |
مرحله ۱۴: Rollback را قبل از Cutover بنویسید، نه بعد از مشکل
FreePBX در FAQ رسمی هشدار می‌دهد Restore از نسخه 17 به 16 به‌عنوان Downgrade تست‌شده و پشتیبانی‌شده نیست. بنابراین Rollback شما نباید بر پایه «Backup 17 را دوباره روی 16 Restore می‌کنیم» باشد.
Rollback واقعی این است که FreePBX 16 قبلی را سالم نگه دارید و فقط Traffic را برگردانید.
FreePBX 16
10.10.10.10
KEEP INTACT
FreePBX 17
10.10.10.20
TEST + RESTORE
CUTOVER
NAT / DNS / SIP PROVIDER / PHONE PROVISIONING
↓
FreePBX 17
ROLLBACK
Revert the same changes
↓
FreePBX 16قبل از Cutover این اطلاعات را روی کاغذ داشته باشید
🔹 Ruleهای NAT قبل و بعد.
🔹 IP پابلیک و داخلی دو PBX.
🔹 DNS Record و TTL.
🔹 IP Whitelist سمت Provider.
🔹 DHCP/TFTP/Provisioning URL تلفن‌ها.
🔹 شماره تماس Provider NOC یا Support.
مرحله ۱۵: Cutover با کمترین Downtime
وقتی تمام Test Plan پاس شد، یک Backup نهایی از FreePBX 16 بگیرید. اگر از زمان Backup آزمایشی تا Cutover تغییرات زیادی ایجاد شده، Delta اصلی را دوباره Restore/Sync کنید.
ترتیب پیشنهادی:
🔹 تغییرات مدیریتی روی FreePBX 16 را موقتاً Freeze کنید.
🔹 Backup نهایی را بگیرید.
🔹 داده‌های نهایی Recording/Voicemail را Sync کنید.
🔹 Trunk/NAT/DNS را به FreePBX 17 منتقل کنید.
🔹 چند Extension نماینده را Re-register کنید.
🔹 Inbound و Outbound را بلافاصله تست کنید.
🔹 اگر Test بحرانی Fail شد، Rollback Plan را اجرا کنید.
FreePBX 16 را همان شب حذف نکنید. بعد از Cutover موفق، مدتی سیستم قدیمی را خاموش اما قابل‌بازگشت نگه دارید تا اگر مشکل پنهانی در Queue، Recording، Fax، DID یا Module جانبی دیده شد، Evidence و Recovery Path داشته باشید.
اشتباه‌های رایج در مهاجرت FreePBX 16 به 17
🔹 Restore مستقیم روی Production بدون Lab Test.
🔹 اعتماد به سبز بودن Trunk بدون تست Inbound/Outbound.
🔹 فرض اینکه همه Recordingها داخل Backup آمده‌اند.
🔹 نادیده‌گرفتن Third-party Module و Custom PHP Code.
🔹 بررسی نکردن Certificate پس از تغییر FQDN/IP.
🔹 تبدیل خودکار chan_sip به PJSIP و رفتن مستقیم به Production.
🔹 حذف FreePBX 16 قبل از پایان دوره Validation.
🔹 طراحی Rollback بر پایه Restore نسخه 17 به 16.
می‌خواهید FreePBX 16 را بدون ریسک روی Production به 17 منتقل کنید؟
یک روش مطمئن این است که FreePBX 17 را ابتدا روی VPS جدا راه‌اندازی کنید، Backup را Restore کنید و تمام داخلی‌ها، Trunkها، Recordingها، Certificateها و Moduleها را قبل از Cutover تست کنید.
ایرانیکاسرور می‌تواند برای ساخت سرور آزمایشی، نصب Debian 12 و FreePBX 17، Restore Backup، تبدیل PJSIP، تست Trunk و طراحی Rollback کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
آیا می‌توان FreePBX 16 را مستقیم به 17 Upgrade کرد؟
مسیر رسمی FreePBX برای مهاجرت به 17 نصب تازه روی Debian 12 و سپس Backup/Restore است. برای Production بهتر است سیستم 16 قبلی تا پایان Validation دست‌نخورده بماند.
آیا داخلی‌ها و Trunkهای chan_sip بعد از Restore از بین می‌روند؟
FreePBX 17 می‌تواند هنگام Restore آن‌ها را به PJSIP تبدیل کند، اما Trunkهای تبدیل‌شده باید به‌دلیل تفاوت Providerها به‌طور کامل تست شوند.
از کجا مطمئن شویم Backup کامل است؟
Backup Job را از نظر Moduleها و Pathهای موردنیاز بررسی کنید و سپس Manifest Archive را با `fwconsole bu –manifest` بخوانید. برای فایل‌های سفارشی و Recordingهای حجیم، Copy جداگانه نیز منطقی است.
آیا Call Recordingها خودکار منتقل می‌شوند؟
به تنظیمات Backup Job بستگی دارد. روی Migration حساس نباید فرض کنید همه Recordingها داخل Backup هستند؛ حجم و Manifest را بررسی کنید و در صورت نیاز `/var/spool/asterisk/monitor` را جداگانه Sync کنید.
Certificateهای FreePBX بعد از Restore چه می‌شوند؟
Certificateهای مدیریت‌شده ممکن است همراه داده Module Restore شوند، اما HTTPS، SIP TLS، Private Key، FQDN و Renewal باید روی سرور جدید دوباره Verify شوند.
اگر FreePBX 17 مشکل داشت می‌توان Backup آن را روی 16 Restore کرد؟
FreePBX این Downgrade را تست‌شده یا پشتیبانی‌شده نمی‌داند. Rollback امن این است که FreePBX 16 قبلی را نگه دارید و NAT/DNS/SIP Route را به آن برگردانید.
آیا Moduleهای Commercial قبل از Restore باید فعال شوند؟
FAQ رسمی FreePBX توصیه می‌کند اگر Module تجاری دارید، Deployment جدید را قبل از Restore فعال کنید تا اطلاعات Moduleهای Commercial بهتر Restore شوند.
چقدر Downtime برای Migration لازم است؟
اگر Restore و Test روی سرور جدا از قبل انجام شده باشد، Downtime اصلی می‌تواند به زمان تغییر NAT/DNS/SIP Provider و Re-register شدن تلفن‌ها محدود شود. عدد دقیق به معماری شبکه و Provider شما بستگی دارد.
جمع‌بندی
مهاجرت FreePBX 16 به 17 زمانی کم‌ریسک است که آن را «تعویض PBX» در نظر بگیرید، نه یک Upgrade ساده. سیستم 17 را روی Debian 12 و IP جدا بسازید، Backup نسخه 16 را Restore کنید و chan_sip/PJSIP، Moduleها، Certificateها، Recordingها و تمام Call Flowها را قبل از Cutover بررسی کنید.
برای Recording و فایل‌های سفارشی به نام Full Backup اعتماد نکنید؛ Manifest را بخوانید و داده حجیم را در صورت نیاز جدا Sync کنید. برای Trunkها هم فقط Registration کافی نیست؛ Inbound، Outbound، DTMF و RTP باید تست شوند.
مهم‌ترین بخش Rollback است: FreePBX 16 را حذف نکنید. اگر در Production مشکلی رخ داد، به‌جای Downgrade Backup، مسیر NAT، DNS، SIP Trunk و Provisioning را به PBX قبلی برگردانید.
برای مهاجرت FreePBX 16 به 17 کمک می‌خواهید؟
اگر Backup، Trunk یا Recordingهای مهم دارید، بهتر است FreePBX 17 ابتدا روی سرور جدا Restore شود و فقط بعد از عبور از Test Plan به Production برود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)