Вообщем, как показали мои эксперементы, эти ошибки не приводят к прерыванию разговора, по крайней мере в моих эксперементах такого не было.

насчет чудес , то да оин происходят причем на обоих астерисках, помогает только перезагрузка машины.

Да везде читал, что подобные ошибки связаны с конфликтом прерываний, но хочу заметить, что когда у меня синхронизация была развернута в другу сторону и соответсвено в zaptel.conf было настроено на синхронизацию с потока, то таких ошибок не было.

Ладно буду разбираться.

Так давайте дальше разбираться, так всё таки кто у вас мастер на E1? Если АТС выдаёт синхробиты - это всеголишь означает, что включен фреймированный режим E1, а не прозрачный g.703, к конфигурации мастер-слэйв на E1 это не имеет отношения.

что такое?!? написал сообщение, а оно исчезло.

по поводу чудес - копай в сторону udev, devfs и подобного.

насчет ldk 100 - у меня такая же, скорее всего у него стоит урезанный вариант платы pri, который умеет быть только slave.
сейчас вспомнил, что когда ставил prib вместе с ней поставил pllu (за точность названий не ручаюсь ;)). это такая мелкая плата с кварцем, используется для синхронизации станции от потока (?!?). по поводу необходимости этой платки были сомнения (если она обязательна - то почему её нет в базовой поставке), но поскольку очень рекомендовали её поставить и стоит она недорого, то воткнул. может быть в этом у тебя проблема?

Ну хорошо, давайте разбираться

Мастером назначен ATC2 (LG LDK100). Я не знаю какой режим там включен, там есть только одна перемычка, которая отвечает за это, переключающая режимы NT(мастер) и TE(slave). На пути до Астериск2 канал Е1 проходит через 2 демултиплексора FCD-IP, который делит канал(link E1) для телефонии(sub link E1) и для данных(LAN)(это только наше оборудование через какое оборудование операторов все это проходит я не в курсе). Конечно в дальнейшем планируется подключить Астериск2 непосредственно к АТС2, и все гонять по ИП. Но так как АТС2 находится на достаточном расстоянии то в тестовых целях пока так.
Сейчас сделано так что FCD-IP1 синхронизируется от Астериск2, FCD-IP2 от FCD-IP1, и АТС2 должна синхронизироваться от FCD-IP2.

На FCD-IP в параметрах sub link E1 стоит
Frame type G732N, CRC4 выключен.

Нет, там стоит плата LDK-300 PRIB, с процессором, и она может быть мастером, а LDK-100 PRIB действительно может быть только slave. Модуля PLLU вроде нет. Но как я выяснил в побобных станциях Если плата работает в режиме Network, то она автоматически является источником синхронизации.

Дело в том что до этого АТС2 была воткнута в АТС1 минуя астериск2, и со стороны АТС1 абсолютно никаких ошибок не наблюдалось. А так как АТС1 это Меридиан 11С, то думаю он сказал бы что нибудь. ПРи моей схеме подключния у меня возможны слипы на участке FCD-IP2 - АТС2. Так как АТС1 синхронизируется от оператора, и АТС2 как бы тоже должна быть источником синхронизации. И когда я развернул синхронизацию вот так АТС2->FCD-IP2->FCD-IP1-ATC1, то мередиан мне начал показывать слипы на потоке. Когда же я воткнул поток в Астериск2 и сказал ему синхронизироваться с потока, он не синхронизуется с него, а показывает в качества источника - свой внутренний.

Диагностируйте отдельно ошибки на E1 линии от ошибок на PCI. Зондируйте каждый сегмент E1 на наличие потери фрейминга, ошибок hdb3 ну и CRC4 в конце концов. Я полагаю что у RAD не такие убогие диагностические возможности как у TE110P.

а где нить можно почитать что обозначают эти ошибки, что такое hdlc вообще. Хочу более глубже вникнуть в проблему.

По поводу синхронизации

Слипы (как следствие падение D-канала - прерывание разговора) - отсутвие синхронизации и копать надо в эту сторону

Думаю схема синхронизации была такая
Оператор -> АТС1 -> FCD1 -> FCD2 -> ATC2

Синхронизация между FCD1 и FCD2 "не честная" но за счет того что FCD2 постоянно мониторит состояние линка между FCD1-FCD2 и подстраивает свой внутренний генератор, то для ATC1/2 это выглядит как "честный" канал.

АТС2 вроде никак не могла быть источником синхронизации.

Оператор-АТС1-Ast1-Ast2-FCD1-FCD2-ATC2

После установки астерисков схема получается такая?
Через астериски вы не сделаете синхронизацию от ATC1 поэтому попробуйте сделать такую схему синхронизации:

1: Оператор -> АТС1 -> Ast1
здесь ничего не меняется
2: АТС2 -> FCD2 -> FCD1 -> Ast2
АТС2 делается источником синхронизации (возможно ее прийдется для этого переключить в ISDN Net side, уж не знаю как там в LG с этим)
у FCD1/2 меняется направление синхронизации
Ast2 ставиться как "потребитель" синхронизации

Да я тоже прихожу к выводу что это результата проблеммы с синхронизацией.

После перерыва продолжил копать, и вот что откопал

В Астериск1 стоит TE210P, настройки в певом посте, zttool показывае

Sync Source: T2XXP (PCI) Card 0 Span 1

теперь беру вытаскиваю из этого астериска TE210P, и вставляю туда плату TE110P из asterisk2. В конфигах, все что касается span 2 комментирую. Для span 1 ничего не меняю. Контрольная перезагрузка. Все нормально, связь есть, НО zttool показывает

Sync Source: Internally clocked

Отсюда у меня вопрос, в чем же дело?

zttool как вообще показывает нормально источник синхронизации для TE110P?

нда, я так и знал

From: support@digium.com
Unfortunetely zttool reports it's timing source incorrectly the majority of the time. It is a known bug. Do not rely on zttool's output to determine it's timing/clock source. If you have your span specified as "span=1,1,0,esf,b8zs" in your zapata.conf, then your card is taking timing from the telco if the telco is providing timing. Otherwise, the card will default to being internally clocked if the telco is not providing it. Regards, Chris Hozian

http://bugs.digium.com/view.php?id=4186

хоть это и было больше года назад, думаю мало что изменилось с тех пор.