Дано: LIK300 по потоку соединен с LDK300, городской поток подключен к LDK. Телефоны 8002Е, IP8802. Проблема одинакова для обоих типов аппаратов.

В списке набранных номеров одни и те же номера (ТфОП) иногда сохраняются с 9, иногда без. Если номер сохранился без 9, подстановки не происходит. Соответственно номер набрать нельзя.

И что интересно, со списком принятых вызовов все в порядке. Они все хранятся без 9 (ну естественно) и 9-ка всегда подставляется.

Посоветуйте, куда копать?

Может, в сторону LCR?

На LIK - Disable LCR

И вроде как ошибки с LCR не очень объясняют почему в телефоне один и тот же номер может сохраниться как с префиксом, так и без.

С LCR при повторе будет еще больше проблем.

Конфиг бы посмотреть. Вызовы идут на разные транки?? О каких номерах речь?? О набранных пользователем (и потом Redial) или о входящих вызовах (CLI Wait), сохраненных в журнале вызовов ??

Со входящими нет проблем. Они все сохраняются в журнале без 9 (ну так как на дисплее высветилось), но при наборе из журнала всегда 9 подставляется.

Речь идет только о набранных пользователем, т.е. о Redial. Вызов всегда идет через LIK-PRIM в сторону LDK.

"О каких номерах речь?" - не понял вопрос.


Конфиг тут:
http://yadi.sk/d/m1v0MWJj8QeaG

Вот об этих номерах (вход. или исход.) и был вопрос. Вы все ответили.

Да, на оконечной АТС есть проблемы с повтором набранного номера и с набором из журнала вызовов.
Проблема в том, что в этом случае требуется отсылать в линию PSTN код (для транзитной АТС).
При наборе из журнала вызовов только для номеров принятых вызовов (отвеченных) подставляется 9-ка.
И только для вызовов, принятых по линиям PSTN. Если вызов был принят по линии типа NET, то 9-ка не подставляется.

Для журнала и для повтора используется разные алгоритмы.
При наборе из журнала тупо подставляется LOOP код (доступ к младшей разрешенной группе линий, 1-sr Access CO Group).
При наборе "ручками" станция запоминает линию, по которой производился исход. вызов, и при повторе занимает эту эе линию (или из этой же группы линий по ПГМ141), но таблица NET при этом уже используется и Digit Repeat не отрабатывается (транзитная 9-ка не уходит в линию).
Таковы дела.

Если использовать 9-ку как INT LCR код, то можно сделать, чтобы при повторе набранного номера 9 также уходила в линию на транзитную АТС. Т.е. повтор номера будет работать. Но при этом не будет работать набор из журнала вызовов (даже из директории принятых вызовов).

Я уже связывался (год назад) с корейцами по поводу аналогичной проблемы. Но, чтобы это исправить нужно значительно перелопать софт, во многих частях, связанных с сохранением номеров и пр., и корейцы не хотели бы это трогать.
Когда будут разрабатывать LIK 7, тогда можно будет поднять эту тему опять.

Ясно. Спасибо за подробный ответ.

Я попробую еще раз написать в Корею, но тут нужно прежде досконально самим разобраться, что именно просить от корейцев. Чтобы не навредить...
По поводу повтора - лучше всего, если они бы сделали как на MG, где просто запоминаются все цифры, набранные пользователем. Выбранная линия не запоминается. И при повторе этот же набор отрабатывается заново, т.е. заново производится выбор линии.
Но корейцы говорят, что так будет сложно переделать софт.
С журналом вызовов, ИМХО, еще сложнее.

Вообще, ситуация достаточно удивительная. Функция Redial одна из самых востребованных, если не самая.
Так что, по идее, они должны массу нареканий за это получать. Я не программист, но то, что ради такой функции надо весь код перелопатить - это круто. Не индусы ведь. )))
И, да, самое простое это как то запоминать последние набранные цифры, чтоб хотя бы 1 номер запоминался. Уж фиг бы с ним, с полноценным журналом.

Видимо, в других странах не очень используют сеть АТС (Networking)... Проблема-то всплывает только при транзите.

Если в большей степени требуется именно Redial, то как я писал выше, вы можете это сделать, прописав 9-ку как код INТ LCR. Повтор будет работать, на всякий случай сейчас проверил все еще раз у себя на станции.

Поставлю вопрос перед непосредственными пользователями. Пусть решают.
Но предположу, что нормальная работоспособность журнала принятых (пропущенных) вызовов и возможность их корректного набора, более интересная фича, чем Redial.

А вы сами проверяли набор из журнала именно пропущенных вызовов (а не отвеченных вызовов) ??? Это работает или нет??
При моей проверке набор пропущенных вызовов не работал так, как вам нужно - 9ка не подставляется.
Станция подставляет 9-ку только для отвеченных вызовов (из папки "входящие").

У меня транзит: LIK 600 через сеть подключена к LDK300. На ТА 8002Е запрограммировал кнопку повтора (Programming (PGM Code) – 97 – кнопка REDIAL) - повтор номера по нажатию этой кнопки всегда работает..
Нажатий меньше, чем из журнала набирать..

А вот тут интересный момент. В аппарате есть три списка: 1. Входящий вызов 2. Исходящий вызов 3. Утерянный вызов.
Так вот и отвеченные, и пропущенные вызовы сохраняются в списке "Входящий вызов" и корректно оттуда набираются.
А вот список "Утерянный вызов" всегда пустой с пометкой "Нет информации".

О! А работает. :-) Вполне решение проблемы. Причем даже список, а не просто последний номер.

Этот баг уже исправляли на версиях:
для уровня 5.6 - на E.6Cl и выше
для уровня 6.0 - на F.0Cd и выше

Я уточню для понимания.
Т.е. если я сейчас перешью станцию на Cd, то номера в списке утерянных вызовов появятся, но набираться перестанут? :-)

Вот это я не могу точно сказать... Все, что я писал выше по поводу моих тестов относилось к версии 6.0Bo (так как на моей тестовой станции в данный момент стоит 6.0Bo).
Если будет время, то чуть позже проверю на F.0Cp.

Две новости
Хорошая, что работает!
Плохая - на сайте ее нет...
И вторая плохая:
У меня - MFIM/GS97M-F.0Cp JUL/13 - отображения - нет..
А Cp - более поздняя по отношению к F.0Cd, если исходить из порядковой нумерации алфавита..

А версия самих ТА влияет?

Стас! Какого отображения нет??? Ты опять уже перескочил на другую тему, про русификацию что-ли??

На F.0Cp журнал пропущенных вызовов отображается.
Но в пропущенные вызовы не попадают сетевые (Network) вызовы, а только внешние и внутр.
Но так было и на остальных версиях (F.0Cd, F.0Ck), и так будет на последующих.
Пропущенные сетевые вызовы НЕ БУДУТ сохраняться в журнале Lost Call Log.
Так написан софт, такова концепция Networking, и в ближайшее время корейцы ничего менять в этом смысле не планируют.

На версии LIK 600 F.0Cp JUL/13
На ТА 8002Е при нажатии на клавушу вправо джойстика выводится
1. Входящий вызов
2. Исходящий вызов
3. Утерянный вызов

Первые два пункта не нужны мне и не понимаю вообще кому они и зачем нужны..
А вот единственный всем нужный пункт - 3 не отображает ничего и никогда.

Мне непонятно - зачем нужны первые два пункта и зачем не работает единственный нужный пункт.. и что мне начальству объяснять - зачем я выбирал именно эту АТС?!

Стас!
1) Ты, конечно, меня извини, но ты своим начальством уже окончательно достал... Сколько можно стонать??
Ты выбирал эту АТС, потому что ты себя всюду позиционируешь как страстный приверженец и фанат техники LG. Разве не так?? Так что ты тогда хочешь?? Кто за тебя должен разбираться с твоим начальством??
2) Я не собираюсь тебе объяснять, зачем нужны журналы Входящих (Отвеченных) вызовов и Исходящих вызовов (набранных номеров). Есть дока.
Что касается журнала пропущенных вызовов, то как я уже писал, там не сохраняются пропущенные СЕТЕВЫЕ вызовы, только внешние (с линий PSTN) и внутренние (ICM).
Что и как проверяешь ты - мне неизвестно.
Я проверял последний раз на LIK ver. F.0Cp и на LIP-8002E ver. 1.1Ao.
Мне больше нечего добавить.

В общем, рано я обрадовался. Похоже, что программная кнопка обращается к тому же самому списку.
В результате имеем тот же самый глюк: какие-то набранные номера сохраняются с 9, какие то без. Самый прикол в том, что один и тот же номер, набранный дважды с интервалом в минуту, может сохраниться как с 9, так и без.
Если номер сохранился с 9, то повезло. Но бывает это гораздо реже, чем без 9.

Пичалька...