Странно...
Да, такая проблема была обнаружена на версиях 5.5С. По нашему запросу корейцы устранили баг на версии 5.5Df. Я проверял - на 5.5Df действительно все было исправлено...
Неужели этот баг опять "вернулся" на версии 5.5Ed ??

Подниму-ка я тему...

И так есть станция MFIM/GS96M-5.5Gt MAY/12.
Подключена с Cisco по потоку, необходимо отправить в циску номер с 9-кой.
Что сделал, убрал в номерном плане 9, включил Internal and Loop LCR, в 221 вставил 9 DMT 111111, в 222 отправил в 1 CoGr ничего не обрезая, все работает, но напрягает один момент, не отрабатываю таблицы Prefix Dialing Table(206) [N].
Если отключить LCR и добавить 9 в номерной план, то таблицы отрабатывают как и положено (но 9 режется как и положено), таблица используеться 1, линии в Enblock.
Пробовал в LCR писать 9DDDDDD после этого вобще набор после 9-ки пропадает...

Вопрос что я делаю не так, может я где то чтото забыл? менял типы LCR не помогло, хотя выше Харрис писал что все должно работать....

ОК. Я постараюсь сегодня проверить такую ситуацию.

Спасибо, жду ответа...

Все работает!!
А что Вы прописываете в Prefix Table??
Если используете INT LCR и 9-ка посылается в линию, то префикс в ПГМ206 должен начинаться с 9-ки!!
В моем примере:
ПГМ220: LCR Mode = M02 (Loop & Internal)
ПГМ221: INT, 9, DMT 00 00 00
ПГМ222: AD=пусто, RP=1, RN=0, AP=1, COG=1, ALT = пусто
ПГМ140-142: Prefix Table -1
ПГМ206: Prefix Code =9, Table 1, Min =8, Max=8, ISDN/Telephony, Subscriber, Send_Complete=ON.

При наборе 9-ки станция ждет еще 7 цифр (ни больше и ни меньше) и сразу же отсылает Setup.

Если нужны еще другие префиксы, например, на МГ, то тогда еще нужно заполнить префикс для этого:
ПГМ206: Prefix Code =98, Table 1, Min =12, Max=12, ISDN/Telephony, National, Send_Complete=ON.
Здесь кол-во цифр 12 = 9 + 8 + зона (3 цифры)+ номер (7 цифр)

Спасибо, поставил Send_Complete=ON и все пошло!!! хотя без ЛСР и без него работает...

Какая связь между LCR и Send_Complete?? Что-то Вы тут путаете...
Если не используете LCR, то Prefix Table по другому нужно прописывать (без 9-ки).
Prefix Table - это не то, что пользователь набирает, а то, что станция уже отсылает непосредственно в линию!! Это "форматирование" посылки Enblock, а не форматирование набора пользователя.

Снимите трассировки потока для 4-х случаев:
- при включенной LCR и при Send_Comp = On / а потом при Send_Comp=Off
- при вЫключенной LCR и при Send_Comp = On / а потом при Send_Comp=Off

Send_Complete в ПГМ206 - это использование (вставить или нет) элемента Sending Complete для номеров, обработанных по префиксной таблицы. Т.е. это позволяет послать номер как Enblock (c элементом Send_Comp) или как псевдо-Enblock (без Send_Comp). Но это никак не связано с LCR.

Без LCR, у Вас, вероятно, и не работала Префиксная таблица (т.к. она заполнена для другого случая). А раз не работала Префиксная таблица, то станция отправляла по ПГМ143 Enblock'ом (т.е. с Send_Comp).
При LCR начинала работать префиксная таблица и посылка была Псевдо-Enblock (т.к. в ПГМ206 было Send_Comp =OFF).
А Cisco просто не настроена на прием псевдо-Enblock. И всё.

Связь как показали эксперементы есть, если я не ставлю Send_Complete, то станция ждет пока не отработает enblock inter digit timer 5 сек (по умолчанию) и эта задержка сразу чувствуеться, если отключить ЛСР, то таблица 206 работает при любом значении параметра Send_Complete, таблица изначально была заполнена на все возможности набора, с ЛСР и без него... могу выслать Вам базу, может я еще чтото не заметил...
Станция пока стоит в лабе можно по любому менять настройки....

Снимите трассировки потока для 4-х случаев:
- при включенной LCR и при Send_Comp = On / а потом при Send_Comp=Off
- при вЫключенной LCR и при Send_Comp = On / а потом при Send_Comp=Off
И пришлите файл конфига.

База вот https://dl.dropbox.com/u/26969027/DB_ALL300-1130311.zip пароль на вход в програмированиее 1
А вот трассировку что-то не могу снять, куда слать вывод сделал, что трассировать выбрал, но при звонке SMDR запись вижу, а сообщения потока нет, может что-то подзабыл, вроде маску тут не надо писать, как на MG.

iPECS-300 System
Version MFIM/GS96M-5.5Gt MAY/12
Checksum: 0
DATE: 03/11/13
TIME: 12:29:28
SITE NAME :
You are on TCP1
ENTER PASSWORD:

mon> tt vv

[1] Q Trace (event trace for all devices) enabled.
[2] Physical Brief Trace disabled.
[3] Board-Level Trace Option List :
1 2 4
[4] Device-Level Trace Option List :

[5] Trace Option List : 0000 0000


mon>
2001 001 00:00:00 11/03/13 12:23 O9ХХХХХ 0
2901 002 00:00:00 11/03/13 12:23 GХХХХХ *620 RING 00:01

Может что-то изменили для трассировки потока, ранее на LDK без проблем делал, да и на МГ недавно трассировал, а тут ни в какую....

На старых версиях для трассировки потока нужно подключаться непосредственно к PRIM, а не к процессору MFIM !!

https://dl.dropbox.com/u/26969027/lik_trace.txt

Во всех случаях набирал номер 9378500, в случае без ЛСР 9-ка откусывалась (циска пока и так принимает).
Выявилось что если поставить send_complite ON в любом случае таблица отрабатывает, а если в OFF то не работает, что с ЛСР что без него... Хотя ранее мне показалось было по другому...

Непонятно, что и как Вы проверяете???
Почему от LIK идет исходящий на номер 9378500, и тут же приходит входящий от Cisco на номер 378500...
Это как??
Cisco просто заворачивает вызов?? Что Вы этим проверяете??

Станция готовиться к выезду на реальный объект и поэтому все обкатываеться в лабе.
Да циска просто на данном этапе просто разварачивает обратно (эмулирую город), но меня заинтересовало, то что если send_coml OFF, то приходиться ждать еще 5 сек, а это сразу заметно и видно , и заметил я это когда включил ЛСР, вот поэтому и поднял старюу тему.

Господа, нужно правильно осуществлять проверку, т.е. делать "чистый эксперимент", тогда и не будет лишних вопросов..., и лишних подозрений!!
Если бы Вы проверяли правильно:
- Только исходящий вызов на абонента Cisco (без заворота), то Вы бы увидели, что НЕТ никакой разницы (в смысле "задержки") между случаем Send_Comp = ON и Send_Comp=OFF (по ПГМ206)!!!
Станция LIK НЕ ЖДЕТ 5 сек (в обоих случаях), а при наборе указанного кол-ва цифр сразу же отсылает это в Cisco!! Кстати, Вы это можете сами проконтролировать по трассировке!!! (Я это как раз еще раз проверил!!).
Разница только в том, что есть или отсутствует элемент Send_Comp.
И для CISCO это совершенно все равно: Enblock и псевдо-Enblock (без Send_Comp) она отрабатывает одинаково.

В действительности же, Вы проверяете не один, а сразу 2 вызова:
- исходящий от LIK на Cisco
- входящий на LIK от Cisco (завернутый)
Так вот: CISCO при завороте тупо копирует наличие/отсутствие Send_Comp и точно также направляет обратно в LIK.
НО для LIK наличие/отсутствие Send_Comp имеет принципиальное значение!!!
- если во вход. вызове есть Send_Comp, то LIK сразу же отвечает Call_Proc и Alerting
- если же во вход. вызове Send_Comp отсутствует, то LIK посылает запрос на следующие цифры номера (Setup_Ack) и ждет таймер DID_Interdigit (3 сек). И только после этого (не получив больше других цифр номера), LIK принимает вход. вызов в обработку с уже полученными цифрами (только после этого таймера LIK отвечает посылкой Call_Proc и Alerting).

Т.е. "задержка" связана вовсе с исход. вызовом, а с входящим (LIK отрабатывает входяший псевдо-Enblock "с задержкой" на DID Interdigit таймер)!!

Общий вывод:
- LCR и Send_Comp никак не связаны.
- Prefix Table отрабатывается одинаково как для LCR, так и без (если набор попадает в префиксную таблицу).

Спасибо, вот теперь все понятно!!!
Еще бы трасировки от LG как то в более удобоваримом виде были, и я никак не мог подумать что задержка идет на входе, сейчас попробуй еще снять трассиорвки на Cisco, убедиться в этом.

Трассировки имеют вполне удобоваримый вид. Откройте стандарт Q.931 - там все расписано.
На новых версиях софта (5.5Gu и выше) можно поток трассировать через MFIM, и в этом случае трассировка выводится в расшифрованном виде.

Ого, оказываеться здесь есть версия iPECS-LIK300 версия 6.0 Bo, надо обновиться, жаль что сейчас не вкладывают описания, что изменилось....

С учетом того, что конфига цыски не было, предположить, как она себя поведет, получив setup без sending complete сложно.
Но следует помнить следующее:
1. Прием цифр оверлапом управляется командой isdn overlap-receiving. В отсутствии этой команды маршрутизация начинается немедленно, после получения сетапа, вне зависимости от наличия sending complete. При наличии команды isdn overlap-receiving И подходящего диал-пира с T-терминатором, цыска ждет таймер T.302 (10 сек по умолчанию) или получения sending complete, после чего начинает маршрутизацию. Если пира с T-терминаторм нет, то маршрутизация начинается после того КАК БУДЕТ СОБРАНО необходимое для маршрутизации количество цифр ( произойдет матчинг диал-пира), и в пир уедут собранные, а не набранные цифры.
2. Принудительная отправка sending complete при исходящем звонке на интерфейсе управляется командой isdn sending-complete. По умолчанию - выключено.

Исправим упущение

!
interface Serial0/0/1:15
description LG
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn protocol-emulate network
isdn incoming-voice voice
no cdp enable
!

dial-peer voice 9 pots
destination-pattern 9......
direct-inward-dial
port 0/0/0:15
forward-digits 6
!
!
dial-peer voice 3785 pots
destination-pattern 3785..
direct-inward-dial
port 0/1/0:15
forward-digits all
!
вот так примерно выглядело в лабе, там циска просто разворачивала нумерацию 3785ХХ обратно в ЛЖ. Ничего более на сериальнике и на диалпирах сказано не было...
так сказать на циске все по дефолту, без допов в виде send_comlite and progress_indicator