Здравствуйте! Анализирую станции 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. Гостевая трубка может приземлиться в абсолютно любой шел и иметь, соответственно, разные параметры, в частности, доступа. Т.е. сейчас у меня доступа на межгород нет, а завтра, глядишь повезет, будет. Можно ли как-то жестко задать привязку конкретной трубки к конкретному шелу?
Огромное спасибо!
Привязать 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, ведь на них будет использоваться разная версия ПО?
Есть ли еще какие нюансы, на которые стоит обратить внимание в моем случае?
Спасибо!
Запуск/останов телефонии без перезагрузки станции, Возможно ли?
Некоторые операции по обслуживанию станции требуют чтобы телефония была остановлена. Чтоб остановить телефонию приходится использовать Swinst с отключением функции автостарта телефонии и последующей перезагрузкой. Соответственно для запуска выполняем аналогичные действия в обратном порядке.
Подскажите, нет ли способа делать эти операции без перезагрузки станции? Например, останов какой-нибудь службы или нескольких служб типа service xxx stop, /etc/init.d/xxx stop, убивание (корректное) процесса типа kill -TERM и т.д. и т.п. Уж больно напрягает постоянно ждать, когда же станция соизволит загрузиться.
Спасибо.
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. Вот пример трассировки:
Имеем 7 узлов OXE, объединенных с помощью ABC гибридных линков по IP. На 5 узлах используется ПО версий от 9 и выше. На двух узлах релиз 8.0.1 патч 12. Стали изучать проблему прохождения факсов с помощью T38 по имеющимся IP линкам. Выяснили, что был настроен вразнобой протокол T38. Включили везде T38 only в true для работы по стандартному протоколу (false везде поставить не можем, т.к. на некоторых узлах стоят INT-IP3).
В документации вычитали If there are GD-3/GA-3/INT-IP3 boards on one node of the network, the T.38 only option must be enabled on all the nodes of the network. This entails that all the nodes must support the standard T.38 protocol. In other words, they must be in release R8.0.5 or later.
Т.е. два узла с релизом 8.0.1 выпадают из нашей схемы. Связался с поставщиком на тему обновления ПО, надеясь, что в рамках минорного релиза можно будет обновиться без покупки нового софта. Поставщик, посмотрев ресурсы Alcatel, проинформировал, что такого релиза как 8.0.5 не существует - последний 8.0.1. Также поставщик предположил, что возможно до 8.0.5 возможно будет обновиться путем установки патчей и предложил последний из доступных под номером 35.
Вопрос: прав ли поставщик насчет 8.0.5 и поможет ли обновление путем патча для включения T38only=true?
Спасибо!
Стыковка двух OXE через H323, Настройка взаимодействия
Есть необходимость связать две АТС OXE (Crystal и MG) по H.323. На станциях нет H323-терминалов, абоненты - цифровые и аналоговые аппараты, подключенные напрямую к станциям. Ознакомился с документацией (раздел H323: terminals, gateway, gatekeeper) и не совсем понял следующий момент: для трансляции E164 в IP в схемах документации используется Gatekeeper. А как же быть если его нет и станции связаны напрямую? Можно назначить какую-то одну из них на роль GK или каждая станция является GK, или же вообще можно настроить взаимодействие без GK?
P.S. Прошу Вашего терпения за столь очевидные вопросы - ранее АТС занимался очень опосредованно, а теперь вот приходится.
Большое спасибо!
Возможность связать две станции по IP, С учетом имеющихся лицензий
Пытаюсь к имеющейся сети ABC из 7 узлов (Crystal) привязать еще один (MG) по IP. Для начала решил проверить теоретическую возможность такой связи с точки зрения лицензионных ограничений. На узле сети ABC по spadmin(опция 2) обратил внимание на следующие, важные с моей точки зрения параметры: 19 Corporate netw.(ABC,ABCVPN,ISVPN) 500 80 VPN 500 132 IP-Trunk 94 187 H.323(G.711) network link 94 342 ABC-IP Access number 0 467 ARS 500
На новом (подключаемом) узле 19 Corporate netw.(ABC,ABCVPN,ISVPN) 0 80 VPN 0 132 IP-Trunk 30 187 H.323(G.711) network link 30 342 ABC-IP Access number 0 467 ARS 50
Насколько я понял из документации, отсутствие опции 342 на станциях говорит о невозможности их связи через ABC-IP trunk group. С другой стороны где-то на этом форуме попадался пост о том, что для связи через ABC logical link нужна опция 80 (VPN), и видимо, тоже надеяться на этот режим напрасно. Правильно ли я понимаю, что ABC по IP между этими станциями не поднять? Можно ли (без ABC) связать эти станции по H.323? Порядок связи примерно такой же (т.е. настройка hybrid link, объявление плат и т.д.) или есть разница (какая)?
Спасибо!
Проблема с broadcast, Ошибка после получения информации с удаленного узла
В очередной раз обращаюсь к Вашей помощи. Стал разбираться с включенным, но не работающим broadcast. Ситуация следующая - имеем один центральный узел (3) и несколько филиалов. Везде включен broadcast.
Код
(4)ri_06> mao -a
BROADCAST is on
MAOAGENT running process 0
MAO is on
MAO trace : off
Trace on BRODCAST is off
Synchronization 4400-47xx is on
(4)ri_06>
(3)xa000000> mao -a
BROADCAST is on
MAOAGENT running process 0
MAO is on
MAO trace : off
Trace on BRODCAST is off
Synchronization 4400-47xx is on
(3)xa000000>
Обратил внимание, что на удаленных узлах, после, например, создания префикса в центре, регистрируются инциденты
Код
24/02/14 14:44:49 000004M|---/--/-/---|=2:2777=Network mgt : from node 3, error CREATE PREFIX : 3 1 7570
24/02/14 14:44:49 000004M|---/--/-/---|=2:2767=Network mgt : creation on a file *RLOG.3.515
Попробовал открыть создаваемый log-файл в текстовом редакторе - сплошная неразбериха, видимо не для просмотра он предназначен.
Правильно ли я понимаю, что ситуацию спасет только приведение все в консистентное состояние с помощью аудита?
Станции достались "по наследству" от ушедшего из нашей конторы телефониста. И вот за пару недель работы с УАТС уже вторая заявка о неработающих hunt-группах. Работало ли оно раньше - не знаю, возможно нет. Смысл в том, что настроены hunt-группы, тип обзвона последовательный (sequential). В группу добавлено несколько аппаратов, в основной массе - цифровики 4029/4039 с привязкй по тандему DECT400. Почему-то звонок проходит только на первый номер, а при неответе не переключается на следующие. Создал стенд с аналогичной конфигурацией: два цифровых телефона, один с тандемом - все работает. Т.е. получается что не работают только некоторые группы искания. Почему?
Подскажите пожалуйста, в каком направлении копать?
Спасибо.
Определить TG в трассировке, Можно ли определить транкгруппу по трассировке
Имеем станцию, на которой используется ARS. Два маршрута для некоторого префикса: основной (TG 305) и резервный (TG 103). Хочу с помощью трассировки убедиться, что используется именно первая TG.
В настоящее время на наших OXE (3 станции) отсутствуют лицензии для SIP- и Soft- аппаратов. Хотим расширить текущий функционал (в основном с целью тестирования), чтобы была возможность подключения по 5 SIP и Softphones. Нужны ли какие-либо дополнительные лицензии, кроме непосредственно клиентских SIP и Softphones, чтобы к станции можно было подключиться с помощью софтового SIP-клиента, или алкателевского софтфона?
1. Нужно ли отдельно приобретать ПО софтфона или его можно бесплатно использовать при наличии лицензий на станции? 2. Правильно ли я понимаю, что имея на станции лицензии для SIP-аппаратов, можно будет создавать абонентов типа SIP, указывая для них соответствующий DN? При этом больше ничего покупать не надо? 3. Если есть необходимость связки станции с некоторым шлюзом типа Астериск по SIP, требуются лицензии другого типа?
Недавно занимаюсь телефонией и в частности Alcatel, поэтому прошу отнестись с пониманием к моему детскому вопросу. Ознакомился с разделом Public Networks документации. Не могу полноценно осознать суть NPD и NPI.
1. Правильно ли понимаю, что NPD позволяет определить DID транслятор, который будет использоваться. Однако сам номер NPD в сообщении SETUP не передается. Вместо этого в документации говорится о некотором Byte3, который позволяет определить номер NPI, а тот уже - номер NPD?
2. Что это за Byte3? Он определен стандартом Q.931 или каким-то другим? Каковы его возможные значения и как осуществляется сопоставление номеру NPI? Виден ли данный Byte3 в трассировке?
3. В рамках жестко заданного перечня NPI, не очень понятно как разрулить следующую ситуацию: допустим станция подключена потоком E1 к оператору типа Ростелекома. При входящих звонках в SETUP указан NPI ISDN national, которому сопоставляется NPD равный например 65, к которому уже привязан DID. Если я решаю подключить второго оператора, тот также возможно будет использовать NPI ISDN national. Т.е. мне не удастся использовать другой транслятор для второго оператора. Как же быть?
Спасибо.
P.S. Если я копнул уж совсем в азы, требующие долгого разжевывания, просьба порекомендовать, куда посмотреть на данную тему кроме документации Alcatel.
Об использовании mtracer и t3, Правила использования, типовые сценарии
Занимаюсь темой OXE недавно, поэтому прошу прощения за детский вопрос. С документацией по вопросу трассировки ознакомился, но не все уложилось в голове. Прошу помочь.
1. Насколько я понял, до запуска "mtracer -a" необходимо настроить фильтр с помощью "trc C <Cr> c <Cpl> t <int#>. Правильно ли я понимаю, что в качестве интерфейса можно указать любой порт любой платы, в том числе и NPRAE (например, второй порт), или NDDI, и в трассировку попадут только интересующие сообщения по данному порту?
2. Можно ли, и как, получить трассировку звонка заданного внутреннего абонента по его dir-номеру? Трассировку звонков НА данного абонента? Трассировку звонков между заданными абонентами A и B?
3. Имея опыт работы с оборудованием Cisco и учитывая такую особенность использования команды debug, как повышение нагрузки на железо, опасаюсь включать трассировку в рабочее время на станции. Сильно ли ее использование влияет на производительность станции? Чего стоит опасаться? Какие параметры особо опасны?
4. Обращал внимание на указанную в форуме команду t3 и,в частности, утилиту t3online. В чем принципиальное отличие от mtracer? Коллега на работе сказал, что эта команда трассирует на 3-м уровне. До этого мало общался с PBX и не совсем понимаю, где здесь OSI. Имеется в виду Layer3 применительно к ISDN? Т.е. Q.931 или что-то другое?
Подскажите пожалуйста, можно ли все-таки обеспечить прохождения факсов через IP если две станции оснащены разными платами INTIP? С чем может быть связана проблема?
