Внимательней читаем вопрос - вопрос не о типе поиска, а о том, что при звонке в ОДНУ и туже группу ведет себя она по разному. Хочется параллельный звонок, и тип поиска такой и стоит, и при вызове из города звонят все аппараты, а при звонке по сети - только ОДИН аппарат (по версии пользователей с сайта надо полагать). Тут для начала надо проверить самому - что реально набирается - 1000 раз встречал ситуацию - человек считает что 3333 - это номер группы, а это на самом деле номер аппарата входящего в группу.
Скорее всего на той станции народ (поскольку видит номера ответивших абонентов) набирает номер абонента, а не номер группы (процентов на 99). Тип указанный в network номере на втором узле (абонент, группа) по идее не должен влиять на это.
сомневаюсь, что ОХО может ходить на один и тот-же IP шлюз с разными паролями. А номер наверное фрмируется так-же по сути как и для ISDN. Пусть поправят - если не прав.
А когда cuser делали - вам система чего ответила - найдены были или нет записи удовлетворяющии запросу? Командами commit; . Заканчивали (последняя - "точка")?
Удаление было в общем правильно написано, только не "info" а "nulog=28", и не из tabtrad, а из poste.
Смотрится например через zdpost. там по идее и увидите nulog, который равен info в менеджменте (плане нумерации). Само сообщение KCI_NULL_INSTANCE - объект не существует.
Уважаемые коллеги, когда пишете - просьба, показвайте менеджмент, инциденты и пр. Слова типа - в дискриминаторе все в порядке - не вставляют. Утрировано - запрограммировал все правильно, но не работает, ваши советы - тяжело чего-то ответить. Настоятельная просьба - пишите чего запрограммировано - реально из менеджмента, какие проблемы - только не со слов заказчика, проверяем сами. Неоднократно поднимал вопросы перед разработчиками - потом краснел, теперь - все проверяю сам. Прошу прощения - если кого обидел наездами.
Можно бл.дский вопрос - checkdb не показали, чего cuser сказал на ваши телодвижения не сказали (может вышли из него без сохранений, может не нашлось ничего соответствующего запросу), чего сказал checkdb после рестарта не говорите - я конечно понимаю, что надеетесь на телепатов (не обижайтесь плиз). Но чего хотите при таких вопросах?
Это очень забавная проблема и однозначных путей решения нет. Но в общем и целом откуда могут расти ноги - в станции есть база на винте, есть база в ОЗУ, и соответственно то-же самое на втором проце (если есть). Если юзер отсутствует в одной из баз, или на одном из процессоров - и появляются такие проблемы. Какого лешего они там не появились - это отдельная тема. Что делается в целом: - если дублированная система - смотрим небыло ли переключений, и присутствует ли данный абонент на втором проце (запуская mgr на stand-by - работаем с его локальной базой). Т.е. если базы просто разбежались - надо переключиться на процессор, где она лучше. - даем команду checkdb - если ругается только на cdt entity - с базой на диске все ОК и должен помочь рестарт станции. - если ругается - через cuser правим базу - но это дело тонкое, неоднозначное, неописанное в доке и требующее после этого рестарт станции. - если ничего не помогает - рестартуем без телефонии и восстанавливаем базу - за вчера, позавчера или еще когда (у вас должны быть на диске базы за 7-мь последних дней, 3-и последних воскресенья и 2-а последних месяца) - ориентироваться легко - при восстановлении с cpu диска - предлагается восстанавливать базы за конкретное число.
А насчет обнуления станции - всегда рекомендую следующее: - сохраняем через swinst OPS файлы (забираем их на комп); - если не уверены в себе - сохраняем и забираем базу; - перезагружаем станцию с выключенным автостартом (запускаемся без телефонии); - создаем базу по умолчанию - swinst/ expert menu/ database tool - create empty database, выбираем страну SU; - восстанавливаем OPS файлы. Если (в зависимости от древнести релиза) железо при этом не создалось - даем RUNMAO, через mgr создаем 0-й шелф (того типа который у вас есть), создаем платы. Далее KILLMAO, потом RUNTEL - после запуска телефонии не забываем включить обратно автостарт (swinst/ expert menu/ system management/ autostart management).
Без базы с 0-ля можно огрести непредсказуемые проблемы - чего там раньше делалось с таймерами, категориями, всякими параметрами в system, other system и далее во вложенных пунктах - кто ж помнит.
Да, в догонку - не обижайтесь но - если со станцией совсем плохо, если говорить обо мне, то я не буду рассказывать ПОДРОБНО, ПО ШАГАМ, ВЕСЬ МЕНЕДЖМЕНТ. Всегде рекомендую в таких случаях (если станция первый раз в руках) - проявить свой регион, как правило находятся люди, которые за пиво/спасибо могут показать первые шаги и т.п.
С удовольствием подскажу что делать, если чего-то ДЕЛАЕТЕ, но не получается.
1. У абонента сначала убираем галку с пункта S0 extention, потом удаляем абонента. Может быть еще в shelf/board/SO bus - для данной платы и порта удалить S0 шину.
2. Зайти в entity и поудалять номера в разделе day/ night routing.
3. Открыть транковые группы - может есть такие, ссылающиеся на данную плату
trunk groups/ trunk group/ T0/T1/T2 access - удаляете доступы - дальше плата должна удалиться.
MANDATORY INFORMATION ELEMENT MISSING, Выход в город Е1
Или swinst/ easy menu/ stop the telephone (если есть) Или swinst/ expert menu/ system manag/ autostart manag/ unset autostart и рестарт. Или просто рестарт (в ком порту) и прерываете запуск телефонии (после появления копирайтовского окна и слов про запуск DHS3 и 5 сек).
На будущее - создаем новую тему, а не пишем в старой (тем более не в тему название)
18-й таймер меньше 50 - это не есть гуд. Например на МН у нас открытая нумерация (810 - 20-ть цифр), соответственно после каждой цифры запускается таймер 18, отвлеклись на что-то - и все, набор закончен, тракт проключен. А про цифры спрашивал - когда приводят менеджмент с конкретными цифрами - эт понятно, а словам с дискриминатором у меня все в порядке - я никогда не верю, всегда смотрим и проверяем. Регулярно сталкиваешься - что люди работая с реальным 0-м дискриминатором забывают о логическом в TG, потом с удивлением вспоминают, что поменяли его когда-то.
Т.е. если разбираться с проблемой - всегда смотреть ТЕКУЩИЙ менеджмент и ни в коем случае не полагаться на память.
Т.е. в NDDI TG стоит number compat.=0? Вы набирали номер XXXX96YYYYY ? XXXX9 - это ячейка? А call number там чего? Overlap seizure на NDDI не распространяется. В локальных параметрах TG minimum no digits on seize надеюсь не стоит больше 6. Так как уменьшение 18 таймера приводит к уменьшению задержки (уже наверное почти приемлемая) - наводит на ощущение, что какие-то проблемы с форматом набора. Например вы почему-то смотрите в правила 0-го дискриминатора, а в TG поставлено No digits to send=20.
