Есть проблема гигасетов с последними прошивками микротиков 6.48.х, вариант откат на лонгтерм или попробовать отключить neighbor  обнаружение по протоколу mndp
/ip neighbor discovery-settings set protocol=cdp,lldp

не вчитывался, но может поможет
по контексту похоже вроде

Ого. Очень похоже, спасибо.

дополнительно по теме в том же чате

Вот  ответ переписка с ТП, обещали решить в скором времени, но это было в начале января:
The MNDP does differ from both versions. In the 6.47.8 version, the bridge ports are using the admin bridge MAC for the MNDP packets (хх:хх:хх:хх:хх:01), but in the 6.48 version, this behavior was changed and MNDP was sent by using the individual bridge port MAC addresses, in your example the хх:хх:хх:хх:хх:05 (from SFP1). This change is also mentioned in the changelog:
*) discovery - use interface MAC address when sending MNDP from slave port;

So my theory is this - the phones might periodically learn the wrong MAC address from these MNDP packets. Instead of using хх:хх:хх:хх:хх:01, phone are sending packets with the destination MAC address of хх:хх:хх:хх:хх:05.

There are a few ways how to test this:
1. You can try to disable the bridge fast-path under the "/interface bridge settings" menu. The slow path actually does not care if the destination MAC address is different from the admin-mac as long as the address is from one of the bridge slave ports. Try using these commands, enable the MNDP and see if problem is still active on 6.48.
/interface bridge settings set allow-fast-path=no
/ip neighbor discovery-settings set protocol=cdp,lldp ,mndp

2. You can try to change the bridge admin-mac to match with SFP1 mac. So, change the address and enable back the fast-path, and see if the phones are still working.
/interface bridge set [find name=bridge-inet] admin-mac=хх:хх:хх:хх:хх:05
/interface bridge settings set allow-fast-path=yes

Замечу что оба предложенных варианта работают.

добрый день, есть необходимость писать звонки в моно 8бит 8кгц, моно-стерео я понимаю как и где прописать, а остальные параметры диктуются кодеком?

Да. Сложности в записи были только с G722, где 16КГц вместо 8КГц такт. Потенциально могут быть приколы с OPUS по той же причине.
Если кто-то писал потоки с НЕ 8КГц кодеков, поделитесь, пожалуйста, опытом.

мне одновременно нужны и стереозаписи, которые будут храниться на сервере фс, и моно, которые отправляются на другой сервер. Задачами конвертации аудиофайлов фс заниматься не должен, по той информации, которую я впитал здесь. Но другого железа не будет( Как мне лучше поступить, писать скрипт, который вызывается из диалплана для переконвертации или использовать внешнее приложение (скриптик на питоне), которое подбирает файл и делает с ним все что угодно.

Ну да, сделайте скрипт

Да, лучше писать стерео и ПОТОМ внешним скриптом его как-то обрабатывать, как нужно.

привет коллеги!

подвисла сессия,
fs_cli -x "uuid_kill 0e7fd6d9-e174-44b3-a8d9-018dc05bb18a"
-ERR No such channel!
не работает
перегружать ФС не вариант, много звонков

по идентификаторам не киляется

mod_xml_curl есть?

он сессии в бд хранит. удалите из БД запись

да

он не может достучаться до сервера и держит сессию потушенную уже в списке

пока таймауты и попытки не выйдут - не отпустит