Comments 41
ID правила можно увидеть только при выборе английского языка. В русском интерфейсе ID правила отсутствует
+1
Спасибо за замечание, сейчас создадим тикет и постараемся поправить в самое ближайшее время.
0
Пробую… но пока некоторые вещи не очень понятны в документации. Например, где взять API Key?
0
В посте есть про это отдельно
свой api_key можно узнать в разделе Profile
0
Да, понял. Я уже прочитал :) Только это в вашем посте есть. А в документации — нету совсем.
Ну и account_id — тоже не очень понятно где брать. Я плюс-минус разобрался, но вот документацию бы чуть-чуть дополнить.
Вообще хорошо, что вы пишете такие статьи. Потому что примеров у вас на сайте практически нет — писать неимоверно сложно. Мне очень все нравится. Я готов запустить и начать пользоваться реальным серивисом вот прямо сейчас. Осталось только написать :)
Ну и account_id — тоже не очень понятно где брать. Я плюс-минус разобрался, но вот документацию бы чуть-чуть дополнить.
Вообще хорошо, что вы пишете такие статьи. Потому что примеров у вас на сайте практически нет — писать неимоверно сложно. Мне очень все нравится. Я готов запустить и начать пользоваться реальным серивисом вот прямо сейчас. Осталось только написать :)
+1
account_id — это один из вариантов, вместо него можно указать account_name или email-адрес. Мы знаем, что наша дкоументация далека от совершенства на данный момент, мы работаем над ее улучшением и продолжим писать статьи как в блоге, так и на Хабре. Комментарии очень помогают сделать платформу лучше.
0
Дак мы с удовольствием бы! Только вот дальше куда смотреть? Вот я взял этот сценарий… а что мне дальше делать? Потому что пока не очень ясно…
0
После HTTP-запроса StartScenarios в облаке запустится данный сценарий и сделает звонок сначала на 1 номер, а потом на другой и соединит их.
0
Сорри, оно заработало. Оказывается, я неправильно вводил номер телефона. Правильный формат: 74951234567
Та-а-а-а-ак… а еще ма-а-а-аленький вопрос. Мне пришел звонок сейчас на мобильный. С некоего номера в коде 499. А что это за номер?
Та-а-а-а-ак… а еще ма-а-а-аленький вопрос. Мне пришел звонок сейчас на мобильный. С некоего номера в коде 499. А что это за номер?
0
Ага. Ну для начала я должен буду купить номер в разделе Phone Numbers?
И еще — сколько одновременных соединений потянет такая схема с двумя вызовами? Если у меня 100-150 звонков в течение дня — это как? Много, мало?
И еще — сколько одновременных соединений потянет такая схема с двумя вызовами? Если у меня 100-150 звонков в течение дня — это как? Много, мало?
0
Не обязательно, купить номер — это один из вариантов, второй — валидировать уже существующий у вас, придет автоматизированный вызов с кодом для валидации.
Мы не ограничиваем количество вызовов, 100-150 звонков в течение дня — это очень незначительная нагрузка для нашей инфраструктуры :)
Мы не ограничиваем количество вызовов, 100-150 звонков в течение дня — это очень незначительная нагрузка для нашей инфраструктуры :)
0
Я все-таки решил для тестов купить у вас номер. Купил, указал, для какого приложения он. Но все-равно определяется другой. Как привязать?
0
Здравствуйте. Пытаемся разобраться с вашим сервисом. На странице voximplant.com/docs/references/websdk/ есть vox.addEventListener(VoxImplant.Events.AuthResult, handleAuthResult); vox.login(«voximplant_username», «voximplant_password»). Значит у меня в коде в открытом виде на странице должен быть логин и пароль, это же не безопасно. Как решается вопрос чтобы мои логин-пароль не использовал кто угодно для совершения звонков?
0
Ну в целом идея такая, что эти данные клиент должен вводить :) в форме авторизации. Но есть и другой вариант — voximplant.com/docs/references/websdk/VoxImplant.Client.html#loginWithOneTimeKey, вместо пароля используется специальный хэш, который считается у вас на сервере после получения ключа.
0
Понял что webSDK удобно, но использовать в нашем случае можно исключительно на свой страх и риск. Смотрим в сторону voximplant.com/docs/references/httpapi/.
0
Есть ли пример сценария когда при недозвоне на телефон кол центра идет дозвон на другой и т.д. (т.е. у меня входящих Х номеров в массиве)
0
Выше был вопрос про X номеров колл центра в массиве тут все понятно. А есть ли пример сценария, когда может быть от 1 до N номеров колл центра и 1 номер абонента. Script_custom_data у вас через двоеточие — и в этом сложность. Помню про JSON, но не разобрались с вашим отладчиком. Дадим ваш хорошую загрузку. Помогите разобраться с сценарием.
0
Андрей, а отладчик у вас сейчас работает? Запускаю ваш же пример, пишет «ожидание начала сессии отладки» и все. Ничего не происходит. Что я делаю не так? Как отладить самописный сценарий без слива денег?
0
Разобрались с каскадной переадресацией. Вопрос по записи разговоров voximplant.com/docs/references/appengine/Recorder.html. Сценарий запускает бекенд и получает в ответ media_session_access_url и на этом все. Как бекенду в этом же сеансе получить ссылку на запись разговора?
0
В сценарии можно получить URL записи из voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html, параметр url. Бэкенд может вызывать функции сценария через media_session_access_url, передавая туда параметры, которые будут приходить сюда voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html, соответственно возвращать данные можно просто сделав return из хэндлера этого события.
0
Пожалуйста, добавьте в ваш же пример сценария выше (в статье) как с помощью voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html включить запись и по факту отработки получить ссылку на файл. Из сценария ссылку дальше мы самостоятельно с помощью voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html пробросим на свой бекенд.
Без примеров кода справится очень затруднительно.
Без примеров кода справится очень затруднительно.
0
Да вроде все вполне просто (если нужно писать разговор 2х соединенных звонков, то все это делается у любого одного из них):
var record_url;
call.addEventListener(CallEvents.RecordStarted, handleRecordStarted);
call.record();
function handleRecordStarted(e) {
record_url = e.url;
}
0
Спасибо. Я правильно понимаю, что единственный способ бэкенду получить record_url это повесить в функцию из примера http вызов с передачей параметра? или есть возможность, все же, получить урл с записью после вызова сценария с бэкенда (делаем http запрос для запуска сценария, делаем http запрос для получения урла записи)?
т.е. что-то вроде этого (пример для проброса урла записи из сценария на бэкенд)
т.е. что-то вроде этого (пример для проброса урла записи из сценария на бэкенд)
function handleRecordStarted(e) {
record_url = e.url;
Net.httpRequest("http://somewebservice?url=encodeURIComponent(record_url)", function(e1) {
});
}
0
или есть возможность все же получить урл с записью после вызова сценарий с бэкенда (делаем 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;
}
0
ну мы же понимаем, что это не совсем красивое решение. Ибо один итак запущенный процесс (который запускаем сценарий) вместо отработки в самом себе породить еще один, который придет из сценария через AppEvents.HttpRequest
Итого: 1 запрос на запуск сценария, второй запрос на вызов нашей функции из сценария через media_session_access_url который породит третий (по счету, а по факту второе соединение) запрос на бэкенд из сценария.
По-моему не совсем удачное решение, когда вопрос решается всего то лишь возвращением урла с потенциальной записью при вызове самого сценария там же где приходит media_session_access_url в ответ, а уж существует запись или нет — итог отработки сценария, но мы заранее будем знать где 'если что' искать контент и все в 1 запрос, не правда ли? :)
Итого: 1 запрос на запуск сценария, второй запрос на вызов нашей функции из сценария через media_session_access_url который породит третий (по счету, а по факту второе соединение) запрос на бэкенд из сценария.
По-моему не совсем удачное решение, когда вопрос решается всего то лишь возвращением урла с потенциальной записью при вызове самого сценария там же где приходит media_session_access_url в ответ, а уж существует запись или нет — итог отработки сценария, но мы заранее будем знать где 'если что' искать контент и все в 1 запрос, не правда ли? :)
0
Вы по-моему неправильно поняли. Запрос функции (media_session_access_url) вернет сразу URL на запись, когда этот URL будет сформирован. Про потенциальный URL даж комментировать не хочется… Вы же понимаете что URL записи формируется только в случае запуска в сценарии записи я надеюсь?
0
Хотя удобнее вызвать сценарий сразу с флагом записи и получить в ответ адрес где ее можно получить по факту. Это гораздо удобнее для сервисов, которые будут подключены. Тем более все входящее данные при запросе, который включает сценарий у вас все есть. Одно дело глобальные опции, другое дело нюансы сценария, так вот в большинстве случаев глобальной опции на включение записи будет достаточно.
0
Вы плохо себе представляете кол-во сценариев, которые делают на платформе, у вас частный случай и есть все необходимые инструменты для решения задачи. В сценарии может быть до 10 звонков — и какие же из них нужно писать при включении флага?
0
Все правильно. Наш случай это много телефонов колцентра и 1 клиентский, писать нужно сам разговор клиента. Понятно, что ожидание и пробросы на другие звонки колцентра не интересы. Интересует сам разговор, он один (либо он есть либо его нет, поэтому говорю о потенциальном разговоре) Но для удобства использования, глобальную опцию можно вытащить, это частный случай, но думаю, он удобнее в использование будет и не для одного клиента.
Кстати, Спасибо за быстрые ответы.
Кстати, Спасибо за быстрые ответы.
0
Ну и в дополнение URL записи всегда можно вытащить из HTTP API уже после завершения звонка, если не горит.
0
Sign up to leave a comment.
Быстрое создание callback-сценариев с помощью Voximplant