Amir Jabbari
اگر هدف شما فقط ساخت چند داخلی ساده باشد، گزینه‌های زیادی برای Asterisk وجود دارد؛ اما VitalPBX زمانی جذاب‌تر می‌شود که بخواهید یک سرویس تلفنی سازمانی یا Multi-Tenant بسازید و چند شرکت را از یک پنل مرکزی مدیریت کنید.
در این راهنما ابتدا وضعیت نسخه VitalPBX در سال ۲۰۲۶ و Asterisk زیر آن را مشخص می‌کنیم، سپس VitalPBX 4.5 را روی Debian 12 و سرور مجازی نصب می‌کنیم، ساختار چندشرکتی را توضیح می‌دهیم و در ادامه امنیت، Firewall، Fail2Ban، Backup و برنامه بازیابی را برای یک PBX واقعی بررسی می‌کنیم.
خلاصه نسخه روز: در ۱۷ اکتبر ۲۰۲۶، آخرین Release ثبت‌شده VitalPBX برابر 4.5.4 R2 است. سیستم‌عامل پایه VitalPBX 4.5، Debian 12 است و موتور تلفنی این شاخه در نسخه فعلی روی Asterisk 20.21.0 قرار دارد.
VitalPBX چیست؟
VitalPBX خودش موتور تماس نیست؛ بخش اصلی تماس‌ها توسط Asterisk انجام می‌شود.
VitalPBX روی Asterisk یک لایه مدیریتی ایجاد می‌کند تا بدون نوشتن دستی تعداد زیادی فایل Dialplan و PJSIP بتوانید سیستم تلفنی را مدیریت کنید.
ساختار ساده آن را می‌توان این‌گونه تصور کرد:
IP Phone / Softphone → VitalPBX → Asterisk → SIP Trunk / PSTN
در کنار Asterisk نیز سرویس‌هایی مثل NGINX، PHP، MariaDB، Firewall و Fail2Ban فعالیت می‌کنند.
VitalPBX در سال ۲۰۲۶ روی چه نسخه‌ای است؟
طبق Changelog رسمی VitalPBX 4.5، نسخه:
VitalPBX 4.5.4 R2
Release: 15 October 2026نسخه فعلی این شاخه در زمان بررسی مقاله است.
نسخه R2 علاوه بر Fixهای مختلف، تغییرهایی در Provisioning، Geo Firewall، AI Agents، Queue و Web Server Configuration داشته است.
Asterisk فعلی VitalPBX چه نسخه‌ای است؟
VitalPBX 4.5.4 R1 موتور Asterisk را به:
Asterisk 20.21.0ارتقا داده و در Changelog نسخه 4.5.4 R2 تغییر دیگری برای Asterisk اعلام نشده است.
بنابراین در زمان نگارش این مقاله VitalPBX برخلاف FreePBX 17 روی Asterisk 22 نیست؛ شاخه فعلی VitalPBX همچنان از Asterisk 20 استفاده می‌کند.
نسخه واقعی سرور خودمان را چطور ببینیم؟
نسخه Asterisk:
asterisk -rx "core show version"نسخه سیستم‌عامل:
cat /etc/os-releaseنسخه VitalPBX را نیز از پنل مدیریتی و بخش اطلاعات سیستم بررسی کنید.
VitalPBX 4.5 روی چه سیستم‌عاملی نصب می‌شود؟
شاخه رسمی VitalPBX 4.5 به Debian 12 منتقل شده است.
این نسل همراه با تغییر سیستم‌عامل، PHP 8.2 و NGINX را نیز وارد معماری اصلی کرده است.
برای نصب جدید روی VPS بهتر است از:
Debian 12 Minimal 64-bit
شروع کنید.
VitalPBX برای چه کسانی مناسب است؟
🔹 شرکت‌هایی که می‌خواهند سانترال VoIP روی VPS داشته باشند.
🔹 سازمان‌هایی با چند شعبه.
🔹 شرکت‌های ارائه‌دهنده تلفن ابری.
🔹 شرکت‌هایی که چند مشتری را روی یک زیرساخت مدیریت می‌کنند.
🔹 Call Centerها.
🔹 مجموعه‌هایی که به SIP Trunk متعدد نیاز دارند.
🔹 شرکت‌هایی که Provisioning تلفن‌های IP برایشان مهم است.
Multi-Tenant در VitalPBX یعنی چه؟
Multi-Tenant یعنی یک نصب VitalPBX بتواند چند سازمان یا مشتری را به‌صورت منطقی از یکدیگر جدا کند.
مثلاً:
Tenant A: شرکت فروش
Tenant B: شرکت پشتیبانی
Tenant C: یک مشتری دیگر
هرکدام می‌توانند:
🔹 داخلی‌های خودشان را داشته باشند.
🔹 IVR خودشان را داشته باشند.
🔹 Queue مستقل بسازند.
🔹 Ring Group مستقل داشته باشند.
🔹 Administrator مخصوص خودشان داشته باشند.
آیا Multi-Tenant در VitalPBX رایگان است؟
خیر.
طبق مستند رسمی Tenant Configuration، برای ساخت بیش از یک Tenant باید ماژول تجاری:
Multi-Tenantرا نصب و License مناسب تهیه کنید.
نوع و ظرفیت License به پلن انتخابی بستگی دارد؛ بنابراین قبل از طراحی سرویس Hosting، محدودیت مجوز فعلی را در سایت VitalPBX بررسی کنید.
آیا دو شرکت می‌توانند هر دو داخلی 1000 داشته باشند؟
بله؛ این یکی از مزیت‌های مهم Multi-Tenant VitalPBX است.
مثلاً:
Tenant A → Extension 1000
Tenant B → Extension 1000
Tenant C → Extension 1000VitalPBX از Prefix داخلی برای یکتا کردن Configuration هر Tenant استفاده می‌کند؛ بنابراین Numbering Plan مشتری‌ها می‌تواند مشابه باشد بدون اینکه با یکدیگر تداخل کند.
Tenant Administrator چه دسترسی‌ای دارد؟
برای هر Tenant می‌توان Administrator تعیین کرد.
مدیر یک شرکت وارد محیط همان Tenant می‌شود و بدون دسترسی به شرکت‌های دیگر می‌تواند بخش‌هایی که Administrator اصلی مجاز کرده است مدیریت کند.
این ویژگی برای شرکت‌هایی که PBX ابری به مشتریان ارائه می‌کنند بسیار مهم است.
آیا Trunk هر شرکت باید جدا باشد؟
هر Tenant می‌تواند اتصال خودش به Provider را داشته باشد، اما VitalPBX امکان استفاده از Trunk و Route مرکزی را نیز فراهم می‌کند.
در یک سرویس Hosted PBX می‌توانید دو مدل داشته باشید:
مدل اول: هر مشتری SIP Trunk مستقل داشته باشد.
مدل دوم: Trunk مرکزی Provider توسط Main System مدیریت و Routeها بین Tenantها توزیع شوند.
انتخاب صحیح به Provider، Billing، DID Allocation و مدل کسب‌وکار شما بستگی دارد.
آیا Tenantها می‌توانند با هم تماس بگیرند؟
بله.
VitalPBX قابلیتی با عنوان Tenant Trunk دارد که اجازه می‌دهد Tenantهای داخل همان سرور بدون ساخت Trunk شبکه‌ای معمول PJSIP با یکدیگر ارتباط داشته باشند.
این قابلیت برای یک شرکت با چند شعبه مفید است؛ مثلاً هر شعبه Tenant مستقل باشد اما داخلی‌های آن‌ها بتوانند با هم تماس بگیرند.
Multi-Tenant یعنی چند ماشین مجازی مستقل؟
خیر.
این نکته مهم است.
Tenantها از نظر Application و Configuration از یکدیگر جدا می‌شوند، اما همچنان روی یک سیستم‌عامل و یک زیرساخت PBX مشترک قرار دارند.
بنابراین خرابی:
🔹 VPS
🔹 Asterisk
🔹 Database
🔹 Storage
می‌تواند روی همه Tenantها اثر بگذارد.
اگر مشتری بسیار حساس، SLA سخت یا الزام جداسازی زیرساخت دارد، نصب VitalPBX مستقل روی VPS جدا می‌تواند معماری مناسب‌تری باشد.
چند Tenant روی یک سرور می‌توان ساخت؟
VitalPBX در مستندات Multi-Tenant توصیه می‌کند روی یک Server از حدود ۱۰۰ Tenant فراتر نروید.
اما این عدد به‌تنهایی معیار Capacity نیست.
مهم‌تر از تعداد Tenant:
🔹 تعداد Extension هر Tenant
🔹 تماس هم‌زمان
🔹 Queue و Call Center
🔹 Call Recording
🔹 Transcoding
🔹 CDR حجم بالا
است.
۱۰۰ Tenant به معنی ۱۰۰ شرکت کوچک بدون محدودیت نیست
مثلاً:
۱۰۰ Tenant با هرکدام ۵ داخلی با ۱۰۰ Tenant دارای ۱۰۰ داخلی و Call Center کاملاً متفاوت است.
بنابراین Capacity Planning باید بر اساس:
Concurrent Calls + Media Processing + Recording + Database Load
انجام شود.
منابع موردنیاز VPS
VitalPBX برای نصب پایه حداقل حدود:
🔹 ۲ هسته CPU
🔹 ۴ گیگابایت RAM
🔹 ۵۰ گیگابایت Storage
را در اسناد خود مطرح می‌کند.
اما این منابع برای Hosted Multi-Tenant واقعی معیار خوبی نیستند.
برای سیستم چندشرکتی بهتر است Capacity را از تعداد تماس هم‌زمان طراحی کنید.
چه چیزی بیشترین CPU را مصرف می‌کند؟
اگر تماس فقط با همان Codec از Trunk به Phone منتقل شود، مصرف CPU نسبتاً پایین‌تر است.
اما Transcoding مثلاً بین دو Codec متفاوت می‌تواند CPU را به‌شدت افزایش دهد.
موارد دیگری که مصرف منابع را بالا می‌برند:
🔹 ضبط هم‌زمان تعداد زیادی تماس
🔹 Conference
🔹 Call Center سنگین
🔹 AI Voice Agent
🔹 CDR بزرگ
Storage در PBX چندشرکتی را دست‌کم نگیرید
در سروری با چند شرکت، Recording می‌تواند بسیار سریع‌تر از انتظار رشد کند.
فرض کنید هر Tenant روزانه صدها تماس ضبط کند؛ حتی اگر مصرف CPU پایین باشد، Disk ممکن است اولین گلوگاه شما شود.
برای همین Storage Monitoring و Retention Policy ضروری است.
مرحله ۱: آماده‌سازی VPS
برای نصب جدید یک VPS با:
🔹 Debian 12 Minimal
🔹 Public IP ثابت
🔹 دسترسی Root
🔹 Disk کافی
آماده کنید.
برای Production بهتر است Hostname و FQDN را نیز از ابتدا مشخص کنید.
مثلاً:
pbx.example.comDNS را قبل از نصب بررسی کنید
A Record دامنه باید به Public IP سرور اشاره کند.
dig +short pbx.example.comمرحله ۲: Debian را به‌روز کنید
apt update
apt upgrade -yاگر Kernel Update شد، Reboot انجام دهید.
مرحله ۳: Installer رسمی VitalPBX 4.5
طبق راهنمای رسمی VPS Installation:
wget https://repo.vitalpbx.com/vitalpbx/v4.5/pbx_installer.sh
chmod +x pbx_installer.sh
./pbx_installer.shInstaller باید با دسترسی Root اجرا شود.
اسکریپت اینترنتی را قبل از Production بررسی کنید
هرچند این Installer رسمی VitalPBX است، برای محیط حساس بهتر است قبل از اجرا:
🔹 Snapshot VPS بگیرید.
🔹 URL را بررسی کنید.
🔹 سرور Production دیگری روی همان VPS نداشته باشید.
PBX را بهتر است روی سیستم‌عامل تمیز و اختصاصی نصب کنید.
مرحله ۴: بعد از نصب Serviceها را بررسی کنید
Asterisk:
systemctl status asterisk --no-pagerNGINX:
systemctl status nginx --no-pagerMariaDB:
systemctl status mariadb --no-pagerمرحله ۵: ابتدا یک PBX ساده را سالم کنید
قبل از نصب Multi-Tenant، بهتر است یک داخلی و یک تماس معمولی روی Main System تست شود.
یک Extension بسازید و بررسی کنید:
🔹 PJSIP Registration
🔹 تماس داخلی
🔹 RTP دوطرفه
🔹 Voicemail در صورت استفاده
اگر Base PBX هنوز مشکل دارد، اضافه‌کردن Tenant عیب‌یابی را پیچیده‌تر می‌کند.
مرحله ۶: نصب Multi-Tenant Add-on
پس از تهیه License مناسب:
Admin → Add-Ons → Add-Ons
ماژول Multi-Tenant را نصب کنید.
بعد از فعال‌شدن، بخش:
Admin → Multi-Tenant
در دسترس قرار می‌گیرد.
مرحله ۷: اولین Tenant را بسازید
در:
Admin → Multi-Tenant → Tenants
Tenant جدید بسازید.
مثلاً:
Tenant Name: company-a
Description: Company A
Prefix: APrefix را جدی بگیرید
Prefix بخشی اساسی از معماری Multi-Tenant VitalPBX است.
با Prefix می‌توان Objectهای متعلق به Tenantهای مختلف را داخل Asterisk یکتا کرد.
بنابراین اگر Tenant A و B هر دو Extension 1000 داشته باشند، سیستم در لایه داخلی می‌تواند آن‌ها را جدا نگه دارد.
مرحله ۸: Tenant Administrator بسازید
برای هر Tenant می‌توانید Administrator جدا بسازید.
این User فقط بخش‌های مجاز همان Tenant را می‌بیند.
همچنین یک User می‌تواند در صورت نیاز به بیش از یک Tenant دسترسی داشته باشد؛ قابلیتی که برای Reseller یا نماینده فروش کاربرد دارد.
مرحله ۹: Extensionهای Tenant را بسازید
داخل همان Tenant داخلی‌ها را ایجاد کنید.
مثلاً:
1000
1001
1002سپس همین شماره‌ها را در Tenant دیگر نیز می‌توانید داشته باشید.
مرحله ۱۰: Trunk و Route را طراحی کنید
قبل از اضافه‌کردن تعداد زیادی Tenant، تصمیم بگیرید Trunking شما چه مدلی دارد.
| مدل | کاربرد |
|---|---|
| Trunk مستقل برای هر Tenant | هر شرکت Provider و Credential خودش را دارد |
| Trunk مرکزی | Provider و Route توسط Main System مدیریت می‌شود |
| Tenant Trunk | ارتباط مستقیم بین Tenantهای همان VitalPBX |
برای Hosted PBX، DID Mapping باید از ابتدا طراحی شود
اگر چند شرکت از یک SIP Trunk مرکزی استفاده می‌کنند، باید مشخص باشد هر DID به کدام Tenant و Destination تعلق دارد.
مثلاً:
DID 021XXXX001 → Tenant A
DID 021XXXX002 → Tenant B
DID 021XXXX003 → Tenant CRoute اشتباه در معماری چندمشتری فقط یک تماس خراب نمی‌کند؛ ممکن است تماس شرکت A وارد شرکت B شود.
امنیت VitalPBX چندشرکتی مهم‌تر از PBX تک‌شرکتی است
در یک سیستم Single-Tenant اگر Credential یک داخلی لو برود، یک سازمان آسیب می‌بیند.
در Hosted Multi-Tenant، compromise شدن Administrator اصلی یا VPS می‌تواند روی همه مشتری‌ها اثر بگذارد.
پس Security باید از ابتدا بخشی از معماری باشد.
Firewall را همیشه فعال نگه دارید
VitalPBX در راهنمای رسمی امنیت توصیه می‌کند Firewall داخلی فعال باشد و در معماری‌های حساس از Firewall خارجی یا SBC نیز استفاده شود.
برای SIP Trunkهایی که Provider IP ثابت دارد، Sourceها را تا حد ممکن محدود کنید.
دلیلی ندارد هر IP اینترنت بتواند به تمام SIP Interfaceهای PBX دسترسی داشته باشد.
Fail2Ban را غیرفعال نکنید
VitalPBX از Fail2Ban برای مقابله با Login و Registrationهای ناموفق استفاده می‌کند.
مواردی مثل:
🔹 SSH Brute Force
🔹 Web Login Attack
🔹 SIP Password Guessing
می‌توانند باعث Ban شدن IP شوند.
IP مدیریت را Whitelist کنیم؟
اگر Administrator از Public IP ثابت قابل اعتماد استفاده می‌کند، می‌توانید آن را از:
Admin → Firewall → Access Control
به Whitelist اضافه کنید.
اما کل Range یک ISP را فقط برای اینکه Administrator Ban نشود Whitelist نکنید.
رمز داخلی‌ها را استاندارد کنید
در Hosted PBX از Passwordهایی مثل:
1000
123456
companynameاستفاده نکنید.
هر Extension باید Secret طولانی و تصادفی خودش را داشته باشد.
پنل مدیریت را از اینترنت عمومی محدود کنید
برای سرور Carrier یا Multi-Tenant بهتر است بخش Administrator فقط از:
🔹 VPN
🔹 IP ثابت مدیریت
🔹 شبکه مدیریتی
در دسترس باشد.
دسترسی کاربران Tenant را از دسترسی Root/Admin اصلی جدا کنید.
SSH را نیز مستقل امن کنید
امنیت پنل VitalPBX جای امنیت لینوکس را نمی‌گیرد.
برای SSH بهتر است Key Authentication، محدودکردن Root Access، Firewall و Fail2Ban را بررسی کنید.
برای این بخش می‌توانید راهنمای امن‌سازی SSH با SSH Key و Fail2Ban در ایرانیکاسرور را نیز ببینید.
TLS و Certificate را جدی بگیرید
برای پنل وب از HTTPS و Certificate معتبر استفاده کنید.
اگر Phoneها و SIP Provider شما پشتیبانی می‌کنند، SIP over TLS نیز می‌تواند Signaling را رمزنگاری کند.
اما TLS جای Firewall و Password قوی را نمی‌گیرد.
امنیت Recordingها در VitalPBX 4.5.4 بهتر شده است
از VitalPBX 4.5.4 R1، برای Call Recording و Voicemail روش‌های Secure Access جدید اضافه شده تا فایل‌های صوتی فقط با مسیر عمومی ساده در دسترس نباشند.
این ویژگی برای Multi-Tenant اهمیت زیادی دارد؛ چون Recordingهای هر شرکت می‌توانند اطلاعات محرمانه مشتریان را شامل شوند.
Update امنیتی را پشت گوش نیندازید
در ژوئن ۲۰۲۶ نسخه 4.5.3 R7 حتی حداقل نسخه NGINX را برای رفع آسیب‌پذیری‌های امنیتی مهم اجباری کرد.
این مثال نشان می‌دهد PBX را نمی‌توان بعد از نصب برای چند سال بدون Update رها کرد.
اما Update روی سرور چندشرکتی نیز باید با Backup و Maintenance Window انجام شود.
Backup در VitalPBX چگونه کار می‌کند؟
VitalPBX ماژول:
Admin → Tools → Backup and Restore
دارد.
در Backup Profile می‌توانید موارد مختلف را انتخاب کنید.
🔹 Configuration
🔹 CDR
🔹 Call Recordings
🔹 Voicemail
🔹 Fax
🔹 برخی داده‌های Add-onها
Backup را زمان‌بندی کنید
Backup Profile می‌تواند با Cron به‌صورت خودکار اجرا شود.
برای PBX Production، Backup دستی قبل از Upgrade کافی نیست.
حداقل باید Backup زمان‌بندی‌شده داشته باشید.
Backup روی همان VPS، Backup کامل نیست
اگر Backup داخل همان Disk باقی بماند و VPS یا Storage خراب شود، هم سیستم و هم Backup را از دست می‌دهید.
نسخه Backup را به Storage جدا منتقل کنید.
برای مثال:
🔹 Backup Server
🔹 NAS
🔹 Object Storage
🔹 سرور دیگر از طریق SCP/SFTP
Recordingها را جداگانه مدیریت کنید
مستند رسمی VitalPBX هشدار می‌دهد Call Recordingها می‌توانند حجم بسیار زیادی ایجاد کنند.
مسیر متداول Recording:
/var/spool/asterisk/monitorاست.
برای سیستم چندشرکتی بزرگ بهتر است Recordingها را روی Storage جداگانه نگهداری یا به‌صورت مستقل Copy کنید.
چرا Recording را از Backup Configuration جدا کنیم؟
فرض کنید Configuration کل VitalPBX فقط چندصد مگابایت باشد، ولی Recordingها ۲ ترابایت باشند.
قرار دادن همه‌چیز در یک Backup واحد باعث می‌شود:
🔹 Backup بسیار طولانی شود.
🔹 Restore کند شود.
🔹 فضای VPS پر شود.
🔹 احتمال شکست فرآیند افزایش پیدا کند.
بهتر است Configuration Backup و Recording Archive را به‌عنوان دو لایه مستقل مدیریت کنید.
CDR هم با بزرگ‌شدن Multi-Tenant مهم می‌شود
در یک سیستم چندشرکتی CDR می‌تواند میلیون‌ها Record داشته باشد.
VitalPBX در نسخه‌های ۲۰۲۶ چندین Optimization برای Report و CDR اضافه کرده است.
اما Retention Policy هنوز مهم است.
داده‌ای که باید ۵ سال نگهداری شود با داده‌ای که فقط برای سه ماه لازم است یک طراحی Storage یکسان ندارد.
Backup خوب یعنی Restore تست‌شده
وجود فایل Backup کافی نیست.
حداقل دوره‌ای روی VPS آزمایشی:
Backup → Import → Restore → Test
را اجرا کنید.
بعد از Restore بررسی کنید:
🔹 Tenantها وجود دارند.
🔹 Extensionها سالم‌اند.
🔹 Trunkها درست هستند.
🔹 Routeها برگردشته‌اند.
🔹 Licenseها فعال‌اند.
🔹 Recordingها قابل دسترس‌اند.
قبل از Upgrade حتماً Snapshot بگیریم؟
اگر VPS Provider شما Snapshot ارائه می‌کند، قبل از Upgradeهای مهم گرفتن Snapshot منطقی است.
ولی Snapshot جای Backup مستقل را نمی‌گیرد.
مدل بهتر:
Backup VitalPBX خارج از سرور + Snapshot VPS قبل از Upgrade
برنامه Backup پیشنهادی برای Hosted PBX
| نوع داده | پیشنهاد |
|---|---|
| Configuration | Backup خودکار روزانه |
| Database/CDR | بر اساس Retention و حجم |
| Recording | Storage مستقل + Backup خارج از VPS |
| Voicemail | داخل Backup دوره‌ای |
| قبل از Update | Backup + Snapshot |
| Restore Test | به‌صورت دوره‌ای روی سیستم آزمایشی |
اگر یک Tenant اشتباه Configuration کند چه می‌شود؟
سطح دسترسی Tenant Administrator را محدود کنید.
هر Moduleای که مشتری واقعاً نیاز ندارد در اختیار او قرار ندهید.
اصل:
Least Privilege
در Hosted PBX بسیار مهم است.
همه Tenantها را روی یک Trunk مشترک قرار دهیم؟
همیشه نه.
Trunk مشترک مدیریت را ساده می‌کند، اما روی:
🔹 Billing
🔹 Caller ID
🔹 Abuse Control
🔹 Credit Limit
🔹 Call Restriction
نیاز به طراحی دقیق‌تری دارد.
برای بعضی مشتری‌ها Trunk مستقل، Isolation عملیاتی بهتری ایجاد می‌کند.
محدودیت تماس خروجی را Tenant به Tenant طراحی کنید
یکی از بزرگ‌ترین ریسک‌های PBX اینترنتی Toll Fraud است.
مثلاً یک Extension نباید فقط به این دلیل که Trunk اجازه تماس بین‌الملل دارد، بتواند هر مقصدی را شماره‌گیری کند.
برای هر Tenant Class of Service و Route Permission مناسب تعریف کنید.
Monitoring برای Multi-Tenant ضروری است
فقط Online بودن VPS را مانیتور نکنید.
موارد مهم:
🔹 CPU Load
🔹 RAM
🔹 Disk Usage
🔹 IOPS
🔹 Asterisk Service
🔹 Trunk Registration
🔹 تماس هم‌زمان
🔹 Recording Storage
🔹 Database Growth
🔹 Certificate Expiry
چرا Disk Alert شاید مهم‌تر از CPU Alert باشد؟
در سیستم‌های Recording-heavy، معمولاً Storage آرام‌آرام پر می‌شود.
پرشدن `/var` یا Root Filesystem می‌تواند Database، Logging و حتی Asterisk را دچار مشکل کند.
Alarm را قبل از رسیدن Disk به 100 درصد تنظیم کنید.
VitalPBX و FusionPBX چه تفاوت مفهومی دارند؟
هر دو می‌توانند برای PBX چندمشتری استفاده شوند، اما موتور زیرین متفاوت است:
| ویژگی | VitalPBX | FusionPBX |
|---|---|---|
| موتور تلفنی | Asterisk | FreeSWITCH |
| Multi-Tenant | Commercial Add-on | ساختار Domain-based |
| سیستم‌عامل فعلی رایج | Debian 12 | Debian 12/13 |
| مدیریت Extension | GUI مبتنی بر Asterisk | GUI مبتنی بر FreeSWITCH |
انتخاب بین این دو فقط به ظاهر پنل وابسته نیست؛ تجربه تیم شما با Asterisk یا FreeSWITCH و مدل Multi-Tenant اهمیت بیشتری دارد.
آیا VitalPBX برای ۱۰۰ شرکت روی یک VPS مناسب است؟
ممکن است، اما تعداد شرکت به‌تنهایی معیار کافی نیست.
قبل از رسیدن به چنین مقیاسی باید Load Test، Storage Plan، Monitoring و Backup/Restore واقعی داشته باشید.
مستند رسمی VitalPBX نیز با وجود نمونه‌های بیش از ۱۰۰ Tenant، بیش از حدود ۱۰۰ Tenant روی یک Server را توصیه نمی‌کند.
برای سرویس‌دهنده تلفن ابری، یک Server کافی است؟
برای شروع شاید.
اما اگر Hosted PBX برای مشتری‌های تجاری ارائه می‌کنید باید از ابتدا Failure Domain را در نظر بگیرید.
اگر تنها VPS شما از دسترس خارج شود، تمام Tenantها Offline می‌شوند.
در مقیاس بالاتر باید معماری‌هایی مثل:
🔹 چند Node
🔹 High Availability
🔹 Backup خارج از Node
🔹 SBC
🔹 Monitoring خارجی
را بررسی کنید.
VitalPBX قابلیت High Availability دارد؟
بله، VitalPBX مستندات رسمی برای HA روی Debian 12 با ابزارهایی مانند DRBD، Pacemaker و Corosync ارائه کرده است.
اما HA یک موضوع مستقل و بسیار حساس است؛ صرف نصب دو VPS بدون تست Failover به معنی High Availability واقعی نیست.
چک‌لیست ساخت VitalPBX چندشرکتی
مرحله ۱: Debian 12 Minimal روی VPS نصب کنید.
مرحله ۲: Public IP ثابت و FQDN بسازید.
مرحله ۳: VitalPBX 4.5 را با Installer رسمی نصب کنید.
مرحله ۴: نسخه Asterisk و VitalPBX را Verify کنید.
مرحله ۵: Firewall، Fail2Ban و HTTPS را بررسی کنید.
مرحله ۶: یک Extension پایه بسازید و تماس داخلی بگیرید.
مرحله ۷: Multi-Tenant Add-on و License را فعال کنید.
مرحله ۸: Tenant و Prefix هر شرکت را تعریف کنید.
مرحله ۹: Tenant Administrator بسازید.
مرحله ۱۰: Extensionهای هر Tenant را ایجاد کنید.
مرحله ۱۱: Trunk و DID Routing را طراحی کنید.
مرحله ۱۲: تماس داخلی، ورودی و خروجی هر Tenant را تست کنید.
مرحله ۱۳: Backup خودکار ایجاد کنید.
مرحله ۱۴: Recordingها را روی Storage مناسب قرار دهید.
مرحله ۱۵: یک Restore آزمایشی انجام دهید.
Test Plan قبل از ورود مشتری واقعی
| تست | نتیجه مورد انتظار |
|---|---|
| Tenant Login | فقط اطلاعات همان Tenant دیده شود |
| Extension Registration | داخلی‌های هر Tenant Register شوند |
| شماره داخلی مشابه | 1000 در دو Tenant بدون تداخل کار کند |
| Inbound DID | هر DID به Tenant صحیح برسد |
| Outbound Call | Route و Caller ID درست باشند |
| Tenant Trunk | فقط Tenantهای مجاز با هم تماس بگیرند |
| Recording | فایل صحیح برای تماس صحیح ذخیره شود |
| Backup | Backup بدون خطا تولید شود |
| Restore | Tenant و Trunk و Route برگردند |
| Security | Tenant به Tenant دیگر دسترسی نداشته باشد |
پرسش‌های رایج
VitalPBX چیست؟
VitalPBX یک پنل مدیریتی مبتنی بر Asterisk است که امکان ساخت مرکز تلفن VoIP، داخلی، SIP Trunk، IVR، Queue، Recording، Provisioning و Multi-Tenant را فراهم می‌کند.
آخرین نسخه VitalPBX در اکتبر ۲۰۲۶ چیست؟
در زمان بررسی این مقاله آخرین نسخه ثبت‌شده در Changelog رسمی VitalPBX، نسخه 4.5.4 R2 منتشرشده در ۱۵ اکتبر ۲۰۲۶ است.
VitalPBX 4.5.4 از چه نسخه Asterisk استفاده می‌کند؟
شاخه فعلی VitalPBX 4.5.4 از Asterisk 20.21.0 استفاده می‌کند.
VitalPBX روی چه سیستم‌عاملی نصب می‌شود؟
برای VitalPBX 4.5 نصب رسمی روی Debian 12 Minimal انجام می‌شود.
آیا Multi-Tenant در VitalPBX رایگان است؟
برای بیش از یک Tenant به Multi-Tenant Commercial Add-on و License مناسب نیاز دارید.
آیا دو Tenant می‌توانند داخلی یکسان داشته باشند؟
بله. VitalPBX با استفاده از Prefix Configurationهای Tenantها را از هم جدا می‌کند و مثلاً Extension 1000 می‌تواند در چند Tenant وجود داشته باشد.
چند Tenant را می‌توان روی یک VitalPBX داشت؟
ظرفیت واقعی به سخت‌افزار، تعداد Extension، تماس هم‌زمان، Call Center و Recording بستگی دارد. VitalPBX توصیه می‌کند روی یک سرور از حدود ۱۰۰ Tenant فراتر نروید.
Backup VitalPBX شامل Recording هم می‌شود؟
Backup Profile می‌تواند Call Recording را نیز شامل شود، اما به دلیل حجم بالا VitalPBX توصیه می‌کند Recordingهای بزرگ روی Storage یا Backup Server جدا مدیریت شوند.
آیا VitalPBX برای Hosted PBX مناسب است؟
بله؛ Multi-Tenant، Tenant Administrator، Trunkهای مستقل یا مشترک و Tenant Trunk آن را برای Hosted PBX مناسب می‌کنند، اما امنیت، ظرفیت، Backup و Failure Domain باید از ابتدا طراحی شوند.
آیا برای VitalPBX روی VPS IP ثابت لازم است؟
از نظر فنی همه سناریوها الزام مطلق ندارند، اما برای SIP Trunk، DNS، TLS، Firewall و Remote Extensionها Public IP ثابت انتخاب بسیار مناسب‌تری است.
جمع‌بندی
VitalPBX در سال ۲۰۲۶ همچنان یکی از گزینه‌های فعال برای ساخت PBX مبتنی بر Asterisk است و نسخه فعلی 4.5.4 R2 روی Debian 12 و Asterisk 20.21.0 قرار دارد.
مهم‌ترین مزیت آن برای سرویس‌دهندگان، Multi-Tenant است؛ چند شرکت می‌توانند روی یک سرور قرار بگیرند، Numbering Plan مشابه داشته باشند و Administrator مستقل دریافت کنند.
اما Multi-Tenant به معنی چند VPS مستقل نیست. CPU، RAM، Storage، Database و Asterisk بین Tenantها مشترک‌اند؛ بنابراین خرابی یا کمبود منابع می‌تواند همه مشتری‌ها را تحت تأثیر قرار دهد.
برای Production ابتدا یک VitalPBX ساده را روی VPS با IP ثابت راه‌اندازی و تست کنید، سپس Multi-Tenant را اضافه کنید. Trunk، DID، Permission و Backup را Tenant به Tenant طراحی کنید و از قرار دادن تعداد زیادی مشتری روی سروری که Restore و Failover آن آزمایش نشده خودداری کنید.
در نهایت یک Hosted PBX حرفه‌ای فقط پنل زیبا و چند Extension نیست؛ Firewall، Fail2Ban، Password قوی، Recording Storage، Backup خارج از سرور، Monitoring و برنامه بازیابی همان‌قدر اهمیت دارند که خود Asterisk.
می‌خواهید چند شرکت را روی یک VitalPBX میزبانی کنید؟ زیرساخت را قبل از فروش سرویس درست طراحی کنید
برای Multi-Tenant، فقط نصب VitalPBX کافی نیست. سرور باید IP ثابت، منابع قابل ارتقا، فضای مناسب Recording و امکان Snapshot و Backup داشته باشد؛ چون خرابی یک VPS می‌تواند تلفن تمام Tenantهای همان Node را قطع کند.
می‌توانید ابتدا VitalPBX 4.5 را روی یک سرور مجازی ایران با IP ثابت راه‌اندازی کنید، دو Tenant آزمایشی بسازید و Registration، Trunk، DID Routing، Recording، Fail2Ban و Restore را کامل تست کنید؛ سپس شرکت‌های اصلی را وارد سیستم کنید.
مشاوره راه‌اندازی VitalPBX و سانترال چندشرکتی: 021-91302467
دیدگاه‌ها (۰)