Тема: Зависание внутренних линий на TDA
Мы не пробовали. Цена у них больно кусается.
http://tsol.spb.ru/view_price.cgi?id=162
Какбы бюджет на плату уже выделен... менять на что-то другое не планируется =(
Думается что тут дело в некоторой кривой реализации протокола PRI с одной из сторон. Ибо точно та же плата идеально работала с TD500, c железом провайдера - а при подключении к TDA200 секунд 20 работало, потом терялся линк в D-канале, и так до сброса или перетыкания провода в плату. Исправилось прошивкой. Что-то в мозгах у панасоника съезжает, но почему после перезагрузки через консоль проблема не исчезает - для меня загадка...
А вы хоть CRC-4 согласовывали на обоих концах? Пробовали при включенных и выключенных режимах?
А вы хоть CRC-4 согласовывали на обоих концах? Пробовали при включенных и выключенных режимах?
+1! Внешне очень похоже.
немногим более недели назад, как временный вариант, до подтягивания оптики от местного представителя питерского провайдера O**t.ru, их технари у одного из клиентов поставили Астер с 2-х портовой PRI платой от Digium (специально открывал крышку компа с астером), я этот поток поднимал на клиентской TDA
Из аналоговых внутренних в наличии только несколько Ext от DHLC8, остальные штук 30 цифровики 76xx
вроде вышеописанных проблем нет, но в первые несколько дней был другой прикол:
исходящая связь пропадала, вернее астер установленный у клиента вероятно всего “засыпал” примерно через 75 сек бездействия канала (делали тестовые исходящие звонки с перерывом в сторону уменьшения начиная с 2-х минут и проверяли по секундомеру) ,
если в момент свершения исходящей связи “ловили тишину”, то можно было сделать входящий вызов, он приходил без проблем и “будил” клиентский астер, появлялся КПВ по исходящей, и как бы все ОК до тех пор, пока канал будет бездействовать вышеуказанное время
ошибки по каналу за те несколько дней были по нулям
Кстати прикол в том, что даже если CRC4 выключить на Панасонике, поток работает всё равно. Хотя не должен. От такие пироги.
На кусиге сцээрцэ должен быть включен.
В чем принципиальность? Никогда не включал.
Кажется удалось решить одну проблему с ошибками SL.
У меня TDA должна была врать синхронизацию с астериска, и на PRI плате было выставлено QSIG-slave, но в пункте 1.4 на всех позициях стояло NONE. поставил первым плату PRI, и ошибки SL пропали.
Когда конфигурировал TDA оставил NONE везде по незнанию, и думал что QSIG-slave достаточно чтоб TDA знала откуда синхру брать, а похоже что нет.
Надеюсь что и другие проблемы исчезнут.
UPD: Транк отваливаться не перестал.
и думал что QSIG-slave достаточно чтоб TDA знала откуда синхру брать,
Это разные уровни любимой всеми модели OSI.
Это разные уровни любимой всеми модели OSI.
Понятно, полезная информация, спасибо.
У меня наоборот - в 1.4 ставил синхонизацию - получил в итоге внезапные умирания SL портов. Сейчас убрал всю синхронизацию, проблема исчезла.
У меня наоборот - в 1.4 ставил синхонизацию - получил в итоге внезапные умирания SL портов. Сейчас убрал всю синхронизацию, проблема исчезла.
У меня TDA берет синхру с астериска, а похоже не брал.
а у вас наверно TDA отдает синхру?
Нет, в системе плата PRI единственная. Сейчас в 1.4 вся синхронизация убрана. Режим QSIG-Slave. CRC4 выключено.
Нет, в системе плата PRI единственная. Сейчас в 1.4 вся синхронизация убрана. Режим QSIG-Slave. CRC4 выключено.
Хм, я конечно не телефонист, но это правильно что у вас TDA должна принимать синхронизацию, а сама ее отдает? или я не прав, поправьте пожалуйста.
Вопрос к специалистам, откуда берет синхронизацию TDA если в плате установлено QSIG-slave, а в 1.4 везде стоит NONE?
может я неправильно понимаю, интересует суть взятия/раздачи синхронизации при QSIG-slave.
Спасибо.
P.S. У меня была такая конфигурация, транк отваливался и линии зависали.
