Плохое качество связи и согласование вызовов по TCP

[elena.tsay.maximumtest]

Добрый день!

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

Подскажите, что именно нужно отключить в конфигурациях, чтобы отключить согласования звонков по TCP

 

[Max]

Добрый день.
Настройка

sip_force_tcp=false

должна помочь.
При этом лучше добавить настройку

allow_outside_codecs=false

чтобы SDP звонка не раздувалась лишними кодеками от клиентского браузера.

 

[elena.tsay.maximumtest]

Добрый день.

sip_force_tcp=false проставили данную настройку и у нас вообще перестали проходить звонки.

Делаем исходящий звонок и не можем "достучаться" до Манго и совершить звонок.

Подскажите, в чем может быть проблема?
Если нужны какие-то логи или наши конфиги, скажите что лучше предоставить

 

[Max]

sip_force_tcp=false проставили данную настройку и у нас вообще перестали проходить звонки.

Звонки не устанавливаются из-за того, что не проходит согласование кодеков. В свою очередь, согласование кодеков не проходит из-за того, что в SIP INVITE SDP перечислено слишком много кодеков, и SDP обрезается по размеру UDP пакета (1400 байт). В этом случае необходимо либо возвращать сигналинг на TCP, либо исключать все лишние кодеки. Например, оставить для SIP звонков только Opus и G711 кодеки для аудио и H264 для видео

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip=mpeg4-generic,flv,mpv,g729,speex16,g722,vp8
allow_outside_codecs=false

Если при звонках не используется видео, H264 тоже можно исключить.
При этом нужно смотреть, какие кодеки поддерживает SIP сервер. Если он не поддерживает Opus, его также можно исключить.

 

[elena.tsay.maximumtest]

Добрый день. Извиняемся, но не совсем поняли что убрать. Присылаю наши конфиги, можете пожалуйста посмотреть что именно нужно поменять.
ip_local=
codecs_exclude_sip_rtmp=opus,g729,g722,mpeg4-generic,vp8,mpv,speex16
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
ip=
wss.port=8443
ws.port=8080
codecs_exclude_streaming=flv,telephone-event
media_port_to=32000
#streaming_distributor_subgroup_enabled=true
rtc_ice_add_local_component=true
codecs_exclude_sip=mpeg4-generic,flv,mpv,g729,speex16,g722,h164,vp8
custom_stats_script=
client_mode=false
media_port_from=31001
ice_tcp_nio=false
sip_force_tcp=true
allow_outside_codecs=false
send_busy_when_on_call=true

 

[Max]

Варианты:

1. Оставляем только opus и telephone-event (DTMF)

codecs_exclude_sip=alaw,ulaw,g729,speex16,g722,mpeg4-generic,h264,vp8,flv,mpv

2. Оставляем только opus, alaw, ulaw и telephone-event (DTMF)

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

3. Оставляем только opus, alaw, ulaw, g729 и telephone-event (DTMF)

codecs_exclude_sip=speex16,g722,mpeg4-generic,h264,vp8,flv,mpv

Проверьте какой из вариантов у вас заработает.
Чем меньше кодеков, тем короче SDP. Поэтому приоритетный Вариант 1, где остается только Opus.

Далее проверьте SDP между WCS и манго в логе flashphoner.log или с помощью tcpdump udp -s 4096 -w log.pcap
SDP должно быть коротким и в нем должен быть только Opus кодек.

Т.е. в результате SDP должно быть коротким и звонки должны устанавливаться через UDP при настройке sip_force_tcp=false

 

[Max]

Далее проверьте SDP между WCS и манго в логе flashphoner.log или с помощью tcpdump udp -s 4096 -w log.pcap
SDP должно быть коротким и в нем должен быть только Opus кодек.

SIP - Web Call Server 5.2 - RU - Flashphoner Documentation

docs.flashphoner.com

Как проверить SIP трафик с помощью tcpdump и Wireshark

 

[elena.tsay.maximumtest]

Добрый день.

Спасибо за информацию.

Мы попробовали все 3 варианта:

При первом варианте пропал звук со стороны пользователя, но дозвон проходил, просто тишина

При втором варианте полностью отвалилась телефония на этапе ее включения (самый первым шагом мы запрашиваем в Манго статус пользователя)

3 вариант все работало, но так как мы не перестали получать жалобы пользователей на качество звука, то в Манго были направлены кейсы, когда плохой звук, и в настройках уже sip_force_tcp=false .

Ответ Манго был следующим. В связи с этим вопрос:
Какая минимальная скорость интернет -соединения у конечного пользователя должна быть для стабильного взаимодействия Бразурер - флешфоннер - телефония

 

[Max]

При первом варианте пропал звук со стороны пользователя, но дозвон проходил, просто тишина

При втором варианте полностью отвалилась телефония на этапе ее включения (самый первым шагом мы запрашиваем в Манго статус пользователя)

3 вариант все работало

Это говорит о том, что минимальный набор аудио кодеков для работы через Mango, следующий: Opus, PCMA (alaw), PCMU (ulaw), G729 (плюс обязательный telephone-event)

Какая минимальная скорость интернет -соединения у конечного пользователя должна быть для стабильного взаимодействия Бразурер - флешфоннер - телефония

Речь идет не о скорости, а о пропускной способности канала вызывающий абонент-WCS-SIP-вызываемый абонент. Для аудио звонков (без видео) требования к пропускной способности зависят от битрейта аудио, используемого в разговоре. Например, если связь установлена в кодеке Opus, и битрейт выставлен в 128 кбит/с (это качество уже не для речи, а для музыки в стерео), то минимальная пропускная способность канала от точки до точки должна быть не ниже 512 кбит/с.
То есть для аудио звонков в общем случае достаточно полосы в 1 Мбит/с.
Также на канале могут быть потери при использовании UDP для передачи медиа трафика. Повлиять на трафик между WCS и SIP-сервером в этой части мы не можем, но можно переключиться на TCP на участке между клиентом и WCS:

ice_tcp_transport=true

Это должно убрать потери, и, как следствие, улучшить качество со стороны абонентов, использующих WCS.

 

[Max]

В скриншотах, приведенных сотрудниками Mango, виден большой джиттер медиа пакетов и большая задержка между последовательными медиапакетами, отправленными WCS в сторону SIP-сервера

Такие задержки могут быть обусловлены, например, работой сборщика мусора (GC) Java на WCS сервере. Пожалуйста, убедитесь, что Вы выполнили рекомендации по настройке Java heap на сервере и включили сборщик мусора ZGC, который обеспечивает меньшие паузы в работе Java машины. После этого нужно собрать дамп трафика на стороне WCS при звонке и проверить, уменьшились ли задержка и джиттер.
Также соберите отчет, как описано здесь, включая дамп трафика, при помощи скрипта report.sh и пришлите, используя эту форму. Если архив отчета превышает 30 М, разместите его в облачном хранилище (Google Drive, OneDrive, Yandex Disk) и пришлите ссылку в комментарии к этой форме.