Примерно 30 000 человеко-часов со стороны админки VoIP части и думаю в несколько раз больше со стороны проектов eё использующих. Но, если учесть, что бизнес у нас строится вокруг call-центров и это наш основной инструмент, то это того стоило. Именно благодаря этим часам ма продолжаем расти и зарабатывать.
И да, анализ что произошло со звонком производится. Так, например премиальные операторов могут ментяться (или даже налагаться штафы), если слишком много пропущенныз звонков, или оператор кладёт трубку первым слишком часто.
Как я уже писал в самой статье — основная нагрузка это не PBX (не switching) а как раз «навороты» (music on hold, IVR, интеграция с CRM, сбор статистики, конвертация записей в MP3 и отчёты). Так что сравнение, вероятно не совсем корректно.
Но сам FreeSwitch, ИМХО, продукт довольно интересный. Мы тоже с ним играемся, некоторые вещи он делает лучше астериска. Например работу с Google Talk.
Да, именно трансфер и делаем. В результате провайдеру уходит SIP/2.0 302 Moved Temporarily и он идёт туда, куда его послали.
Если я помню верно, opensips либо kamailio — одно и то же, они то сходятся, то расходятся… К тому же это чистый SIP, если я ничего не путаю. Оба проекта пока ещё более слабые технически (хотя и с лучшим маркетингом).
В случае того же астериска мы активно пользуемся ещё и IAX (что даёт заметный выигрыш по ресурсам). Да и community у астериска поболе будет. У нас конечно «исторически сложилось» (мы начинали, когда OpenSER был ещё младенцем), но и сейчас выбрали бы всё же астериск.
Каждому звонку в момент эго начала присвивается некий уникальный внутреренний ID который тянется за ним потом до самого завершения. Всё что можно по этому звонку, все его переходы по очередям, между агентами, между серверами — всё пишется в логи и/или в базу. Следовательно проследить всю его историю нет никакой проблемы.
В момент звонка мы точно знаем на extention какого агента он попал, extention привязан к учётной записи оператора в системе. Сооответственно в момент звонка на этот еxtention у этого оператора автоматом выскакивает попап с номером звонящего и тем что мы про него знаем ну и/или автоматом заполняются некоторые поля (забыл упомянуть, что админка asterisk'a у нас не только експортирует широкий API, но и на определённые группы звонков активно дёргает соответствующие API в других наших админках). Кроме того, в некоторых менее тривиальных ситуациях у нас всё ещё есть номер звонившего, время звонка, номер на который он позвонил и вся история по предыдущим звонкам с этого номера, что позволяет допривязать часть «потерянных» звонков позже, обработав эти данные. Так же клиент иногда диктует другой номер телефона и/или Discount ID который был выдан лично ему на одном из FrontEnf-ов. Всё это тоже может быть позже использовано для привязки звонков к клиентам и продажам.
Со стороны провайдера просто стучатся по очереди на 4 наших IP пока 1 из них не ответит. С нашей стороны — сами астериски (точнее скрипты на каждой ноде) каждые несколько секунд собирают и кладут в базу состояние ноды (активные сервисы, количество звонков и нагрузку), а нода, которая получила звонок, прежде чем обработать или передать соседу (agi-скриптик) смотрит эту информацию и решает кто будет обрабатывать звонок. Плюс есть ещё мониторинг, который может некоторые из этих данных в базе менять.
Соответвственно если какая-то нода выпала — это будет заметно по устеравшим данным в базе либо по изменениям внесённым туда мониторинг-скриптами.
Прокси, в свою очередь, запрашивают для себя активные ноды curl'ом (realtime), а дальше тот же механизм, что и с провайдером.
Звучит логично, но с другой стороны эта информация у нас тоже есть, так как точно помню, пару раз мы её использовали. Уточню у человека, который именно этой частью у нас занимался и отпишу позже.
Конкретно эти данные, если мне не изменяет память, мы получаем не через management interface, и из полного лога с дебагом, парсим, дёргаем оттуда всё что нам рассказывает RTCP по id звонка и складываем в базу.
Сканят каждые пару дней. Если в общих чертах, принцип примерно такой: анализируя логи проксей и серверов, вылавливаем подозрительные действия, типа подбора паролей, смены IP телефона, нескольких одновременных SIP-сессий с одного телефона и т.п. (полный список приводить не буду, дабы не накликать беду).
Далее, соответственно, либо блокировка по IP, либо логоффим оператора (его личный extention) с данного конкретного телефона (после чего для злоумышленника он становится бесполезен, ибо звонить с него, не будучи залогиненым как оператор, нельзя).
Есть ещё механизм лимитов для разных групп операторов на разные типы звонков и действий. Но это всё скорее относится к первой части — подозрительные действия.
Да, как уже упомянул AndreyNagih, в каждом офисе всё резервировано. Если одна машина с прокси выйдет из строя — вторая подхватит всё на себя совершенно прозрачно для телефонов.
Посредством realtime интерфейсов астериска (curl и mysql) обеспечивается моментальное отслеживание изменений конфигурации и частично взаимодействие между нодами и между прокси и серверами.
Посредством agi обеспечивается порядочная часть бизнес-логики (в свою очередь опять-таки взаимодействует с MySQL) и сбор информации / статистики.
Через asterisk management interface конкретным нодам посылаются всяческие команды и опять-таки получаем некую информацию / статистику.
Написанная на php админка, используя вышеперечисленные методы и данные, позволяет этим всем управлять и пользоваться, а так же мониторить в реальном времени. Какой конкретно интерфейс используется для чего зависит просто от удобства реализации конкретной задачи.
Кроме того эта же админка через xmlrpc експортирует довольно широкий API, c которым в свою очередь взаимодействуют все остальные наши сисмемы. Этот API развивался и рос (и продолжает расти) почти с самого начала фирмы, около 6 лет. На данный момент это более 50 разных функций, почти каждая имеет свои вариации в зависимости от переданных параметров.
Этим API в свою очередь пользуется около десятка фронтендов, 4 бекенда, а также firefox плагины на операторских машинах и всякие утилитки. Например в залах где сидят операторы висят телевизоры, показывающие всяческую статистику и (запрашивая это через xmlrpc) состояние очередей, в результате чего периодически поднимают панику и привлекают внимание, когда слишком много клиентов висит в очереди. Мол «соберитесь уже и обслужите».
Далее, как правило все операторы сидят в офисе, ибо за многими нужен глаз да глаз. :) Но некоторым особенно хорошим (и доверенным) дозволено работать из дома, что повышает им уровено комфорта и мотивацию, освобождает места в офисе и создаёт головную боль HelpDesk'у. Кроме того, руководство и многие другие ключевые персоны тоже нужны на связи не только в офисе. Так что и хотели бы унифицировать, да нельзя.
— Multizone RDS
— Возможность быстро добавить ещё ноды, ежели не справляются (snapshot + new instance + 2 минуты на настройку).
— «Резиновое» место под бекапы на S3.
— Возможность «расставить» все ноды в разных регионах (дополнительная защита от отказа датацентра).
Но сам FreeSwitch, ИМХО, продукт довольно интересный. Мы тоже с ним играемся, некоторые вещи он делает лучше астериска. Например работу с Google Talk.
Если я помню верно, opensips либо kamailio — одно и то же, они то сходятся, то расходятся… К тому же это чистый SIP, если я ничего не путаю. Оба проекта пока ещё более слабые технически (хотя и с лучшим маркетингом).
В случае того же астериска мы активно пользуемся ещё и IAX (что даёт заметный выигрыш по ресурсам). Да и community у астериска поболе будет. У нас конечно «исторически сложилось» (мы начинали, когда OpenSER был ещё младенцем), но и сейчас выбрали бы всё же астериск.
В момент звонка мы точно знаем на extention какого агента он попал, extention привязан к учётной записи оператора в системе. Сооответственно в момент звонка на этот еxtention у этого оператора автоматом выскакивает попап с номером звонящего и тем что мы про него знаем ну и/или автоматом заполняются некоторые поля (забыл упомянуть, что админка asterisk'a у нас не только експортирует широкий API, но и на определённые группы звонков активно дёргает соответствующие API в других наших админках). Кроме того, в некоторых менее тривиальных ситуациях у нас всё ещё есть номер звонившего, время звонка, номер на который он позвонил и вся история по предыдущим звонкам с этого номера, что позволяет допривязать часть «потерянных» звонков позже, обработав эти данные. Так же клиент иногда диктует другой номер телефона и/или Discount ID который был выдан лично ему на одном из FrontEnf-ов. Всё это тоже может быть позже использовано для привязки звонков к клиентам и продажам.
Соответвственно если какая-то нода выпала — это будет заметно по устеравшим данным в базе либо по изменениям внесённым туда мониторинг-скриптами.
Прокси, в свою очередь, запрашивают для себя активные ноды curl'ом (realtime), а дальше тот же механизм, что и с провайдером.
Далее, соответственно, либо блокировка по IP, либо логоффим оператора (его личный extention) с данного конкретного телефона (после чего для злоумышленника он становится бесполезен, ибо звонить с него, не будучи залогиненым как оператор, нельзя).
Есть ещё механизм лимитов для разных групп операторов на разные типы звонков и действий. Но это всё скорее относится к первой части — подозрительные действия.
Посредством agi обеспечивается порядочная часть бизнес-логики (в свою очередь опять-таки взаимодействует с MySQL) и сбор информации / статистики.
Через asterisk management interface конкретным нодам посылаются всяческие команды и опять-таки получаем некую информацию / статистику.
Написанная на php админка, используя вышеперечисленные методы и данные, позволяет этим всем управлять и пользоваться, а так же мониторить в реальном времени. Какой конкретно интерфейс используется для чего зависит просто от удобства реализации конкретной задачи.
Кроме того эта же админка через xmlrpc експортирует довольно широкий API, c которым в свою очередь взаимодействуют все остальные наши сисмемы. Этот API развивался и рос (и продолжает расти) почти с самого начала фирмы, около 6 лет. На данный момент это более 50 разных функций, почти каждая имеет свои вариации в зависимости от переданных параметров.
Этим API в свою очередь пользуется около десятка фронтендов, 4 бекенда, а также firefox плагины на операторских машинах и всякие утилитки. Например в залах где сидят операторы висят телевизоры, показывающие всяческую статистику и (запрашивая это через xmlrpc) состояние очередей, в результате чего периодически поднимают панику и привлекают внимание, когда слишком много клиентов висит в очереди. Мол «соберитесь уже и обслужите».
Далее, как правило все операторы сидят в офисе, ибо за многими нужен глаз да глаз. :) Но некоторым особенно хорошим (и доверенным) дозволено работать из дома, что повышает им уровено комфорта и мотивацию, освобождает места в офисе и создаёт головную боль HelpDesk'у. Кроме того, руководство и многие другие ключевые персоны тоже нужны на связи не только в офисе. Так что и хотели бы унифицировать, да нельзя.
— Возможность быстро добавить ещё ноды, ежели не справляются (snapshot + new instance + 2 минуты на настройку).
— «Резиновое» место под бекапы на S3.
— Возможность «расставить» все ноды в разных регионах (дополнительная защита от отказа датацентра).