asterisk.ru

Asterisk 1.8.13.1. Старовата версия, но обновить возможности нет, ибо сборка интегрированная с 1С. Используются бюджетные IP-телефоны Grandstream GXP-1610 и софтфоны Zoiper Lite. Собственно, с грандстримами, подключенными в локалке проблем нет, связь отличная - все друг друга слышат. Проблема с грандстримами, находящиеся за пределами локалки в сети филиала, подключенного по VPN, а, также с Zoiper, который установлен на смарты сотрудников. Смартфоны находятся в Wi-Fi в одной локалке с Asterisk. Входящий звук всегда прекрасен, абсолютно на всех устройствах, но на исходящий жалобы на каждый второй звонок. Заикания, бульканья. Но, если прослушать запись такого проблемного звонка, то в записи звук чистый, никаких заиканий нет. tcpdump одного из таких звонков сделал.

1) Давно ли начался эффект?
2) У вас не виртуалка ли, часом? Если да, то какой гипервизор? И что показывает
cat /sys/devices/system/clocksource/clocksource0/current_clocksource ?
cat /sys/devices/system/clocksource/clocksource0/available_clocksource ...?

3) Пробуйте сделать звонок на эхо тест ( *43 - в варианте FreePBX) и также проанализировать через Wireshark.

ded писал(а):1) Давно ли начался эффект?

Сразу после попытки использовать вышеописанный способ коммуникации. Идеально работали только аппаратные телефоны, включенные в локалку.

ded писал(а):2) У вас не виртуалка ли, часом?

Не виртуалка. Вполне реальная банка, по характеристикам сейчас точно не скажу, но не раритет, вполне адекватные характеристики.

У вас выше описаны два способа коммуникации:
1) Grandstream GXP-1610, находящиеся за пределами локалки в сети филиала, подключенного по VPN,
2) Zoiper Lite в локальной сети по WiFi.

Проблема может быть в производительности VPN устройства, шифрографии на нём, несимметричном интернет-канале к сети филиалов, работе точки доступа WiFi, и др.
Каждый из элементов в этих цепочках можно протестировать, проанализировать, исключить для теста,
Например - пустить голос по другой технологии VPN, или отключить шифрацию, или протестировать другую модель софтфона.
Подчеркну: для изоляции проблемы нужно звонить-тестировать на эхо-тест.

ded писал(а):Подчеркну: для изоляции проблемы нужно звонить-тестировать на эхо-тест.

Спасибо за подсказку. Попробовал 2 эхотеста. Стандартный, который сразу все повторяет и тот, который пишет все, что говоришь до нажатия решетки, а потом проговаривает. Все это делалось с Zoiper Lite. Качество звука отличное. Никаких заиканий, помех и прерывания голоса нет. Такое же как при прослушивании записи разговора. Поэтому вроде и дамп выкладывать бессмысленно. Хотя я его и сделал. Ощущение, что отсутствует некая синхронизация голосовых потоков при реальном звонке. Но удивительно то, что при разговоре с IP-телефона, находящегося в локалке, такая проблема не наблюдается. Я понимаю, что по локалке пакеты ходят быстрее, чем по VPN и WiFi. Но на то ж есть jitter, чтобы оные пакеты ждать. Пробовал
jbenable=yes
jbforce=yes
jbimpl=adaptive
jbmaxsize=2000
Неэффективно.

Skew хреновый судя по скринам.

Skew is a measure of how late (or early) the current packet is for the total conversation (relative to the nominal packet rate). So if the packet rate should be 50 pps and say the 1000th packet of the conversation arrives 20.03 seconds after the 1st then the skew for that packet would be -30ms

адаптивный jitter не особо эффективен при подобном. В Wireshark в плеере RTP можно задать нужный jitter buffer - на нем и поиграться подобрать.

ded писал(а): что показывает
cat /sys/devices/system/clocksource/clocksource0/current_clocksource ?
cat /sys/devices/system/clocksource/clocksource0/available_clocksource ...?.

Deadlymic писал(а):Ощущение, что отсутствует некая синхронизация голосовых потоков при реальном звонке.

Вот эта самая синхронизация берётся из
current_clocksource
Хотя в 1.8 ещё наверное используется DAHDI/dummy
он присутствует по dahdi show channels ?
Должен быть pseudo там.

помимо всего прочего такое может быть из-за задваивания/затраивания/etc RTP
ловил такое из-за криво настроенного tinc-vpn
так же было на шлюзах одного вендора при исходящих в PSTN, причем только на определенном кодеке
сохранил на память:

Deadlymic писал(а):jbforce=yes

А это зачем?

Vlad1983 писал(а):помимо всего прочего такое может быть из-за задваивания/затраивания/etc RTP
ловил такое из-за криво настроенного tinc-vpn

Нет, у меня нет такого, Seq строго по порядку двумя счетчиками (в одну и в другую сторону).

amateur писал(а):А это зачем?

Сейчас это уже убрано.

Zavr2008 писал(а):он присутствует по dahdi show channels ?
Должен быть pseudo там.

Присутствует

Zavr2008 писал(а):адаптивный jitter не особо эффективен при подобном. В Wireshark в плеере RTP можно задать нужный jitter buffer - на нем и поиграться подобрать.

Да, тут уже что-то есть интересное. При jitter buffer 150 ms исчезают Drop by Jitter Buff (становится 0%) и при jitter buffer 330 ms исчезают черточки Wrong TimeStamp тоже.