Помигите всезнающие !!!
Устнавил первую в жизни реальную (для небольшой конторы) систему.

HP Proliant ML110 G4, Debian 4.0 (ядро 2.6.18.6), Asterisk 1.4.22.
Связь с миром через BN4S0 (ISDN) y AEX800P (ANALOG)
Внутри - 8 телефонов GrandStream (GSX1200, GSX2000, GSX2020) и там небольшой набор факсов и аналоговых телефонов

1. В течении первой же недели получаем жалобу, что при разговорах между ГрандСтримами - эхо (по словам пользователей - "как будто в пещере")

2. Около 30% входящих звонков (все входящие через RDSI и принимаются на ГрандСтримах) - начиная с проигрывания Playback(msg_welcom) и последующим разговором на ГрандСтриме - голос "как у ДжиДаев в STAR WARS", причем испорченный звук только для звонящего (принимающий звонок ни о чем не догадывается).
--------------------

Все собиралось по следующему руководству:
http://www.howtoforge.com/asterisk-zaptel-libpri-misdn-asterisk-addons-asterisk-gui-on-debian-etch

Замерялись, загрузка CPU - не больше 2%, памяти - не больше 50%. В консоле * ошибок нет, в логах системы иногда (три-четыре раза в день) появляются следующие записи:

Nov 7 21:08:42 pbx kernel: hfcmulti_rx: CRC-error
Nov 7 21:21:50 pbx kernel: ECHOCAN: TXBUF Underrun:4097 txbuflen:65 rxcancellen:128
Nov 7 21:22:58 pbx kernel: hfcmulti_rx: CRC-error

Где копать ?????

Спасибо.

Первое что приходит в голову - копать в сторону драйвера сетевого интерфейса либо исправности железа на нём.
Второе - копать в сторону надёжности СПД, в которой работает сервер и грандстримы. Убедиться, что свичи не теряют пакеты. Если порты часто выходят на полку, надо наладить косы и приоритизацию для воипного трафика.
Третье - копать в сторону надёжности самих грандстримов либо правильности их настроек. В бытность получения опыта с D-link DVG, я встречал некоторые отдельные экземпляры железок которые давали ужасное качество звука. Хоть Грандстрим это не D-link, но малоли что может быть. С эхом можно попробовать побороться изменяя настройки джиттера как на сервере, так и на грандстримах.

Все телефоны и "астериск" воткнуты в один свитч - по статистике портов - потери пакетов (точнее ошибок по портам) никаких нет, Грандстримы настроены "по-умолчанию". Читал на различных форумах - что "эхо" между SIP телефонами, впринципе, не возможно. Также странно оно и для ISDN линий. Как раз мой случай, только - наоборот.

Что здесь странного?

Вы посмотрите у себя, как проходит вызов, когда появляется эхо. Точно он не идет через Zap-каналы?

1. Какой канал используется для связи с миром через BN4S0 (ISDN)?
zap_hfc ? chan_misdn ?

2. Во время жеванного разговора:
CLI>sip show channels ?

3. cat /proc/interrupts ?

1. BN4S0 - используем chan_misdn
2. завтра попытаемся отследить
3. cat /proc/interrupts
USB, COM, LPT, etc порты отключены в БИОСЕ. Материнка не позволяет назначить опреледенное IRQ для PCI-шины. Ядро было перекомпилировано с параметром IRQ-Balancing: Disable (по многочисленным советам на интернет форумах)

CPU0 CPU1
0: 612970155 55979 IO-APIC-edge timer
1: 0 0 IO-APIC-edge i8042
8: 627566413 67503 IO-APIC-edge rtc
9: 1 0 IO-APIC-level acpi
14: 65 0 IO-APIC-edge ide0
50: 9956254 0 PCI-MSI eth0
177: 612872338 56768 IO-APIC-level uhci_hcd:usb4, wctdm24xxp0
217: 2 0 IO-APIC-level uhci_hcd:usb1, ehci_hcd:usb5
225: 236426 41 IO-APIC-level uhci_hcd:usb2, libata
233: 38304807 3839 IO-APIC-level uhci_hcd:usb3, HFC-multi
NMI: 0 0
LOC: 594482768 594478983
ERR: 0
MIS: 0

Я думаю нет. Непроходит через ZAP:

Connected to Asterisk 1.4.22 currently running on pbx (pid = 2918)
Verbosity is at least 4
-- Executing [0963852520@misdn:1] Answer("mISDN/4-u1919", "") in new stack
-- Executing [0963852520@misdn:2] Wait("mISDN/4-u1919", "1") in new stack
-- Executing [0963852520@misdn:3] Goto("mISDN/4-u1919", "msg-welcome|s|1") in new stack
-- Goto (msg-welcome,s,1)
-- Executing [s@msg-welcome:1] Answer("mISDN/4-u1919", "") in new stack
....
-- Executing [s@msg-welcome:12] Playback("mISDN/4-u1919", "custom/msg-outofwork") in new stack
-- <mISDN/4-u1919> Playing 'custom/msg-outofwork'

Ядро конечно перекомпилировано, но IO-APIC всё равно использует share interrupts.
Налицо две проблемные зоны:
177: 612872338 56768 IO-APIC-level uhci_hcd:usb4, wctdm24xxp0
233: 38304807 3839 IO-APIC-level uhci_hcd:usb3, HFC-multi

то еcть оба драйвера - делят прерывания с USB: wctdm24xxp0 на одном 177 с uhci_hcd:usb4
и
HFC-multi на одном 233 с uhci_hcd:usb3

А используется ли ztdummy?

1) Попробуйте всё таки на обычном ядре, и если проблема останется, то
2) указать в загрузчике ядра параметр noapic

Но это не критично, вот записи hfcmulti_rx: CRC-error
ECHOCAN: TXBUF Underrun:4097 txbuflen:65 rxcancellen:128
вполне тревожные, говорят о том, что включеный механизм эхоподавления плохо работает, и регулярно валится из-за переполнения буфера.
Если на карте HFC-multi нет аппаратного эхоподавления, то надо вообще его отключить в конфиге misdn.conf, а если эхо будет отчетливо слышно, то установить OSLEC. Но это не простой ход, зато эффективный.

Btw, полагаю это где-то в Испании, Валенсия, офтальмологическая клиника Castro?

Это из первого поста.

alphil:

1. В течении первой же недели получаем жалобу, что при разговорах между ГрандСтримами - эхо (по словам пользователей - "как будто в пещере")

А оказлось, что эхо не между ГрандСтримами, а из канала mISDN ...

В misdn.conf параметры - echocancel и echotraining по умолчанию выключены. Вы там что нибудь прописывали?

В БИОСе все контролеры USB и порты USB отключены DISABLE, я конечно вижу что они появляются в списке interrupts, но надеялся, что ни как не влияют на работу астериск-карт ???

А используется ли ztdummy?

Тут я немного затрудняюсь ответить. Думаю, что да:
=======================================================
dahdi show status
Description Alarms IRQ bpviol CRC4
Wildcard AEX800 Board 1 OK 6 0 0
ZTDUMMY/1 (source: RTC) 1 UNCONFIGUR 0 0 0
========================================================

Хотя одновременно при этом присутсвует Digium карта AEX800

1) Попробуйте всё таки на обычном ядре, и если проблема останется, то
2) указать в загрузчике ядра параметр noapic

Попробуем

Но это не критично, вот записи hfcmulti_rx: CRC-error
ECHOCAN: TXBUF Underrun:4097 txbuflen:65 rxcancellen:128
вполне тревожные, говорят о том, что включеный механизм эхоподавления плохо работает, и регулярно валится из-за переполнения буфера.

Если на карте HFC-multi нет аппаратного эхоподавления, то надо вообще его отключить в конфиге misdn.conf, а если эхо будет отчетливо слышно, то установить OSLEC. Но это не простой ход, зато эффективный.

Спасибо за советы, попробуем все чио вы сказали. Хочу подтвердить, замеченое пользователем "cron333", в линиях mISDN у меня жеваный звук, а при внутренних разговорах по GrandStream - эхо (как будто в пещере).

Btw, полагаю это где-то в Испании, Валенсия, офтальмологическая клиника Castro?

Откуда такая проницательнось ;-) По номеру телефона, 963... ???