IPECS-600 сброс вызова в фазе его установления, Сетевой вызов [Net Call] Опции

[Demon]

Добрый день, коллеги!
Вновь к Вам за мудростью и опытом.
Имеется 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ом" ) улетает последовательность цифр 06ХХХ, + непонятно с какого перепуга в конце указанного набора, появляется мифическая цифра 3 (видно в прилагаемой трассировке, возникает вопрос-ОКУДА???). При этом, абонент IPECS-600 (4XXX) слышит одну посылку вызова (КПВ), тишину сек. 5-6, отбой. Если на дальнем конце абонент (6XXX) успеет поднять трубку после одной вызывной посылки, соединение между участниками вызова устанавливается .
Если абонент 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 влагаю. Готов сотрудничать со следствием и отвечать на все поставленные, уважаемой публикой, вопросы.
Приём....

Прикрепленные файлы

 __________________.rar ( 420,61 килобайт ) Кол-во скачиваний: 8

 

[Demon]

1) В LIK не нужно пользоваться трассировкой потока, которую предоставляет MFIM. Там в расшифровке сообщений есть ошибки!! Нужно снимать трассировку непосредственно с PRIM.
2) Добавленная "3" - вовсе не цифра 3. Это ошибка отображения информации при расшифровки трассировки. См. п.1.
Это код 23, соответствующий #. Т.е. символ # уходит из LIK в поток.
3) Чтобы включить Enblock на линиях типа NET (ПГМ322) для кодов типа PSTN (ПГМ324) нужно включить две опции:
- PSTN Enblock = YES (ПГM324) и
- ENBLOC Sending = ON (ПГМ143, 151 - ISDN CO Attr)

Спасибо, мн.уважаемый Harris за скорый ответ!
Как говорил один мой очень хороший знакомый: "Век живи, век учись!"
1) Понял Вас. Стесняюсь спросить:- Не дадите намек примерный, каким образом или где прочитать? Не "Avrora" ли имеется ввиду? Хотя, в принципе, и данная форма в полне информативна, но попробывать хочется как Вы настаиваете. Очень волнует вопрос, почему IPECS-600 отдаёт запрос DISCONNECT раньше времени?
2) От оно что?! Она ведь мне весь моск вынесла. Спасибо!
3) Понял Вас профессор! Как-то в мануале я не обнаружил сей информации. Уяснил теперь на века. Спасибо!
Завтра будем внедрять Ваши феноменальные знания. О результате отпишусь.

[harris]

Спасибо, мн.уважаемый Hirris за скорый ответ!
Как говорил один мой очень хороший знакомый: "Век живи, век учись!"
1) Понял Вас. Стесняюсь спросить:- Не дадите намек примерный, каким образом или где прочитать? Не "Avrora" ли имеется ввиду? Хотя, в принципе, и данная форма в полне информативна, но попробывать хочется к Вы настаиваете.
2) От оно что?! Она ведь мне весь моск вынесла. Спасибо!
3) Понял Вас профессор! Как-то в мануале я не обнаружил сей информации. Уяснил теперь на века. Спасибо!
Завтра будем внедрять Ваши феноменальные знания. О результате отпишусь.

Извините, я не понял вопрос. Прочитать про что?? Прибор "Аврора" - это наилучший вариант, если есть в наличии свободные 5-7 тыс. $ (точно не знаю, сколько она сейчас стоит).
Можно просто подсоединиться к PRIM по RS232 (или по Telnet) и ввести команду: tr t3.
Расшифровки не будет, будут пакеты 16-ти ричных данных. Но можно разобраться, т.к. все соответствует стандарту Q.931.
Попробуйте набирать в Enblock'е. Хотя мне кажется, не в этом дело.
А есть снифер при звонке на номера SIP от абонентов LDK ??