Проверил удаленную регистрацию трубки. Убедился что номер 1569 удаленной станции (узел 1) существует в префиксах на локальной станции (узел 3): номер узла соответствует удаленному (1), Number with subaddress = NO, Type = PWT/DECT Mobile, Identifier = 0. На локальном узле запустил dectinston 1569 -pari 11110000040
Появилось приглашение подтвердить параметры, правда смутило что PLI был указан 31. Согласился.
Трубка зарегилась. Однако после перезагрузки стала показывать Out of Range. Принес трубку на удаленный узел - работает корректно. Вернулся с ней назад на местный узел, опять Out of Range.
Почему?
Об использовании DECT, Несколько вопросов о подсистеме DECT
Здравствуйте! Анализирую станции OXE с разными релизами (от 8 до 11), доставшиеся по наследству от предыдущего админа. Станции соединены по IP с помощью ABC-IP hybrid link. Станции расположены далеко друг от друга, зоны действия DECT не пересекаются.
1. Одной из проблем является то, что когда некоторые абоненты одной станции входят в область действия другой, они значатся как Unknown sets. Поисследовав ситуацию, я понял, что это связано с тем, что на станциях абсолютно хаотично настроены PARI и PLI. Почитал теорию, но немного неуверен, правильно ли я ее понял. У меня сложилось впечатление, что PARI аналог адреса сети в IP протоколе, а PLI - аналог маски. Это так? Т.е. первые PLI цифр в PARI на всех станциях должны совпадать, а последние различаться подобно адресу хоста в IP-подсети?
Потребуется ли перерегистрация всех трубок станции после изменения ее PARI/PLI?
2. Насколько я понял из документации при необходимости регистрации трубки на удаленном узле совсем необязательно ее нести в зону действия этого узла. Якобы это можно сделать находясь в области локального узла. Т.е. немного переформулировав: Можно ли для пользователя удаленного узла проинициализровать трубку находясь в области действия локального узла с учетом того, что узлы соединены по IP гибридному линку?
Попробовал сделать так: на удаленном узле создал абонента типа GAP+, на нем же запустил dectinston с указанием только что созданного номера. Утилита стала ожидать включения аппарата. На локальном узле включил трубку в режиме инициализации. Связи утилиты и трубки не установилось. Что я делаю не так?
3. Не совсем понятна ситуация с shell-ами. Насколько я понял, shell это логическое место, к которому привязывается гостевая трубка. Но ведь имея несколько шелов я могу настроить им разные параметры, в частности разный Public COS. Гостевая трубка может приземлиться в абсолютно любой шел и иметь, соответственно, разные параметры, в частности, доступа. Т.е. сейчас у меня доступа на межгород нет, а завтра, глядишь повезет, будет. Можно ли как-то жестко задать привязку конкретной трубки к конкретному шелу?
Через CBRMA. Просто еще посмотрел на станцию сзади и обнаружил, что помимо кабеля с CPU на CBRMA с платы CPU выходит еще один провод, соединенный со вторым CPU.
Привязать IPTouch к другой станции, Настроить DHCP для подключения телефона к удаленной станции
Спасибо! Благодаря Вашим объяснениям удалось немного продвинуться, но до конца проблему решить не удалось.
Удалось разобраться с получением адреса по DHCP. Проблема заключалась в том, что порт коммутатора (Cisco), куда подключен телефон, я настроил в обычном режиме access
Цитата
switchport mode access switchport access vlan 19
Vlan 19 - выделенный Vlan для телефонии, куда подключены станции с платами, а также IP-телефоны. В настройках телефона сказал, что VLAN использовать не нужно (пробовал с наоборот, говоря телефону о необходимости использования VLAN, при этом VLAN ID = 19). В результате телефон не получал адреса по DHCP и застывал на втором этапе.
После того как я изменил настройки порта коммутатора на следующие
Цитата
switchport switchport voice vlan 19
Телефон успешно получил адрес. Изначально я не хотел настраивать voice vlan (802.1p) и поэтому использовал первый вариант настроек. Видимо, он оказался неработоспособен из-за AVA (Automatic VLAN Assignment). Наверное, нужно его отключать на станции, если есть необходимость использования простого access-порта. В общем, с горем пополам адрес я получил.
На удаленной станции создал абонента для этого телефона. На локальной станции в префикс плане автоматически (видимо через broadcast) префикс типа Network number прописался с указанием на удаленный узел (тип Station, идентификатор 74).
На локальной станции выполнил lanpbxbuild. В первую очередь решил посмотреть его текущие параметры и очень удивился когда увидел, что ничего не настроено, но IP-телефоны тем не менее работают. Добавил следующие настройки
Цитата
Download IP (TFTP Server) address 10.197.133.12 Download IP RD(TFTP Server) address 10.197.133.3 CPU1 IP address 10.197.133.11 CPU2 IP address 10.197.133.10
Остальное все - nonе. По адресам: процессоры локальной станции - 10.197.133.11, 10.197.133.10. Виртуальный IP на кластер (main) - 10.197.133.12. Виртуальный IP удаленной станции (там тоже два CPU) - 10.197.133.3.
Телефон загружается. Проходит 5-й этап. Просит ввести номер. Ввожу. Просит ввести пароль. Ввожу 0000. В ответ на телефоне получаю сообщение о достижении какого-то максимума.
Думал, что превышено кол-во лицензий на IP аппараты на удаленной станции. Однако spadmin показывает, что как минимум одна свободная лицензия есть точно.
Vad, спасибо за разъяснения. Прошу прощения что туплю, но если я решил использовать Ethernet, то что должно быть с указанной Вами перемычкой (межпроцессорный обмен по Ethernet должен быть разрешен?)? И остался неясным вопрос насчет физического подключения CPU к свичу, т.е. можно ли оставить текущее подключение, когда оба CPU одной ногой торчат в свич, а второй связаны друг с другом, или же вторую ногу надо тоже подключать к свичу?
Привязать IPTouch к другой станции, Настроить DHCP для подключения телефона к удаленной станции
Есть два здания. В каждом OXE ACT. Местная АТС - 11 релиз. Удаленная - 8-й. Узлы находятся в одной IP сети и связаны друг с другом через ABC-IP гибридный линк. Есть телефон IP Touch 4038. Необходимо привязать его к удаленной станции.
На удаленной станции создал соответствующего абонента. В параметрах телефона сказано получать IP по DHCP. Телефон находится в том же VLAN, что и CPU, INT-IP станций. При загрузке доходит до этапа 2. При этом по параметрам IP видно, что адрес телефон не получил, а в параметре CPU1 указан адрес местного узла. Насколько я понял, это связано с тем, что местный узел быстрее отвечает на DHCP-запрос, тем самым не давая удаленной станции повлиять на это.
Подскажите пожалуйста, можно ли добиться того, чтобы телефон взаимодействовал только с удаленным узлом?
Спасибо!
Установка патча при дублированных CPU, Порядок установки
Собираюсь впервые устанавливать патч. Станция ACT с дублироваными CPU. Релиз 8.0.1 патч 12. Буду обновлять до 35-го, который якобы последний для 8-го релиза.
Порядок установки в целом известен. Однако неясен нюанс относительно установки при дублированных CPU. Сначала нужно обновлять пассивный узел или наоборот? Не возникнет ли потом каких-либо проблем с синхронизацией между CPU, ведь на них будет использоваться разная версия ПО?
Есть ли еще какие нюансы, на которые стоит обратить внимание в моем случае?
куча вопросов. в первой станции IO2N появилась из-за наличия INTOF, что косвенно означает существование периферийного кристалла (его может не быть фактически - у вас эти платы не проинициализированы). если в периферийном кристалле за ИНТОФ стоит хоть одна плата eUA32 с аппаратами 9-й серии - наличие IO2N обязательно. Это касательно четкого критерия наличия IO2N.
да, действительно, имеется периферийный кристал, который проинициализирован и скоро будет развернут. Насчет IO2N всё понятно. Спасибо. Тема закрыта.
Цитата
Во втором кристалле у Вас ИНТОФ нет, зато есть куча INT-IP - скорее всего за этими платами у вас стоят перифеийные кристаллы, только с включением по IP. Судя по примеру инцидента - есть кристалл 6. У Вас инциденты идут по всем линкам или тоько по этому?
1. К сожалению, никаких 6-х кристаллов нет. Откуда станция берет эти данные - непонятно. Может ли быть такое, что где-то в конфигурации указано наличие 6-го кристалла, в то время как по факту его нет? Можно ли как-то отключить данный несуществующий кристалл, удалить о нем информацию?
Действительно есть куча INT-IP, но насколько я понял, основная масса из них не используется. Станция вяжется по IP (ABC-IP hybrid link) с 8-ю удаленными узлами. Но насколько мне известно, для этого достаточно одной платы. Также имеется небольшое количество IP-телефонов. Т.е. максимум необходимы 2 платы.
Цитата
4. надо оба процессора подключать к коммутаторам, если локальная сеть не айс то возможно что бд на процессорах будут расходиться. ребут атс потребуется
2. В настоящий момент оба процессора подключены к одному коммутатору. Также процессоры еще одним линком соединены друг с другом напрямую. Правильно ли я понимаю, что в моем случае достаточно просто поменять сигналинг на Ethernet и перезагрузить станцию или, все же, речь идет о необходимости разрыва прямого линка между CPU и его подключения через свич?
Спасибо!
Запуск/останов телефонии без перезагрузки станции, Возможно ли?
Некоторые операции по обслуживанию станции требуют чтобы телефония была остановлена. Чтоб остановить телефонию приходится использовать Swinst с отключением функции автостарта телефонии и последующей перезагрузкой. Соответственно для запуска выполняем аналогичные действия в обратном порядке.
Подскажите, нет ли способа делать эти операции без перезагрузки станции? Например, останов какой-нибудь службы или нескольких служб типа service xxx stop, /etc/init.d/xxx stop, убивание (корректное) процесса типа kill -TERM и т.д. и т.п. Уж больно напрягает постоянно ждать, когда же станция соизволит загрузиться.
Спасибо.
ARS switchover problem, Проблема переключения на резервный маршрут
Читал. В разделе в основном речь идет о том, что данный метод применяется чтобы связать абонентов через публичную сеть, когда приватная не может быть использована. Но вот про использование VPN overflow для гибридных линков как-то совсем мало информации.
ARS switchover problem, Проблема переключения на резервный маршрут
Спасибо за разъяснения! Немного неясно первое замечание. Правильно ли я его понял, что по умолчанию, при создании 2х маршрутов в ARS таблице, они распределяются по разным Time based таблицам, в связи с чем в любом случае требуется редактирование этих таблиц с целью объединения маршрутов в одной таблице?
Читал раздел ARS документации. Насколько я помню, Time based списки необходимы в том случае, если мы хотим настроить изменение маршрутизации в зависимости от расписания. Или я ошибаюсь?
По поводу Quality - возьму на заметку. Спасибо!
Насчет АОНа - тоже интересно. С чем может быть связан тот момент, что источник не отдает АОНа? Вообще, верно ли мое предположение о том, что при VPN overflow реальные номера не передаются в явном виде, а упаковываются (подобно тому как при передаче данных функционируют туннели GRE и IPSec в туннельном режиме) с использованием неких внешних данных (в данном случае виртуальных номеров)? Можно ли в этом случае каким-то образом все-таки отследить, что передается внутри? Например, использовать какой-то специфический фильтр или что-то еще?
Спасибо!
ARS switchover problem, Проблема переключения на резервный маршрут
В настоящий момент на узлах 1 и 3 настроен ARS таким образом, что по префиксу 8 существует 2 маршрута: один через tg 103, второй через tg 305. Однако, как выяснилось, на узле 1 первый маршрут - 103, второй - 305. А на узле 3 наоборот. Вариант 3-го узла является правильным, поэтому решил изменить конфигурацию узла 1 поменяв местами маршруты. Но предварительно рещил проверить, корректно ли отрабатывает маршрут через tg 305. Отключил физически интерфейс потока tg 103 и попробовал позвонить наружу - неудачно. На аппарате высвечивалось Out of service.
Абоненты узла 3 успешно звонят через tg 305. Абоненты узла 1 успешно звонят через tg 103. Абоненты между узлами также могут звонить друг другу без проблем. Между станциями настроен ABC гибридный линк по IP (TG300). Никаких DDI трансляций не используется.
Транкгруппы:
Код
output of all Trunk_Groups and Links
-------------------------------------------------------------------
Numb | Name | Type | Var. | Node | Pfx
-------------------------------------------------------------------
TG 103 | MPLS-r | T2 | ISDN | 1 => local | No pfx
TG 300 | IP | T2-IP | ISDN | 3 => remote | C300
TG 305 | MPLS | T2 | ISDN | 3 => remote | No pfx
Маршруты ARS первого узла (lookars r 1)
Код
(1)node1> lookars r 1
Tue Mar 11 09:44:08 GMT-4 2014
====================================================================
| A R S R O U T E S L I S T No 1 |
--------------------------------------------------------------------
| ROUTES DEFINITIONS X |
--------------------------------------------------------------------
|
| 1) trk_grp = 103 dialing_table = 0
| nb_deleted_digits = 0 inserted_digits =
| vpnCostLimit = 0
| idx_atm = -1
|
| --> trk_grp 103 local TG name : MPLS-r state : PART_FREE
| type : T2 variante : ISDN
| fais_suiv = -1 category = 0 nbjonc = 30
| vpnRate = 50 vpnCostLimit = 0
| Route usefull for : SPEECH FAX
| Protocole Type = DEPENDENT ON TG
| Route Type = Public
| NPD Id = 67
| Preempter = 0
| Trunk group source = ROUTE
--------------------------------------------------------------------
|
| 2) trk_grp = 305
dialing_table = 0
| nb_deleted_digits = 0 inserted_digits =
| vpnCostLimit = 0
| idx_atm = -1
|
| --> trk_grp 305 remote TG name : MPLS
| type : T2 variante : ISDN
| node_number = 3 network_number = 15
| fais_suiv = -1
| Route usefull for : SPEECH FAX
| Protocole Type = DEPENDENT ON TG
| Route Type = Public
| NPD Id = 67
| Preempter = 0
| Trunk group source = ROUTE
--------------------------------------------------------------------
Пробовал включить трассировку между узлами. Для фильтрации, не зная, как можно настроить более конкретный фильтр, использовал trc C 0 c <INTIP slot>. К сожалению, ничего толкового поймать не смог: во-первых, между узлами достаточно интенсивное взаимодействие абонентов, поэтому в трассу попадает много лишнего, во-вторых, насколько я понял по пойманным данным, в связи с тем что между узлами используется гибридный линк с VPN overflow реальное взаимодействие ведется между виртуальными префиксами типа VPN Overflow. Вот пример трассировки:
Благодаря Вашим советам удалось обеспечить частичную работоспособность - вызов проходит только в одну сторону. По предыдущим проблемам: 2. Действительно не было создано диапазона для ячеек Speed dial. 3. Настроил префикс со значением Professional trunk seizure (т.е. без overlapping) 4. Поправил IP адреса назначения на адреса плат INT-IP.
Первый вопрос открыт. Дело в том, что на станции 1 установлена плата INT-IPA. Как раз на ней создана IP транк группа для связи с другими узлами (удаленными филиалами) по гибридному линку с VPN overflow. Насколько я понял из документации (раздел Configuration procedure - IP trunk group) фраза "Note: A GD, GA or INT-IP A board can only support one trunk group." означает, что о тестовой IP транк группе, которая разделяла бы ресурсы платы с существующей можно забыть. Так что стал экспериментировать с существующей транк группой на 1-м узле. На втором узле создал транк группу в соответствии с документацией.
В результате вызов в 1-го узла на 2-й проходит корректно. Т.е. с номера 1570 удается дозвониться по номеру 3508. При вызове в обратную сторону (с 3508 на 1570) происходит отбой (короткие гудки). Трассировка со станции 2:
DID вроде бы не настроен. Насколько я понял, отбивает именно первая станция, не предоставляя 2-му узлу B-канал. Причина - неправильный формат номера. Но почему - непонятно.
