Amir Jabbari
انتقال سانترال یا PBX داخلی شرکت به VPS یعنی مرکز تماس شما دیگر روی یک سرور فیزیکی داخل شرکت اجرا نمی‌شود و به یک سرور مجازی در دیتاسنتر منتقل می‌شود. این کار می‌تواند وابستگی تلفن سازمان به برق، اینترنت و سخت‌افزار یک ساختمان را کمتر کند و مدیریت شعبه‌ها و کاربران دورکار را ساده‌تر کند؛ اما اگر بدون بررسی شبکه، SIP Provider، امنیت، Backup و Rollback انجام شود، نتیجه می‌تواند قطع تماس، صدای یک‌طرفه، رجیستر نشدن داخلی‌ها یا حتی از دست رفتن Recordings باشد.
در این راهنما قرار نیست فقط Asterisk را روی VPS نصب کنیم. هدف، طراحی یک مهاجرت کم‌ریسک است: ابتدا وضعیت PBX فعلی را مستند می‌کنیم، سپس Latency و مسیر شبکه را می‌سنجیم، سازگاری SIP Trunk را بررسی می‌کنیم، VPS را امن می‌کنیم، Backup قابل‌بازیابی می‌سازیم، Cutover را مرحله‌ای انجام می‌دهیم و در پایان یک Rollback واقعی داریم که اگر مهاجرت خوب پیش نرفت بتوانیم به PBX قبلی برگردیم.
اصل مهم: روز مهاجرت نباید اولین روزی باشد که PBX جدید را تست می‌کنید. نسخه VPS باید قبل از Cutover با داخلی آزمایشی، تماس ورودی و خروجی، RTP دوطرفه، DTMF، Queue، IVR، Recording و Backup/Restore تست شده باشد.
آیا انتقال PBX به VPS برای هر شرکتی مناسب است؟
نه همیشه. اگر تلفن‌های شما فقط داخل یک LAN کوچک هستند، اینترنت بسیار ناپایدار است یا SIP Provider فقط از یک اتصال خصوصی محلی سرویس می‌دهد، PBX داخل شرکت هنوز می‌تواند انتخاب منطقی‌تری باشد. در مقابل، شرکت‌هایی با چند شعبه، کاربران دورکار، نیاز به دسترسی خارج از دفتر یا محدودیت سخت‌افزار محلی معمولاً از معماری VPS سود بیشتری می‌برند.
قبل از تصمیم، این سؤال‌ها را جواب دهید:
🔹 چند داخلی و چند تماس هم‌زمان دارید؟
🔹 کاربران از یک ساختمان وصل می‌شوند یا چند شهر و شعبه دارید؟
🔹 SIP Provider شما Trunk را با Username/Password می‌شناسد یا با Source IP؟
🔹 تماس‌های شما Record می‌شوند؟ حجم Recording چقدر است؟
🔹 اگر اینترنت دفتر قطع شود، چه تعداد کاربر باید همچنان تلفن داشته باشند؟
🔹 بیشترین قطعی قابل‌قبول هنگام Migration چقدر است؟
🔹 اگر VPS اصلی Down شود، RTO و RPO شما چیست؟
مرحله صفر: از PBX فعلی یک Inventory واقعی بسازید
اولین کار Export گرفتن از فایل‌های Asterisk نیست؛ اول باید بدانید دقیقاً چه چیزی را منتقل می‌کنید. بسیاری از Migrationها به این دلیل ناقص می‌شوند که IVR و داخلی‌ها منتقل می‌شوند ولی یک AGI Script، Certificate، Cron Job، Queue خاص یا Integration با CRM فراموش می‌شود.
| بخش | چه چیزی ثبت شود؟ |
|---|---|
| PBX | محصول، نسخه، سیستم‌عامل، ماژول‌ها |
| داخلی‌ها | شماره، Auth User، نوع Endpoint، Codec |
| Trunk | Provider، روش Auth، IPها، Portها، Caller ID |
| Inbound | DID، IVR، Queue، Time Condition |
| Outbound | Route، Prefix، محدودیت بین‌الملل |
| Recording | Path، حجم روزانه، Retention |
| Database | AstDB، Realtime DB، CDR/CEL |
| Integration | AMI، ARI، AGI، CRM، Webhook |
| Security | ACL، TLS/SRTP، Fail2Ban، VPN |
| Network | SIP/RTP Ports، NAT، Public IP، DNS |
Latency را قبل از خرید و Cutover اندازه بگیرید
برای VoIP، فاصله شبکه مهم‌تر از فاصله روی نقشه است. یک VPS جغرافیایی نزدیک ممکن است Route بدتری نسبت به یک دیتاسنتر کمی دورتر داشته باشد. بنابراین از همان اینترنت‌هایی که تلفن‌ها واقعاً استفاده می‌کنند به مقصد VPS تست بگیرید.
برای Voice باکیفیت، Cisco در راهنماهای QoS خود مقادیر برنامه‌ریزی رایج زیر را پیشنهاد کرده است: One-way Latency حداکثر حدود ۱۵۰ میلی‌ثانیه، Jitter کمتر از ۳۰ میلی‌ثانیه و Packet Loss کمتر از ۱٪. این اعداد قانون مطلق نیستند، اما برای انتخاب مسیر و تشخیص شبکه نامناسب نقطه شروع خوبی هستند.
تست ساده:
ping -c 50 VPS_IP
mtr -rwzc 100 VPS_IPاما Ping فقط RTT پایه را نشان می‌دهد. برای تصمیم نهایی، در ساعات شلوغ شبکه هم تست کنید و اگر امکان دارد یک تماس واقعی آزمایشی با RTP برقرار کنید.
چه چیزهایی را از هر شعبه ثبت کنیم؟
🔹 RTT میانگین و بیشینه.
🔹 Jitter واقعی تماس.
🔹 Packet Loss و Burst Loss.
🔹 مسیر MTR و Hopهای مشکل‌دار.
🔹 کیفیت در ساعات Peak.
🔹 اینترنت پشتیبان شعبه.
مطلب مرتبط: اگر VPS در بعضی ساعات کند یا ناپایدار است، قبل از انتقال PBX علت شبکه یا منابع را پیدا کنید.
محل VPS را نسبت به سه نقطه انتخاب کنید، نه فقط کاربران
برای PBX سه مسیر مهم دارید:
Branch Phones
|
v
VPS
|
v
SIP Provider / PSTNVPS باید هم برای کاربران/شعبه‌ها مسیر مناسبی داشته باشد و هم به SIP Provider شما Route قابل‌قبولی بدهد. اگر داخلی‌ها در ایران هستند ولی Provider در مسیر دیگری قرار دارد، هر دو Leg را جدا اندازه‌گیری کنید.
SIP Provider را قبل از Migration درگیر کنید
یکی از مهم‌ترین ریسک‌ها این است که PBX جدید آماده باشد اما Provider تماس‌های ورودی را هنوز به IP قدیمی بفرستد.
قبل از Cutover مشخص کنید Trunk شما کدام حالت را دارد:
| نوع Trunk | اثر مهاجرت |
|---|---|
| Registration-based | PBX جدید باید REGISTER کند؛ هم‌زمانی دو Registration ممکن است رفتار Provider را تغییر دهد |
| IP Authentication | IP جدید VPS باید در ACL Provider ثبت شود |
| Inbound by SIP URI/FQDN | Origination Target باید به VPS جدید تغییر کند |
| Private Interconnect | ممکن است VPS عمومی بدون SBC/اتصال خصوصی سازگار نباشد |
از Provider درباره این موارد پاسخ مکتوب بگیرید:
🔹 IPهای Signaling و RTP.
🔹 Codecهای مجاز.
🔹 DTMF Mode.
🔹 TLS/SRTP در صورت نیاز.
🔹 تغییر Source IP یا ACL.
🔹 امکان داشتن Primary و Secondary PBX.
🔹 روش Failover تماس ورودی.
همه Providerها یکسان نیستند. برای نمونه، Twilio Elastic SIP Trunking اجازه می‌دهد چند Origination SIP URI با Priority و Weight تعریف شود تا تماس ورودی بین چند PBX/SBC Failover یا Load Balance شود؛ این قابلیت را فقط وقتی روی Provider خودتان مستند شده است فرض کنید.
PBX جدید را با همان نسخه یا نسخه سازگار بالا بیاورید
Migration زمان مناسبی برای انجام چند Upgrade بزرگ هم‌زمان نیست. اگر PBX فعلی قدیمی است، بهتر است اول Restore را روی نسخه‌ای که با Backup شما سازگار است انجام دهید و بعد Upgrade را به‌عنوان پروژه جداگانه تست کنید.
Asterisk در مستند Backup خود صریحاً هشدار می‌دهد که Restore روی Major Version جدید می‌تواند به تغییر Syntax، Schema دیتابیس و رفتار Applicationها برخورد کند؛ در این حالت Restore دیگر صرفاً کپی فایل نیست و باید مثل Upgrade واقعی با آن رفتار کرد.
پیشنهاد کم‌ریسک: در روز انتقال فقط «محل اجرا» را عوض کنید. تغییر Major Version، تبدیل chan_sip به PJSIP، تغییر Codec، عوض‌کردن Provider و بازطراحی Dialplan را تا جای ممکن در همان شب Migration با هم انجام ندهید.
Backup واقعی PBX شامل چه چیزهایی است؟
طبق راهنمای رسمی Asterisk، حداقل Configuration، دیتابیس داخلی Asterisk، دیتابیس‌های خارجی و Log/Reportهای موردنیاز باید در Backup دیده شوند. در عمل برای PBX سازمانی این موارد را هم بررسی کنید:
🔹 /etc/asterisk/ و فایل‌های Custom.
🔹 AstDB در /var/lib/asterisk/astdb.sqlite3.
🔹 Realtime DB، CDR و CEL.
🔹 AGI Scriptها و Integrationها.
🔹 TLS Certificate و Keyها با Permission امن.
🔹 Voicemail.
🔹 Recordings.
🔹 Cron، Systemd Unit و Scriptهای نگهداری.
🔹 Firewall Rules و Fail2Ban.
در ساختار پیش‌فرض Asterisk، /var/spool/asterisk شامل زیرشاخه‌هایی مثل monitor، recording و voicemail است؛ بنابراین Backup تنظیمات بدون Backup این داده‌ها لزوماً بازیابی کامل PBX نیست.
نمونه Archive ساده قبل از Migration
mkdir -p /root/pbx-migration-backup
tar -czf /root/pbx-migration-backup/asterisk-config.tar.gz \
/etc/asterisk \
/var/lib/asterisk \
/var/spool/asteriskاین دستور جای Backup دیتابیس جداگانه را نمی‌گیرد. اگر MariaDB/PostgreSQL دارید، Dump Transaction-consistent مناسب همان Database را هم تهیه کنید.
مطلب مرتبط: برای Backup خارج از همان VPS، می‌توانید یک مخزن جدا با Restic داشته باشید.
Backup بدون Restore Test هنوز Backup قابل‌اعتماد نیست
روی VPS جدید یا یک ماشین آزمایشی، Backup را Restore کنید و بررسی کنید:
🔹 Asterisk بدون Error بالا می‌آید.
🔹 داخلی آزمایشی Register می‌شود.
🔹 Dialplan و Routeها وجود دارند.
🔹 CDR/Database Connection سالم است.
🔹 Queue، IVR و Voicemail کار می‌کنند.
🔹 Recording واقعاً نوشته می‌شود.
🔹 Integrationهای AMI/ARI/AGI وصل می‌شوند.
VPS عمومی یعنی سطح حمله بیشتر؛ قبل از Cutover آن را Hardening کنید
PBX داخل LAN ممکن است هیچ‌وقت مستقیماً در معرض اینترنت نبوده باشد. وقتی همان PBX را روی VPS می‌برید، SIP، SSH، پنل مدیریت و گاهی AMI/ARI روی یک آدرس Public قرار می‌گیرند.
Asterisk در بخش Security هشدار می‌دهد که تنظیم نادرست می‌تواند به استفاده غیرمجاز و هزینه مالی منجر شود. مستند Network Security نیز توصیه می‌کند Manager Interface در محیط امن یا پشت SSH/VPN باشد و برای سرویس‌ها ACL استفاده شود.
حداقل کنترل‌های قبل از Cutover:
🔹 SSH با Key و محدودیت IP/VPN.
🔹 پنل Admin فقط از IPهای مدیریت یا VPN.
🔹 ACL برای SIP Provider.
🔹 Password قوی و اختصاصی برای هر داخلی.
🔹 Routeهای بین‌المللی فقط در صورت نیاز.
🔹 TLS/SRTP در صورت پشتیبانی دو طرف.
🔹 Fail2Ban به‌عنوان لایه مکمل، نه جای ACL.
🔹 بستن Portهای غیرضروری.
مطلب مرتبط: قبل از Public کردن VPS، دسترسی مدیریتی SSH را هم سخت‌سازی کنید.
تلفن‌ها مستقیم به VPS وصل شوند یا از VPN؟
یک جواب برای همه وجود ندارد. اگر تمام تلفن‌ها داخل چند شعبه ثابت هستند، Site-to-Site VPN می‌تواند سطح Exposure را کم کند و PBX را از Endpointهای اینترنتی ناشناس جدا کند. اگر کاربران Mobile و پراکنده‌اند، اتصال مستقیم SIP با TLS/SRTP و ACL/Authentication ممکن است عملی‌تر باشد.
| روش | مزیت | محدودیت |
|---|---|---|
| Direct SIP | مسیر ساده‌تر و Overhead کمتر | PBX بیشتر در معرض اینترنت است |
| Site-to-Site VPN | شبکه شعبه‌ها قابل‌کنترل‌تر | وابستگی به VPN و MTU/Route |
| SBC Edge | کنترل و Security بهتر برای مقیاس بالا | پیچیدگی و هزینه بیشتر |
اگر VPN استفاده می‌کنید، MTU و مسیر RTP را بعد از Tunnel دوباره تست کنید. «Ping وصل است» تضمین نمی‌کند RTP بدون Jitter یا Fragmentation مناسب باشد.
تنظیم NAT در PJSIP را بعد از انتقال بازبینی کنید
یکی از تفاوت‌های اصلی PBX داخل شرکت و VPS این است که ممکن است Asterisk قبلاً پشت NAT بوده و حالا روی Public IP مستقیم اجرا شود؛ یا برعکس، در Cloud پشت NAT Provider باشد.
Asterisk برای PJSIP گزینه‌هایی مثل external_media_address، external_signaling_address، local_net، rtp_symmetric، force_rport و rewrite_contact دارد. بعد از Migration نباید تنظیم NAT قدیمی را کورکورانه کپی کنید.
بررسی Transport:
asterisk -rx "pjsip show transports"
asterisk -rx "pjsip show endpoints"
asterisk -rx "pjsip show registrations"برای عیب‌یابی Signaling:
asterisk -rvvv
pjsip set logger onCutover را مثل Runbook اجرا کنید
مهاجرت Production باید Sequence مشخص داشته باشد. نمونه:
| زمان | کار |
|---|---|
| T-24h | Backup نهایی آزمایشی، تست Restore، تأیید Provider و کاربران کلیدی |
| T-2h | Freeze تغییرات PBX قدیمی، Snapshot/Backup جدید، بررسی Monitoring |
| T-30m | Sync آخر Database/Config و Recordingهای جدید |
| T0 | انتقال Trunk/IP/DNS/VPN به VPS جدید |
| T+5m | تست Register، تماس ورودی/خروجی و RTP دوطرفه |
| T+15m | تست Queue، IVR، Transfer، DTMF و Recording |
| T+60m | بررسی CDR، Error Rate، CPU، Network و کیفیت تماس |
| T+24h | تأیید Business Owner و نگه‌داشتن PBX قدیمی برای Rollback Window |
Test Plan روز مهاجرت
فقط یک تماس بین دو داخلی کافی نیست. این Matrix را اجرا کنید:
🔹 داخلی → داخلی.
🔹 تماس خروجی شهری/موبایل.
🔹 تماس ورودی روی همه DIDهای مهم.
🔹 Caller ID ورودی و خروجی.
🔹 DTMF داخل IVR.
🔹 Blind Transfer و Attended Transfer.
🔹 Hold/Resume.
🔹 Queue و Agent Login.
🔹 Voicemail.
🔹 Recording و Playback.
🔹 تماس طولانی حداقل چند دقیقه.
🔹 تست از هر شعبه و اینترنت اصلی/پشتیبان.
🔹 Integration با CRM/AMI/ARI.
Monitoring را از همان دقیقه اول فعال کنید
بعد از Migration، «تماس برقرار شد» پایان کار نیست. باید حداقل این موارد مانیتور شوند:
🔹 Trunk Registration و SIP Response Codeها.
🔹 تعداد تماس هم‌زمان.
🔹 CPU، RAM و Load.
🔹 Disk Space و رشد Recordings.
🔹 RTT، Jitter و Packet Loss.
🔹 Backup Job.
🔹 Certificate Expiry.
🔹 Fail2Ban/Firewall Eventها.
🔹 CDR Gap یا Call Failure Spike.
برای کیفیت تماس، میانگین Ping سرور کافی نیست. اگر ابزار RTCP یا Call Quality Monitoring دارید، Metric را به Call-ID و Direction هر تماس متصل کنید.
Disaster Recovery با High Availability یکی نیست
HA تلاش می‌کند سرویس هنگام خرابی سریع روی نود دیگر ادامه پیدا کند. DR یعنی اگر VPS، دیتاسنتر، Database یا حتی Configuration اصلی از دست رفت، بتوانید سرویس را در یک محیط دیگر برگردانید.
برای یک شرکت متوسط، DR قابل‌اجرا می‌تواند این باشد:
Primary VPS
|
+--> daily config/database backup
|
+--> recordings off-site
|
+--> encrypted backup repository
|
v
Warm Standby / Recovery VPSاگر Provider شما چند Origination Target را پشتیبانی می‌کند، می‌توانید Secondary PBX/SBC را هم به‌عنوان Failover تعریف کنید. Twilio مثلاً چند Origination SIP URI با Priority و Weight را پشتیبانی می‌کند و در صورت عدم پاسخ می‌تواند سراغ URI بعدی برود.
RTO و RPO را با عدد مشخص کنید
دو عبارت «Backup داریم» و «DR داریم» یک معنی ندارند.
🔹 RTO: بعد از خرابی حداکثر چه مدت زمان برای برگشت سرویس قابل‌قبول است؟
🔹 RPO: حداکثر چه مقدار Data Loss قابل‌قبول است؟
مثلاً اگر Recording برای شما حقوقی یا مالی اهمیت دارد، Backup شبانه ممکن است RPO مناسبی نباشد. اگر فقط Config روزی یک بار تغییر می‌کند، همان Strategy ممکن است کافی باشد.
Rollback باید قبل از Cutover نوشته شده باشد
Rollback واقعی یعنی بتوانید PBX قدیمی را بدون حدس و آزمون دوباره Online کنید.
قبل از Migration این موارد را آماده نگه دارید:
🔹 PBX قدیمی خاموش/دست‌نخورده، نه پاک‌شده.
🔹 IP و Route قبلی مستند.
🔹 Credential و ACL قبلی Provider.
🔹 Backup قبل از Cutover.
🔹 روش بازگرداندن Trunk به PBX قدیمی.
🔹 معیار تصمیم برای Rollback.
مثلاً معیار Rollback می‌تواند این باشد: اگر تا ۱۵ دقیقه بعد از Cutover تماس ورودی/خروجی پایدار نشد یا بیش از یک شعبه One-Way Audio داشت، Route به PBX قبلی برگردد. عدد واقعی باید با SLA شرکت شما تعیین شود.
نمونه Runbook Rollback
1. Stop new PBX trunk registration
2. Restore provider ACL / origination target to old PBX
3. Re-enable old PBX trunk
4. Revert branch VPN / DNS if changed
5. Test inbound + outbound + RTP
6. Freeze new PBX data for postmortemچه زمانی PBX قدیمی را خاموش کنیم؟
نه بلافاصله بعد از اولین تماس موفق. بهتر است PBX قدیمی در یک Rollback Window مشخص نگه داشته شود، اما هم‌زمان نباید با Credential یا IP یکسان باعث Registration Conflict شود.
پس از عبور از Window مهاجرت:
🔹 Backup نهایی PBX قدیمی را بگیرید.
🔹 Secretهایی را که دیگر لازم نیست Rotate کنید.
🔹 Provider ACL قدیمی را حذف کنید.
🔹 Monitoring را روی VPS جدید تثبیت کنید.
🔹 Runbook DR را با تیم پشتیبانی مرور کنید.
اشتباه‌های رایج در انتقال VoIP به VPS
🔹 انتخاب VPS فقط بر اساس CPU/RAM و نادیده‌گرفتن Route شبکه.
🔹 تغییر Major Version PBX هم‌زمان با Migration.
🔹 فراموش‌کردن IP ACL سمت SIP Provider.
🔹 انتقال Config بدون Recordings و Voicemail.
🔹 Public کردن پنل Admin و AMI.
🔹 تست نکردن تماس از همه شعبه‌ها.
🔹 نداشتن Backup خارج از همان VPS.
🔹 نداشتن Rollback معیارمند.
🔹 فرض اینکه Snapshot به‌تنهایی DR کامل است.
🔹 قطع PBX قدیمی قبل از تأیید Business Owner.
پرسش‌های رایج
برای VoIP چه Latencyای مناسب است؟
برای طراحی Voice باکیفیت، One-way Delay حدود ۱۵۰ میلی‌ثانیه یا کمتر، Jitter زیر ۳۰ میلی‌ثانیه و Packet Loss زیر ۱٪ نقطه شروع مناسبی هستند؛ اما مسیر واقعی، Codec و کیفیت Endpoint هم اثر دارند.
آیا تلفن‌های شرکت باید حتماً با VPN به VPS وصل شوند؟
خیر. برای شعبه‌های ثابت VPN می‌تواند Exposure را کم کند، اما برای کاربران پراکنده SIP مستقیم با TLS/SRTP و کنترل امنیتی مناسب ممکن است عملی‌تر باشد.
آیا می‌توان Backup PBX قدیمی را روی نسخه جدید Asterisk Restore کرد؟
گاهی بله، اما Major Version جدید ممکن است Syntax، Schema یا رفتار Moduleها را تغییر داده باشد. Asterisk توصیه می‌کند Restore روی نسخه جدید مثل Upgrade کامل تست شود.
آیا Snapshot VPS برای Disaster Recovery کافی است؟
نه. اگر Snapshot در همان زیرساخت از دست برود یا خراب باشد، Recovery ندارید. Backup خارج از همان VPS و Restore Test جدا لازم است.
چرا بعد از انتقال تماس برقرار می‌شود ولی صدا نداریم؟
معمولاً Signaling سالم است اما RTP به آدرس یا Port درست نمی‌رسد. NAT، Firewall، SDP، Provider RTP Range و تنظیم‌های rtp_symmetric/direct_media را بررسی کنید.
آیا PBX قدیمی را بعد از Cutover خاموش کنیم؟
بهتر است تا پایان Rollback Window نگه داشته شود، اما نباید به‌صورت هم‌زمان با Credential یکسان باعث Registration Conflict شود.
HA و Disaster Recovery چه تفاوتی دارند؟
HA برای ادامه سریع سرویس در خرابی نود اصلی است؛ DR برای بازیابی سرویس و داده بعد از خرابی بزرگ‌تر مثل از دست رفتن VPS، دیتابیس یا دیتاسنتر طراحی می‌شود.
چه زمانی Migration را Rollback کنیم؟
قبل از شروع، معیار مشخص تعریف کنید؛ مثلاً عدم پایداری تماس‌های اصلی یا One-Way Audio گسترده بعد از بازه زمانی تعیین‌شده. Rollback نباید تصمیمی احساسی وسط قطعی باشد.
جمع‌بندی
انتقال PBX شرکت به VPS فقط جابه‌جایی فایل‌های Asterisk نیست. شبکه کاربران، مسیر SIP Provider، NAT، Firewall، Database، Recording، Backup و Monitoring همگی بخشی از همان Migration هستند.
قبل از Cutover کیفیت مسیر را با Latency، Jitter و Loss اندازه بگیرید و مطمئن شوید Provider IP یا Origination Target جدید را قبول می‌کند. PBX جدید را قبل از روز مهاجرت با تماس واقعی تست کنید.
Backup باید قابل Restore باشد و خارج از همان VPS نگهداری شود. Recordings، Voicemail، Database و Integrationها را هم کنار Configها ببینید.
در پایان، PBX قدیمی را تا پایان Rollback Window نگه دارید و DR را با RTO/RPO مشخص طراحی کنید. مهاجرت موفق یعنی اگر VPS جدید مشکل داشت، تیم شما از قبل می‌داند چگونه و در چه زمانی به سرویس قبلی برگردد.
برای انتقال سانترال شرکت به VPS به زیرساخت مطمئن نیاز دارید؟
اگر تعداد داخلی‌ها، تماس هم‌زمان، محل شعبه‌ها و SIP Provider مشخص باشد، می‌توان قبل از مهاجرت مسیر شبکه و نیاز منابع را ارزیابی کرد و سپس VPS، Backup و Rollback را متناسب با همان معماری آماده کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)