Заглядывая в разработку программного обеспечения IVR
Компания, в которой я работаю, ищет реализацию IVR, которая была бы в высшей степени совместима с любой потенциальной комбинацией PBX/IVR или PBX ИЛИ для обеспечения нашего собственного хостинг-решения.
Поэтому идея состоит в том, чтобы создать приложение, которое взаимодействует с любой потенциальной платформой и обеспечивает управление вызовами и голосовой диалог / взаимодействие для IVR.
Технологии, на которые я смотрел до сих пор (мы хотели бы использовать Java): API телефонии Java (JTAPI), API JAIN-JCC (Java Call Control) и другие. Основная суть этих API имеет для меня смысл, но что я не могу собрать, так это то, как именно приложение, которое я бы создал для управления вызовами и голосового IVR / VXML, взаимодействовало бы независимо от платформы для телефонной системы. Как именно я могу получить звонок от телефонной системы?
Похоже, что эти API и библиотеки оставляют этот вопрос без ответа, что наводит меня на мысль, что независимое от платформы решение невозможно и что оно всегда будет зависеть от конкретной реализации. Есть также JAIN-SIP, если я могу преобразовать все вызовы в SIP, то, возможно, я смогу создать общее приложение для управления вызовами / IVR таким образом.
Если я здесь произнесу какие-то невежества или недоразумения, пожалуйста, прости меня, я абсолютно новичок в любой телекоммуникационной технологии - кто-нибудь, кто хочет, чтобы меня поправили? Я был бы очень очень благодарен, связи на уровне реализации детализации очень и очень нечеткие, и иногда мне нужно немного подержать руку. Любая помощь или толчки в правильном направлении будут полезны.
Я поливал спецификации и API на прошлой неделе.:)
РЕДАКТИРОВАТЬ - я забыл упомянуть, что мы предпочитаем разрабатывать это в домашних условиях, если это вообще возможно и разумно с точки зрения затрат / выгод - на самом деле не нужно тратить деньги на интегрированную платформу, если это вообще возможно - это моя работа:)
5 ответов
Я работал на VoiceGenie несколько лет назад: они создали (я использую прошедшее время здесь только потому, что я не знаю, что они делают сейчас, а не потому, что они больше не делают этого) движок VoiceXML, который:
- Это коробка Linux
- Подключены сторонние механизмы преобразования речи в текст и преобразования текста в речь (путем взаимодействия с API, специфичными для Engine)
- Интерпретирует VoiceXML (используя собственный синтаксический анализатор VoiceXML) и выполняет его, используя сторонние механизмы преобразования речи в текст и преобразования текста в речь
Они наняли меня для сопряжения их устройства с системами управления вызовами: и первой системой, для которой я это сделал, была Cisco (и наоборот, я вижу, что VoiceGenie теперь принадлежит Genesys). Их движок также поддерживал приложения, отличные от VoiceXML, например, предоставлял интерфейс приложений Java.
В заключение:
- Различные телефонные системы имеют собственные API для управления вызовами; и / или они могут поддерживать стандартные протоколы управления вызовами (например, SIP) и / или API (например, JTAPI, TAPI, CCXML) и, если они это делают, делают это более или менее хорошо.
- Вы можете найти сторонние механизмы (например, Genesys Voice Platform, Microsoft Office Communications Server и другие), которые предоставляют вам некоторый унифицированный API, а также обрабатывают и поддерживают (или не поддерживают) взаимодействие с другими компонентами.
Я не менеджер по продукту, системный инженер, сетевой архитектор, специалист в этой области.
НО все они обычно поддерживают несколько протоколов и API
Некоторые поддерживают только проприетарные, рекламные / или некоторые поддерживают один или несколько стандартов.
Таким образом, идея состоит в том, чтобы взаимодействовать с API или протоколом, который поддерживается наиболее.
Я бы поставил под сомнение экономическое обоснование для этого, но я считаю, что вам следует найти и поговорить с инженером телефонии, который обладает конкретными знаниями в области и знанием продукта / реализации. Я столкнулся с тем, что написал выше, работая разработчиком программного обеспечения, но у меня нет опыта в предметной области.
Это будет SIP?
SIP - это протокол, а не API. Этот материал находится в слоях, например, как приложение, которое вы можете использовать:
Нижний уровень: стек протокола SIP с собственным API; вы используете этот API, понимаете, как выглядят SIP-диалоги, и общаетесь (только) с системами, которые понимают SIP
Более высокий уровень: механизм VoiceXML/CCXML (или механизм TAPI или JTAPI); вы пишете XML (или используете API-интерфейсы TAPI и JTAPI); и механизм (в зависимости от того, какой это механизм) может иметь встроенный стек SIP, который он использует для связи с компонентами, использующими SIP, и / или он может иметь другие стеки протоколов для компонентов, которые используют другие (не SIP) протоколы,
У Cisco был только один (собственный) протокол, который я мог использовать, чтобы общаться с их системой "Интеллектуального управления контактами" (т.е. центра обработки вызовов). И у Genesys, я думаю, был закрытый, проприетарный API/ протокол.
Если это так, то будет ли мое решение по управлению вызовами и IVR лучше всего реализовано в качестве интерфейса SIP для приложения JTAPI или какого-либо варианта?
Я запутался в том, что вы хотите сделать, где в стеке вы хотите быть (не то, чтобы я мог сказать что-нибудь полезное, если бы знал).
Я думаю, что, возможно, вам следует поговорить с продавцами: выяснить, что они могут сделать для вас (если вы не пытаетесь завершить их, что было бы трудно).
Можете ли вы сузить, что означает "любая потенциальная комбинация PBX/IVR или PBX"?
Я работал в этом пространстве в течение ряда лет. Ответ ChrisW очень хорош. Вот некоторая дополнительная информация, которая может быть полезна людям в подобных ситуациях.
Я предполагаю, что вы предлагаете исходное решение, поскольку большинство ваших проблем интеграции исчезают, если вы размещаете свое приложение. Если вам нужно сменить оборудование и вы изолировали логику телефонии от диалога и бизнес-логики, перевод не должен быть слишком сложным.
Проблемы интеграции IVR/PBX проявляются по-разному:
Телефония:
Под телефонией я имею в виду управление вызовами первой стороны. Особенности телефонной линии.
- Информация о прибытии звонка (ANI/DNIS). Предполагая, что вы работаете на более высоком уровне, таком как VoiceXML, у вас все еще могут быть различные проблемы. Лишь некоторые:
- Существование данных. Не все коммутаторы предоставляют эти данные. Что еще хуже, данные могут быть доступны только при определенных конфигурациях коммутатора. Эта конфигурация может конфликтовать с другими потребностями (переносами) вашего приложения или колл-центра.
- Формат данных. В зависимости от вашего приложения, это может быть или не быть проблемой, но формат данных может немного отличаться от коммутатора к коммутатору.
- Различные типы передачи. В зависимости от архитектуры окружающей телефонной сети тип передачи может быть различным. Как правило, стандартная передача по умолчанию в VoiceXML будет работать при передаче агентам или ACD в местном колл-центре. Тем не менее, переадресация с / на внешнюю АТС / АТС-АТС должна выполняться как контролируемая (2-ступенчатая) пересылка. Обратите внимание, что стандарт VoiceXML не распространяется на этот тип передачи. Он охватывает только слепые передачи и конференции, но большинство платформ предоставляют механизм доступа к дополнительной логике передачи.
Интеграция компьютерной телефонии (CTI):
Под CTI я имею в виду управление вызовами первого или третьего лица посредством интеграции данных с УАТС.
- Особенности отличий. Больше, чем многие могут себе представить. Это может быть очень сложно, если вы находитесь в колл-центре с ACD. Функции ACD могут сильно отличаться от поставщика к поставщику.
- Потоки событий / форматы данных. Опять же, они могут быть очень разными. На некоторых коммутаторах вы получите богатый набор событий. В некоторых средах вы можете увидеть практически ничего.
- Отслеживание звонков. Отслеживание вызова вокруг коммутатора для всплывающих данных не всегда так просто, как получение идентификатора ссылки на вызов и помещение данных в базу данных с использованием его в качестве ключа. На нескольких коммутаторах идентификационные номера меняются по мере перемещения вызова по системе. Вам нужно будет написать программное обеспечение, чтобы отслеживать переходы и обновлять его по внутреннему идентификатору ссылки. Ох, и не все коммутаторы поддерживают идентификаторы ссылок...
Таким образом, вы увидите не только различия между коммутаторами, но и разные протоколы одного и того же коммутатора, различия в зависимости от класса обслуживания / конфигурации и даже для каждого устройства. Позже я имею в виду, что вы можете видеть различное поведение в зависимости от телефона, установленного на столе оператора (имеет отношение к всплывающим данным CTI).
Не существует единого решения, которое бы скрывало все это и, учитывая некоторые различия, универсальное решение не может существовать. Однако может быть создана ограниченная модель для конкретных случаев использования. Это просто не очень просто и требует большого опыта работы с переключателями для создания слоя нормализации.
Итак, теперь, когда я обрисовал основные области проблемы (да, есть и другие:-(), несколько советов:
- Отсоедините логику приложения от логики телефонии. Предположим, вам потребуется несколько подключаемых модулей для интеграции телефонии.
- Избегайте переключения определенных функций рядом со слоем нормализации. Вы не сможете избежать их, если будете развертывать на рабочих столах агентов, так как центры обработки вызовов ожидают, что вы будете использовать или хотя бы соблюдать их особую конфигурацию ACD (если ваши вызовы не отображаются правильно в их отчетах, вы рискуете потерять клиента)
- Выберите основного поставщика IVR, который поддерживает широкий спектр протоколов телефонии и предоставляет богатый расширенный набор функций передачи.
- Хотя стандарты... плохие... они все, что у вас есть. Напишите ваше заявление в VoiceXML. У вас есть возможность сменить поставщиков IVR, если у вас есть сделка по коммутатору или в колл-центре, которую основной поставщик не может поддержать.
- Существует множество протоколов CTI. TAPI, JTAPI, TSAPI, CSTA и так далее. Там нет ни одного ответа. Существует несколько коммерческих слоев нормализации, которые предоставляют более согласованный API, но функции и потоки событий по-прежнему различаются для каждого коммутатора. Либо планируйте писать на несколько интерфейсов, либо платите за сторонний API. Здесь непросто ответить, так как стоимость стороннего продукта может быть дорогим дополнением, но усилия по разработке широкого спектра коммутаторов могут быть еще больше.
- Партнер с ограниченным набором поставщиков коммутаторов или серверов CTI (например, Cisco ICM, Genesys T-Server). Это ограничивает ваш рынок, но сводит к минимуму затраты на интеграцию. Но это партнерство может помочь вам увеличить продажи и получить доступ к большему количеству клиентов.
Также в качестве альтернативного ответа на мой вопрос мы наткнулись на проект с открытым исходным кодом, который создает интерфейс с использованием JTAPI для обеспечения поддержки нескольких систем телефонии (плат, УАТС и IP-телефонии) и платформ. Таким образом, я могу разработать приложение, как я уже упоминал, и заставить его работать для многих различных систем независимо от системы. Я уверен, что есть исключения, но это должно работать с большинством из них - учитывая, что TAPI в любом случае является общепринятым стандартом:
Это называется "Generic JTAPI":
Сэкономьте себе время на боль и развитие с Twilio. В основном они имеют дело с соединением PSTN/VOIP, и вы просто говорите им, что делать с XML/HTTP REST. У них есть вспомогательные библиотеки на разных языках, включая Java.