راهاندازی VoIP برای شرکت؛ تجهیزات، مراحل و معماری پیشنهادی
در یک دفتر تازهتأسیس، همهچیز ظاهراً آماده است: اینترنت پرسرعت، کابلکشی شبکه، سوئیچ PoE و چند تلفن روی میزها. مدیر فروش میخواهد تماس مشتریان در صف قرار بگیرد، مدیرعامل میخواهد از سفر با داخلی خود پاسخ دهد و شعبه دوم باید بدون شمارهگیری شهری با دفتر مرکزی تماس بگیرد. اگر این نیازها پس از خرید تجهیزات مطرح شوند، معمولاً نتیجه مجموعهای از تنظیمات پراکنده، تماسهای یکطرفه، قطعیهای نامعلوم و هزینههای دوباره است. راه درست این است که پیش از انتخاب سرور یا تلفن، مسیر تماس و معماری کل سیستم طراحی شود.
راهاندازی VoIP فقط تبدیل صدای آنالوگ به بستههای شبکه نیست. این پروژه نقطه تلاقی تلفن، شبکه، امنیت، برق اضطراری، اینترنت و فرایندهای کسبوکار است. کیفیت یک مرکز تلفن تحت شبکه زمانی مشخص میشود که در ساعات شلوغ، هنگام قطع یک لینک، زمان دورکاری یا انتقال تماس میان شعب نیز پایدار بماند؛ نه فقط زمانی که تکنسین یک تماس آزمایشی کوتاه برقرار میکند.
پاسخ سریع: راهاندازی VoIP برای شرکت به شبکه پایدار، سرور یا سرویس مرکز تلفن، مسیر اتصال خطوط شهری یا SIP، تلفن IP یا نرمافزار، سوئیچ مناسب، امنیت و سناریوی تماس نیاز دارد. قبل از خرید باید تعداد کاربران، تماسهای همزمان، شعب، دورکارها، IVR، صف، ضبط و سطح پشتیبانی مشخص شود. |
برای طراحی معماری و دریافت مسیر اجرایی متناسب با تعداد کاربران و شعب، صفحه راه اندازی VoIP را بررسی کنید و اطلاعات اولیه پروژه را ارسال کنید.
VoIP دقیقاً چه مشکلی را برای شرکت حل میکند؟
بررسی نقشه شبکه، کاربران، خطوط و مسیر تماس پیش از اجرای VoIP
مرکز تلفن سنتی معمولاً ارتباط خطوط شهری و داخلیها را برقرار میکند؛ اما با رشد شرکت، افزایش شعب، دورکاری و نیاز به گزارشگیری، محدودیتهای آن بیشتر دیده میشود. VoIP تماس را روی بستر IP مدیریت میکند و اجازه میدهد داخلیها فقط به یک تلفن روی میز محدود نباشند. کارمند میتواند با تلفن IP، نرمافزار رایانه یا اپلیکیشن موبایل و براساس سطح دسترسی تعریفشده به مرکز تلفن متصل شود.
ارزش واقعی VoIP در امکانات فهرستشده روی کاتالوگ نیست؛ در حل مسئلههای عملیاتی است. برای مثال، وقتی تماس فروش بیپاسخ میماند، سیستم میتواند آن را در صف نگه دارد، بین کارشناسان توزیع کند، نتیجه را ثبت کند و گزارش دهد چند تماس از دست رفته است. وقتی شعبه دیگری راهاندازی میشود، داخلیهای دو دفتر میتوانند در یک طرح شمارهگذاری مشترک قرار بگیرند و هزینه و پیچیدگی ارتباط میان شعب کاهش یابد.
|
مسئله شرکت |
راهحل قابل طراحی در VoIP |
معیار موفقیت |
|
تماسهای از دست رفته |
صف تماس، زنگ همزمان یا مرحلهای و گزارش تماس بیپاسخ |
کاهش تماس بیپاسخ و زمان انتظار |
|
رشد تعداد نیروها |
تعریف داخلی جدید بدون بازطراحی کامل کابل تلفن سنتی |
افزودن کاربر با کمترین توقف |
|
دورکاری و مأموریت |
داخلی امن روی نرمافزار یا موبایل |
پاسخگویی با هویت سازمانی |
|
چند شعبه |
ارتباط داخلی میان شعب و مدیریت متمرکز |
شمارهگیری کوتاه و گزارش یکپارچه |
|
نبود گزارش مدیریتی |
ثبت تماس، صف، زمان پاسخ و وضعیت اپراتور |
تصمیمگیری براساس داده واقعی |
|
تجربه نامنظم مشتری |
IVR، ساعات کاری، پیام خارج از ساعت و مسیر جایگزین |
هدایت تماس به واحد درست |
گیت وی گرند استریم مدل HT818 کد 17807
380,000,000 ریالگیت وی گرنداستریم GXW4232 کد 17453
1,240,000,000 ریالگیت وی ویپ گرنداستریم HT841 کد 17799
330,000,000 ریالگیت وی ویپ گرنداستریم HT881 کد 17803
490,000,000 ریالپیشنیازهای شبکه و اینترنت
صدای تلفنی نسبت به بسیاری از ترافیکهای عادی شبکه حساستر است. یک فایل دانلودی میتواند چند ثانیه کند شود و کاربر شاید متوجه نشود، اما نوسان تأخیر، از دست رفتن بستهها یا ازدحام در مسیر تماس به شکل صدای رباتی، بریدگی یا مکالمه یکطرفه شنیده میشود. به همین دلیل، نصب ویپ باید با ارزیابی شبکه شروع شود؛ نه با وصل کردن تلفنها به نزدیکترین پورت آزاد.
ابتدا نقشه شبکه، مدل سوئیچها، ظرفیت PoE، وضعیت کابلها، ساختار IP، روتر، فایروال، اینترنت و برق اضطراری بررسی میشود. در شرکتهایی که ترافیک داده سنگین دارند، تفکیک منطقی Voice VLAN و اعمال اولویت ترافیک صوتی میتواند از رقابت تماس با بکاپ، دانلود یا دوربینها جلوگیری کند. این تنظیمات باید از ابتدا مستند شوند تا در تغییرات بعدی شبکه، تماسها ناخواسته مختل نشوند.
موضوع بررسی | پرسش اجرایی | خروجی مورد انتظار |
کابل و پورت شبکه | آیا هر میز پورت سالم و تستشده دارد؟ | نقشه پورتها و لیبلگذاری |
سوئیچ و PoE | توان PoE برای همه تلفنها و تجهیزات کافی است؟ | بودجه توان و ظرفیت رزرو |
آدرسدهی | IP ثابت تجهیزات اصلی و DHCP تلفنها چگونه تعریف میشود؟ | IP Plan و رزروهای مشخص |
کیفیت مسیر | در ساعات شلوغ تأخیر، Jitter و Packet Loss چگونه است؟ | ثبت خط مبنا پیش از اجرا |
اینترنت | تعداد تماس بیرونی همزمان و لینک پشتیبان چیست؟ | محاسبه پهنای باند و Failover |
فایروال و NAT | ترافیک SIP/RTP و کاربران راه دور چگونه عبور میکنند؟ | قواعد محدود و مستند |
برق اضطراری | مودم، روتر، سوئیچ، سرور و گیتوی روی UPS هستند؟ | زمان پایداری موردنیاز |
- برای تلفنها و مرکز تلفن یک طرح IP و نامگذاری قابل فهم تهیه شود.
- پورتهای سوئیچ، VLAN و QoS براساس نقش تجهیز مستند شوند.
- در پروژههای حساس، اینترنت یا مسیر تماس جایگزین تعریف شود.
- مودم، روتر، سوئیچ، گیتوی و سرور همگی در سناریوی UPS دیده شوند.
- قبل از مهاجرت، کیفیت شبکه در ساعات اوج و نه فقط زمان خلوت آزمایش شود.
تجهیزات لازم: سرور، گیتوی، تلفن IP و سوئیچ
رک منظم شامل سوئیچ PoE، روتر، IP-PBX، گیتوی و UPS
فهرست تجهیزات VoIP باید از روی معماری انتخاب شود. خرید یک تلفن گران یا سرور قدرتمند، ضعف مسیر شبکه یا طراحی نادرست خطوط را جبران نمیکند. در بعضی پروژهها یک مرکز تلفن ابری و تلفنهای نرمافزاری کافی است؛ در پروژه دیگر، سرور داخلی، گیتوی چندپورت، تلفن IP مدیریتی، هدست حرفهای و لینک پشتیبان لازم میشود.
تجهیز | نقش در معماری | نکته انتخاب |
IP-PBX یا سرور VoIP | ثبت داخلیها، مسیریابی تماس، IVR، صف، ضبط و گزارش | براساس تماس همزمان، امکانات، افزونگی و رشد انتخاب شود. |
گیتوی FXO | اتصال خطوط شهری آنالوگ به مرکز تلفن IP | تعداد پورت برابر خطوط فعال و ظرفیت رزرو باشد. |
گیتوی FXS | اتصال تلفن، فکس یا تجهیز آنالوگ به شبکه VoIP | سازگاری تجهیز آنالوگ و سناریوی قطع برق بررسی شود. |
SIP Trunk یا خط مبتنی بر IP | ورود و خروج تماس از بستر سرویسدهنده | تعداد کانال همزمان، شمارهها و مسیر پشتیبان روشن باشد. |
تلفن IP | رابط کاربر برای تماس و امکاناتی مثل BLF و انتقال | مدل براساس نقش کارمند، مدیر یا اپراتور انتخاب شود. |
Softphone و اپ موبایل | داخلی روی رایانه یا موبایل | هدست، امنیت ورود و کیفیت اینترنت کاربر مهم است. |
سوئیچ PoE | شبکه و برق تلفنهای IP | پورت، PoE Budget، مدیریتپذیری و VLAN کنترل شود. |
روتر و فایروال | NAT، امنیت، VPN، QoS و مسیرهای اینترنت | قواعد محدود، لاگ و دسترسی مدیریتی امن لازم است. |
UPS و برق پشتیبان | حفظ سرویس هنگام قطعی کوتاه برق | تمام زنجیره تماس، نه فقط سرور، روی UPS قرار گیرد. |
برای مشاهده مسیرهای خدماتی و تجهیزات قابل استفاده در پروژه، صفحه مشاهده تجهیزات مرتبط با VoIP را ببینید. مدل نهایی باید پس از بررسی خطوط، شبکه و نقش کاربران انتخاب شود.
مراحل طراحی و راهاندازی
تست Pilot و انتقال مرحلهای سیستم تلفنی با برنامه بازگشت
پروژه حرفهای VoIP چند مرحله مشخص دارد. حذف هر مرحله ممکن است در روز تحویل دیده نشود، اما در توسعه، عیبیابی یا قطعی بعدی هزینه ایجاد میکند. بهتر است برای هر مرحله خروجی قابل تحویل تعریف شود؛ بهطوریکه کارفرما بداند چه چیزی طراحی شده، چه چیزی اجرا شده و چه چیزی هنوز خارج از محدوده قرارداد است.
|
مرحله |
اقدام اصلی |
خروجی قابل تحویل |
|
۱. نیازسنجی |
ثبت خطوط، کاربران، تماس همزمان، شعب، ساعات کاری و الزامات ضبط |
فرم نیازسنجی تأییدشده |
|
۲. طراحی سناریوی تماس |
مسیر تماس ورودی و خروجی، IVR، صف، گروهها و حالت خارج از ساعت |
فلوچارت تماس |
|
۳. ارزیابی شبکه |
کابل، سوئیچ، VLAN، QoS، اینترنت، فایروال و UPS |
گزارش آمادگی و فهرست اصلاحات |
|
۴. انتخاب معماری |
ابری، داخلی یا ترکیبی؛ خطوط شهری، SIP و کاربران راه دور |
دیاگرام معماری و BOM |
|
۵. اجرای آزمایشی |
راهاندازی چند داخلی و یک مسیر تماس محدود |
نتیجه Pilot و اصلاحات |
|
۶. پیکربندی کامل |
تعریف کاربران، خطوط، مسیرها، امنیت، ضبط و گزارش |
نسخه تنظیمات و فهرست دسترسی |
|
۷. مهاجرت |
انتقال مرحلهای شمارهها و داخلیها با برنامه بازگشت |
صورتجلسه Cutover |
|
۸. تست و آموزش |
آزمون سناریوها، تحویل رمزها و آموزش مدیر و کاربران |
چکلیست امضاشده و مستندات |
داخلیها، IVR، صف، ضبط و گزارشگیری
تلفنهای IP، سوئیچ PoE، هدست، لپتاپ و موبایل در شبکه VoIP
شمارهگذاری داخلیها بهتر است منطق سازمان را دنبال کند؛ برای نمونه، بازهای برای مدیریت، بازهای برای فروش و بازهای برای شعب تعریف شود. این ساختار باید فضای رشد داشته باشد تا با اضافه شدن نیرو، شمارهها بهصورت پراکنده و گیجکننده ایجاد نشوند. نام کاربر، ایمیل، تلفن، داخلی، سطح دسترسی و تجهیز او در فهرست تحویل ثبت شود.
IVR باید کوتاه و براساس نیاز تماسگیرنده باشد، نه براساس ساختار پیچیده سازمان. اگر بیشتر تماسها برای فروش و پشتیبانی است، این دو مسیر باید سریع در دسترس باشند. صف تماس نیز فقط پخش موسیقی نیست؛ سیاست توزیع، مدت انتظار، پیامهای دورهای، خروج از صف، تماس برگشتی و وضعیت اپراتورها باید تعریف شود.
در ضبط مکالمات باید مشخص شود چه تماسهایی ضبط میشوند، فایلها کجا ذخیره میشوند، چه مدت نگهداری میشوند، چه کسانی امکان شنیدن یا دانلود دارند و ظرفیت ذخیرهسازی چگونه پایش میشود. گزارشها نیز باید با سؤال مدیریتی شروع شوند: تعداد تماس ورودی، تماس ازدسترفته، زمان انتظار، مدت مکالمه، پاسخگویی هر واحد و ساعات پرترافیک چه وضعی دارند؟ گزارش بدون هدف، فقط داده تولید میکند.
- ساعات کاری، تعطیلات و مسیر خارج از ساعت تعریف و آزمایش شود.
- مسیر تماس در صورت پاسخ ندادن، اشغال بودن یا آفلاین بودن کاربر مشخص باشد.
- سطح دسترسی تماس شهری، بینالملل، انتقال و ضبط برای هر نقش ثبت شود.
- فایل صوتی IVR، موسیقی انتظار و پیامهای صف با نسخه نهایی بایگانی شوند.
- گزارش موردنیاز مدیر پیش از انتخاب نرمافزار و لایسنس مشخص شود.
معماری ابری یا On-Premise
مقایسه تصویری معماری دفتر کوچک، شرکت چندشعبهای و مرکز تماس
در معماری ابری، هسته مرکز تلفن روی زیرساخت ارائهدهنده یا سرور ابری قرار میگیرد و کاربران از دفتر، شعب یا بیرون به آن متصل میشوند. در معماری On-Premise، سرور یا IP-PBX داخل شرکت نصب میشود و کنترل بیشتری روی شبکه داخلی، فایلها و یکپارچهسازیها وجود دارد. هیچکدام بهصورت مطلق بهتر نیستند؛ انتخاب به ریسک، مهارت تیم، اینترنت، سیاست داده و بودجه بستگی دارد.
|
معیار |
معماری ابری |
معماری On-Premise |
|
سرمایهگذاری اولیه |
معمولاً سبکتر و مبتنی بر اشتراک یا سرویس |
نیازمند سرور، زیرساخت و اجرای داخلی |
|
مدیریت و نگهداری |
بخش بیشتری برعهده ارائهدهنده |
برعهده تیم داخلی یا پیمانکار |
|
وابستگی به اینترنت |
برای دسترسی کاربران اهمیت بیشتری دارد |
تماسهای داخلی میتوانند در LAN ادامه یابند |
|
کنترل داده و ضبط |
طبق سیاست و محل میزبانی سرویس |
کنترل مستقیمتر روی محل ذخیره و دسترسی |
|
توسعه شعب و دورکاری |
معمولاً سریعتر و سادهتر |
نیازمند طراحی VPN، SBC یا مسیر امن |
|
سفارشیسازی |
وابسته به امکانات سرویس |
انعطاف بیشتر با هزینه مدیریت بالاتر |
|
پشتیبانگیری و افزونگی |
طبق SLA ارائهدهنده بررسی شود |
باید جداگانه طراحی، تست و نگهداری شود |
|
معیار تصمیم: محل سرور را فقط براساس قیمت انتخاب نکنید. مسیر تماس هنگام قطع اینترنت، محل نگهداری ضبطها، دسترسی مدیر سیستم، زمان بازیابی، SLA، امکان خروج از سرویس و روش گرفتن نسخه پشتیبان باید پیش از قرارداد روشن باشد. |
امنیت و پشتیبانگیری
کنترل فایروال، دسترسی راه دور امن و حفاظت از مرکز تلفن IP
مرکز تلفن IP یک سرویس شبکهای است و باید مانند هر سامانه حیاتی دیگر محافظت شود. رمز ساده، باز گذاشتن دسترسی مدیریتی روی اینترنت، تعریف یک حساب مشترک برای همه کاربران یا باقی ماندن دسترسی پیمانکار قبلی میتواند زمینه سوءاستفاده، شنود یا تماس غیرمجاز را ایجاد کند. امنیت باید در طراحی باشد، نه یک تنظیم اضافه پس از وقوع مشکل.
دسترسی مدیریتی باید به IPها یا مسیرهای مشخص محدود شود. برای کاربران بیرون از دفتر، استفاده از روش امن مورد تأیید معماری مانند VPN، SBC یا تونل اختصاصی نسبت به باز کردن بیرویه پورتها قابلکنترلتر است. در صورت پشتیبانی تجهیزات و سرویسدهنده، رمزنگاری سیگنالینگ و رسانه میتواند بخشی از لایه امنیت باشد؛ اما رمزنگاری جایگزین مدیریت رمز، فایروال، بهروزرسانی و کنترل دسترسی نیست.
|
کنترل امنیتی |
اقدام اجرایی |
مدرک تحویل |
|
حسابها و رمزها |
رمز منحصربهفرد، حذف حسابهای پیشفرض و تفکیک نقشها |
فهرست حسابها و مالک هر دسترسی |
|
فایروال و ACL |
اجازه فقط به مبادی و سرویسهای لازم |
خلاصه قواعد و مسئول تغییر |
|
کاربران راه دور |
VPN، SBC یا روش امن متناسب با سامانه |
دستورالعمل اتصال و لغو دسترسی |
|
محدودیت تماس |
سقف هزینه، محدودیت مقصد و ساعات مجاز |
ماتریس دسترسی تماس |
|
ثبت رخداد |
نگهداری لاگ ورود، خطا و تماس غیرعادی |
محل لاگ و دوره بازبینی |
|
بهروزرسانی |
برنامه کنترل نسخه سرور، تلفن و گیتوی |
تقویم نگهداری و مسئول اجرا |
|
پشتیبانگیری |
نسخه تنظیمات، فایلهای صوتی، فهرست کاربران و در صورت نیاز ضبط |
نسخه آزمایشی و روش بازیابی |
- دسترسی مدیر سیستم، پیمانکار و کاربر عادی از هم جدا شود.
- پس از خروج کارمند یا پایان همکاری پیمانکار، دسترسی فوراً لغو شود.
- هشدار تماس غیرعادی، تلاش ورود و پر شدن فضای ضبط فعال شود.
- نسخه پشتیبان خارج از همان سرور و با سطح دسترسی محدود نگهداری شود.
- طرح واکنش به اختلال شامل شماره تماس، مسیر جایگزین و زمان پاسخ باشد.
تست کیفیت تماس و تحویل پروژه
آزمایش تماس، انتقال، داخلی موبایل، گزارش و آموزش کاربران
روشن شدن تلفن و برقراری یک تماس داخلی، تحویل پروژه نیست. تست باید تمام مسیرهای مهم را پوشش دهد: تماس ورودی از خطوط مختلف، تماس خروجی، انتقال، صف، IVR، ضبط، داخلی موبایل، شعبه دوم و حالت خارج از ساعت. همچنین باید از داخل و خارج شبکه آزمایش شود تا مشکل NAT، فایروال یا صدای یکطرفه پنهان نماند.
کیفیت تماس با شنیدن صدای «بد نیست» سنجیده نمیشود. در زمان تست باید تأخیر، نوسان تأخیر، از دست رفتن بسته، قطع کوتاه، اکو و تغییر کیفیت در زمان شلوغی شبکه ثبت شود. اگر مشکل فقط در ساعات خاص رخ میدهد، تست خلوت نتیجه قابل اتکایی نمیدهد. مقایسه قبل و بعد از اعمال QoS یا اصلاح شبکه نیز باید مستند شود.
آزمون تحویل | روش اجرا | نتیجه مورد انتظار |
تماس ورودی و خروجی | از هر خط و هر مسیر اصلی چند تماس برقرار شود. | شماره درست، صدای دوطرفه و مسیر صحیح |
IVR و ساعات کاری | تمام گزینهها، ورودی نامعتبر و حالت تعطیل آزمایش شود. | هدایت بدون حلقه یا بنبست |
صف تماس | چند تماس همزمان، خروج اپراتور و زمان انتظار بررسی شود. | توزیع طبق سیاست و گزارش درست |
انتقال و Hold | انتقال کور، مشورتی، نگهداشت و بازگشت انجام شود. | قطع نشدن تماس و نمایش درست شماره |
ضبط | نمونه تماس ضبط، پخش و دانلود شود. | فایل سالم، تاریخ درست و دسترسی محدود |
کاربر راه دور | با اینترنت موبایل و خارج از شبکه تست شود. | ثبت پایدار و صدای دوطرفه |
قطع اینترنت یا برق | سناریوی پشتیبان یا توقف کنترلشده آزمایش شود. | رفتار مطابق برنامه تداوم سرویس |
بازیابی تنظیمات | نسخه پشتیبان روی محیط آزمایشی یا طبق روش امن کنترل شود. | امکان بازگردانی مستند |
- فلوچارت تماس و شمارهگذاری داخلیها تحویل شود.
- فهرست تجهیزات، IPها، پورت سوئیچ و محل نصب ثبت شود.
- رمزها با روش محرمانه تحویل و حساب موقت پیمانکار محدود شود.
- نسخه پشتیبان تنظیمات و تاریخ آخرین Backup ثبت شود.
- SLA، زمان پاسخ، محدوده پشتیبانی و موارد خارج از قرارداد روشن باشد.
سناریو شرکت کوچک، چندشعبهای و مرکز تماس
یک معماری خوب باید با اندازه و ریسک پروژه متناسب باشد. استفاده از همان نسخهای که برای مرکز تماس طراحی شده در دفتر کوچک، هزینه و پیچیدگی غیرضروری ایجاد میکند. در مقابل، اجرای ساده و بدون افزونگی برای شرکتی که فروش آن به تماس وابسته است، میتواند در زمان اختلال خسارت بیشتری از صرفهجویی اولیه ایجاد کند.
|
سناریو |
معماری پیشنهادی اولیه |
نقاط تصمیمگیری |
|
دفتر کوچک ۵ تا ۱۵ کاربر |
مرکز تلفن ابری یا سرور سبک، چند تلفن IP/Softphone و گیتوی متناسب با خطوط |
تعداد تماس همزمان، اینترنت پایدار، نیاز به ضبط و بودجه تلفنها |
|
شرکت متوسط ۱۵ تا ۵۰ کاربر |
IP-PBX ابری یا داخلی، Voice VLAN، سوئیچ PoE مدیریتی، گزارش و Backup منظم |
صف واحدها، نقش مدیر، رشد کاربران و مسیر جایگزین |
|
شرکت چندشعبهای |
مرکز مدیریتشده، ارتباط امن شعب، شمارهگذاری مشترک و مسیر محلی یا مرکزی خطوط |
کیفیت WAN، قطع شعبه، Dial Plan و دسترسی راه دور |
|
مرکز تماس |
سرور و ذخیرهسازی متناسب، صف پیشرفته، ضبط، داشبورد، هدست و مانیتورینگ |
تماس همزمان، SLA، KPI، نگهداری ضبط و افزونگی |
هزینه نهایی هر سناریو به تعداد داخلی، تماس همزمان، نوع خطوط، تلفنها، گیتوی، سرور، لایسنس، ضبط، شبکه و سطح پشتیبانی وابسته است. برای بررسی سبدهای اقتصادی، حرفهای و مرکز تماس، مقاله هزینه راه اندازی VoIP را پس از انتشار محتوای W4-2 مطالعه کنید. لینک رفتوبرگشت میان دو مقاله باید همزمان فعال شود.
|
CTA پروژه: تعداد کاربران، خطوط فعلی، تماسهای همزمان، شعب، نیاز به ضبط و امکانات موردنظر را ارسال کنید تا معماری اولیه راهاندازی VoIP برای شرکت شما بررسی شود. برای پروژههای تهران، امکان هماهنگی اجرای حضوری و پشتیبانی ریموت براساس محدوده خدمت فراهم میشود. |
برای ثبت نیازسنجی و طراحی اولیه، وارد صفحه راه اندازی VoIP شوید و اطلاعات خطوط، داخلیها و شعب را ارسال کنید.
سوالات متداول
تماسهای داخلی در معماری On-Premise میتوانند داخل شبکه شرکت برقرار بمانند، اما تماس بیرونی مبتنی بر SIP، کاربران راه دور یا مرکز تلفن ابری به ارتباط اینترنت وابستهاند. رفتار سیستم هنگام قطع اینترنت باید در طراحی و تست تحویل مشخص شود.
نه همیشه. تلفنهای آنالوگ یا فکس را میتوان در صورت نیاز با گیتوی FXS نگه داشت و خطوط شهری آنالوگ را با FXO به مرکز تلفن متصل کرد. بااینحال، هزینه گیتوی و محدودیت امکانات باید با خرید تلفن IP مقایسه شود.
عدد ثابت براساس تعداد کارمندان درست نیست. تعداد تماسهای همزمان، کدک، کیفیت لینک، رمزنگاری و سایر ترافیکها تعیینکنندهاند. علاوه بر ظرفیت، پایداری، تأخیر و از دست رفتن بسته باید در ساعات شلوغ آزمایش شود.
برای تیم پراکنده و شرکت کمظرفیت، سرویس ابری میتواند مدیریت سادهتری داشته باشد. برای کنترل مستقیم داده، اتصالهای اختصاصی یا نیازهای سفارشی، On-Premise یا Hybrid مناسبتر است. تصمیم باید براساس SLA، اینترنت، امنیت و بازیابی گرفته شود.
بله، اما نباید با باز کردن ساده پورتها و رمز ضعیف انجام شود. روش اتصال امن، سیاست استفاده، امکان پاککردن دسترسی و کیفیت اینترنت کاربر باید تعریف و در خارج شبکه آزمایش شود.
حجم به تعداد تماس، مدت مکالمه، کدک، کانالهای ضبط و دوره نگهداری بستگی دارد. پیش از اجرا باید سیاست نگهداری، سطح دسترسی، بکاپ، حذف خودکار و هشدار پر شدن فضا مشخص شود.
با اجرای آزمایشی، مستندسازی خطوط، برنامه Cutover و مسیر بازگشت میتوان قطعی را به حداقل رساند. انتقال ناگهانی تمام خطوط بدون Pilot و تست، ریسک بیشتری دارد.
جمعبندی
تحویل مستندات، بکاپ، تجهیزات و برنامه پشتیبانی مرکز تلفن
راهاندازی VoIP برای شرکت زمانی موفق است که از نیاز کسبوکار شروع شود و شبکه، خطوط، کاربران، امنیت و پشتیبانی را در یک معماری واحد ببیند. سرور و تلفن فقط بخشی از پروژهاند. مسیر تماس، کیفیت شبکه، دسترسی راه دور، برق اضطراری، نسخه پشتیبان و چکلیست تحویل تعیین میکنند سیستم در روزهای عادی و زمان اختلال چگونه عمل خواهد کرد.
برای دریافت طراحی اولیه، تعداد کاربران، خطوط شهری یا SIP، شعب، ساعات کاری، نیاز به IVR، صف، ضبط و گزارش را همراه با نقشه یا توضیح کوتاه شبکه ارسال کنید. بازبینی نهایی محتوا و معماری پیشنهادی باید توسط کارشناس شبکه و VoIP انجام شود.