Обновление sipOptions на лету

[iejobs]

Есть ли возможность подключиться к sip серверу в WebSDK на лету? То есть передать sipOptions не в методе Flashphoner.createSession(), а уже потом?

 

[Max]

Добрый день.
Нет, такой возможности нет: регистрация на SIP сервере привязана к клиентской сессии и происходит в момент ее создания.
Если необходимо скрыть данные SIP-аккаунта от клиента, можно их добавить на стороне бэкенда в ответе на REST hook /connect:

switch($api_method) {
    case"connect":
        $rest_client_config = json_decode(file_get_contents('rest_client_config.json'), true); 
        $incoming_data['restClientConfig'] = $rest_client_config;
        $incoming_data['sipLogin'] = "1234";
        $incoming_data['sipAuthenticationName'] = "1234";
        $incoming_data['sipPassword'] = "password";
        $incoming_data['sipDomain'] = "sip-pbx-address";
        $incoming_data['sipOutboundProxy'] = "sip-pbx-address";
        $incoming_data['sipPort'] = "5060";
        header('HTTP/1.1', true, 200);
        header('Content-Type: application/json');
        echo json_encode($incoming_data);
    break;
    ...
}

 

[iejobs]

Спасибо
Подскажите еще пожалуйста, есть ли возможность передавать в sipOptions сразу несколько учетных записей?
Пример: у нас в SIP сервисе настроена АТС и там есть несколько внутренних номеров, например 123456-100 и 123456-101, которые соответственно являются логинами для sipOptions объекта, мы бы хотели зарегистрировать их оба, чтобы слушать звонки на обоих номерах. Есть ли такая возможность реализации?

 

[Max]

WebSDK (API) сейчас работает таким образом, что с сервером устанавливается 1 websocket - соединение, которое имеет 1 набор SIP credentials (login, password, proxy, port).

Т.е. нельзя в одном соединении передать два и более наборов SIP credentials.

Что можно попробовать сделать - это создать несколько сессий:

var session1 = Flashphoner.createSession(connectionOptions);
var session2 = Flashphoner.createSession(connectionOptions);

Каждая из сессий будет открывать собственное соединение с сервером.
Каждой из сессий будет соответсвовать собственная регистрация.

Однако, такой кейс не тестировался. Мы не можем сказать будут ли стабильно работать звонки, если придет входящий звонок на session1 и одновременно на session2, не будет ли коллизий. В случае таких коллизий, потребуется дорабатывать WebSDK из исходников.

 

[iejobs]

Еще раз добрый день) Спасибо за прошлые ответы.
Можете подсказать еще момент, на демо странице https://flashphoner:8888/client2/examples/demo/sip/phone-video/phone-video.html при попытке поднять трубку входящего звонка в консоли вываливается ошибка:

flashphoner.js:6759 Uncaught (in promise) DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to parse SessionDescription. a=rtpmap:110 speex/8000 Duplicate  payload type with conflicting codec name or clock rate.

С чем такое поведение может быть связано?

 

[Max]

Выглядит так, что та сторона присылает кодек speex/8000.
Такой кодек не поддерживается в браузере и бросает ошибку.

1. Попробовать выключить кодек speex на стороне сервера в конфиге flashphoner.properties

codecs_exclude_sip=speex16

2. Снять дамп SIP трафика между WCS - сервером и внешним PBX

UDP
tcpdump udp -s 4096 -w log.pcap

TCP
tcpdump tcp -B 10000 -w log.pcap

Дамп можно отправить нам на изучение через приватную форму или дать ссылку прямо здесь.

Со своей стороны попробуем воспроизвести проблему с софтфоном, который отправляет сразу два Speex - кодека: Speex 8000 и Speex 16000

 

[iejobs]

Отправил дампы по ссылке.
Кодек отключили, ошибка сохранилась, но, как мы смогли заметить, не во всех браузерах. На MacOS 12.2.1 в браузере Google Chrome 110.0.5481.177 (x86_64) проблема есть, в Safari проблемы нет, на EndeavourOS Linux (x86_64) BUILD_ID=2022.09.10 (6.1.19-1-lts) в браузере Google Chrome 109.0.5414.119 (x64) проблемы нет.

 

[Max]

Пришлите пожалуйста также лог консоли в Chrome браузере.

Developer Tools > Network > domain

Среди этих сообщений должен быть SDP конфиг.

 

[iejobs]

Отправил лог с консоли через ту же форму.

 

[Max]

Выглядит так, что от SIP стороны в INVITE SDP приходят кодеки speex 8000 и speex 16000, которые Chrome не может использовать одновременно

Поэтому браузер не может применить SDP, которое предлагается сервером. В наших тестах (звонок с софтфона со следующими кодеками: Speex 8000, Speex 16000, GSM на браузер, настройки WCS по умолчанию) проблема не воспроизводится с Chrome 111 на MacOS 12.6.3.
Одной из рекомендаций будет обновление браузера до 111 мажорной версии.
Также на стороне WCS можно использовать настройку

allow_outside_codecs=false

в этом случае в SDP для браузера не должно быть Speex 8000, пример для тестового звонка с вышеприведенными параметрами: