Астериск под реальной нагрузкой – распределённый отказоустоичивый колл-центр на >500 операторов

    Порядка 600 операторов в 4 странах, обрабатывающих звонки клиентов на американские (и немного на российские) номера.
    Примерно 200 одновременных разговоров в пиковое время.
    Примерно 15 000 звонков в день.
    Возможность за несколько минут масштабировать это решение в несколько раз (по нашим прикидкам до ~1000 параллельных звонков, прежде чем начнутся проблемы).

    Ну и конечно же, плотная интеграция с внутренними системами (CRM, сопровождение покупок, приоритеты операторов и клиентов и много-много других плюшек).

    Кому интересно как это это работает и почему именно так — добро пожаловать

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

    Для начала общая схема:
    image

    Провайдер телефонии по SIP подаёт звонки на наши сервера. Сервера, на данный момент, на Амазоне, но мы не сильно привязаны к нему, просто есть некие удобства, которые нам помогают решать некоторые задачи проще и элегантнее. Со стороны провайдера телефонии настроен failover: если не ответил один сервер, звонок автоматом пойдёт на другой, если и он – то на третий, и так далее (прописано реально 4 IP, используется сейчас 2, но, в случае чего, есть возможность быстро поднять новые основные ноды без шаманства с IP-шками и переписки с провайдером).

    Сервер получивший звонок (один из основных серверов), смотрит какие сервера сейчас доступны и где какая нагрузка на них в данный момент, и либо обрабатывает звонок сам, либо кидает провайдеру SIP-redirect на другой наш сервер, который должен заняться этим звонком. Всего серверов сейчас 2+N:
    2 – это два полностью взаимозаменяемых основных сервера, знающих как балансировать нагрузку, а так же держащие на себе некоторые дополнительные сервисы, такие как распределённая файловая система (glusterfs) для файлов, которые должны быть идентичны на всех нодах, memcache для локов, и всякую прочую мелочь. Эти две ноды запущены постоянно. N — остальные ноды, они запускаются по мере необходимости (по достижении неких пороговых значений количества одновременных звонков), на данный момент их тоже 2.

    Каждый сервер, получив звонок, совершенно независимо от других, по мере необходимости, проводит его через IVR, в зависимости от разных факторов, прогоняет через различные очереди, закидывает звонок на voicemail (автоответчик), либо на конкретного человека (оператора) в одном из офисов, после чего держит этот звонок и пишет логи и статистику, ну и сам разговор, если разрешено, тоже пишет. В общем, проводит его через всю бизнес логику, которая реализована частично в MySQL-конфиге, частично в скриптах через agi интерфейс (которые опять таки смотрят в MySQL), частично curl-запросами.

    Список звонков на каждом сервере свой, а вот IVR и очереди (и операторы, ожидающие звонка в очередях) дублируются на всех серверах. Соответственно, для некоторых действий, как например передача звонка из очереди свободному оператору, сервер сначала вешает лок на соответствующие объекты (на этого оператора) посредством curl-запроса на некий внутренний URL, на котором отвечает простенький скрипт с memcache за ним, и только если запрос вернул OK, это действие выполняется. Таким образом, к примеру, оператору не может поступить несколько новых звонков из очереди одновременно с разных серверов, но и нет необходимости синхронизировать между машинами полностью всё их состояние.

    Оператор в свою очередь имеет на своём столе VoIP-телефон, у некоторых Soft-Phone, но это не приветствуется. При Soft-Phone страдает качество, нет нормального звонка и, если агент снял наушники и отвернулся от экрана (пьёт чай), он может пропустить звонок. Кроме того, тогда нужно более дорогое железо для компа агента (сейчас это low-end бездисковые станции на базе ubuntu, ~300$ за комплект) и заметно сложнее (а следовательно дороже) становится поддержка. Поддержка на Soft-phone дороже потому, что железные телефоны, в отличие от Soft-Phone, получают IP-адреса и ссылку на свою конфигурацию по DHCP. Конфигурацию им отдают всё те же сервера на Амазоне, после чего телефоны радостно и полностью самостоятельно регистрируются на серверах через VoIP-прокси стоящий в локалке. То есть работа по ручной настройке сведена почти к нулю (спасибо provisioning-у, который поддерживают все телефоны, что мы используем). Почти вся поддержка — это просто замена телефона. Софтверные же телефоны, как показала практика, в масштабах компании съедают довольно много времени на консультации пользователей, установку и настройку, решение проблем то со звуком, то ещё с чем-то, в общем 600 человек может создать нескончаемый поток проблем, если дать им инструмент для их создания… :)

    Всё общение телефона с внешним миром происходит только через VoIP-прокси (+ прозрачный HTTP-прокси, для получения конфига). А вот VoIP-прокси уже общается с серверами на Амазоне, которые в свою очередь общаются только со со списком заранее прописанных на них проксей, с провайдером, и ни с кем более.

    VoIP-прокси представляет собой тот же астериск, только в максимально упрощённой конфигурации: максимально упрощено и выкинуто всё что можно, его задача только пропускать траффик между телефонами и серверами через себя, пропихивая его через jitter-buffer (заметно повышает качество, когда траффик гуляет через пол-глобуса), снимать часть нагрузки с серверов (и траффика) общаясь с телефонами локально, отвечать на всяческие тесты для отлова проблем, ну и всякая мелочь. Это же точка входа для операторов, работающих из дома (как правило линки домашних пользователей до Амазона заметно менее стабильны и быстры чем наш офисный, а вот линк до ближайшего офиса обычно в пределах той же страны и как правило очень хорош) для улучшения качества и упрощения схемы (все телефоны только через прокси). Кроме того, это ещё и «первая линия обороны». Хотя в ближайшем будущем мы скорее всего всё же перейдём на VPN подключения для таких пользователей, благо сейчас это уже не так дорого в плане железа как 5 лет назад.

    Сами телефоны полносью взаимозаменяемы и практически не требуют ручной настройки: надо только присвоить ему IP и тип в DHCP, после чего всё происходит само: телефон получит IP и ссылку на конфиг, скачает его, затем, уже зная что и где, зарегистрируется через прокси на серверах. При этом новые телефоны автоматом получают некий новый внутренний номер (extention). Звонки с этого номера делать нельзя, звонки на него тоже не поступят, он может делать только некоторые совсем базовые вещи, среди которых возможность севшему за него оператору залогиниться на этот аппарат своим личным телефонным номером, после чего звонки для номера этого оператора начнут поступать именно на этот аппарат, и перестанут поступать туда, куда поступали раньше (если же оператор не залогинен нигде — звонки идут на его голосовую почту). Если по аналогии с сетевыми технологиями, extention телефона — это что-то вроде MAC-адреса, на который, после логина оператора вешается нечто вроде IP адреса — личный extention оператора. Таким образом достигается отвязка логики работы колл-центра от его физической составляющей: вся бизнес логика, отчёты, приоритеты и прочее производятся с extention-ом оператора (который по сути своей не является чем-то физическим, это скорее логический объект), extention самого аппарата — это просто точка, где в данный момент залогинен этот оператор.

    Несколько слов об отказоустойчивости.

    Общение с провайдером телефонии, как уже упоминалось, имеет механизм failover'a с их стороны. К сожалению нет фейловера в плане самого оператора. Во первых не так уж много самих операторов, способных предоставить всё что нам нужно, качественно, с поддержкой да ещё и по разумной цене. Во вторых, в телефонии, в отличие от IP-сетей, так просто, одним движением роутера на другого провайдера не перейдёшь. Перевести свои номера на другого провайдера — это время и деньги, не много, но при примерно 1500 номерах, это уже пара суток и ощутимая сумма денег на каждое переключение — дешевле дождаться решения проблемы. К счастью (к чести телефонистов) сбои у них бывают очень редко и очень ненадолго. Так что провайдеров дающих входящие звонки только два, один в США, один в России.
    Cервера (астериски) всю, какую только можно (и немножечко остальной) конфигурацию кладут и читают как «realtime» в/из MySQL. Дабы заметить изменения сделанные другими серверами и через веб-интерфейс. Сначала это немного глючило, а астериск падал раз в несколько часов, но после нескольких патчей нам удалось сделать его более-менее стабильным. Таким образом, какая бы нода и каким бы образом ни сделала изменения в конфиге, следующее действие, зависящее от этого места конфига все ноды делают уже зная об изменении.
    Каждые несколько секунд все ноды пишут своё состояние (количество звонков, load average, активные сервисы, и т. п.) в MySQL. Соответственно, ноды которые распределяют звонки, на основании этих данных определяют которые из серверов онлайн и кому лучше отдать звонок (а нагрузка меняется довольно плавно). Таким образом, пока жив mysql и хоть одна из основных нод, звонки будут идти, всё будет работать и нагрузка будет распределена почти поровну между доступных машин (± небольшие пики, но как правило всегда есть некий запас). Если же, по какой-то причине, нагрузка на ноде начинает превышать некие разумные пределы, нода (посредством простеньких скриптов) сама начинает останавливать или блокировать на себе некоторые менее важные сервисы, дабы не допустить потери качества и стабильности собственно звонков. Так, например, первыми становятся недоступными всяческие тяжёлые отчёты.
    В качестве MySQL у нас амазоновский RDS с включенным Multi-Availability Zone. И конечно же собственные off-site бекапы. В теории — если RDS Instance умрёт, всё должно переключиться само и без нашего участия. Не знаю, происходило ли это на практике или нет, уведомлений не получали, но пока всё работает как часики. Но даже если RDS умрёт совсем, в течение получаса можно снова запустить всё с ближайшего бекапа. Не будет статистики и логов (коей террабайты) и следовательно часть отчётов будут неверными, но вся конфигурация будет не старее полутора часов (ибо она-то как раз весьма компактна).
    VoIP-прокси в офисах у нас стоят на роутерах под Linux. Роутеров 2 в каждом офисе, с heartbeat'ом запущенным между ними. Если один дохнет — все сервисы (включая и VoIP прокси) тут же начинают работать на втором роутере с тем же IP.
    Провайдера у нас тоже 2 в каждом офисе. Если один дохнет/глючит — переходим на второго. Тут начинаются проблемы с регистрациями телефонов — IP ведь меняется (сервер должен знать на какой IP посылать звонки). Для этого каждый прокси раз в минуту ходит на сервера на Амазоне на некий специальный URL в веб-админке и рассказывает, что «мой текущий IP такой-то». С той же стороны, скрипт сравнивает это значение с тем что в базе и, если вдруг оно изменилось, обновляет в базе всё что с этим связано (напрмер текущие регистрации телефонов). Так как большая часть конфигурации realtime — уже следующее действие над многими объектами будет оперировать верным IP — звонки в/из этого офиса снова пойдут.
    Вся эта конструкция (сервер со всем софтом, voip-proxy, и т. п. у нас оформлены в виде проектов в svn со своими инсталляционными скриптами, и разворачивается на свежем чистом линуксе просто методом svn checkout … && ./install.sh. Конечно требуется некое количество конфигурации, но оно довольно мало. Для серверов же на Амазоне есть ещё и up-to-date снепшоты, из которых можно быстренько развернуть +1 основной либо дополнительный сервер.
    На каждой ноде есть apache+php и полный набор php скриптов и в плане веба все ноды полность идентичны (все ходят в один mysql, все используют memcached на основных нодах). Управлять и смотреть в realtime что происходит со всей этой конструкцией можно через веб-интерфейс на любой из машин. Веб интерфейс работает с тем же MySQL. Кроме того, некоторые команды посылаются asterisk-у на нужной ноде напрямую. Например «хочу послушать о чём говорят сейчас вот этот оператор и клиент» в веб-панели руководителя группы или департамента контроля качества (что незаменимо при обучении новых операторов и отлове недобросовестных — с деньгами же работаем).
    На отдельном маленьком инстансе крутится nginx, который разруливает все внешние запросы к вебу (авто-конфигурация телефонов, обновление IP от проксей, доступ к админке/статистике) на реальные сервера. У этого инстанца есть снепшот и есть скриптик, который за несколько секунд может поднять новую такую же машину и навесить на неё старый IP, ежели будет такая необходимость. Эта машинка настолько простая и примитивная, что глючить и дохнуть там просто нечему, кроме железа. Последнее и решается вышеупомянутым скриптиком (пока кроме как для теста ни разу не применяли).
    Ну и естественно мониторинг всего и вся с уведомлениями на э-мейл и на смс (о критичных ситуациях). Мониторим с помощью NetXMS + кучи самодельных скриптов, для сбора информации о компонентах всей этой конструкции.

    О нагрузке.

    Как ни странно, основную нагрузку создают вовсе не разговоры. Собственно разговоры с клиентами — это 15-25% нагрузки. Очень ресурсоёмкие действия с точки зрения астериска, это прежде всего music on hold и IVR. Когда клиент общается с оператором астериск всего лиш прокидывает траффик. Когда же клиент в очереди и слушает музыку и заверения в том как он важен и ценен, всё это время мы для него на лету создаём этот поток аудио. Если мы имеем 50 человек в очереди — мы вынуждены на лету создавать 50 потоков аудио для них, и уже эти потоки слать клиентам (это упрощённо, на практике часто это разные очереди, разные IVR, и т. п., то есть один поток им всем сразу не отдашь, как делали на некоторых телефонных станциях).

    Довольно дорого обходится конвертация записей звонков (или голосовой почты) в mp3. Но если есть желание слушать это в браузере / на рабочем компе, а не только с телефона — то от этого не уйти. А желание есть. Да и место на дисках опять-таки экономится.

    Ещё дороже обходится веб-интерфейс. Всяческие отчёты и realtime-статистика — это чёрная дыра по ресурсам. Везде где только можно понатыкано море agi-шек, которые пишут логи и собирают статистику для её дальнейшего использования во всяческих отчётах. Порядка 5MB разных данных на звонок, включая полный SIP-Trace звонка на случай, если что-то было не так.

    Когда всё это обработано, можно получить море полезной информации. «Из каких штатов звонили этому агенту в вечернее время за последние 3 месяца?», «каков % пропущенных звонков у вот этого департамента?», «который раз нам звонит этот клиент в этом месяце?», «какой средний процент потерь SIP-пакетов при звонках в Пакистан?» и так далее.

    Каждая внутренняя система компании (CRM, управление рекламой, фронтеды) запрашивает периодически всяческую realtime статистику. Например фронтенд проекта yaturist.ru показывает телефоны по которым можно поговорить с оператором только в том случае, когда очередь звонков этого проекта в данный момент обслуживает хотя бы 1 агент. В остальных случаях показывается формочка для подачи заявки в электронном виде.

    Админка каждого проекта тоже может делать массу нетривиальных вещей через XMLRPC вызовы. Например, агенты которые лучше обслуживают клиентов получают больший приоритет при обслуживании очереди, но, после обработки некого дневного лимита продаж, получают меньший приоритет и получают звонки только если никого больше не осталось. Таким образом, им приходится более основательно работать с каждым клиентом, а не «брать за счёт оборота». Звонки VIP-клиентов, поступают только операторам имеющим право с ними работать, а если их нет на месте — то лучшим операторам из имеющихся онлайн. И всё это, на основании постоянно запрашиваемой статистики постоянно «подкручивается» из недр этих самых систем посредством кучи XLMRPC запросов, постоянно («на лету») “подкручивая” конфигурацию астериска (в MySQL).

    Если запретить отчёты и показ статистики, отключить запись разговоров / голосовую почту и music on hold, временно заблокировать XMLRPC, по идее, даже в пиковое время, мы могли бы запустить это всё на одной ноде, и ещё остались бы ресурсы. Но… если бы мы это сделали бы, это потеряло бы смысл, ибо, по моему мнению, астериск как раз и прекрасен возможностью создания таких глубоких интеграций с бизнес-нуждами, которые можно постоянно «докручивать» одновременно с развитием компании. Как показала практика — это платформа, на базе которой можно построить что угодно, начиная от мини-атс на 3 человек, и до огромных инсталляций почти любого уровня сложности.

    Заключение

    Это скорее обзорная статья, многие технические детали остались «за кадром». Мы все слишком разные, я не знаю что именно Вам будет интересно. Если есть интерес к этой теме, задавайте вопросы. С удовольствием отвечу или даже опишу заинтересовавшие технические детали в отдельной статье.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 58

      0
      Так почему же всё-таки амазон, если (судя по схеме) сами проекты у вас не на амазоне?
        +1
        — Multizone RDS
        — Возможность быстро добавить ещё ноды, ежели не справляются (snapshot + new instance + 2 минуты на настройку).
        — «Резиновое» место под бекапы на S3.
        — Возможность «расставить» все ноды в разных регионах (дополнительная защита от отказа датацентра).
        0
        а что это у вас картинка такая профессиональная, Вы дизайнер что ли?
          +3
          Нет. Но должность позволяет использовать иногда наших дизайнеров немного «налево», если сильно не наглеть. :)
          0
          Очень интересно и складно написано, читается на одном дыхании! Все бы так писали. ;) Хотелось бы еще узнать поименно что прикручено к астериску, сколько это писалось или настраивалось, ну короче — чуть-чуть шире.
          На картинке видно домашних и офисных агентов — зачем и те и другие? Не проще перейти на один формат, туда или сюда, опять же поддержка будет одинаковой/проще/дешевле?
            +1
            Посредством realtime интерфейсов астериска (curl и mysql) обеспечивается моментальное отслеживание изменений конфигурации и частично взаимодействие между нодами и между прокси и серверами.

            Посредством agi обеспечивается порядочная часть бизнес-логики (в свою очередь опять-таки взаимодействует с MySQL) и сбор информации / статистики.

            Через asterisk management interface конкретным нодам посылаются всяческие команды и опять-таки получаем некую информацию / статистику.

            Написанная на php админка, используя вышеперечисленные методы и данные, позволяет этим всем управлять и пользоваться, а так же мониторить в реальном времени. Какой конкретно интерфейс используется для чего зависит просто от удобства реализации конкретной задачи.

            Кроме того эта же админка через xmlrpc експортирует довольно широкий API, c которым в свою очередь взаимодействуют все остальные наши сисмемы. Этот API развивался и рос (и продолжает расти) почти с самого начала фирмы, около 6 лет. На данный момент это более 50 разных функций, почти каждая имеет свои вариации в зависимости от переданных параметров.

            Этим API в свою очередь пользуется около десятка фронтендов, 4 бекенда, а также firefox плагины на операторских машинах и всякие утилитки. Например в залах где сидят операторы висят телевизоры, показывающие всяческую статистику и (запрашивая это через xmlrpc) состояние очередей, в результате чего периодически поднимают панику и привлекают внимание, когда слишком много клиентов висит в очереди. Мол «соберитесь уже и обслужите».

            Далее, как правило все операторы сидят в офисе, ибо за многими нужен глаз да глаз. :) Но некоторым особенно хорошим (и доверенным) дозволено работать из дома, что повышает им уровено комфорта и мотивацию, освобождает места в офисе и создаёт головную боль HelpDesk'у. Кроме того, руководство и многие другие ключевые персоны тоже нужны на связи не только в офисе. Так что и хотели бы унифицировать, да нельзя.
              0
              можете подробнее рассказать, как вы через asterisk management interface получаете статистику о качестве звонка? потеряные пакеты звука, как колебался джиттер.
                0
                Конкретно эти данные, если мне не изменяет память, мы получаем не через management interface, и из полного лога с дебагом, парсим, дёргаем оттуда всё что нам рассказывает RTCP по id звонка и складываем в базу.
                  0
                  RTCP мало что полезного несет о именно звонке. Это скорее качество связи до пира. А А-абонент от него может быть далеко.
                    0
                    Звучит логично, но с другой стороны эта информация у нас тоже есть, так как точно помню, пару раз мы её использовали. Уточню у человека, который именно этой частью у нас занимался и отпишу позже.
                      0
                      Ну вот всякие железные железки умеют для каждого звонка считать MOS, анализируя голосовой тракт. И если абонент например звонит с GSM телефона в зоне плохого покрытия, то качество звонка будет соответствовать реальности. Что потом можно анализировать, использовать дял маршрутизации и т.д.
                      Астериску такое не по зубам, так как нужны хитрые DSP. Обычный CPU тут загнется на втором десятке.
                        0
                        Таки то что было в сети провайдера оказывается просто запрашивали у самого провайдера.
            0
            Скажите, а есть у ли у Вас план на случай, если навернется какой-нибудь из asterisk-прокси? Есть ли у телефонов возможность использовать другой прокси, если основной не отзывается?
              0
              В статье есть об этом — в каждом офисе 2 прокси, связанных heartbeat
                0
                Да, как уже упомянул AndreyNagih, в каждом офисе всё резервировано. Если одна машина с прокси выйдет из строя — вторая подхватит всё на себя совершенно прозрачно для телефонов.
                0
                > Кроме того, это ещё и «первая линия обороны».
                Часто сканят? И как боретесь?
                  0
                  Сканят каждые пару дней. Если в общих чертах, принцип примерно такой: анализируя логи проксей и серверов, вылавливаем подозрительные действия, типа подбора паролей, смены IP телефона, нескольких одновременных SIP-сессий с одного телефона и т.п. (полный список приводить не буду, дабы не накликать беду).
                  Далее, соответственно, либо блокировка по IP, либо логоффим оператора (его личный extention) с данного конкретного телефона (после чего для злоумышленника он становится бесполезен, ибо звонить с него, не будучи залогиненым как оператор, нельзя).
                  Есть ещё механизм лимитов для разных групп операторов на разные типы звонков и действий. Но это всё скорее относится к первой части — подозрительные действия.
                    0
                    Извините, не туда ткнул, это был ответ на вопрос от floor.
                    –2
                    Охохо, наворотили. Но до профессиональных систем далеко.
                    Например на астериск никак не избежать сброса активных звонков при вылете одного из серверов. И такой фичи там не будет скорее всего никогда. Не того уровня «продукт».
                      0
                      О каких именно профессиональных системах идёт речь? Было бы интересно посмотреть подробнее. Может что-то позаимствуем.
                        0
                        Да много их, начиная от генезиса и заканчивая акме-пакетом. Подробнее вы их вряд ли увидите, это штучный товар. Но если поискать, то можно найти клоунов в каком-нибудь интеграторе, которые вам слайдов покажут.
                          0
                          Спасибо, по названиям нашёл пару человек знакомых, кто с ними работает. Появился повод пообщаться за кружечкой пива. :)
                            0
                            Freeswitch это уже давно делает кстати.
                      • UFO just landed and posted this here
                          0
                          Со стороны провайдера просто стучатся по очереди на 4 наших IP пока 1 из них не ответит. С нашей стороны — сами астериски (точнее скрипты на каждой ноде) каждые несколько секунд собирают и кладут в базу состояние ноды (активные сервисы, количество звонков и нагрузку), а нода, которая получила звонок, прежде чем обработать или передать соседу (agi-скриптик) смотрит эту информацию и решает кто будет обрабатывать звонок. Плюс есть ещё мониторинг, который может некоторые из этих данных в базе менять.

                          Соответвственно если какая-то нода выпала — это будет заметно по устеравшим данным в базе либо по изменениям внесённым туда мониторинг-скриптами.

                          Прокси, в свою очередь, запрашивают для себя активные ноды curl'ом (realtime), а дальше тот же механизм, что и с провайдером.
                          0
                          Как у вас обеспечивается связывание пришедшего звонка к оператору (на аппаратный или софт-телефон) и CRM-системы или ещё чего-то, для работы оператора именно с этим звонком? И производится ли дальше каким-то образом контроль за звонком (отключился, перевели, и т.д.) со стороны используемой CRM?
                            0
                            Каждому звонку в момент эго начала присвивается некий уникальный внутреренний ID который тянется за ним потом до самого завершения. Всё что можно по этому звонку, все его переходы по очередям, между агентами, между серверами — всё пишется в логи и/или в базу. Следовательно проследить всю его историю нет никакой проблемы.
                            В момент звонка мы точно знаем на extention какого агента он попал, extention привязан к учётной записи оператора в системе. Сооответственно в момент звонка на этот еxtention у этого оператора автоматом выскакивает попап с номером звонящего и тем что мы про него знаем ну и/или автоматом заполняются некоторые поля (забыл упомянуть, что админка asterisk'a у нас не только експортирует широкий API, но и на определённые группы звонков активно дёргает соответствующие API в других наших админках). Кроме того, в некоторых менее тривиальных ситуациях у нас всё ещё есть номер звонившего, время звонка, номер на который он позвонил и вся история по предыдущим звонкам с этого номера, что позволяет допривязать часть «потерянных» звонков позже, обработав эти данные. Так же клиент иногда диктует другой номер телефона и/или Discount ID который был выдан лично ему на одном из FrontEnf-ов. Всё это тоже может быть позже использовано для привязки звонков к клиентам и продажам.
                              0
                              И да, анализ что произошло со звонком производится. Так, например премиальные операторов могут ментяться (или даже налагаться штафы), если слишком много пропущенныз звонков, или оператор кладёт трубку первым слишком часто.
                            0
                            Расскажите пожалуйста, чем вы реализуете SIP-redirect. На ум приходит только трансфер звонка.

                            Сейчас строю чтото подобное и понял, что от астерисков надо уходить, и ставить во главе угла какойнить opensips либо kamailio, там делать все регистрации и принятие решений, а астериск либо аналог использовать только для медиа ( трансляция кодеков, ИВР, автоответчик и тп. )
                              0
                              Да, именно трансфер и делаем. В результате провайдеру уходит SIP/2.0 302 Moved Temporarily и он идёт туда, куда его послали.

                              Если я помню верно, opensips либо kamailio — одно и то же, они то сходятся, то расходятся… К тому же это чистый SIP, если я ничего не путаю. Оба проекта пока ещё более слабые технически (хотя и с лучшим маркетингом).

                              В случае того же астериска мы активно пользуемся ещё и IAX (что даёт заметный выигрыш по ресурсам). Да и community у астериска поболе будет. У нас конечно «исторически сложилось» (мы начинали, когда OpenSER был ещё младенцем), но и сейчас выбрали бы всё же астериск.
                              0
                              Не так давно (в мае) на форуме замечательного продукта 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.
                                0
                                Как я уже писал в самой статье — основная нагрузка это не PBX (не switching) а как раз «навороты» (music on hold, IVR, интеграция с CRM, сбор статистики, конвертация записей в MP3 и отчёты). Так что сравнение, вероятно не совсем корректно.
                                Но сам FreeSwitch, ИМХО, продукт довольно интересный. Мы тоже с ним играемся, некоторые вещи он делает лучше астериска. Например работу с Google Talk.
                                +1
                                Если не секрет какии VOIP аппараты используете?
                                  0
                                  В основном GrandStream BudgeTone 100, 200 и Cisco SPA 303. Есть ещё немного экзотики, но это так, в порядке эксперимента.
                                  0
                                  Скажите, что у вас за VoIP-оператор?
                                    0
                                    В US — WCI, в RU — Zebra.
                                    0
                                    Потрясающе! Снимаю шляпу!
                                      0
                                      Спасибо!
                                      0
                                      Спасибо, очень познавательно.
                                      Сколько же человека-ресурсов положено на алтарь этого решения…
                                        0
                                        Примерно 30 000 человеко-часов со стороны админки VoIP части и думаю в несколько раз больше со стороны проектов eё использующих. Но, если учесть, что бизнес у нас строится вокруг call-центров и это наш основной инструмент, то это того стоило. Именно благодаря этим часам ма продолжаем расти и зарабатывать.
                                          0
                                          Пардон. "… часам мы продолжаем ..."
                                        0
                                        Спасибо, действительно интересно почитать. Но из статьи не понятно, у вас тиражируемый продукт, или это решение развернуто у единственного заказчика?
                                          0
                                          Это внутренний продукт. Даже не продукт, а решение-интеграция под нужды конкретно нашего бизнеса.
                                            0
                                            а что мешает убрать интеграцию с вашими внутренними системами, добавить красивых оберток и предложить его как отдельный продукт (решение)?
                                              0
                                              Технически — ничто не мешает. Но это отдельное направление бизнеса, на это нужны ресурсы. А таковых и так нехватка. Так что получается, что приоритеты мешают. Да и потом, без интеграции с нашими системами это будет просто кластеризованный астериск с фантиками, а таких решений и без нас хватает.
                                          0
                                          Какие линукса используете для астера? CentOS, Ubuntu/Debian?
                                            0
                                            Amazon Linux (на базе Fedora 8) и Ubuntu (10-12).
                                            0
                                            как вы мониторите операторов которые сидят из дома что у них связь с сервером нормальная и для клиетов приемлимо слышно?

                                            jitter buffer всегда используете? ведь он тоже сервер нагружает?

                                              0
                                              Операторы работают с нашим VoIP proxy, а там у нас есть все логи, как на оператор<->прокси, так и на прокси<->сервера. Из полного дебаг-лога астериска довольно много можно надёргать. Кроме того, операторы сами жалуются на качество, так как они не на зарплате, а на проценте + надбавки/убавки за эффективность и плохое качество весьма мешает им зарабатывать, а вовремя заявленное плохое качество может быть принято во внимание при рассчётах.

                                              Jitter-buffer используем всегда на линке прокси<->сервера и сервера<->провайдер потому как там почти всегда есть и неравномерные задержки и частенько перестановка пакетов. Дешевле платить за ресурсы, чем терять клиентов из-за «А? Что? Не расслышал!», а при его размере в 50ms задержка голоса всё ещё небольшая.
                                              0
                                              500 операторов на линии постояно? или это всего экстеншинов столько?

                                                0
                                                ~600 операторов «наготове». Одновременно говорящих в пиковое врема около 200. Ещё около 100 клиентов может быть во всяки Voice-Menu или очередях под музыку — а это куда более ресурсоёмко чем все разговоры вместе с Jitter-Buffer-ом.
                                                0
                                                Очень интересно, спасибо.
                                                У вас есть сайт?
                                                Подключаете ли сторонние колл-центры?
                                                  0
                                                  Сайт есть и не один, один из них я даже упомянул в статье. К сожалению не совсем понял суть Вашего вопроса, Вы хотите связаться или посмотреть другие проекты или что-то предложить или что-то ещё?
                                                  0
                                                  > Из полного дебаг-лога астериска довольно много можно надёргать.

                                                  Можно поподробней?
                                                    0
                                                    Подробней это реально долго… Полный дебаг лог астериска + куча дополнительной отладки и дампа переменных и состояний в каждом agi-скрипте — это 3-5 MB лога на каждый звонок.
                                                    0
                                                    Ёлки палки, я что то такое же создал как и вы, конечно примерно, деталей туча, только ушло 3 года, поделитесь сколько человек работало над этим?
                                                    Правда у меня система другая, я раздаю звонки через опенсипс на котором есть логика очереди, а медиа серверы просто играют музыку, я так прикинул и вышло что могу 5000 человек без особых напрягов, а если подумать то и больше.
                                                      0
                                                      В разное время от 1 до 5 человек разной квалификации.
                                                      0
                                                      Image:
                                                      image

                                                      Only users with full accounts can post comments. Log in, please.