При трансфере звонков менеджер ничего не слышно

[seriousnik]

Добрый день,

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

версия флэшфоннера 5.2.1329.
Скрипт беру отсюда https://flashphoner-downloads.nyc3.digitaloceanspaces.com/builds/WEB-SDK/2.0/current/flashphoner.js. - выглядит, как недоработанный скрипт. И он отличается от этого https://github.com/flashphoner/flashphoner_client/blob/wcs_api-2.0/src/flashphoner-core.js. Какой из них использовать?

И почему может быть проблема со слышимостью при трансфере? Если разговаривать с клиентом, то все ок.

Спасибо!

 

[Max]

Здравствуйте.

1. Скрипт flashphoner.js рекомендуется брать в составе последней релизной версии Web SDK, а файлы Web SDK держать на вашем веб-сервере.

Вы ссылаетесь на наше облако хранения для демонстрационных целей. Т.е. используя этот путь https://flashphoner-downloads.nyc3.digitaloceanspaces.com/builds/WEB-SDK/2.0/current/flashphoner.js, можно быстро протестировать демо-страницу.

2. Скрипт flashphoner-core.js является одним из файлов с исходным кодом. После выполнения процесса сборки, собирается Web SDK, в составе которого будет уже файл flashphoner.js

Поэтому, если вы работаете на уровне релизных сборок, используете flashphoner.js (ваш вариант)
Если работаете уровнем ниже и собираете все из исходников, то flashphoner-core.js

3. По трансферу

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

Трансфер работает по спецификации https://www.rfc-editor.org/rfc/rfc5589

Т.е. SIP сервер, для работы с которым настроен WCS, должен поддерживать эту спецификацию.

1. User1 и User2 разговаривают.
2. User1 намерен сделать трансфер звонка пользователю User3.
Т.е. в результате успешного трансфера, должен установиться звонок между User2 и User3.
3. User1 дает команду transfer()
4. Звонок между User1 и User2 ставится на удержание HOLD
5. WCS отправляет SIP серверу команду REFER.
SIP сервер отправляет пользователю User3 входящий (для пользователя) вызов.
6. Пользователь User3 берет трубку. Устанавливается звонок между User2 и User3.
7. Пользователь User1 завершает звонок, который стоял на холде.

В результате:
1. Установлен звонок между User2 и User3.
2. Завершен звонок между User1 и User2.

Поэтому не совсем понятно кто в вашем случае есть кто.
Например:

User1 - первый менеджер
User2 - клиент, который позвонил первому менеджеру User1
User3 - второй менеджер, которому происходит попытка трансфера звонка.

Если все так, то результатом успешного трансфера будет установленный звонок между User2 (клиентом) и User3 (второй менеджер).

звонка с менеджера на менеджера, когда они соединяются между собой

Возможно, то, что вы описываете, не является Трансфером.
Если цель состоит в том, чтобы поставить звонок с клиентом на удержание HOLD и в это время установить дополнительный звонок между двумя менеджерами, то это не трансфер, а два звонка одновременно, один из которых в состоянии HOLD.

1. User1 ставит Звонок1 с User2 на удержание.
2. User1 инициирует новый Звонок2 пользователю User3.
В результате, имеем два звонка: один HOLD, второй TALK

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

 

[seriousnik]

спасибо за развернутый ответ, у меня именно последний сценарий:

Если цель состоит в том, чтобы поставить звонок с клиентом на удержание HOLD и в это время установить дополнительный звонок между двумя менеджерами, то это не трансфер, а два звонка одновременно, один из которых в состоянии HOLD.


Планируется реализация в ближайшем будущем?

 

[Max]

Планируется реализация в ближайшем будущем?

Нет, не планируется, т.к. сценарий очень редкий, и есть обходное решение: открыть новый звонок в отдельной вкладке браузера или окне. Если будет больше запросов на подобный функционал, мы, конечно, заведем тикет на его добавление.
Что касается использования Web SDK в Вашем проекте, Вы можете также воспользоваться NPM пакетом, который обновляется одновременно с выкладыванием новой сборки для скачивания: NPM пакет

npm i @flashphoner/websdk

 

[seriousnik]

понял, спасибо большое за ответ

 

[seriousnik]

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

 

[Max]

Пожалуйста, опишите Ваш тест пошагово, в виде: "1. User1 открывает пример Phone Min..." и т.д.
Также соберите отчет на стороне сервера при помощи скрипта report.sh и пришлите, используя эту форму.

 

[seriousnik]

постараюсь собрать и отправить на форму, но на это уйдет некоторое время.

а вообще кейс такой:
User1 - клиент
User2 - менеджер, который позвонил User1, и поставил его на удержание, а затем позвонил User3.
User3 - менеджер, который должен получить вызов от User2.

User2 звонит User1. Звонок начался, связь хорошая, проблем нет. Далее User2 вызывает метод hold() или holdForTransfer(). User1 становится на удержании.
ЗатемUser2 открывает новую вкладку в хроме, коннектиться(все конфиги те же), и когда будет вызван Flashphoner.createSession(_connectionOptions), то звонок у User2 прекращается в первой вкладке.

Так как звонок между User2 и User1законился, то и нет смысла уже звонить User3.

 

[Max]

К сожалению, Вы прислали только клиентские логи, а необходим был полный отчет, собранный при помощи скрипта report.sh, т.к. он содержит серверный лог, где видна информация SIP сигналинга при регистрации пользователей на SIP сервер и установке звонков между ними. Мы воспроизвели Ваш кейс на тестовом стенде.
Есть ограничение: WCS не поддерживает одновременную регистрацию одного и того же клиента (с одним и тем же внешним IP адресом) в одном и том же SIP аккаунте на одном и том же SIP сервере. Это можно обойти, используя два SIP аккаунта (мы тестировали в примере Phone Min, он отображает кнопку Hold при установленном звонке и использует методы Call.hold()/Call.unhold()):
1. User2 звонит User1 с аккаунта User2.1
2. User2 ставит звонок на удержание
3. User2 звонит User3 с аккаунта User2.2
4. User3 получает вызов от User2.2, звонок между User2.1 и User1 остается в холде
5. User2 завершает звонок User2.2-User3 (или User3 завершает этот звонок, нет разницы, какая именно сторона это сделает)
6. User2 снимает звонок User2.1-User1 с холда и продолжает разговор

 

[Max]

Еще одно решение можно применить, если Ваш SIP сервер поддерживает исходящие звонки без регистрации:
1. User2 регистрируется на SIP сервере (взводит переключатель Register required в примере Phone Min, при этом проставляется опция сессии sipRegisterRequired: true)
2. User2 звонит User1
3. User2 ставит звонок на удержание
4. В другой вкладке User2 указывает произвольные параметры SIP login и SIP password и не взводит переключатель Register required, при этом проставляется опция сессии sipRegisterRequired: false
5. С этой вкладки User2 звонит User3.
В этом случае звонок между User2 и User1 не завершится, а останется в холде, и его можно будет возобносить после завершения звонка между User2 и User3.
Ограничения:
- SIP сервер должен поддерживать исходящие звонки без регистрации
- Пользователь, подключившийся без регистрации, не сможет принимать входящие звонки, только делать исходящие

 

[seriousnik]

Добрый день, создал user2.1 и user2.2. История потворилась, один менеджер не слышит другого.

 

[Max]

один менеджер не слышит другого

Ранее Вы описывали кейс как:
1. Менеджер User2 звонит клиенту User1
2. Менеджер User2 ставит звонок с User1 на холд
3. Менеджер User2 звонит менеджеру User3
и проблема была в том, что звонок User2->User1 сбрасывался.
Правильно ли мы понимаем, что с рекомендациями из этого сообщения не устанавливается звонок User2->User3? Если да, то это другая проблема, и нужно проверить, устанавливается ли звонок User2->User3 отдельно (без звонка User2->User1), то есть сузить кейс.
Обычно, если звонок не устанавливается, мы рекомендуем следующие настройки на стороне WCS:
- если SIP сервер поддерживает TCP сигналинг, переключиться на него

sip_force_tcp=true

- браузер добавляет в SDP все кодеки, какие поддерживает, это поведение желательно исключить

allow_outside_codecs=false

- можно исключить кодеки, которые не будет использованы в звонке, например, если звонок только аудио, то видео кодеки можно убрать, также можно отключить лишние аудиокодеки, оставив только Opus и PCMA/PCMU

codecs_exclude_sip=mpeg4-generic,g729,speex16,g722,flv,mpv,h164,vp8

 

[seriousnik]

Нет, не так.

Мы сделали два sip на одного юзера User 2.1, user2.2, как вы посоветовали.

User2.1 звонит User1. Они законнектились, все ок. User2 открывает новую вкладку и звонит User2.2. -> User3. Связь между User2.1и User1 не потеряна, но User2.2 ничего не слышит от User3.

 

[Max]

Пожалуйста, примените на WCS настройки из этого сообщения (потребуется перезапуск WCS). Затем попробуйте установить звонок между User2.2 и User3 (только этот звонок, других звонков в этот момент на сервере быть не должно). Если так работает, повторите тест полностью.
Если настройки не помогают, нужно:
- перезапустить WCS
- запустить сбор дампа трафика на стороне WCS командой

tcpdump -npi any -B 10240 -w log.pcap

- воспроизвести проблему
- остановить сбор дампа
- собрать отчет при помощи скрипта report.sh
- отправить отчет и дамп трафика, ипользуя эту форму.

 

[seriousnik]

Добрый день,
У нас 5.2.1329 а по документации нужна версия 5.2.241 для автоматического сбора логов.
Нам стоит обновиться?

 

[Max]

Добрый день,
На 5.2.241 не нужно. 5.2.241 - более ранняя сборка, чем 5.2.1329. (Release notes)
report.sh работает в 5.2.241 и более поздних сборках.

 

[Max]

Проверили Ваш отчет. Видим некоторые проблемы в настройках:
1. При использовании WCS как WebRTC-SIP шлюза, не может быть более одного подписчика на один SIP медиа поток, только клиент-участник звонка. Поэтому включение оптимизации доставки потока подписчикам выглядит лишним

2. Ранее мы рекомендовали исключить лишние кодеки в настройке codecs_exclude_sip, это не было сделано

Отметим, что настройки применяются при перезапуске WCS
Также сценарий тестирования, который есть в дампе, отличается от описанного вами ранее:
1. user321 звонит на внешний мобильный номер, звонок устанавливается, затем ставится на холд
2. nikita звонит на другой аккаунт, звонок устанваливается успешно, есть медиатрафик в дампе и клиентском логе звонка
3. user542 получает входящий звонок (не звонок от nikita), звонок устанавливается успешно, есть медиатрафик в дампе и клиентском логе звонка
Поэтому непонятно, о какой проблеме в этом случае идет речь. Необходимо сузить кейс. Например, если проблемы возникают при приеме входящего звонка, нужно попробовать установить только этот звонок и собрать отчет заново. При отправке отчета необходимо описать, что именно и как тестировали.