ded писал(а):Если связь м\у В и С по IAX, то на IAX пирах поставьте
trunk=yes
Это естественно было добавлено
Vlad1983 писал(а):на серваках с задействованными картами E1 "internal_timing = yes" не нужен они от потока синхронизируются
IAX2 при отсутствии NAT нафиг не нужен
Итак сегодня побывал на объекте, в общемто проблема в следующем, приходит звонок в очередь, диспечер берёт трубу, а там тишина, проходит несколько секунд и после этого он уже полноценно слышит абонента. Причём проблема плавающая, то она есть то её нет, и проявляется рандомно на нескольких диспечерах. Клиент везде одинаковый, настройки тоже. Хотел снять дамп по совету Влада, tcpdump -i any -vvvnn -s0 -w /tmp/cvac.cap udp, но идёт большое количество звонков, причём какой из них с дефектом не понятно.
это точно только с того сервака с E1?
если так - поиграйте с параметрами echo* в chan_dahdi.conf
можно такие выставить
echocancel=yes
echocancelwhenbridged=yes
echotraining=800
предпочитаю с картами не работать может кто подскажет у кого больше опыта с ними.
эхо наоборот надо выключать, нечего не даст
посмотрите внимательно - не падает ли канал на dahdi
что то типа - pri got event hdlc bad fcs (8) on d-channel of span цифра
И ещё небольшой не относящийся к теме вопрос:
Было пару раз что абонент зависает в очереди со статусом Busy,
его перерегистрируешь, а он остаётся висеть, соответственно звонки на него не приходят, решается
queue reload all
может есть какойто вариант сбрасывать таких автоматом?
Выключил эхоподавление на платах Е1 и на клиентах, а также шумоподавление, никакого эффекта. тожесамое периодически появляется задержка звука, диспечер первые несколько секунд не слышит звонящего, причём я понимаю еслиб проблема была у всех и постоянно, так она возникает рандомно, то есть то нет.
если серваки физически в одном месте стоят (точнее, нет канала связи между ними способного проседать), остаются 2 варианта:
1. подвисания софтфонов
2. несправляются CPU на серваках