Contact Center «на коленке»

Некоторое время назад руководство поставило задачу создать Contact Center на пару десятков операторов. Операторы должны были контролируемо и оперативно отрабатывать запросы от клиентов и отдела продаж приходящие по телефону, почте, обращения через web. Сроку на все-про все было дано пару месяцев. Столь экстремальный подход определялся быстрыми значительными изменениями в организационной структуре и бизнесе Компании.

Во-первых, было решено централизовать отдел поддержки продаж (ОПП), который был распределен по городам и весям России. Управление централизованным подразделением существенно более простая задача. С точки зрения IT инфраструктуры тоже немалое подспорье, т.к. её организация и сопровождение при централизованном варианте существенно упрощается и удешевляется. Обеспечить отказоустойчивость систем и высокую производительность работы куда проще в центральном офисе.

Во-вторых, количество офисов продаж по России подрастало, что требовало соответствующей поддержки back-office. Контролировать же работу back-office подразделений в филиалах очень непросто. IT от децентрализации страдает значительно, т.к. обеспечить приемлемую удаленную работу сотрудника ОПП в Хабаровске, при том, что только из-за длины трассы ВОЛС задержки в теории не могут быть ниже 60 мс, т.к. скорость распространения света все-же конечна. А с учетом многочисленных маршрутизаторов, конвертеров и т.д. задержки становятся существенно больше 100 мс, что уже нехорошо для терминальных сессий.

В-третьих, необходимо было существенно оптимизировать бизнес-процессы в компании, обеспечив клиентам максимально комфортную работу с Компанией, минимальные сроки решения поставленных задач и т.д. При этом численность компании не должна была прирасти кардинально (за этим зорко наблюдают датские собственники). Соответственно, типичная задача для IT — обеспечить эффективную работу минимальным составом работников.

Идея создания централизованного ОПП витала давно, но никто не решался её реализовать, т.к. изменения в орг. структуре действительно серьезные и бизнес не был готов к столь кардинальному шагу.

Из-за экстремального (как минимум, для нас) согласования идеи централизации ОПП, не менее экстремально следовало и обеспечить IT инфраструктуру (примерно в середине октября был дан старт проекту, а в конце ноября — начале декабря новобранцы-операторы, которых интенсивно набирали, уже должны были работать на своих местах). Закупить оборудование для рабочих мест — задача несложная, а вот сделать Contact Center для 2-х десятков агентов, организовать бесплатный номер 8-800, запустить FMTN/FMC для сокращения затрат на коммуникации, поднять SMS-шлюз, сделать интеграцию с CRM, обеспечить управляемую обработку сообщений приходящих по почте и через web — это уже более интересные и серьезные задачи.

Организация Contact Center. Nortel/Avaya vs Asterisk.

Поскольку использование отдельных «кусков» Contact Center несколько раз рассматривалось в компании, я грубо представлял затраты на реализацию задачи на базе имеющейся у нас станции Nortel CS1000. По прикидкам получалось, что добавление к базовому функционалу нашей станции (IVR у нас уже есть на CallPilot-е) хотя-бы записи разговоров с агентами + статистика по ним уже выходили в десяток тыс. $ (соответствующие цифры двухгодовалой давности у меня были, а вендоры, вроде Avaya/Nortel/Cisco и т.п. цены меняют редко).

Возможности использования интерфейса интеграции (CTI) с АТС добавляли ещё несколько тысяч долларов. Причем по опыту двухгодичной давности, настройка CTI у Nortel — та ещё задачка, над которой спец. (аутсорсер) по Nortel бился немало времени, но приемлемого результата не достиг. Аналогичный трехгодичный опыт был у наших московских коллег и только недавно они мне сообщили, что смогли продвинутся в этом направлении и готовы поделится результатами (когда мы уже всё закончили). В общем, для меня было очевидно, что писать софт для интеграции с Nortel — задача зубодробительная, а результат непонятно когда будет достигнут.

Поскольку имеющего функционала станции нам не хватало, чтобы удовлетворить запросы бизнеса, пришлось бы закупать дополнительное железо + софт. Call Center от Nortel — Symposium, стоит очень недешево и суммарные затраты (вместе с внедрением) легко бы превысили планку в 25-30 штук вечнозеленых. Причем было очевидно, что только согласование этих непредвиденных расходов (в бюджете в начале года заложены не были) заняло бы немало времени, а запустили бы мы проект вообще не знаю когда.

Взвесив все за и против я решил, что стоит попробовать реализовать Contact Center на базе используемого у нас совместно с Nortel решения на базе OpenSource продукта Asterisk. Asterisk мы использовали в компании продолжительное время в качестве конвертера SIP протокола АТС Panasonic (серий TDA/TDE) с SIP протоколом Nortel. Вроде везде SIP, но напрямую Panasonic с Nortel по SIP толком заставить работать нам не удалось.

Asterisk — решение достаточно зрелое, надежное (использовали мы его больше года) и весьма гибкое. Продолжительное время порыскав в недрах интернет я нашел немало свидетельств использования этой системы для организации небольших Call Center. Функционал IVR, ACD, записи переговоров имелся в базовом варианте (ничего дополнительного ставить/закупать не требовалось). Софт для обработки статистики по агентам также был вскоре найден за сравнительно смешные деньги в районе 500$ — Asternic. После переговоров с «Софтлайн» — они согласились эксклюзивно поставить это ПО за те-же 500$ со всеми требующимися по закону оправдательными документами. Также был найден работающий многоканальный TAPI Service Provider (TSP). В общем, в первом приближении все выглядело достаточно зрело и пригодно к употреблению.

Риск был значительный, но все-же меньше, чем в случае реализации на Nortel. C Asterisk я рисковал срывом сроков реализации проекта и копеешными затратами, а в случае с Nortel в сроки бы не уложился в любом случае (согласование инвестиций + заказ с доставкой оборудования заняли бы минимум 4-5 месяцев), а затраты были бы существенно выше, а соответственно, «кнут» в случае неудачи был бы куда больнее.

Оснащение Contact Center

Чтобы минимизировать потери в случае неудачи с Asterisk, либо вообще свертывания проекта CallCenter — решил приобрести для агентов Nortel/Avaya телефоны 1120E с поддержкой SIP прошивки и возможностью подключения профессиональных USB гарнитур (чтобы сократить расходы на адаптер гарнитура-телефон). В случае чего у меня оставалась возможность использовать эти телефоны c нашей CS1000.

Выбор Nortel/Avaya 1120E — один из моих недочетов в этом проекте. Хотя, опытом уже научен выбирать унифицированные решения, поэтому тяжело было бы уйти от используемого решения.  Телефоны достаточно дорогие (кто использует оборудование Nortel/Avaya/Cisco/Siemens и пр. хорошо знает цену на IP телефоны этих вендоров) ~ 300$, хотя очень качественные. За более чем 3 года эксплуатации этих IP телефонов  у нас «сдохло» лишь пара штук из нескольких десятков. С другой стороны VoIP телефон от LinkSys, Grandstream, Zyxel с аналогичным функционалом обошелся бы в 4-7 тыс. руб.

Домовитые парни из Avaya, после приобретения Nortel, решили срубить побольше бабла и с 3-ей версии прошивки ввели лицензии на SIP на самом телефоне, о которых ни слова не написали на сайте в разделе где давалась краткая спецификация 1120E. Ранее лицензировать требовалось только SIP подключения на самой АТС. VoIP телефоны ведущих вендоров по-прежнему стоят существенно дороже цифровых и тем более аналоговых портов… Мы оттестировали работу SIP прошивки с Asterisk на одном из наших Nortel 1120E и все необходимые функции отрабатывались замечательно. После чего я экстренно заказал 1120E для агентов (по счастью, они были на складе, поэтому поставка была скорой). Примерно через неделею-полторы после запуска в работу CallCenter (агенты вышли на работу) самый первый тестовый 1120E (по счастью, мы отдали его одному из агентов) неожиданно перестал регистрироваться на Asterisk, сигнализируя о нехватке какой-то лицензии. Оказалось, что в телефоне «прошита» триальная лицензия, отрабатывающая 30 дней, после чего функционал SIP отключается. Я начал заниматься выяснением стоимости и сроков поставки лицензии, а спец. занимающийся настройкой Asterisk поиском временных решений, чтобы не останавливать работу всех сотрудников ContactCenter по завершения триального периода на остальных телефонах. К счастью, откат на версию SIP 2.0 решал проблему с регистрацией, но при этом переставали работать USB гарнитуры Jabra 2400. После недели-двух общения с Avaya наконец удалось выяснить что за лицензия необходима (70$ MSRP или ~60$ со скидкой — не малые деньги для телефона за 300$). Причем после оплаты лицензий мы не могли их получить три месяца, т.к. никто в Avaya толком не знал каким образом нужно активировать лицензии на телефонах, т.е. горе-маркетологи Avaya как-то не подумали, что их телефоны с заявленной SIP функциональностью могут использоваться на оборудовании отличном от Avaya.

Профессиональные USB гарнитуры Jabra 2400 BIZС профессиональными гарнитурами тоже имеется немало нюансов. Обычно в Call Center используются гарнитуры двух производителей: Jabra и Plantronix. Ранее мне приходилось закупать гарнитуры обеих производителей. Беспроводные гарнитуры для агентов не удобны (масса пока приличная, да и весь день подвергать мозг электромагнитному излучению, пусть малой мощности, желающих найдется немного). Из проводных гарнитур для определенных моделей телефонов Nortel/Avaya выбор достаточно ограниченный. Гарнитуры с поролоновым амбушюром достаточно быстро теряют внешний вид и приходиться закупать новые амбушюры. Кожаные амбушюры существенно более стойкие (нужно реже менять) и более комфортные в постоянной носке. Гарнитуры Jabra мне нравились больше Plantronix, хотя все это достаточно субъективно. Профессиональные гарнитуры оснащаются хитрыми быстроразъемными штекерами, естественно, у каждого производителя собственной конструкции. Для подключения к телефонам разных моделей требуется переходник, который может стоить вполне ощутимых денег 20-55$. В результате проф. гарнитура получается довольно недешевым удовольствием 100-300 $. Микрофоны этих гарнитур достаточно своеобразная вещь, рассчитанная на работу агента в шумных помещениях, где ведутся перекрестные переговоры других агентов. Для этого в гарнитуры добавлены механизмы гашения посторонних шумов и пр., что, на мой взгляд, несколько ухудшает громкость голоса агента для клиента. Практически все проф. гарнитуры с которыми приходилось иметь дело в той или иной степени грешат этим. Поэтому гарнитуры лучше тестировать на совместную работу с телефоном не доверяя таблицам производителей. Взять на тестирование гарнитуру практически не реально, приходиться её приобретать. Учитывая сроки поставки при таком раскладе нужно порядка 2-3 месяцев, чтобы подобрать подходящую модель. У меня этого времени не было, поэтому для агентов закупалось то, что есть на складе и подбиралась модель исключительно по таблицам, так что когда мы их получили, меня постигло очередное разочарование. Агент слышал клиента замечательно, а вот клиент слышал агента хуже, чем при общении по телефону без гарнитуры. После обновления прошивки гарнитуры (до чего дошли, уже и в гарнитуре софт) вроде бы стало получше, но не кардинально. Из общения с производителем получили информацию как должен размещаться микрофон у рта агента, чтобы уровень сигнала был максимальным. Стало чуть лучше, но не очень удобно агенту, тем более что он не слышит каков уровень громкости у клиента. В общем, ждем очередное обновление прошивки.

Настройка систем

Параллельно с закупкой оборудования спецы по настройке Asterisk и Nortel занимались «бесшовной» интеграцией двух станций, чтобы у клиентов и агентов была полная иллюзия использования единой системы. Стыковали по SIP транкам. За исключением нескольких нюансов (часть из которых не решена до сих пор, но есть понимание как решать и это мелкие проблемы, вопрос денег) основную интеграцию и настройку удалось сделать примерно в месячный срок. Основные проблемы возникли из-за телефонного стыка между центральным офисом и производственной площадкой, работающего по H.323 транкам.

Из-за запрета на использование одного из VoIP кодеков мы долго не могли понять, почему звонок переадресованный с Asterisk на внутренний номер на производство не доходит до абонента. Кроме того, похоже, из-за различий в реализации стандартного протокола SIP на Asterisk и Nortel при переводе звонка с Asterisk на Nortel клиента встречала тишина, вместо стандартного сигнала ожидания или занято. Удалось найти обходное решение на Asterisk, имитирующее соответствующий зуммер на нем до тех пор, пока на Nortel не будет поднята трубка. Также совершенно случайно было обнаружено, что из-за использования фантомного номера на Nortel для проброса звонков, на Asterisk уходит только одна линия, т.е. многоканального телефона не получается. При поступлении второго звонка клиент слышит сигнал как будто никто не берет трубку. После переделки на Nortel с фантомного номера на ACD — многоканальность вернулась.

После всех этих мытарств можно констатировать, что бесшовное «сшивание» этих двух станций — вполне реализуемся задача. Сейчас все звонки приходящие на определенный номер (в т.ч. с 8-800) пробрасываются с Nortel по SIP транкам в очередь на Asterisk и обрабатываются уже им. Соответственно, IVR, запись разговоров, статистика агентов, интеграция с компьютером (CTI) реализуются уже на Asterisk и практически бесплатно. SIP телефоны агентов регистрируются на Asterisk, но агенты могут переводить звонки на корпоративные номера набрав обычный внутренний номер без доп. префиксов, как и на Nortel, за счет сконфигурированного dial plan-а.

8-800

Номер 8-800 был оперативно приобретен у «Билайна» и запущен в течении пары недель. Есть два варианта тарификации: повременная и фикс-прайс. Плюс повременного тарифа — задействованы все таймслоты в PRI, т.е. 30 клиентов могут одновременно позвонить в Call Center. При формировании бюджета я прикидывал насколько возрастут затраты на телефонию при запуске 8-800, но такой прогноз крайне неточен, т.к. предсказать поведение клиентов невозможно, а при централизации ОПП существенно изменяется структура звонков. Чтобы соблюдать бюджет на связь в качестве запасного варианта можно использовать фикс-прайс. Скажем, если затраты на 8-800 начинают регулярно превышать некоторую величину, тогда нужно переходить на фиксированный тариф. Цена в этом случае устанавливается за таймслот (телефонную линию), т.е. ~35 тыс. руб. в мес. заплатил за одну линию и голова не болит сколько клиенты будут её занимать. Понятно, что в этом случае возрастают риски, что клиент будет слышать «занято» чаще, т.к. платить абон. плату за 30 таймслотов — смысла нет, придется определять некоторое оптимальное количество линий для 8-800.

Нужно учитывать, что звонки с номера 8-800 просто переадресовываются на некоторый обычный многоканальный номер, принадлежащий Компании. Когда звонок с 8-800 приходит на этот номер, в его параметрах нет никаких данных, что он пришел с 8-800, что приводит к смешению в статистике. Становится проблематично разобрать сколько звонков было с 8-800, а сколько пришло на номер как обычный звонок, оплачиваемый клиентом. Поэтому лучше использовать для принятия звонков с 8-800 специально выделенный номер о котором никто не знает, чтобы не было «шумовых» звонков искажающих статистику 8-800.

CTI

Для максимального сокращения времени на обработку звонка, силами одного разработчика, за пару недель был разработан модуль на .NET интегрирующий Asterisk c нашей системой CRM. От использования TAPI пришлось отказаться, т.к. не получилось решить ряд критичных для нас проблем. Поэтому вместо TAPI использовали интерфейс Asterisk (AMI) с помощью библиотеки Asterisk.NET. Пока что реалиован минимально необходимый функционал: определение кто звонит, отображение карточки клиента и т.п., но добавление необходимого функционала — не особо сложная задача.

SMS

Интеграция с SMS шлюзом провайдера (в нашем случае «Билайн-бизнес») — дело не для слабонервных. В теории все хорошо, поддерживается два протокола: SMTP и SMPP. Нам было проще реализовывать передачу сообщений по SMTP, т.к. с соответствующими библиотеками мои разработчики много работали и знали их «вдоль и поперек». Наверное, выбор SMTP — это была наша ошибка, т.к. при интеграции мы столкнулись с массой проблем. Видимо, надо было выбирать SMPP. Во-первых, оператор для получения  SMS сообщений по SMTP использует нестандартный порт из-за чего нам пришлось перестроить наше оборудование. Кроме того первоначально оператор отказался прописывать разрешение на доступ к сервису отправки сообщений с нескольких подсетей (у нас используется балансировка сетевой нагрузки, поэтому письма могут уходить с разных IP адресов). И наконец, осталась одна невыясненная проблема из-за которой ~20% SMS не удается отправить с первого раза. Оператор утверждает, что проблема возникает из-за одновременного доступа с одного ip адреса для отправки нескольких сообщений из-за чего система отказывается обработать вновь пришедшее сообщение, пока не обработано предыдущее. Вроде как многопоточная реализация таких систем должно быть делом обычным, но видать я слишком хорошо думал о системах, используемых у операторов. Будем надеяться, что проблему «полечат» когда-нибудь, сейчас же мы реализовали некоторый workaround, отправляя сообщение по несколько раз, пока не будет получен позитивный ответ об отправке. Возможно, переделаем отправку на SMPP, тем более, что этот протокол реализован в Communigate Pro.

FMTN

Из-за централизации сотрудников ОПП телефонный трафик от продажников в филиалах должен был постепенно мигрировать в центральный офис. В преддверии формирования годового бюджета это обстоятельство немало беспокоило. Чтобы нивелировать последствия и попытаться сохранить бюджет неизменным решено было запустить услугу FMTN. Кроме того использование этого функционала упрощало коммуникации сотрудников из-за появления возможности осуществлять звонки по коротким номерам.

Для организации FMTN пришлось задействовать дополнительный PRI поток (дополнительные затраты в 5000 руб. в мес.), зацепив офисную АТС напрямую к коммутатору мобильного оператора. Не знаю почему «Билайн» не мог пробросить уже приходящий на них поток на оператора мобильной связи. Мы используем у «Билайна» и подключение к фиксированной телефонии (по PRI) и договор на корпоративную мобильную связь. Видимо какие-то технические нюансы. В случае FMC пробрасывать дополнительный поток не пришлось бы, но в этом случае тарификация междугородних переговоров была бы по тарифам оператора фиксированной связи, что меня не очень устраивало, т.к. корпоративные тарифы на междугородние звонки по мобильной связи у нас более выгодные, чем по фиксированной. Опять-же посекундная тарификация добавляет экономии.

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

Соответственно, продажник, набрав на своем мобильном *701 — попадет на офисный телефон сотрудника в центральном офисе, а *0701 — на мобильный.

Ну и главное — цена. Для подключения FMTN на SIM-ку подключается дополнительная услуга с стоимостью зависящей от региона. Например, для сотрудников центрального офиса, цена ~40 руб., а для филиалов — более 100 руб. При этом все звонки тарифицируются с 0-й стоимостью. Хотя, пока в биллинге то и дело проскакивают ненулевые величины из-за чего приходится периодически разбираться с оператором. Но контролировать биллинг оператора нужно в любом случае, т.к. «косяки» с биллингом случаются.

FMTN/FMC, несомненно, обеспечивает существенно более высокое качество соединения, чем при использовании GSM шлюзов. Мы продолжительное время использовали аналоговые GSM шлюзы компании 2N. Устройства неплохие, но то, что звонок дважды проходит по радиоканалу оператора мобильно связи (сначала с GSM шлюза на базовую соту оператора, затем на мобильный, даже если шлюз и мобильный в одном месте) иногда существенно ухудшает его качество и это не лечится в принципе. Даже при размещении GSM шлюза в месте с высоким уровнем сигнала базовой станции, проблемы с качеством голоса, например, в виде слишком тихого сигнала, все равно проявляются.

При использовании FMTN звонок приходящий на мобильный телефон по качеству сигнала не отличается от какого-нибудь DECT телефона. Т.е. FMTN/FMC вполне можно рассматривать как замену традиционной DECT телефонии. Инвестиций, которые надо потратить на развертывание DECT телефонии вполне хватит на несколько месяцев (лет) оплаты стоимости FMTN/FMC.

Планы

Поскольку Asterisk становиться значительно более критичным сервисом есть планы по повышению его отказоустойчивости. Он работает на виртуальной машине VMWare, поэтому, возможно, мы задействуем механизмы, вроде Fault Tolerance, для обеспечения максимально безотказной работы. Хотя более интересен вариант обеспечения load-balancing Asterisk, например, используя протокол DUNDi, поддержка которого уже встроена в Asterisk. Есть и другие решения: http://www.voip-info.org/wiki/view/As…+Solutions, http://www.kamailio.org/dokuwiki/doku…ing-and-ha, http://www.opensips.org/index.php?n=R…dbalancing. Кроме того можно попытаться реализовать отказоустойчивость, используя имеющийся коммутатор Nortel L2-7. Как говорится, прочувствуйте мощь решения на базе Asterisk. 🙂

Заключение

В результате всех действий с минимальными затратами был поднят необходимый функционал Contact Center. Несомненно, есть ещё что подработать и подшлифовать, но уже сейчас можно констатировать, что использование OpenSource решения Asterisk позволяет решать подобные задачи достаточно эффективно и за существенно меньшие деньги, чем в случае использования домовитых монстров Avaya/Cisco и пр. Хотя для разных масштабов задачи — свои решения.

 

 

 

 

 

 

 

 

 

 

 

 

 

 【2018年度版】A4クリアファイル対応ランドセル Simple+Comfort BM7012C キャメル/ダークグリーン/ダークワイン/ダークブルー シンプル トラッド クラシック ソフトニッケル 
クーポンで10%OFF サイズ変更可 無垢 北欧家具 日本製 北欧 テイスト シンプル ナチュラル モダン 家具 ナチュラル家具 パイン材 木製 アンティーク調 大人デスク ライティングデスク PCデ
『家庭用RF美容機器』伊藤超短波 サーマボーテRF【smtb-s】
品質管理、保証もしっかりでお届けします
【TMHG95EC1】TOTO シャワーバー(水栓なしタイプ) 【トートー/TOTO】
Indianapolis Colts Black 20 Hardcase Rolling Bag ユニセックス 小物 一般
phpinfo()
UK18?8ユニット小判湯煎用スタンド シェル 22インチ
Hakkenden- Eight Dogs of the East 13【中古】
間仕切 アコーデオンカーテン ドア スーパー防汚(ウイルNo.7101/カソードNo.7102)

Spread the love
Запись опубликована в рубрике IT решения для бизнеса. Добавьте в закладки постоянную ссылку.

5 комментариев: Contact Center «на коленке»

  1. Dax говорит:

    Может организовать краткий курс ликбеза по развертыванию Asterisk для интересующихся? С вопросами поддержки/обновления компонентов решения и по «железному воплощению» данного вопроса.
    Интересуюсь уже не праздно — вопрос по внутренней телефонии никак не решается — низы уже ничего сделать не могут с имеющимся, верхи ничего не хотят )

    • Андрей Федоров говорит:

      Что именно интересует? Чем смогу — помогу. 🙂

      • Dax говорит:

        У меня настолько все устарело в плане телефонии, что дальше некуда… А полноценное общее адресное пространство для общения голосом очень хочется. Вопрос по голосовым конференциям решен, например, просто с помощью skype, а хочется полноценной телефонии с возможностью переключаться между всеми подразделениями (благо сеть построена и она достаточно надежна).
        Мне желательно понять возможно ли ядро будущей телефонии перевести, к примеру, на Asterisk — что за железо мне понадобится (у меня есть сейчас 5 аналоговых входящих, остальное можно и перенастроить) или все же собраться и продавить покупку той же TDA от Panasonic, а потом уже -со временем- эксперементировать с OpenSource.
        Тут еще накладывается текущее отсутствие квалифицированного персонала, который может выделить время и ресурсы на данную задачу… (

        • Андрей Федоров говорит:

          Panasonic TDA хорошая станция. У нас в филиалах их десятка полтора — работают как часы. Если брать аналоговые телефоны — будет некоторая доп. экономия в сравнении с решением на Asterisk.

          Под строительство телефонии на Asterisk в любом случае нужен более или менее нормальный сервер (системник можно использовать, если надежность не критична). Аналоговые интерфейсные платы городских линий тоже стоят денег. Опять-же VoIP (SIP) телефоны обходятся куда дороже аналоговых телефонов.

          В случае с Panasonic их VoIP телефоны, насколько я знаю, не поддерживают SIP. Т.е. приобрести телефоны Panasonic, чтобы использовать с Asterisk и в случае чего перейти на Panasonic (или наоборот) не получится.

          Надо считать экономику и что в перспективе хочется получить.

  2. Andrey Fedorov говорит:

    По надежности пока нареканий по Asterisk нет. После того как решим вопрос с load-balancing, тогда не страшно будет Asterisk даже на системниках поднимать и с масштабируемостью проблем не будет. Главное решить вопрос с интерфейсными платами городских линий при балансировке нагрузки.В случае с load-balancing лучше цепляться к оператору по SIP/H.323.