Повтор вызова, не подставляется 9 Опции

[mat701]

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

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

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

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

[stasmar]

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

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

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

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

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

[mat701]

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

На LIK - Disable LCR

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

[harris]

На LIK - Disable LCR

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

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

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

[mat701]

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

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

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

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

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


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

[harris]

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

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

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


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

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

[harris]

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

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

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

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

[mat701]

.

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

[harris]

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

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

[mat701]

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

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

[harris]

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

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

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

[mat701]

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

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

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

[harris]

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

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

[mat701]

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

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