Платформы облачных коммуникаций начали появляться давно. То, что началось с REST API для SMS / MMS, вскоре перешло в сферу голосовых и видеозвонков. WebRTC оказался большим ускорителем этой эволюции; проект помог решить сложные вопросы, связанные с обработкой мультимедиа на стороне клиента, и предоставил бесплатную технологию с открытым исходным кодом (и стандарт), над которой все еще работают и совершенствуются каждый месяц.

Технологические гиганты, такие как Google, Cisco и Microsoft, объединили усилия для создания технологического стека, который нравится разработчикам. Мы тоже участвовали в этом процессе, но когда мы начали работать над платформой VoxImplant в 2012 году, мы решили, что отличаться от других игроков на рынке - хорошая идея. Это означало не только отличаться от наших цен / маркетинга, но и предлагать технологии, которые, по нашему мнению, действительно будут иметь значение для разработчиков.

Обработка звонков

Если вы знакомы с такими платформами, как Twilio или Plivo, то знаете, что обработка вызовов выглядит довольно похоже. Вы либо пишете определенный XML (TwiML или Plivo XML), либо пишете код, который генерирует определенный вид XML. Затем их серверная часть связывается с вашей серверной частью, чтобы понять, что делать, когда на платформу поступает вызов либо из PSTN, либо из SIP / SDK. (И те из вас, кто знаком с VoIP, все еще помнят VoiceXML.)

Этот подход может работать, но мы утверждаем, что у него есть ряд серьезных недостатков. К ним относятся:

  • Множество ненужных взаимодействий между серверной частью платформы и веб-службой разработчика.
  • Если что-то пойдет не так, будет намного сложнее обработать вызов каким-либо образом (или завершить его изящно).
  • Это требует генерации XML, что некрасиво (конечно, поставщики предлагают ряд оболочек для всех языков, чтобы помочь с этим)
  • Отладка == проверка логов запросов
  • Существенная нехватка гибкости для сложных сценариев.
  • Требуется больше ресурсов на уровне веб-сервиса.
  • Вы столкнулись с более длительным сроком вывода на рынок

Мы решили использовать возможности механизма облачных приложений, чтобы избежать этих проблем и предоставить разработчикам гибкость, которой они заслуживают. Учитывая, насколько популярным стал JavaScript, для нас это было несложно. Мы выбрали JavaScript в качестве языка, на котором написаны сценарии управления вызовами. И затем мы дали нашему движку имя: VoxEngine.

Большинство веб-разработчиков хорошо знакомы с JavaScript, и многие из них также знакомы с Node.JS. В нашем случае, однако, он работал не так, как Node.JS, поскольку, когда на платформу поступает вызов, нам нужно начать сеанс. И в контексте этого сеанса разработчик решает, что делать с вызовом (перенаправить его куда-нибудь, включить запись вызова, сделать http-запрос к некоторому внешнему веб-сервису для получения данных и т. Д.).

Сценарий VoxEngine выглядит как стандартное приложение JavaScript. Он имеет обработчики событий (события запускаются асинхронно), и доступен полный набор функций ECMA5, а также определенные классы и функции VoxEngine, которые позволяют разработчикам управлять вызовами и использовать различные функции платформы, такие как запись, конференц-связь и т. Д.

См. Пример ниже:

Этот подход позволяет добавлять бизнес-логику в сценарии управления вызовами. Однако это не означает, что вам нужно злоупотреблять этим, поскольку сеанс VoxEngine имеет свои собственные ограничения с точки зрения того, сколько памяти и ресурсов можно выделить для его обработки. Во многих случаях вы поймете, что усилия по разработке значительно сокращаются, а время вывода продукта на рынок сокращается.

Обработка звонков происходит на медиа-сервере в режиме реального времени и контролируется со стороны движка приложения. Таким образом, мы могли бы реализовать отладчик реального времени, аналогичный отладчику JavaScript, который вы можете использовать в любом современном веб-браузере.

Независимый контроль для каждой ветви звонка

В контексте сеанса VoxEngine каждый объект вызова представляет соединение между платформой и некоторой конечной точкой (pstn, sip, sdk), которой можно управлять независимо. Таким образом, у вас обычно есть один входящий вызов на сеанс (если сеанс не запускается через HTTP API или если это не сеанс конференции), и вы можете иметь любое количество исходящих вызовов. Входящие и исходящие аудиопотоки объекта вызова также могут управляться независимо.

Почему важна гибкость

Мы начали получать запросы от разработчиков, которые хотели реализовать особенно интересные и необычные сценарии, в которых стандартные подходы, предлагаемые большинством поставщиков CPaaS, не работают. Гибкость и набор функций VoxImplant помогли решить их проблему. В список входят, например, объединенные аудиоконференции для услуг, подобных рации.

Хотя изучение архитектуры и шаблонов разработки VoxImplant может занять некоторое время, разработчики вскоре используют платформу для (быстрой) реализации очень сложных сценариев. Мы считаем, что облачные платформы для разработчиков 21 века должны быть одновременно мощными и гибкими, и мы продолжим добавлять функциональные возможности, чтобы и дальше продвигать VoxImplant в этом направлении.