Pull to refresh

Comments 41

ID правила можно увидеть только при выборе английского языка. В русском интерфейсе ID правила отсутствует
Спасибо за замечание, сейчас создадим тикет и постараемся поправить в самое ближайшее время.
Пробую… но пока некоторые вещи не очень понятны в документации. Например, где взять API Key?
В посте есть про это отдельно
свой api_key можно узнать в разделе Profile
Да, понял. Я уже прочитал :) Только это в вашем посте есть. А в документации — нету совсем.

Ну и account_id — тоже не очень понятно где брать. Я плюс-минус разобрался, но вот документацию бы чуть-чуть дополнить.

Вообще хорошо, что вы пишете такие статьи. Потому что примеров у вас на сайте практически нет — писать неимоверно сложно. Мне очень все нравится. Я готов запустить и начать пользоваться реальным серивисом вот прямо сейчас. Осталось только написать :)
account_id — это один из вариантов, вместо него можно указать account_name или email-адрес. Мы знаем, что наша дкоументация далека от совершенства на данный момент, мы работаем над ее улучшением и продолжим писать статьи как в блоге, так и на Хабре. Комментарии очень помогают сделать платформу лучше.
Дак мы с удовольствием бы! Только вот дальше куда смотреть? Вот я взял этот сценарий… а что мне дальше делать? Потому что пока не очень ясно…
После HTTP-запроса StartScenarios в облаке запустится данный сценарий и сделает звонок сначала на 1 номер, а потом на другой и соединит их.
Сорри, оно заработало. Оказывается, я неправильно вводил номер телефона. Правильный формат: 74951234567

Та-а-а-а-ак… а еще ма-а-а-аленький вопрос. Мне пришел звонок сейчас на мобильный. С некоего номера в коде 499. А что это за номер?
Это номер платформы в России по умолчанию, чтобы был другой номер надо поменять сценарий, а именно в VoxEngine.callPSTN указать второй параметр. Надо учесть что абы какой номер подставлять нельзя. Сначала нужно его авторизовать в разделе CallerIDs
Ага. Ну для начала я должен буду купить номер в разделе Phone Numbers?

И еще — сколько одновременных соединений потянет такая схема с двумя вызовами? Если у меня 100-150 звонков в течение дня — это как? Много, мало?
Не обязательно, купить номер — это один из вариантов, второй — валидировать уже существующий у вас, придет автоматизированный вызов с кодом для валидации.

Мы не ограничиваем количество вызовов, 100-150 звонков в течение дня — это очень незначительная нагрузка для нашей инфраструктуры :)
Я все-таки решил для тестов купить у вас номер. Купил, указал, для какого приложения он. Но все-равно определяется другой. Как привязать?
В каком формате вы его указываете в методе callPSTN?
Нет-нет, вопрос другой: как сделать, чтобы при звонке на мобильный определялся в качестве обратного номера мой, который я только что купил?
Именно так и сделать, указать его вторым параметров в функции callPSTN
Разбираемся дальше.

Вообще, крутую штуку вы сделали! Респект! :)
Здравствуйте. Пытаемся разобраться с вашим сервисом. На странице voximplant.com/docs/references/websdk/ есть vox.addEventListener(VoxImplant.Events.AuthResult, handleAuthResult); vox.login(«voximplant_username», «voximplant_password»). Значит у меня в коде в открытом виде на странице должен быть логин и пароль, это же не безопасно. Как решается вопрос чтобы мои логин-пароль не использовал кто угодно для совершения звонков?
Ну в целом идея такая, что эти данные клиент должен вводить :) в форме авторизации. Но есть и другой вариант — voximplant.com/docs/references/websdk/VoxImplant.Client.html#loginWithOneTimeKey, вместо пароля используется специальный хэш, который считается у вас на сервере после получения ключа.
Есть ли пример сценария когда при недозвоне на телефон кол центра идет дозвон на другой и т.д. (т.е. у меня входящих Х номеров в массиве)
Отлавливаете событие недозвона (http://voximplant.com/docs/references/appengine/CallEvents.Failed.html) и по его факту инициируете следующий вызов. На одну сессию можно сделать не более 10 звонков.
Выше был вопрос про X номеров колл центра в массиве тут все понятно. А есть ли пример сценария, когда может быть от 1 до N номеров колл центра и 1 номер абонента. Script_custom_data у вас через двоеточие — и в этом сложность. Помню про JSON, но не разобрались с вашим отладчиком. Дадим ваш хорошую загрузку. Помогите разобраться с сценарием.
data = VoxEngine.customData();
data = data.split(":");

а что мешает data[0] какой нить собрать с разделителями "| " и его снова phones= data[0].split("|"); — получаем массив телефонов
Можно прямо массив в JSON передать, в чем проблема?
Андрей, а отладчик у вас сейчас работает? Запускаю ваш же пример, пишет «ожидание начала сессии отладки» и все. Ничего не происходит. Что я делаю не так? Как отладить самописный сценарий без слива денег?
Отладчик работает, чтобы началась сессия отладки нужно сделать HTTP-запрос StartScenario. Сессия запускается на платформе или по факту HTTP-запроса (в случае callback-сценария) или по факту звонка пришедшего на платформу.
Разобрались с каскадной переадресацией. Вопрос по записи разговоров voximplant.com/docs/references/appengine/Recorder.html. Сценарий запускает бекенд и получает в ответ media_session_access_url и на этом все. Как бекенду в этом же сеансе получить ссылку на запись разговора?
В сценарии можно получить URL записи из voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html, параметр url. Бэкенд может вызывать функции сценария через media_session_access_url, передавая туда параметры, которые будут приходить сюда voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html, соответственно возвращать данные можно просто сделав return из хэндлера этого события.
Пожалуйста, добавьте в ваш же пример сценария выше (в статье) как с помощью voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html включить запись и по факту отработки получить ссылку на файл. Из сценария ссылку дальше мы самостоятельно с помощью voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html пробросим на свой бекенд.

Без примеров кода справится очень затруднительно.
Да вроде все вполне просто (если нужно писать разговор 2х соединенных звонков, то все это делается у любого одного из них):

var record_url;
call.addEventListener(CallEvents.RecordStarted, handleRecordStarted);
call.record();

function handleRecordStarted(e) {
   record_url = e.url;
}
Спасибо. Я правильно понимаю, что единственный способ бэкенду получить record_url это повесить в функцию из примера http вызов с передачей параметра? или есть возможность, все же, получить урл с записью после вызова сценария с бэкенда (делаем http запрос для запуска сценария, делаем http запрос для получения урла записи)?
т.е. что-то вроде этого (пример для проброса урла записи из сценария на бэкенд)

function handleRecordStarted(e) { record_url = e.url; Net.httpRequest("http://somewebservice?url=encodeURIComponent(record_url)", function(e1) { }); }
или есть возможность все же получить урл с записью после вызова сценарий с бэкенда (делаем http запрос для запуска сценарий, делаем http запрос для получения урла записи)?

Есть, я же написал что можно делать потом HTTP-запросы к медиа-сессии по адресу media_session_access_url, которые на стороне сценария будут вызывать voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html

На стороне сценария будет:
VoxEngine.addEventListener(AppEvents.HttpRequest, function (e) {
    // в e.path будет строка запроса , которая идет после media_session_access_url, можно там передавать название вызываемой функции, как вариант.
    return record_url;
}


ну мы же понимаем, что это не совсем красивое решение. Ибо один итак запущенный процесс (который запускаем сценарий) вместо отработки в самом себе породить еще один, который придет из сценария через AppEvents.HttpRequest

Итого: 1 запрос на запуск сценария, второй запрос на вызов нашей функции из сценария через media_session_access_url который породит третий (по счету, а по факту второе соединение) запрос на бэкенд из сценария.

По-моему не совсем удачное решение, когда вопрос решается всего то лишь возвращением урла с потенциальной записью при вызове самого сценария там же где приходит media_session_access_url в ответ, а уж существует запись или нет — итог отработки сценария, но мы заранее будем знать где 'если что' искать контент и все в 1 запрос, не правда ли? :)
Вы по-моему неправильно поняли. Запрос функции (media_session_access_url) вернет сразу URL на запись, когда этот URL будет сформирован. Про потенциальный URL даж комментировать не хочется… Вы же понимаете что URL записи формируется только в случае запуска в сценарии записи я надеюсь?
Хотя удобнее вызвать сценарий сразу с флагом записи и получить в ответ адрес где ее можно получить по факту. Это гораздо удобнее для сервисов, которые будут подключены. Тем более все входящее данные при запросе, который включает сценарий у вас все есть. Одно дело глобальные опции, другое дело нюансы сценария, так вот в большинстве случаев глобальной опции на включение записи будет достаточно.
Вы плохо себе представляете кол-во сценариев, которые делают на платформе, у вас частный случай и есть все необходимые инструменты для решения задачи. В сценарии может быть до 10 звонков — и какие же из них нужно писать при включении флага?
Все правильно. Наш случай это много телефонов колцентра и 1 клиентский, писать нужно сам разговор клиента. Понятно, что ожидание и пробросы на другие звонки колцентра не интересы. Интересует сам разговор, он один (либо он есть либо его нет, поэтому говорю о потенциальном разговоре) Но для удобства использования, глобальную опцию можно вытащить, это частный случай, но думаю, он удобнее в использование будет и не для одного клиента.
Кстати, Спасибо за быстрые ответы.
Ну и в дополнение URL записи всегда можно вытащить из HTTP API уже после завершения звонка, если не горит.
Only those users with full accounts are able to leave comments. Log in, please.