Здравствуйте.
iPECS LIK 50A, ver. 5.0Gs JUL/10
В программе CO/IP Attributes(140~142) есть параметр "Prefix Table ID".
Что это за параметр и зачем он? В документации ответа на этот вопрос не нашёл.

при наборе блоком, атс отправляет набор в канал по таблице из 206 программы. то есть не ждет окончания таймера enblock.

См. описание этой же функции в станции ipLDK - п.2.2.10 Префиксы набора при блочной передаче (Dialing Service by Prefix code)

Спасибо. Я не мог понять, на какую таблицу ссылка.
Но немножко хочу развить тему.
Эта функция как раз помогает решить проблему, к которой я не знал как подступиться.
LIK подключен к SIPNET. Пользователь выходит на СO, набирает номер 7xxxyyyyyyy затем 5 cек работает таймер АТС, 4 сек происходит соединение с сипнет. Всего 9 сек - очень долго.
1-й вариант соединения - пользователь набирает в конце номера #. не очень красиво.
2-й вариант - использование Prefix Table ID + таблицу из 206. - гораздо лучше, соединение происходит за 4 секунды.
Но. Начинаю улучшать дальше.
Пользователю удобней набирать номер в привычном для нас виде - 8xxxyyyyyyy.
Нет ничего проще - включаем LCR.
Но, как только включаю LCR, сразу же перестаёт работать Prefix Table ID. Насколько я понимаю, здесь до внешней линии дело не доходит. Тормозит LCR, который тоже включает таймер после набора последней цифры. Вот если бы LCR тоже умел в таблицу из 206 прог смотреть...
Может есть какое-то решение позволяющее LCR определить, что номер набран полностью и отправлять оператору?
Сокращать таймер набора меньше 4-5 секунд как то не функционально...

В LCR можно прописать код в виде 8DDDDDDDDDD. Набор в этом случае сразу пройдет после ввода номера.

D значит Tone Detect? Т. е. АТС будет слушать внешнюю линию.
Тогда я не понимаю механизм работы кода 8DDDDDDDDDD.
В моём случае не работает.

Причем здесь Tone Detect??
D - маска, означает любую цифру.

Интересно! У меня работает, а у вас нет! В этом случае это означает любую цифру.
Для примера:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Для 2DDDDD - набор в линию уходит при наборе 6-ти значного номера, начинающегося на 2. 2-ка заменяется на 7. В Итоге 7DDDDD.

Проверил еще раз у себя - все работает нормально (LCR + Nerworking Table + Prefix Table)
Prefix Table отрабатывает цифры уже после LCR.
Нет необходимости прописывать 8DDDDDDD. Достаточно просто прописать код LCR = 8.
8 + маска прописывается если нужно различать несколько разных разных LCR кодов.

Проверил еще раз у себя - все работает нормально (LCR + Nerworking Table + Prefix Table)
Prefix Table отрабатывает цифры уже после LCR.
Нет необходимости прописывать 8DDDDDDD. Достаточно просто прописать код LCR = 8.
8 + маска прописывается если нужно различать несколько разных разных LCR кодов.

Вот именно, что все работает! Два рабочих варианта, решающие проблему.
С префиксами, думаю, более правильно... А про 8DDDD... - это ж для примеру...

Видимо где-то ещё у нас по разному настроено. Пока не знаю что.
После того, как прописываю 8DDDDDDDDDD происходит следующее:
Я набираю номер. Моя АТС понимает, что я набрал все цифры. но после набора моя АТС даёт мне готовность (длинный гудок) и гудит до начала соединения (10 секунд в моём случае).
Сейчас ещё покапаюсь в настройках...

Networking Table - это в какой программе? я не использовал такое при настройке.

Прошу пардону. Но я проверял для ISDN и H.323.
А у Вас SIP транк. В настоящий момент у меня нет возможности проверить работу LCR + Prefix Table + SIP-транк.
SIP - это другая сигнализация. Возможно, что комбинация LCR+Prefix Table не работает для SIP транка.
Но если у Вас работают варианты:
7xxxyyyyyyy (+Prefix Table) или
8xxxyyyyyyy# (+LCR), то, ИМХО, это уже хорошо.
В этом мире нет совершенства, и пользователи тоже должны это понимать.
Нет ничего страшного в том, чтобы в конце номера набрать #. При наборе с мобильного телефона вообщем так и происходит (вместо # нажимают кнопку "Вызов"), и вроде никто из пользователей на это не жалуется, не так ли???!!!
И также нет ничего страшного, если пользователи будут набирать 7-ку вместо 8-ки. В каждой системе связи свои правила набора и нужно просто им следовать. Пользователи привыкают к этому за пару дней, и всё.

Да, SIP-транки сейчас настраиваю. Подключены два оператора
7xxxyyyyyyy (+Prefix Table) без LCR
и
8xxxyyyyyyy# (+LCR)
работают.
Даже и без этого, не особо привередливый пользователь сможет работать без напрягов.
Но, как известно, лучшее - враг хорошего. Хочется использовать возможности IPECS-LIK на все 100%.
Тем более, что с каждой новой версией ПО появляются новые функции, информацию о которых в документации мне часто сложно найти без посторонней помощи.
Я не знал ни о Prefix Table, ни о выше описанном способе использования символа D в таблицах LCR.
Спасибо всем, кто учавствовал в обсуждении.

Я не написал, прохлопал, но Enblock Inter Digit Timer надо минимальный в этом случае поставить.
По поводу префикса и LCR, что в префиксе прописано 7, или 8?
Ниже не прочел, пардон, 7-ка, конечно же...

Еще эту таблицу можно использовать, чтобы менять поля Numbering Plan в Setup-e в зависимости от направления (у нас провайдер требует так)

MFIM50A 5.5Ed + SIP + Prefix Dialing Table(PGM206)
Цель: не отправлять ошибочные номера на SIP сервер.
Prefix Code = 8; Min Digit = 11; Max Digit = 11;
Если набрать 8495 ххх хх хх хх, срабатывает Max Digit, и в СО отправляются 11 цифр.
Если набрать 8495 ххх, НЕ срабатывает Min Digit, и данный вызов отправляется в СО, а должен быть аларм.

А оно, вообще то, работает по sip?? После набора 8495 ххх хх хх хх сразу номер улетает?

Да работает.
Если набирать с аналогового телефона, то по достижению Max Digit номер моментально улетает на SIP сервер.
Если набирать с Phontage 8495 ххх хх хх хх (именно больше 11 знаков), то номер режется Max Digit и моментально улетает на SIP сервер.
Но Min Digit не отрабатывает.

Странно...
Да, такая проблема была обнаружена на версиях 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

1. На наличие sending complete ей пофиг, на интерфейсе нет команды isdn overlap-receiving. Соответственно, шлет ли его лыжа или нет - с точки зрения цыски ни на что не влияет. Если бы даже и была - опять-таки, пир без Т, номер достаточен для маршрутизации и ждать нечего.
2.По-умолчанию цыска шлет setup без sending complete, соответственно лик и начинал тупить, ожидая интердиджит таймер. Лечится добавлением isdn sending-complete на интерфейс Serial0/0/1:15.

Вот и все.