Комментарии 58
Так почему же всё-таки амазон, если (судя по схеме) сами проекты у вас не на амазоне?
а что это у вас картинка такая профессиональная, Вы дизайнер что ли?
Очень интересно и складно написано, читается на одном дыхании! Все бы так писали. ;) Хотелось бы еще узнать поименно что прикручено к астериску, сколько это писалось или настраивалось, ну короче — чуть-чуть шире.
На картинке видно домашних и офисных агентов — зачем и те и другие? Не проще перейти на один формат, туда или сюда, опять же поддержка будет одинаковой/проще/дешевле?
На картинке видно домашних и офисных агентов — зачем и те и другие? Не проще перейти на один формат, туда или сюда, опять же поддержка будет одинаковой/проще/дешевле?
Посредством realtime интерфейсов астериска (curl и mysql) обеспечивается моментальное отслеживание изменений конфигурации и частично взаимодействие между нодами и между прокси и серверами.
Посредством agi обеспечивается порядочная часть бизнес-логики (в свою очередь опять-таки взаимодействует с MySQL) и сбор информации / статистики.
Через asterisk management interface конкретным нодам посылаются всяческие команды и опять-таки получаем некую информацию / статистику.
Написанная на php админка, используя вышеперечисленные методы и данные, позволяет этим всем управлять и пользоваться, а так же мониторить в реальном времени. Какой конкретно интерфейс используется для чего зависит просто от удобства реализации конкретной задачи.
Кроме того эта же админка через xmlrpc експортирует довольно широкий API, c которым в свою очередь взаимодействуют все остальные наши сисмемы. Этот API развивался и рос (и продолжает расти) почти с самого начала фирмы, около 6 лет. На данный момент это более 50 разных функций, почти каждая имеет свои вариации в зависимости от переданных параметров.
Этим API в свою очередь пользуется около десятка фронтендов, 4 бекенда, а также firefox плагины на операторских машинах и всякие утилитки. Например в залах где сидят операторы висят телевизоры, показывающие всяческую статистику и (запрашивая это через xmlrpc) состояние очередей, в результате чего периодически поднимают панику и привлекают внимание, когда слишком много клиентов висит в очереди. Мол «соберитесь уже и обслужите».
Далее, как правило все операторы сидят в офисе, ибо за многими нужен глаз да глаз. :) Но некоторым особенно хорошим (и доверенным) дозволено работать из дома, что повышает им уровено комфорта и мотивацию, освобождает места в офисе и создаёт головную боль HelpDesk'у. Кроме того, руководство и многие другие ключевые персоны тоже нужны на связи не только в офисе. Так что и хотели бы унифицировать, да нельзя.
Посредством agi обеспечивается порядочная часть бизнес-логики (в свою очередь опять-таки взаимодействует с MySQL) и сбор информации / статистики.
Через asterisk management interface конкретным нодам посылаются всяческие команды и опять-таки получаем некую информацию / статистику.
Написанная на php админка, используя вышеперечисленные методы и данные, позволяет этим всем управлять и пользоваться, а так же мониторить в реальном времени. Какой конкретно интерфейс используется для чего зависит просто от удобства реализации конкретной задачи.
Кроме того эта же админка через xmlrpc експортирует довольно широкий API, c которым в свою очередь взаимодействуют все остальные наши сисмемы. Этот API развивался и рос (и продолжает расти) почти с самого начала фирмы, около 6 лет. На данный момент это более 50 разных функций, почти каждая имеет свои вариации в зависимости от переданных параметров.
Этим API в свою очередь пользуется около десятка фронтендов, 4 бекенда, а также firefox плагины на операторских машинах и всякие утилитки. Например в залах где сидят операторы висят телевизоры, показывающие всяческую статистику и (запрашивая это через xmlrpc) состояние очередей, в результате чего периодически поднимают панику и привлекают внимание, когда слишком много клиентов висит в очереди. Мол «соберитесь уже и обслужите».
Далее, как правило все операторы сидят в офисе, ибо за многими нужен глаз да глаз. :) Но некоторым особенно хорошим (и доверенным) дозволено работать из дома, что повышает им уровено комфорта и мотивацию, освобождает места в офисе и создаёт головную боль HelpDesk'у. Кроме того, руководство и многие другие ключевые персоны тоже нужны на связи не только в офисе. Так что и хотели бы унифицировать, да нельзя.
можете подробнее рассказать, как вы через asterisk management interface получаете статистику о качестве звонка? потеряные пакеты звука, как колебался джиттер.
Конкретно эти данные, если мне не изменяет память, мы получаем не через management interface, и из полного лога с дебагом, парсим, дёргаем оттуда всё что нам рассказывает RTCP по id звонка и складываем в базу.
RTCP мало что полезного несет о именно звонке. Это скорее качество связи до пира. А А-абонент от него может быть далеко.
Звучит логично, но с другой стороны эта информация у нас тоже есть, так как точно помню, пару раз мы её использовали. Уточню у человека, который именно этой частью у нас занимался и отпишу позже.
Ну вот всякие железные железки умеют для каждого звонка считать MOS, анализируя голосовой тракт. И если абонент например звонит с GSM телефона в зоне плохого покрытия, то качество звонка будет соответствовать реальности. Что потом можно анализировать, использовать дял маршрутизации и т.д.
Астериску такое не по зубам, так как нужны хитрые DSP. Обычный CPU тут загнется на втором десятке.
Астериску такое не по зубам, так как нужны хитрые DSP. Обычный CPU тут загнется на втором десятке.
Скажите, а есть у ли у Вас план на случай, если навернется какой-нибудь из asterisk-прокси? Есть ли у телефонов возможность использовать другой прокси, если основной не отзывается?
> Кроме того, это ещё и «первая линия обороны».
Часто сканят? И как боретесь?
Часто сканят? И как боретесь?
Сканят каждые пару дней. Если в общих чертах, принцип примерно такой: анализируя логи проксей и серверов, вылавливаем подозрительные действия, типа подбора паролей, смены IP телефона, нескольких одновременных SIP-сессий с одного телефона и т.п. (полный список приводить не буду, дабы не накликать беду).
Далее, соответственно, либо блокировка по IP, либо логоффим оператора (его личный extention) с данного конкретного телефона (после чего для злоумышленника он становится бесполезен, ибо звонить с него, не будучи залогиненым как оператор, нельзя).
Есть ещё механизм лимитов для разных групп операторов на разные типы звонков и действий. Но это всё скорее относится к первой части — подозрительные действия.
Далее, соответственно, либо блокировка по IP, либо логоффим оператора (его личный extention) с данного конкретного телефона (после чего для злоумышленника он становится бесполезен, ибо звонить с него, не будучи залогиненым как оператор, нельзя).
Есть ещё механизм лимитов для разных групп операторов на разные типы звонков и действий. Но это всё скорее относится к первой части — подозрительные действия.
Охохо, наворотили. Но до профессиональных систем далеко.
Например на астериск никак не избежать сброса активных звонков при вылете одного из серверов. И такой фичи там не будет скорее всего никогда. Не того уровня «продукт».
Например на астериск никак не избежать сброса активных звонков при вылете одного из серверов. И такой фичи там не будет скорее всего никогда. Не того уровня «продукт».
О каких именно профессиональных системах идёт речь? Было бы интересно посмотреть подробнее. Может что-то позаимствуем.
НЛО прилетело и опубликовало эту надпись здесь
Со стороны провайдера просто стучатся по очереди на 4 наших IP пока 1 из них не ответит. С нашей стороны — сами астериски (точнее скрипты на каждой ноде) каждые несколько секунд собирают и кладут в базу состояние ноды (активные сервисы, количество звонков и нагрузку), а нода, которая получила звонок, прежде чем обработать или передать соседу (agi-скриптик) смотрит эту информацию и решает кто будет обрабатывать звонок. Плюс есть ещё мониторинг, который может некоторые из этих данных в базе менять.
Соответвственно если какая-то нода выпала — это будет заметно по устеравшим данным в базе либо по изменениям внесённым туда мониторинг-скриптами.
Прокси, в свою очередь, запрашивают для себя активные ноды curl'ом (realtime), а дальше тот же механизм, что и с провайдером.
Соответвственно если какая-то нода выпала — это будет заметно по устеравшим данным в базе либо по изменениям внесённым туда мониторинг-скриптами.
Прокси, в свою очередь, запрашивают для себя активные ноды curl'ом (realtime), а дальше тот же механизм, что и с провайдером.
Как у вас обеспечивается связывание пришедшего звонка к оператору (на аппаратный или софт-телефон) и CRM-системы или ещё чего-то, для работы оператора именно с этим звонком? И производится ли дальше каким-то образом контроль за звонком (отключился, перевели, и т.д.) со стороны используемой CRM?
Каждому звонку в момент эго начала присвивается некий уникальный внутреренний ID который тянется за ним потом до самого завершения. Всё что можно по этому звонку, все его переходы по очередям, между агентами, между серверами — всё пишется в логи и/или в базу. Следовательно проследить всю его историю нет никакой проблемы.
В момент звонка мы точно знаем на extention какого агента он попал, extention привязан к учётной записи оператора в системе. Сооответственно в момент звонка на этот еxtention у этого оператора автоматом выскакивает попап с номером звонящего и тем что мы про него знаем ну и/или автоматом заполняются некоторые поля (забыл упомянуть, что админка asterisk'a у нас не только експортирует широкий API, но и на определённые группы звонков активно дёргает соответствующие API в других наших админках). Кроме того, в некоторых менее тривиальных ситуациях у нас всё ещё есть номер звонившего, время звонка, номер на который он позвонил и вся история по предыдущим звонкам с этого номера, что позволяет допривязать часть «потерянных» звонков позже, обработав эти данные. Так же клиент иногда диктует другой номер телефона и/или Discount ID который был выдан лично ему на одном из FrontEnf-ов. Всё это тоже может быть позже использовано для привязки звонков к клиентам и продажам.
В момент звонка мы точно знаем на extention какого агента он попал, extention привязан к учётной записи оператора в системе. Сооответственно в момент звонка на этот еxtention у этого оператора автоматом выскакивает попап с номером звонящего и тем что мы про него знаем ну и/или автоматом заполняются некоторые поля (забыл упомянуть, что админка asterisk'a у нас не только експортирует широкий API, но и на определённые группы звонков активно дёргает соответствующие API в других наших админках). Кроме того, в некоторых менее тривиальных ситуациях у нас всё ещё есть номер звонившего, время звонка, номер на который он позвонил и вся история по предыдущим звонкам с этого номера, что позволяет допривязать часть «потерянных» звонков позже, обработав эти данные. Так же клиент иногда диктует другой номер телефона и/или Discount ID который был выдан лично ему на одном из FrontEnf-ов. Всё это тоже может быть позже использовано для привязки звонков к клиентам и продажам.
Расскажите пожалуйста, чем вы реализуете SIP-redirect. На ум приходит только трансфер звонка.
Сейчас строю чтото подобное и понял, что от астерисков надо уходить, и ставить во главе угла какойнить opensips либо kamailio, там делать все регистрации и принятие решений, а астериск либо аналог использовать только для медиа ( трансляция кодеков, ИВР, автоответчик и тп. )
Сейчас строю чтото подобное и понял, что от астерисков надо уходить, и ставить во главе угла какойнить opensips либо kamailio, там делать все регистрации и принятие решений, а астериск либо аналог использовать только для медиа ( трансляция кодеков, ИВР, автоответчик и тп. )
Да, именно трансфер и делаем. В результате провайдеру уходит SIP/2.0 302 Moved Temporarily и он идёт туда, куда его послали.
Если я помню верно, opensips либо kamailio — одно и то же, они то сходятся, то расходятся… К тому же это чистый SIP, если я ничего не путаю. Оба проекта пока ещё более слабые технически (хотя и с лучшим маркетингом).
В случае того же астериска мы активно пользуемся ещё и IAX (что даёт заметный выигрыш по ресурсам). Да и community у астериска поболе будет. У нас конечно «исторически сложилось» (мы начинали, когда OpenSER был ещё младенцем), но и сейчас выбрали бы всё же астериск.
Если я помню верно, opensips либо kamailio — одно и то же, они то сходятся, то расходятся… К тому же это чистый SIP, если я ничего не путаю. Оба проекта пока ещё более слабые технически (хотя и с лучшим маркетингом).
В случае того же астериска мы активно пользуемся ещё и IAX (что даёт заметный выигрыш по ресурсам). Да и community у астериска поболе будет. У нас конечно «исторически сложилось» (мы начинали, когда OpenSER был ещё младенцем), но и сейчас выбрали бы всё же астериск.
Не так давно (в мае) на форуме замечательного продукта Freeswitch один мужик хвастался (сессий как бы на порядок больше в день):
UP 0 years, 7 days, 10 hours, 7 minutes, 58 seconds, 481 milliseconds, 883 microseconds
FreeSWITCH is ready
1009971 session(s) since startup
376 session(s) 4/60
1000 session(s) max
min idle cpu 0.00/69.00
This is running on a XenServer 6 Virtual Machine using CentOS 6.2
It uses 2 cores: Intel® Xeon® CPU E5430 @ 2.66GHz and 4GB of RAM.
Using: FreeSWITCH Version 1.0.head (git-d827cfe 2012-03-04 17-48-30 -0600)
I run freeswitch in -hp mode. I use track-calls in the SIP profile to store calls for HA support and mysql master-slave replication to transfer the database to the standby freeswitch virtual machine (different physical hardware). I use heartbeat and mon for network and service monitoring. If the network or a service drops it fails over to the standby freeswitch virtual machine without dropping the calls.
Great product. Quality and Stability is rock solid. Thanks Anthony, Brian and everyone I forgot.
UP 0 years, 7 days, 10 hours, 7 minutes, 58 seconds, 481 milliseconds, 883 microseconds
FreeSWITCH is ready
1009971 session(s) since startup
376 session(s) 4/60
1000 session(s) max
min idle cpu 0.00/69.00
This is running on a XenServer 6 Virtual Machine using CentOS 6.2
It uses 2 cores: Intel® Xeon® CPU E5430 @ 2.66GHz and 4GB of RAM.
Using: FreeSWITCH Version 1.0.head (git-d827cfe 2012-03-04 17-48-30 -0600)
I run freeswitch in -hp mode. I use track-calls in the SIP profile to store calls for HA support and mysql master-slave replication to transfer the database to the standby freeswitch virtual machine (different physical hardware). I use heartbeat and mon for network and service monitoring. If the network or a service drops it fails over to the standby freeswitch virtual machine without dropping the calls.
Great product. Quality and Stability is rock solid. Thanks Anthony, Brian and everyone I forgot.
Как я уже писал в самой статье — основная нагрузка это не PBX (не switching) а как раз «навороты» (music on hold, IVR, интеграция с CRM, сбор статистики, конвертация записей в MP3 и отчёты). Так что сравнение, вероятно не совсем корректно.
Но сам FreeSwitch, ИМХО, продукт довольно интересный. Мы тоже с ним играемся, некоторые вещи он делает лучше астериска. Например работу с Google Talk.
Но сам FreeSwitch, ИМХО, продукт довольно интересный. Мы тоже с ним играемся, некоторые вещи он делает лучше астериска. Например работу с Google Talk.
Если не секрет какии VOIP аппараты используете?
Скажите, что у вас за VoIP-оператор?
Потрясающе! Снимаю шляпу!
Спасибо, очень познавательно.
Сколько же человека-ресурсов положено на алтарь этого решения…
Сколько же человека-ресурсов положено на алтарь этого решения…
Примерно 30 000 человеко-часов со стороны админки VoIP части и думаю в несколько раз больше со стороны проектов eё использующих. Но, если учесть, что бизнес у нас строится вокруг call-центров и это наш основной инструмент, то это того стоило. Именно благодаря этим часам ма продолжаем расти и зарабатывать.
Спасибо, действительно интересно почитать. Но из статьи не понятно, у вас тиражируемый продукт, или это решение развернуто у единственного заказчика?
Какие линукса используете для астера? CentOS, Ubuntu/Debian?
как вы мониторите операторов которые сидят из дома что у них связь с сервером нормальная и для клиетов приемлимо слышно?
jitter buffer всегда используете? ведь он тоже сервер нагружает?
jitter buffer всегда используете? ведь он тоже сервер нагружает?
Операторы работают с нашим VoIP proxy, а там у нас есть все логи, как на оператор<->прокси, так и на прокси<->сервера. Из полного дебаг-лога астериска довольно много можно надёргать. Кроме того, операторы сами жалуются на качество, так как они не на зарплате, а на проценте + надбавки/убавки за эффективность и плохое качество весьма мешает им зарабатывать, а вовремя заявленное плохое качество может быть принято во внимание при рассчётах.
Jitter-buffer используем всегда на линке прокси<->сервера и сервера<->провайдер потому как там почти всегда есть и неравномерные задержки и частенько перестановка пакетов. Дешевле платить за ресурсы, чем терять клиентов из-за «А? Что? Не расслышал!», а при его размере в 50ms задержка голоса всё ещё небольшая.
Jitter-buffer используем всегда на линке прокси<->сервера и сервера<->провайдер потому как там почти всегда есть и неравномерные задержки и частенько перестановка пакетов. Дешевле платить за ресурсы, чем терять клиентов из-за «А? Что? Не расслышал!», а при его размере в 50ms задержка голоса всё ещё небольшая.
500 операторов на линии постояно? или это всего экстеншинов столько?
Очень интересно, спасибо.
У вас есть сайт?
Подключаете ли сторонние колл-центры?
У вас есть сайт?
Подключаете ли сторонние колл-центры?
> Из полного дебаг-лога астериска довольно много можно надёргать.
Можно поподробней?
Можно поподробней?
Ёлки палки, я что то такое же создал как и вы, конечно примерно, деталей туча, только ушло 3 года, поделитесь сколько человек работало над этим?
Правда у меня система другая, я раздаю звонки через опенсипс на котором есть логика очереди, а медиа серверы просто играют музыку, я так прикинул и вышло что могу 5000 человек без особых напрягов, а если подумать то и больше.
Правда у меня система другая, я раздаю звонки через опенсипс на котором есть логика очереди, а медиа серверы просто играют музыку, я так прикинул и вышло что могу 5000 человек без особых напрягов, а если подумать то и больше.
Image:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Астериск под реальной нагрузкой – распределённый отказоустоичивый колл-центр на >500 операторов