Звонок

[ssyefremov]

Добрый день всем!

Asterisk Asterisk 14.2.1
Linux srv-astrisk 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Произошёл случай на который не могу найти ответ.
В 11:00 пользователь "А" создал конференцию, собрав несколько пользователей... Общались они долго...
В 11:29 пользотель "Б" позвонил пользователю "С" и они начали разговор...
В это же время, все пользователи в конференции пользователя "А", начинают слышать разговор пользователей "Б" и "С"... Но не постоянно, а голоса то появлялись с хрипением и помехами, то пропадали... Со слов тех, кто был в конференции, было ощущение, что кто-то включал и выключал микрофон на громкую связь... Один из участников конференции узнал голоса пользователя "Б" и "С" и пытался донести, что их слышат в конференции, но никакй реакции не последовало...
При этом, в разговоре пользователей "Б" и "С" никаких посторонних звуков и голосов слышно не было...
После того, как узнавший голоса набрал одному из них на мобильный и сообщил что их слышно, то разговор между "Б" и "С" был завершён, положив трубки...
Конференция продолжилась дальше в нормальном режиме...

Исходя со слов всех пользователей, логов и cdr:
1. У всех звонков разные идентификаторы вызова...
2. Никаких странных процессов в это время не обнаружено...
3. Разговор начали слышать не с самого начала, а слышимость по появлялась, то появлялась в плавающем режиме...

Надеюсь, что хоть что-то понятно из описания
Может кто-то сталкивался с подобным.
Или знает куда копать, что смотреть?
Логических объяснений, как могло RTP разных звонков пересекаться, пересекатся в одностороннем режиме (одни слышать, другие нет), да ещё и не постоянно...

Заранее благодарю, за любые подсказки

[virus_net]

Или знает куда копать, что смотреть?

В данном случае копают только в двух направлениях:

• а) исходный код
  б) размещения сообщения о баге для разработчиков

Что не понятно так это то зачем вы используете 14-ю девелоперскую ветку Asterisk и при этом спрашиваете куда копать.

[whoim]

Сталкивался с похожим. Помогла только упаковка каналов от офисов до сервера в vpn. То есть - загон на уровне прова/сормов)

Начиналось в момент запуска допофиса в соседнем государстве, с которым сейчас тёрки)

Второе предположение - путаница ртп в микротике. Ибо голоса из разных офисов не пересекались никогда.

[ssyefremov]

Благодарю за ответы.

Что не понятно так это то зачем вы используете 14-ю девелоперскую ветку Asterisk и при этом спрашиваете куда копать.

Ну тут всё просто... астериск достался в "наследство"... приходится пользоваться чем есть...
Откатывать на 13-ю весьма проблематично, т.к. идёт завязка на колл центры, которые работают 24/7...

Сталкивался с похожим. Помогла только упаковка каналов от офисов до сервера в vpn.

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

Второе предположение - путаница ртп в микротике.

В данном случае микротиков нет, вся маршрутизация на цисках...
Но, путаница ртп - это интересно... Можете чуть подробнее описать?
Опишу как вижу это я, но легко могу ошибаться...
РТП пакет имеет src и dst адрес... Если бы с пакетом что-то произошло, то не сошлась бы хэш сумма и пакет отбросился...
Ну допустим, что так подмена произошла и ртп ушло не туда... Тогда, данное ртп не дошло бы до оригинального адресата, но пользователи "Б" и "С" слышали друг друга отлично и никаких выпадений букв и слов у них небыло (ну это с их слов, но оснований не доверять нет). Получается, что ртп имели правильную адресацию.
Т.е. получается, что произошло что-то типа дублирования ртп... но не всех, а выборочно (т.е. чужой разговор то слышали в конференции, то переставали слышать)... плюс к этому в дублированных ртп появились шумы и помехи... как "шипение" и "хрипение" может появиться в цифровых пакетах - так ещё загадка для меня...

[virus_net]

Значит настала пора менять наследство. Не только у вас есть момент с 24/7 и это не является препятствием для объявления регламентных работ.
От нас то вы чего ждёте ? Волшебного порошка? Его нет.
Для понимания можно сделать запись всего трафика и при повторном появлении проблемы разбирать его в Wireshark

[ssyefremov]

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

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

За рекомендации благодарю!!!
Придётся искать волшебный порошок... вдруг есть у кого-то

[ded]

Разъяснения:
в современных системах для записи разговоров происходит транскодинг alaw & ulaw в slin - вопрос: зачем?
Потому что только он может синхронизироваться в разговоре по двум потокам: входящий и исходящий аудио. Если такой синхронизации не было бы, то тогда записанный разговор, особенно длинный, оставлял бы странное впечатление: собеседники как будто не друг с другом, а с кем-то ещё разговаривают. Ничтожная дельта по скорости начинает нарастать, и к концу разговора - полная нестыковка по смыслу.

Вот пример трансляции через slin

As stated in the introduction, generic PLC can only be used on slin audio. The majority of audio communication is not done in slin, but rather using lower bandwidth codecs. This means that for PLC to be used, there must be a translation step involving slin on the write path of a channel. One item of note is that slin must be present on the write path of a channel since that is the path where PLC is applied. Consider that Asterisk is bridging channels A and B. A uses ulaw for audio and B uses GSM. This translation involves slin, so things are shaping up well for PLC.

https://wiki.asterisk.org/wiki/display/ ... ranslation
* PLC = Packet Loss Concealment

Современные админы уже и не знают такие проблемы, они наблюдались много лет назад в Астериске. Зато они преуспели в виртуализаторах, и, даже сложные, производительные узлы упорно строят как виртуальные машины. Где проблема синхронизации тянется от аппаратных источников синхронизации, которые совсем оторваны от синтетических clock source, используемых в виртуальных машинах.
У вас, вероятно, как раз такой случай.

[whoim]

ded, у них явно чужие голоса в потоке, а не рассмнзронизация двух плеч в записи.
---
Автору - подробнее не объясню, поразбиратся не успел. Офисы упаковали в vpn и все прошло.
На записях при этом все было нормально, лишних голосов не было. В реальности одна из сторон слышала левые голоса или чужие кпв.
Помню ещё, что помогал ребут головного маршрутизатора в офисе. На некоторое время. Потом жалобы начинали идти по нарастающей.

[ded]

Ключевая исходная инфа всё же

пользователь "А" создал конференцию, собрав несколько пользователей...

Обратимся к первоисточникам (Eplained by Malcolm Davenport and Rusty Newton on Mar 30, 2016):

Asterisk, since its early days, has offered a conferencing application called MeetMe (app_meetme.so). MeetMe provides DAHDI-mixed software-based bridges for multi-party audio conferencing. MeetMe is used by nearly all Asterisk implementations - small office, call center, large office, feature-server, third-party application, etc. It has been extremely successful as an audio bridge.
Over time, several significant limitations of MeetMe have been encountered by its users. Among these are two of distinction: MeetMe requires DAHDI for mixing, and is thus limited to 8kHz (PSTN) audio sampling rates; and MeetMe is delivered in a fairly static form, it does not provide extensive configuration options.
To address these limitations, a new conferencing application, based upon the ConfBridge application introduced in Asterisk 1.6.0, is now available with Asterisk 10. This new ConfBridge application replaces the older ConfBridge application. It is not intended to be a direct replacement for MeetMe, it will not provide feature parity with the MeetMe application. Instead, the new ConfBridge application delivers a completely redesigned set of functionality that most users will find more than sufficient, and in many ways better, for their conferencing needs.

Старый MeetMe (модуль конференций) зависил от аппаратного тайминга DAHDI. Новый - ConfBridge освободился от тайминга DAHDI, но не может полностью освободиться от тайминга вообще, он нужен для смешивания разных аудиопотоков, как и в случае с записью через MixMonitor. И вот тут то кроется засада.

Код: Выделить всё

[root@localhost ~]# cat /sys/devices/system/clocksource/clocksource0/available_clocksource ?

[root@localhost ~]# echo "hpet" > /sys/devices/system/clocksource/clocksource0/current_clocksource
[root@localhost ~]# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

[virus_net]

Писать запись всего трафика весьма проблематично

Не понимаю что тут проблематичного. Кто-то ищет обоснования для "почему нет" (это вы), а кто-то ищет обоснования для "а как же можно осуществить" (это я).
Потому у меня сразу рождаются варианты:

• - для ленивых: просим людей, которые собирают конфу, перед этим оповестить себя любимого и включаем запись только в этом случае
  - для продвинутых: встраиваем запуск записи в диалплан, там где и собирается конфа и оповещаем себя любимого об этом посредством звонка/письма/смс/месенджера
  - затираем предыдущий собранный, если проблема не происходила
  - и т.п.

ИМХО: Вы просто ленитесь. Переписываться на форуме и искать "почему нет" гораздо проще, чем расковыривать проблему.

Придётся искать волшебный порошок... вдруг есть у кого-то

Удачи !