Циска выдает следующее:

12:43:55.092: %CONTROLLER-5-UPDOWN: Controller E1 2/1, changed state to up
12:43:55.100: ISDN Se2/1:15 SERROR: service_queue_from_physical_layer: got ISDN_PH_ACT_IND on an active interface?
12:43:55.112: %ISDN-6-LAYER2UP: Layer 2 for Interface Se2/1:15, TEI 0 changed to up
12:43:57.092: %LINK-3-UPDOWN: Interface Serial2/1:15, changed state to up
12:44:37.840: %CONTROLLER-5-UPDOWN: Controller E1 2/1, changed state to down (RAI detected)
12:44:37.860: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se2/1:15, TEI 0 changed to down
12:44:39.840: %LINK-3-UPDOWN: Interface Serial2/1:15, changed state to down
12:44:42.848: ISDN Se2/1:15 SERROR: Pri_Activate_L2: BAD states = 0, 0; IDBS_UP 4

и дальше по кругу

Это в варианте когда циска мастером а TE110P слейвом, напомню в таком варианте вообще не работает (астер в консоли сыплет алармы постоянно, все подробности и конфиги в первом сообщении этой темы)

Если кто может и хочет помочь за скромное ДЕНЕЖНОЕ вознаграждение стучите в асю 12848233, дам рута на астер и циску, но актуально это пару дней. Нужно либо срочно решить за деньги либо уже дальше ковыряться самому из принципа.

помоему тут надо плясять от RAI E1_alarms
A Remote Alarm Indication (RAI) means that the far-end equipment has a problem with the signal it is receiving from the local equipment.
Что-то похоже с работой приёмника на TE110P не то.
Ты писал, что у тебя кабель короткий между Cisco и TE110P. А случайно для E1 нет минимальной длины кабеля, ну типа как в коаксиальной сети - не менее 2 м. Может тебе попробовать кабель подлиньше поставить?

Ну вроде это значит что линк рвется по инициативе TE110P - тоесть она аларм выставляет.
Причем при обрыве астер говорит еще вот что (раньше не замечал):

[Feb 17 00:19:22] ERROR[546]: chan_zap.c:9047 zt_pri_error: Write to 39 failed: Unknown error 500
[Feb 17 00:19:22] ERROR[546]: chan_zap.c:9047 zt_pri_error: Short write: 0/15 (Unknown error 500)
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:3977 zt_handle_event: Detected alarm on channel 1: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 2: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 3: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 4: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 5: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 6: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 7: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 8: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 9: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 10: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 11: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 12: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 13: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 14: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 15: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 17: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 18: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 19: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 20: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 21: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 22: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 23: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 24: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 25: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 26: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 27: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 28: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 29: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 30: Red Alarm
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:6972 handle_init_event: Detected alarm on channel 31: Red Alarm
[Feb 17 00:19:22] NOTICE[546]: chan_zap.c:9333 pri_dchannel: PRI got event: Alarm (4) on Primary D-channel of span 1
[Feb 17 00:19:22] WARNING[546]: chan_zap.c:2563 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway!
Really destroying SIP dialog 'af678ae1-8d03c730@194.9.0.102' Method: ACK
== Primary D-Channel on span 1 down
[Feb 17 00:19:25] WARNING[546]: chan_zap.c:2563 pri_find_dchan: No D-channels available! Using Primary channel 16 as D-channel anyway!
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 1
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 2
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 3
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 4
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 5
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 6
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 7
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 8
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 9
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 10
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 11
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 12
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 13
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 14
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 15
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 17
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 18
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 19
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 20
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 21
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 22
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 23
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 24
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 25
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 26
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 27
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 28
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 29
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 30
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:6965 handle_init_event: Alarm cleared on channel 31
[Feb 17 00:19:27] NOTICE[546]: chan_zap.c:9333 pri_dchannel: PRI got event: No more alarm (5) on Primary D-channel of span 1
== Primary D-Channel on span 1 up

Похоже дело в перавх двух строчках, но что это значит - непонимаю.

Mike_AЧто-то похоже с работой приёмника на TE110P не то.
Ты писал, что у тебя кабель короткий между Cisco и TE110P. А случайно для E1 нет минимальной длины кабеля, ну типа как в коаксиальной сети - не менее 2 м. Может тебе попробовать кабель подлиньше поставить?

Пробовал - без разницы....

Пробовал подключать к мини-АТС SAMSUNG iDCS-500, плата TEPRI, самсунг слейвом, TE110P мастером (пробовал и наоборот - см ниже)
Тезультат еще хуже - на плате TEPRI горит индикатор SYN, что означает проблемы с синхронизацией, причем горит в полнакала. Если кабель отключить то этот индикатор горит с нормальной яркостью.
Также индикатор CLK не горит (если плата является источником синхронизации, тоесть мастер, то не должен гореть, если приемником, тоесть слейв, то должен) хотя плата выставлена слейвом (установки делаются дип-переключателями на плате). Причем состояние индикатора CLK не зависит от того как выставлены переключатели на плате и как мастер/слейв в zaptel.conf.
Хотя при подключении к заведомо нормальному PRI (от телекома) все нормально - индикатор горит (при том что плата слейвом - все как и должно быть).

Тоесть похоже таки у TE110P проблемы с синхронизацией, и дело либо в железе (материнка итд) либо в заптеле....

http://www.asterisk-support.ru/forums/configuration/43082448055
попробуй договорись с кем-нить поюзать другую заведомо рабочую лучше плату.. :(
иначе замучаешься если как у меня было получится....

Да в том-то и дело что нескем :-(
Я уже и свою отдать готов чтоб поставили в заведомо рабочую конфигурацию, но некому, а карту взять темболее.
Сейчас пробую найти Asus P4P800 - слышал от 2х людей какминимум именно в этой маме у них работает, а так пытался проводить опрос так подавляющее большинство на вопрос "в какой МОДЕЛИ МАТЕРИНКИ у вас работает TE110P" отвечают что-то типа "P4 512 мег памяти" ;-)
Еще на астериск орг в форуме читал что на 865/945 чипсетах должно работать. Короче попробую несколько материнок и если не пойдет верну продавцу...
Кстати а у тебя какая материнка? ;-)

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

У меня таже проблема, во всяком случаи очень похожа.
На i865 матери+Celeron уже 4 месяца пашет te110p, причем поднилась достаточно легко (без особых проблем).
Купили мне HP ML150 и еще одну te110p, уже неделю танцую с бубном не фига не получается.
Соединиение встает->падает и так все время, пробобовал: кабель, версию kernel и linux.
Завтра буду пробывать заменить te110p на рабочей системе.
Есть еще вариант покопатся в bios, а может дело в kernel-smp?

Все оказалось до противности просто.
На станции просто разбились контакты куда расшивали кабель и был прохой контакт.