Вновь к Вам за мудростью и опытом.
Имеется iPECS-600 Version : MFIM/GS97M-F.0Bj и LDK-300 в разных офисах.
Организована сетевая связка двух данных PBX по E1 PRI каналу:
IPECS-600 (4XXX,"6"-для Net Call вызова)<--->Е1(PRI)<--->LDK-300 (5XXX, "0"-для транзитного Net Call вызова)<--->SIP.
Канал на IPECS -600 программно поделён на две транк. группы (Tr.2-с 31 по 50 time slots, Tr.4- c 51 по 60 time slots).
Выделен префикс под Ext. в Flexible Station Number для каждой АТС (IPECS-600 4XXX. LDK-300 5XXX).
Дополнительно в IPECS-600 назначен сетевой префикс - "6" с модификацией в LCR для вызова абонентов сети PSTN (6XXX) посредством транзитного проброса вызова через АТС LDK-300 (NET CALL) в SIP Trunk.
На LDK-300 назначен сетевой префикс - "0" с модификацией в LCR для вызова абонентов сети PSTN посредством транзитного проброса вызова в подключённый к АТС SIP Trunk.
Создана необходимая конфигурация в таблицах - "Networking Data" на обеих АТС. Тип сетевого взаимодействия (Net CO Type) -NET для каналов с 31 по 60.
В таблице Net Numbering Plan(324) IPECS-600 закреплены соответствующие Net CO Group 2 и 4 (конфиг прилагается).
При вызовах сетевых абонентов АТС (по префиксам 4 и 5), в обоих направлениях, соединения устанавливаются безупречно (трассировки вызова, снятые с IPECS-600 прилагаются).
Засада происходит при вызове с IPECS-600 (набор префикса -"6") абонентов PSTN живущими за LDK-300.
При этом происходит следующее: абонент IPECS-600 (4XXX) вызывает удалённого абонента (6ХХХ#), путем набора сетевого префикса "6" и XXX#, посредством LCR набор модифицируется, добавляется в первую позицию префикс "0" для анализа в LDK-300 и в сетевую Tr.Gr 4 с IPECS-600 ("[b]overlapом"[/b], хотя в соответствии с назначением в Net Numbering Plan(324) -Net Numbering Plan(324) - "Yes" должно быть "Enblockом"



Если абонент IPECS-600 (4XXX) вызывает сетевого абонента (5ХХХ) по сетевой Tr.Gr.2 (прошу заметить того же Е1 PRI потока, что и в выше приведённом примере) феномена с тишиной и отбоем линии нет. Абонент (5ХХХ) может ответить на вызов с любого количества вызывных посылок, соответственно, абонент (4ХХХ) получает все (КПВ) до снятия трубки абонентом (5ХХХ).
Трассировка, снятая SIP провайдером в транке которого живут короткие номера (6ХХХ) на стороне SIP Trunk АТС LDK-300, показывает, что прилетает IE сообщение CANSEL от LDK-300 в сторону SIP сервера, на что провайдер отвечает сообщением 487 и BAY в сторону LDK-300, что совершенно логично (прилагается). При этом, если выполняются вызовы непосредственно абонентами PBX LDK-300 (5XXX) SIP абонентов с нумерацией (6ХХХ) по SIP каналу к прову, всё получается красиво, без упрёков и проблем. Соединение происходит в соответствии с требованиями закона, отбоев нет.
Прошу Мудрейших коллег форума набраться терпения и разъяснить мне "разумному" где сидит проблема и как её погубить.
Очень надо знать...), 2 недели прожил в обнимку с букварями F&O, результат отсутствует, ушёл в глубокий штопор.

Помажите, пожалуйста.

Заранее благодарю, с Уважением Demon.
Трассы и имеющиеся конфиги с IPECS-600, LDK-300 влагаю. Готов сотрудничать со следствием и отвечать на все поставленные, уважаемой публикой, вопросы.

Приём....
