Есть OXE с одной INTIP платой, которая используется для связи по ABCF-IP с другими OXE. Все ресурсы (тайм-слоты) платы выделены именно для этой цели. Имеется лицензия на IP транки в кол-ве 30 штук. Т.е в настоящий момент все лицензии уходят на созданную единственную транк-группу.
Появилась задача создания еще одной IP транк-группы. Возможно ли "откусить" заданное кол-во тайм-слотов от ABCF-IP транк группы для создания второй ТГ, чтобы не нарушить лицензионные ограничения? Будут ли работать обе транк-группы в рамках одной платы? Т.е. получается, что чисто гипотетически я могу в рамках текущей лицензии создать 30 IP ТГ по одному тайм слоту?
Спасибо!
Вызов через удаленную BCA транк-группу и долгое ожидание КПВ, Как оптимизировать
Прошу помочь советом. Есть центральная УАТС и несколько региональных. Все связаны по ABC через IP в одну сеть. Центральная УАТС подключена к ГТС через PRI. Региональные - через пучки CO-линий. В настоящее время для звонков на ГТС региона с центральной УАТС используем выход в город, что не является оптимальным решением с учетом возможности использования существующей IP сети.
Решили попробовать настроить Public-To-Private reroute, чтобы при наборе префикса выхода на ГТС и выявлении кода региона происходил вызов через удаленную BCA транк-группу заданного региона. Предварительно был проведен аудит по ТГ, таким образом, что в настоящий момент на центральном узле в БД есть все ТГ, как центральной УАТС так и региональных станций.
Настроил ARS, создал соответствующие Area. Все работает, но есть один неприятный момент: Когда абонент центральной УАТС набирает некий региональный номер, в ответ приходится ждать КПВ около 10-15 секунд, до этого в трубке молчание. Связано это, видимо, с тем, что КПВ не появляется пока на удаленной транк-группе не передастся полностью номер. А так как передача происходит в импульсном режиме, ждать приходится долго.
Соответственно возникли следующие вопросы:
1. Можно ли местную УАТС заставить формировать КПВ пока на удаленной станции происходит набор номера?
2. В связи с отсутствием должного опыта с сфере телефонии, огромная просьба просветить на тему возможности оптимизиции скорости набора при включении вместо импульсного тонового режима набора? Поможет ли это в данной ситуации? Можно ли в BCA транк-группе произвести переключение импульсного на тоновый режим? Также, насколько я понимаю, соответствующее переключение должен произвести оператор связи? Как наиболее корректно обратиться к нему по этому вопросу, чтобы не выгладеть дебилом?
Есть две станции, связанные по ABC через IP (центральный и удаленный офисы). На удаленной станции есть BCA транк-группы. Провел аудит по транк-группам в результате чего транк-группы удаленной станции появились в базе данных местной центральной. Решил проверить, могу ли я, абонент центральной станции, позвонить через IP и транк удаленной станции. Создал на центральной станции префикс занятия транк-группы (with overlapping) с информацией об удаленной ТГ. При наборе этого префикса с цифрового или DECT аппарата (аналог не проверял) удаленная ТГ действительно занимается, но вот при наборе последующих цифр городского номера никакой реакции - слышу постоянный длинный гудок. В параметрах ТГ сказано не использовать транслятор (-1), кол-во передаваемых цифр стоит 0 (пробовал указывать реальное кол-во - не помогает).
В связи с тем, что на станциях объединенных посредством ABC-F over IP, содержимое баз абсолютно некогерентно, решили провести аудит абонентов и транк-групп (для начала). Помогите пожалуйста ответом на имеющиеся два вопроса относительно процедуры:
1. Насколько я понял из документации, на второй стадии аудита опорный узел отправляет в том числе "местные" (maintaned identical) объекты на удаленные станции, выполняя на них замещение их "местных" объектов. Вот только не понятно: в этом случае будут замещены только пересекающиеся объекты или на удаленной станции вообще будут удалены местные объекты и установлены те, которые пришли с опорного узла? Т.е. в настоящее время на удаленной станции есть NPD, которой нет на опорном узле, будет ли она удалена в ходе аудита? К сожалению, насколько я понял, этот момент симуляцией не проверишь.
2. Насколько я понял в ходе аудита ТГ могут подтянуться и другие, связанные, объекты. Подскажите пожалуйста, на что нужно обратить первоочередное внимание при проведении аудита по ТГ, чтобы не "завалить" работу УАТС и минимизировать риски пропадания сервисов телефонии для абонентов в ходе данной процедуры?
Спасибо!
Изменение Entity у большого числа абонентов, Есть ли возможность автоматизации
Возникла потребность изменить Entity у почти сотни абонентов. Проходить по каждому - слишком трудоемкая задача. Есть ли какой-то способ сделать это за одну-две команды?
Подскажите пожалуйста, можно ли настроить АТС, ограничив кол-во хранимых тикетов о состоявшихся звонках, например, оставив только те, что были в последнем месяце. Сейчас на станции имеются файлы TAX***.DAT за прошлый год.
Аналогичный вопрос насчет инцидентов, отображаемых по incvisu. Можно ли задать или их кол-во, или временной период за который они хранятся?
Спасибо!
Корректировка базы с помощью fichges, Open file failed
Помогите пожалуйста советом. От тех.поддержки получил рекомендацию исправить ошибки БД станции воспользовавшись утилитой fichges с ключами recover dico и recover all. Тех.поддержка предупредила, что процедура опасная, возможно тотальное разрушение БД. В этой связи решили не рисковать и работы проводить в выходной день.
После выполнения команд постоянно сыпались сообщения типа
Позвонил в тех.поддержку. Они сообщили, что это нормально. Якобы несмотря на ошибку таблица пересоздается заново. Но у меня есть сомнения на этот счет.
Будьте добры, проконсультируйте по вопросу использования данной утилиты. Что конкретно она делает (действительно пересоздает БД, или только переиндексирует существующие таблицы БД)? Насколько она опасна и были ли прецеденты крушения БД? Действительно ли нормально появление сообщений об ошибке открытия файлов?
Большое спасибо!
Проблемы с подсистемой DECT при bascul, Нестабильная работа
При переключении работы с одного процессора на другой наблюдаем странности. Пару недель назад отключились некоторые трубки DECT - пришлось их перерегистрировать. Возможно, это связано с некогерентностью баз. Вчера тестировал станцию, предварительно проведя клонирование.
Во-первых, обратил внимание, что даже после клонирования, процессоры видят DECT базы IBS на выносе (подключен через INTOF) по-разному: основной процессор видит их нормально, как 6-канальные устройства, резерв при этом видит их как 3 канальные базы. После bascul оба процессора стали видеть их как 3 канальные базы. Одновременная перезагрузка обоих процессоров вернула все в исходное состояния: основной видит 6-канальные устройства, резерв - 3х канальные.
Странно, но после перезагрузки выноса путем rstcpl INTOF-платы выноса оба процессора стали видеть базы нормально.
Во-вторых, даже когда удалось добиться того, чтобы оба CPU видели базы как 6-канальные устройства, после выполнения bascul выявился следующий "косяк": при попытке дозвониться на трубку DECT, которая находится в спящем состоянии со своей трубки получаю в ответ на своей трубке сообщение Feature rejected. На стационарном аппарате короткий гудок, как будто трубку вовсе отключена. Но стоит эту трубку пробудить, т.е. либо физически к ней подойти и нажать любую кнопку, либо позвонив на тандемный стационарный аппарат (при его наличии), после чего входящие вызовы на нее начинаю проходить. Ситуация казалась крайне неприятной, т.к. проверку проводил в выходной день, когда большинства сотрудников не было на рабочих местах. Ожидал, что в понедельник начнет шухер.... Позже выяснил, что минут через 15 на спящие трубки могу-таки дозвониться. Это нормальная история?
P.S. Хочу еще добавить, что при переключении CPU в логах фиксируются инциденты типа
Код
06/06/15 11:23:54 000003S|000/15/-/---|=3:2040=Std By CPU. Bad term type = DECT_BS instead of POS_NUM Msg 7 n_term 0
Подскажите пожалуйста. На станции периодически появляются инциденты
Код
27/06/15 12:15:18 000003M|---/--/-/---|=0:1603=IO1 driver error, wrong telephone msg received, line 1451, position (0,13,254)
27/06/15 12:15:18 000003M|---/--/-/---|=3:1607=01.0d.0d.00.00.00.00.0d.04.fe.f9.00.15.ff.ff
Является ли увеличение частоты данных инцидентов признаком того, что базы на двухпроцессорной системе разъехались и необходимо выполнять клонирование?
Спрашиваю потому, что недавно переводили работу bascul-ом на резервный процессор, не обратив внимание на наличие данных инцидентов, после чего приличное кол-во трубок DECT отвалились (просто белый экран на трубках). После отключения трубок пришлось их регистрировать заново. Причем что интересно, команда dectrm для них не отрабатывала, ссылаясь на то что аппарат не является cordless.
Спасибо!
Не удается изменить приоритет синхронизации, На плате INTOF не меняется приоритет
Имеется станция OXE (R11) с выносом, подключенным через двойное INTOF подключение (по две платы на основной полке и выносе, одно из подключений MAIN, другое - STANDBY). На станции постоянно с периодичностью 2-5 минут возникает инцидент, о котором я уже как-то здесь писал, но ответа получить не удалось:
15/04/15 16:41:08 000003M|000/08/-/---|=0:3660=status of 8KFS (0 is OK, 1 is KO): 1 , value : 30 31 15/04/15 16:41:08 000003M|000/08/-/---|=0:3660=status of 8KFS (0 is OK, 1 is KO): 0 , value : 30 30
Обратил внимание, что когда общаешься с абонентом выноса, иногда проскакивают щелчки, кратковременно пропадает голос. Также понаблюдал визуально за платами INTOF. Действительно, в момент возникновения инциденота, примерно на одну секунду, загорается красным индикатор SYNC.
Стал более детально исследовать конфигурацию, и обнаружил, что в параметрах плат INTOF на выносе синхронизация выставлена в 255 (т.е. работать автономно). Вынос нас устанавливал подрядчик. Обратился к нему. Тот подтвердил, что эта настройка может быть причиной некорректной синхронизации и рекомендовал задать значения типа 10 на основной плате и 20 на резервной.
Подскажите пож-та, действительно ли данная настройка является причиной возникновения инцидентов?
Попробовал изменить приоритеты и ... не получилось - появилось сообщение об ошибке:
С чем может быть связан данный запрет и как его преодолеть?
Думал, что возможно, это связано с тем, что плата находится в состоянии INSERVICE. Хотел перевести ее в OUTSERVICE, но понял, что не знаю как это сделать. Пробовал варианты ouserv с различными ключами (например, outserv p 2 6 0 all - не отключает плату). Может ли состояние INSERVICE являться причиной запрета модификации? Ради проверки попробовал изменить приоритет на доступе работающей платы NPRAE - все изменяется без проблем.
Неужели проблема решается только пересозданием выноса? Если так, то что же делать с кучей абонентов, которые работают на этом выносе - ведь они насколько я понимаю, все удалятся? Восстановление из бэкапа тут не поможет.
Иногда возникает необходимость перерегистрации телефонных аппаратов DECT (используем модели 400 и 8232) на удаленной станции. При этом звонить пользователям и разъяснять как надо чистить EEPROM, а потом доходить до состояния running как-то нехорошо. Но и ехать на удаленную площадку ради одной двух трубок тоже невесело. Можно ли зная IPEI привязать трубку к станции без "перепрошивки" трубки? Может есть возможность как-то задать IPEI непосредственно в dectinston? Неужели администратор лишен возможности выполнения этой операции удаленно?
Спасибо!
Создание NDDI транка с подключением абонента напрямую, Аналог Cisco PLAR
Есть две станции OXE, соединенные по IP в единое ABC звено. На одну из станций приходит СО-линия, подключенная напрямую в обход станции к абоненту. В связи с организационными изменениями абонент переехал в зону действия второй станции. Ростелеком не может выполнить переключение старого номера СО-линии на площадку второго здания.
В этой связи есть мысль подключить СО-линию к имеющейся NDDI плате, создать соответствующий BCA транк, а на второй станции создать абонента. Вопрос: можно ли настроить станции таким образом, чтобы абоненту не приходилось набирать префикс занятия новой ТГ? Например, зная, что данный абонент особенный, и что он не может занимать другие ТГ, каким-то образом связать ТГ и абонента, так что при поднятии трубки для звонка в город станция автоматически коммутировала его на заданную ТГ?
Спасибо!
ABCF Logical Link over IP с несколькими платами INTIP
На станциях узла ABC сети создано по одной IP-транкгруппе. В состав транкгруппы включены доступы только одной из плат INTIP. Можно ли включить в транкгруппу плюсом доступы второй платы? Что будет со связью при отключении первой платы (насколько я представляю, текущие соединения разорвутся, но новые должны создаваться без проблем)?
Насколько мне известно, здесь могут быть проблемы связанные с лицензиями. На текущий момент spadmin показывает наличие H323 Virtual ... 92, и IP trunk тоже 92 - возможно данные параметры к данной задаче отношения не имеют.
В нашей организации эксплуатируется 7 станций OXE, объединенных посредством IP каналов в единое звено ABC. Так уж случилось, что на некоторых станциях значения PARI/PLI одинаковые. При этом роуминг корректно работает. Есть подозрение, что где-то этот недочет может всплыть, но где? Не отработает audit? Не смогу регистрировать трубки удаленно? Ведь если все работает в одинаковым значением PARI, то вообще теряется смысл правил назначения PARI - можно просто на вех станциях установить одно и то же значение и все будет работать.
Спасибо!
Низкая скорость модемного подключения, Для внутренних аналоговых абонентов скорость подключения - 9200 бс
Столкнулись со странной ситуацией. Станция OXE подключена двумя транками ISDN PRI (одним - к ГТС, вторым к узлу доступа Cisco с модемным пулом). При подключении модемом из города соединение устанавливается на нормальной скорости 56к. Если же внутренний абонент, подключенный к аналоговой плате ez32, пытается установить соединение по короткому номеру (соответствующему номеру пула), вызов устанавливается только на скорости 9200 бс. Проблема проявилась не сразу - достаточно долго все работало нормально. Пробовали перезагружать плату ez32, проверяли работу на другой аналоговой плате - бесполезно. Есть подозрения, что проблема появилась после перевода процессора на резерв (двухпроцессорная система CPU7-2).
Подскажите пожалуйста, с чем может быть связана данная проблема и как ее можно решить?
