Схема такая

Оператор-(E1 EUROISDN)-ATC1-(E1 EuroISDN)-Asterisk1-(IP IAX2)-Asterisk2-(E1 EuroISDN)-ATC2

При звонках с АТС2 и на АТС2 иногда происходы прерывание разговора, иногда на несколько секунд иногда на савсем. Дело точно не в потери ИП пакетов така как схема пока тестовая и оба астериска воткнуты в один свитч. При этом в логах Asterisk2 в районе времени прерванного разговора наблюдаются вот такие сообщения

Oct 13 10:10:30 VERBOSE[485] logger.c: !! Got reject for frame 99, but we have nothing -- resetting!
Oct 13 10:27:22 VERBOSE[485] logger.c: !! Got reject for frame 27, but we have nothing -- resetting!
Oct 13 10:28:10 VERBOSE[485] logger.c: !! Got reject for frame 47, but we have nothing -- resetting!
Oct 13 10:28:52 VERBOSE[485] logger.c: !! Got reject for frame 51, but we have nothing -- resetting!
Oct 13 10:31:45 VERBOSE[485] logger.c: !! Got reject for frame 34, but we have nothing -- resetting!
Oct 13 10:53:15 VERBOSE[485] logger.c: !! Got reject for frame 30, retransmitting frame 30 now, updating n_r!
Oct 13 10:53:15 VERBOSE[485] logger.c: !! Got reject for frame 31, but we have nothing -- resetting!
Oct 13 10:55:57 VERBOSE[485] logger.c: !! Got reject for frame 16, retransmitting frame 16 now, updating n_r!
Oct 13 10:55:57 VERBOSE[485] logger.c: !! Got reject for frame 16, retransmitting frame 17 now, updating n_r!
Oct 13 10:56:42 VERBOSE[485] logger.c: !! Got reject for frame 13, retransmitting frame 13 now, updating n_r!
Oct 13 10:56:42 VERBOSE[485] logger.c: !! Got reject for frame 13, retransmitting frame 14 now, updating n_r!


а также есть еще такие сообщения

Oct 13 09:26:52 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 09:59:43 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:14:05 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:28:57 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:47:58 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:51:33 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:55:22 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up
Oct 13 10:56:32 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up

Система FreeBSD 6.1 Asterisk 1.12.1 libpri 1.2.3 на обоих астерисках

На Asterisk1 подобных проблем не наблюдается.

ATC2 - LG LDK100, ATC1 - Meridian 11C
В Астериск1 стоит TE210P в Asterisk2 - TE110P

настроикий zaptel.conf и zapata.conf на обоих астерисках одинаковые, кроме того, что на первом астериске стоит pri_net, а на втором pri_cpe.

Подобная проблема была, когда я соединял два астериска по E1 в тестовых целях.

настроики на asterisk2

zptel.conf

span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

loadzone=us
defaultzone=us

zapata.conf

resetinterval = 3600
overlapdial=yes
signalling=pri_net
echocancel=yes
echocancelwhenbridged=no
echotraining=yes
rxgain=0.0
txgain=0.0
musiconhold=default
jitterbuffers=5

context = lg_zap
group = 2
switchtype = euroisdn
signalling = pri_cpe
overlapdial = yes
channel => 1-15


Есть какие-нибудь идеи в чем может быть проблема?

Было дело.

1. Поставил Libpri Version 1.4.0-beta1, пропало:
"Oct 13 09:26:52 VERBOSE[485] logger.c: == Primary D-Channel on span 1 up "

2. Для каждой Digium карты надо выделить отдельную линию IRQ, чтоб на ней никто не сидел больше.

Если это условие не выполняется, выползает сообщение:
"Can not use fast interrupts, switching to generic"
при загрузке модуля.

1. Меня смущает слово beta1 :). Хотя придется попробовать.
2. Да все проде нормально с IRQ

Zapata Telephony Interface Registered on major 196
Echo Canceller: MARK3
T1/E1 device: vendor=e159 device=1 subvendor=795e
wcte11xp0: <Digium Wildcard TE110P T1/E1 Board> port 0xc400-0xc4ff mem 0xef001000-0xef001fff irq 22 at device 2.0 on pci2
WCT1xxP Attach for wcte11xp0: deviceID : 0xe159
wcte11xp0: [FAST]
FALC version: 00000000
TE110P: Setting up global serial parameters for E1 FALC V1.2
TE110P: Successfully initialized serial bus for card
Found a Wildcard: Digium Wildcard TE110P T1/E1
Registered tone zone 0 (United States / North America)
TE110P: Span configured for CCS/HDB3

1.4.0 beta1 не помог.


Обнаружил такой вот глюк на Asterisk2

zaptel.conf

span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

loadzone=us
defaultzone=us

zttool показывает

Sync Source: Internally clocked

хотя с теми же настройками на Астериск1

zaptel.conf

span=1,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

span=2,0,0,ccs,hdb3
bchan=32-46,48-62
dchan=47

loadzone=us
defaultzone=us

zttool показывает

Sync Source: T2XXP (PCI) Card 0 Span 1

В чем может быть проблема?
zaptel стоит один и тот же на обоих машинах.

мне кажется прерывания теряются - глянь что zttest -v говорит.
попробуй top на второй машине под нагрузкой посмотреть (какая загрузка процессора, la).

да edo дело говорит, ещё возможно просто на PCI шине где ваша карты висит просто большая загрузка или процессор данные не успевает выгребать со спанов. Загрузку процессора в студию.

Вообщем разобрался почему на Астериск2 было

Sync Source: Internally clocked

Оказывается если zaptel не видит синхробиты в потоке, то он автоматически преклучается на внутренний источник синхронизации, что собственно логично, я это как то упустил. Так вот zaptel не видит эти синхробиты от ATC2, у меня складывается такое впечатление, сто эта АТС2 их вообще не выдает, либо они теряются где то по пути (на пути стоит еще 2 FCD-IP). Хотя согласно мануалу должен выдавать. Развернул Синхронизацию в обратную сторону.

zaptel.conf

span=1,0,0,ccs,hdb3
bchan=1-15,17-31
dchan=16

loadzone=us
defaultzone=us

Теперь в консоль время от времени валится вот такое

Oct 17 09:53:43 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Oct 17 09:54:06 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:54:41 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Oct 17 09:54:50 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Oct 17 09:55:16 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:55:42 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Oct 17 09:57:37 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:58:05 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:58:09 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:59:01 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 09:59:06 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 10:00:48 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 10:03:57 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Oct 17 10:04:40 NOTICE[485] chan_zap.c: PRI got event: HDLC Bad FCS (8) on Primary D-channel of span 1
Oct 17 10:04:59 NOTICE[485] chan_zap.c: PRI got event: HDLC Abort (6) on Primary D-channel of span 1


Что касается загрузки процессора, то врядли

load averages: 0.25, 0.14, 0.09

это где то при 8 одновременных вызовах, максимум возможно 15.

zttest -v
Opened pseudo zap interface, measuring accuracy...

8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8191 sample intervals 99.987793%
8192 samples in 8193 sample intervals 99.987793%
8192 samples in 8192 sample intervals 100.000000%
8192 samples in 8192 sample intervals 100.000000% ^C
--- Results after 20 passes ---
Best: 100.000000 -- Worst: 99.987793 -- Average: 99.998779

Прерывается ли щас разговор пока не знаю, жду отклика пользователей.

Cинхробиты будем их более правильно метками фрейма называть выдаются обеими сторонами постоянно, как мастером на E1 так и слэйвом так что ваша гипотеза не верна или ваша АТС просто не работает.

Приведённая вами статистика не показательна, у вас нарушение hdlc фрейминга примерно раз в минуту а статистику для zttest вы набирали около 20 секунд, конечно вы ничего не увидите. Ещё скажу ошибки фрейминга набегают не регулярным образом, следовательно дело не в слипах на E1 потоке а скорее всего именно в тормозах на PCI или на пиках загрузки процессора load average не самый лучший показатель.

В качестве резюме, советую в следующий раз покупать нормальную карту, с нормальным E1 трансивером, не требующим ручной подстройки, полноценными средствами для мониторинга E1 потока и возможно индикатором загрузки PCI шины, ну и русскоязычной поддержкой естественно.

Советую взглянуть на платы Российских производителей
parabel.ru
cronyx.ru

АТС не может не работать, так как она работает и звонки через нее совершаются.

last pid: 3828; load averages: 0.10, 0.06, 0.02 up 0+23:17:45 12:56:46
56 processes: 1 running, 55 sleeping
CPU states: 1.9% user, 0.0% nice, 10.2% system, 0.4% interrupt, 87.6% idle
Mem: 48M Active, 193M Inact, 70M Wired, 12K Cache, 60M Buf, 183M Free
Swap: 1024M Total, 1024M Free

Не может быть это связано с загрузкой процессора, такие ошибки случаются при загрузке процессора порядка 10%.

А с чем могут быть связаны тормаза на PCI? у меня ничего дополнительного кроме этой карточки там не стоит.

Более того скажу, что такие сообщения вываливаются даже в отсутвие звонков через сервер.

Т.е. платы Digium считаются ненормальными?

по поводу zttest, он мне выдает такое вот
zttest -v
Unable to open zap interface: No such file or directory

Почемуто этот pseudo channel у меня иногда исчезает

да кто его знает. в первую очередь чипсет, во вторую мамка (если именно о pci речь)

Более того скажу, что такие сообщения вываливаются даже в отсутвие звонков через сервер.

понятное дело - поток в 2 мегабита идет вне зависимости от наличия звонков в нем

по поводу zttest, он мне выдает такое вот
zttest -v
Unable to open zap interface: No such file or directory

Почемуто этот pseudo channel у меня иногда исчезает

чудеса какие-то.