Да, понял. Я уже прочитал :) Только это в вашем посте есть. А в документации — нету совсем.

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

Вообще хорошо, что вы пишете такие статьи. Потому что примеров у вас на сайте практически нет — писать неимоверно сложно. Мне очень все нравится. Я готов запустить и начать пользоваться реальным серивисом вот прямо сейчас. Осталось только написать :)

aylarov 16 июн 2014 в 14:27

account_id — это один из вариантов, вместо него можно указать account_name или email-адрес. Мы знаем, что наша дкоументация далека от совершенства на данный момент, мы работаем над ее улучшением и продолжим писать статьи как в блоге, так и на Хабре. Комментарии очень помогают сделать платформу лучше.

Angelmoon 16 июн 2014 в 14:32

Дак мы с удовольствием бы! Только вот дальше куда смотреть? Вот я взял этот сценарий… а что мне дальше делать? Потому что пока не очень ясно…

aylarov 16 июн 2014 в 14:33

После HTTP-запроса StartScenarios в облаке запустится данный сценарий и сделает звонок сначала на 1 номер, а потом на другой и соединит их.

Angelmoon 16 июн 2014 в 14:42

Сорри, оно заработало. Оказывается, я неправильно вводил номер телефона. Правильный формат: 74951234567

Та-а-а-а-ак… а еще ма-а-а-аленький вопрос. Мне пришел звонок сейчас на мобильный. С некоего номера в коде 499. А что это за номер?

aylarov 16 июн 2014 в 14:44

Это номер платформы в России по умолчанию, чтобы был другой номер надо поменять сценарий, а именно в VoxEngine.callPSTN указать второй параметр. Надо учесть что абы какой номер подставлять нельзя. Сначала нужно его авторизовать в разделе CallerIDs

Angelmoon 16 июн 2014 в 15:24

Ага. Ну для начала я должен буду купить номер в разделе Phone Numbers?

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

aylarov 16 июн 2014 в 15:29

Не обязательно, купить номер — это один из вариантов, второй — валидировать уже существующий у вас, придет автоматизированный вызов с кодом для валидации.

Мы не ограничиваем количество вызовов, 100-150 звонков в течение дня — это очень незначительная нагрузка для нашей инфраструктуры :)

Angelmoon 16 июн 2014 в 16:16

Я все-таки решил для тестов купить у вас номер. Купил, указал, для какого приложения он. Но все-равно определяется другой. Как привязать?

aylarov 16 июн 2014 в 16:29

В каком формате вы его указываете в методе callPSTN?

Angelmoon 16 июн 2014 в 17:00

Нет-нет, вопрос другой: как сделать, чтобы при звонке на мобильный определялся в качестве обратного номера мой, который я только что купил?

aylarov 16 июн 2014 в 17:01

Именно так и сделать, указать его вторым параметров в функции callPSTN

Angelmoon 16 июн 2014 в 17:54

Разбираемся дальше.

Вообще, крутую штуку вы сделали! Респект! :)

OnlyWeb 27 авг 2014 в 16:42

Здравствуйте. Пытаемся разобраться с вашим сервисом. На странице voximplant.com/docs/references/websdk/ есть vox.addEventListener(VoxImplant.Events.AuthResult, handleAuthResult); vox.login(«voximplant_username», «voximplant_password»). Значит у меня в коде в открытом виде на странице должен быть логин и пароль, это же не безопасно. Как решается вопрос чтобы мои логин-пароль не использовал кто угодно для совершения звонков?

aylarov 27 авг 2014 в 16:56

Ну в целом идея такая, что эти данные клиент должен вводить :) в форме авторизации. Но есть и другой вариант — voximplant.com/docs/references/websdk/VoxImplant.Client.html#loginWithOneTimeKey, вместо пароля используется специальный хэш, который считается у вас на сервере после получения ключа.

OnlyWeb 27 авг 2014 в 17:11

Понял что webSDK удобно, но использовать в нашем случае можно исключительно на свой страх и риск. Смотрим в сторону voximplant.com/docs/references/httpapi/.

psman 27 авг 2014 в 16:49

Есть ли пример сценария когда при недозвоне на телефон кол центра идет дозвон на другой и т.д. (т.е. у меня входящих Х номеров в массиве)

aylarov 27 авг 2014 в 16:57

Отлавливаете событие недозвона (http://voximplant.com/docs/references/appengine/CallEvents.Failed.html) и по его факту инициируете следующий вызов. На одну сессию можно сделать не более 10 звонков.

OnlyWeb 3 сен 2014 в 19:41

Выше был вопрос про X номеров колл центра в массиве тут все понятно. А есть ли пример сценария, когда может быть от 1 до N номеров колл центра и 1 номер абонента. Script_custom_data у вас через двоеточие — и в этом сложность. Помню про JSON, но не разобрались с вашим отладчиком. Дадим ваш хорошую загрузку. Помогите разобраться с сценарием.

psman 3 сен 2014 в 19:53

data = VoxEngine.customData();
data = data.split(":");

а что мешает data[0] какой нить собрать с разделителями "| " и его снова phones= data[0].split("|"); — получаем массив телефонов

aylarov 3 сен 2014 в 21:03

Можно прямо массив в JSON передать, в чем проблема?

OnlyWeb 3 сен 2014 в 20:30

Андрей, а отладчик у вас сейчас работает? Запускаю ваш же пример, пишет «ожидание начала сессии отладки» и все. Ничего не происходит. Что я делаю не так? Как отладить самописный сценарий без слива денег?

aylarov 3 сен 2014 в 21:01

Отладчик работает, чтобы началась сессия отладки нужно сделать HTTP-запрос StartScenario. Сессия запускается на платформе или по факту HTTP-запроса (в случае callback-сценария) или по факту звонка пришедшего на платформу.

OnlyWeb 4 сен 2014 в 13:17

Разобрались с каскадной переадресацией. Вопрос по записи разговоров voximplant.com/docs/references/appengine/Recorder.html. Сценарий запускает бекенд и получает в ответ media_session_access_url и на этом все. Как бекенду в этом же сеансе получить ссылку на запись разговора?

aylarov 4 сен 2014 в 13:19

В сценарии можно получить URL записи из voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html, параметр url. Бэкенд может вызывать функции сценария через media_session_access_url, передавая туда параметры, которые будут приходить сюда voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html, соответственно возвращать данные можно просто сделав return из хэндлера этого события.

OnlyWeb 4 сен 2014 в 13:36

Пожалуйста, добавьте в ваш же пример сценария выше (в статье) как с помощью voximplant.com/docs/references/appengine/CallEvents.RecordStarted.html включить запись и по факту отработки получить ссылку на файл. Из сценария ссылку дальше мы самостоятельно с помощью voximplant.com/docs/references/appengine/AppEvents.HttpRequest.html пробросим на свой бекенд.

Без примеров кода справится очень затруднительно.

aylarov 4 сен 2014 в 13:44

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

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

function handleRecordStarted(e) {
   record_url = e.url;
}

OnlyWeb 4 сен 2014 в 14:17

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


function handleRecordStarted(e) {
   record_url = e.url;
  Net.httpRequest("http://somewebservice?url=encodeURIComponent(record_url)", function(e1) {

  });
}

aylarov 4 сен 2014 в 14:22

или есть возможность все же получить урл с записью после вызова сценарий с бэкенда (делаем 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;
}

OnlyWeb 4 сен 2014 в 14:31

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

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

По-моему не совсем удачное решение, когда вопрос решается всего то лишь возвращением урла с потенциальной записью при вызове самого сценария там же где приходит media_session_access_url в ответ, а уж существует запись или нет — итог отработки сценария, но мы заранее будем знать где 'если что' искать контент и все в 1 запрос, не правда ли? :)

aylarov 4 сен 2014 в 14:34

Вы по-моему неправильно поняли. Запрос функции (media_session_access_url) вернет сразу URL на запись, когда этот URL будет сформирован. Про потенциальный URL даж комментировать не хочется… Вы же понимаете что URL записи формируется только в случае запуска в сценарии записи я надеюсь?

OnlyWeb 4 сен 2014 в 14:51

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

aylarov 4 сен 2014 в 14:57

Вы плохо себе представляете кол-во сценариев, которые делают на платформе, у вас частный случай и есть все необходимые инструменты для решения задачи. В сценарии может быть до 10 звонков — и какие же из них нужно писать при включении флага?

OnlyWeb 4 сен 2014 в 15:03

Все правильно. Наш случай это много телефонов колцентра и 1 клиентский, писать нужно сам разговор клиента. Понятно, что ожидание и пробросы на другие звонки колцентра не интересы. Интересует сам разговор, он один (либо он есть либо его нет, поэтому говорю о потенциальном разговоре) Но для удобства использования, глобальную опцию можно вытащить, это частный случай, но думаю, он удобнее в использование будет и не для одного клиента.
Кстати, Спасибо за быстрые ответы.

aylarov 4 сен 2014 в 14:48

Ну и в дополнение URL записи всегда можно вытащить из HTTP API уже после завершения звонка, если не горит.

OnlyWeb 4 сен 2014 в 14:53

А вот это уже интереснее, каким образом можно получить через http api урл записи?

aylarov 4 сен 2014 в 14:54

См. voximplant.com/docs/references/httpapi/GetCallHistory.html

Зарегистрируйтесь на Хабре, чтобы оставить комментарий