LDK-300 + PRIB + TOR2 + Asterisk Опции

[Amel]

Связка работает. Но...
Связка используется для набора офисными абонентами международных направлений и некоторых других, прописанных на *. Работает оно через LCR/LDT типа COL, маска 00.
После срабатывания комбинации "9-00" ЛЖ бросает вызов на * и там оно попадает в экстеншн "00".
Дальше я пробовал по-разному - ничего не помогает. Сейчас так:

exten => 00,1,Noop()
;exten => 00,n,Answer()
exten => 00,n,WaitExten(140)

Проблема собственно в том, что в таком режиме * не получает всех DTMF-кодов набираемого номера!!!
А именно, пропускает 2,3 и 6.
При этом, если набрать сначала 864 (64 - это группа СО-линий PRIB), то мы попадаем в тот же контекст * и при этом все коды DTMF определяются без проблем!
Поэтому я думаю, что причина в ЛЖ.

[Amel]

Менее строгое детектирование DTMF-последовательностей.

[harris]

Менее строгое детектирование DTMF-последовательностей.

ОК.

Я ничего не понимаю в настройках Астера, и не знаю, как точно у Вас запрограммирована LDK, но...
вообще-то при нормальных настройках связки LDK-> Астер не должно было быть никаких посылок DTMF.
Весь набор номера должен уходить в PRI в сигнальном канале, сигнальными сообщениями (INFO).

Тут бы упомянутые выше трассировки потока могли бы пригодится!!! Тогда было бы яснее, что происходит на самом деле.
Подозреваю, что получив 00 Астер сразу же отвечает Connect'ом, и далее номер уже уходит тоном DTMF.
А желательно, чтобы Астер получал полный набор - 00ХХХХХХХХХ, и только потом приступал к анализу и обработке.
Со стороны LDK возможна проблемка при посылке Enbloc'ом:
на старых версиях софта Enblock не отрабатывался при использовании LCR, но нормально работал при прямом доступе к транку (при доступе через код 864).