Виртуальные и облачные АТС: есть ли различия?

«Нереальные» АТС

В зависимости от контекста у слова «виртуальный» может быть множество разных значений, но первая возникающая ассоциация — антоним «реальному» или «физическому». На практике, впрочем, противопоставление будет в определённой степени относительным: виртуальные решения без физического оборудования не существуют. Вопрос в том, как это оборудование используется и, грубо говоря, где оно располагается.

То же самое справедливо и для офисных АТС: либо всё необходимое физическое оборудование для распределения телефонной связи развёрнуто непосредственно в офисе (или в здании) организации, либо они виртуализированы, — то есть, АТС реализована программно, на базе межсетевого протокола IP операторского уровня. Иными словами, голосовой трафик, поступающий извне, преобразуется в поток цифровых данных, передаваемых через протокол IP, так же, как и любой другой интернет-трафик.

Дальше основные различия сводятся к тому, чьи ресурсы использует программная IP-АТC, то есть, реализована ли она локально, с использованием серверов самой компании, или вынесена в «облако» — то есть, в сторонний специализированный центр обработки данных (ЦОД, дата-центр). В целом, в подавляющем большинстве тематических публикаций определения «виртуальные АТС» и «облачные АТС» используются как синонимы.

Зачем это нужно?

Как и в случае с другими типами виртуализации, основное преимущество для клиента заключается в возможности существенно сэкономить на парке оборудования, сняв с себя большую часть расходов на его закупку, установку и поддержку. «Облачные» АТС реализуются как услуга, и всё, что должно волновать клиента, это работоспособность его корпоративной сети, интернет-соединений, собственных телефонных аппаратов и мобильных устройств, на которые могут перенаправляться звонки. Всем остальным занимается поставщик услуги.

На практике вариантов реализации виртуальной АТС для офиса может быть несколько, причём поставщики услуг могут эти варианты комбинировать.

Например, клиенту выделяется абонентский VoIP-шлюз, через который голосовой трафик транслируется по протоколу IP в сеть заказчика, или отдельный сервер с ПО, который устанавливается на площадке у вендора; на стороне клиента настраиваются аппаратные IP-телефоны, программные приложения телефонии (softphones) и/или специализированные программы, такие как клиентское ПО CRM-систем и т.д.

Другой вариант — это предоставление корпоративному клиенту отдельной виртуальной машины с собственной операционной системой и так называемым Softswitch, программным коммутатором, который выступает в качестве ядра мультисервисной сети связи — NGN. Чаще всего в этом контексте упоминаются открытые решения компьютерной телефонии Asterisk и Elastix или Skypе для бизнеса от Microsoft.

Бывают и более сложные варианты: например, предоставление клиенту домена в софтсвиче поставщика услуги; домен в данном случае является виртуальным представлением корпоративной АТС с собственными настройками. Подобная функциональность встречается, например, в российских NGN-софтсвичах Communigate Pro и РТУ.

За что платит клиент?

В большинстве случаев тарифный план определяется количеством конечных точек — т.е. количеством номеров — и дополнительными услугами, такими как интеграция с CRM-системами, голосовая почта, телеконференции, автоматическая генерация аналитических отчётов и т.д., — речь, как правило, идёт о конвергенции сразу нескольких бизнес-инструментов, где интернет телефония лишь один из них.

Безусловным достоинством виртуальных АТС является их доступность малому и среднему бизнесу: с психологической точки зрения, наличие собственной такой системы вызывает у потенциальных клиентов ощущение, что они имеют дело с солидным и надёжным предприятием, вне зависимости от его размеров. При этом для самой организации расходы на эту систему могут быть очень незначительными. По принципу «оптом дешевле» «облака» позволяют более чем ощутимо снижать расценки на предоставление услуг IP-АТС для конечных клиентов без потери в качестве.

В принципе, ничто не мешает той или иной компании реализовать собственную виртуальную АТС, если у неё есть на это ресурсы — например, достаточное количество локальных серверных мощностей. Преимуществом такого подхода будет возможность самостоятельно контролировать функционирование системы и обеспечивать «тонкую настройку» всех её аспектов. При использовании «облачной» АТС вся её инфраструктура оказывается на стороне поставщика услуги и его ЦОД, что несколько ограничивает возможности клиента по настройке нужной ему функциональности. В большинстве случаев, правда, эти ограничения играют очень незначительную роль.

Кроме того, если на уровне ЦОД происходит какой-то сбой, клиенту придётся пассивно ждать разрешения проблемы, не имея никакой возможности повлиять на ситуацию. А от сбоев не защищён никто, даже самые крупные центры обработки данных.

Однако, даже при учёте всех рисков, использование «облачных» АТС в среднем выглядит более практичным подходом. Но в конечном счёте всё определяют потребности клиента.