Почитал документацию, в частности как Вы и рекомендовали раздел Public Networks/ISDN/Maintenance.
1. После этого решил попробовать оттрассировать исходящий вызов со своего внутреннего номера. Аппарат у меня DECT, внутренний номер 1473. Удалил все фильтры и запустил mtracer -a 1473. Набрал некий номер городской сети, но несмотря на установившееся соединение никакой трассировки не получил. Пробовал вместо 1473 указывать внешний номер после DID 790473, или даже с кодом города бед префикса занятия TG. Результат нулевой.
В чем я ошибся задавая номер? Ведь как я понял фраза "trace on interpreted output, where the number is in a message." означает именно наличие в сообщении номера и как мне кажется - того что после DID.
2. Хочу еще спросить по поводу фильтров. Задавая фильтр командой trc, мне стали любопытны поля desti, source, us, term. С Cr и Cpl понятно. Относительно desti и source написано "filter for a module". Это имеются в виду платы? Тогда в чем отличие от Cpl? Относительно us в документации замечательно описано. Оно означает "US". Что это? Term насколько я понимаю связан с аппаратом абонента. Но это не внутренний номер абонента? Можно ли его узнать зная внутренний номер?
Спасибо!
Лицензирование SIP и Softphones, Какие лицензии необходимы для расширения функционала
В настоящее время на наших 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? С чем может быть связана проблема?
Спасибо
Broadcast и разное ПО, Можно ли использовать ф-ции Broadcast
Эксплуатируем несколько станций OXE. Исторически сложилось, что релизы везде разные от 8-го до 11. Хотим настроить механизм Broadcast для обеспечения когерентности конфигураций АТС хотя бы в части каталога абонентов. Попадалась информация, что для корректной работы Audit и Broadcast необходимо, чтобы на всех станциях крутился один релиз. Так ли это? Можно ли задействовать хотя бы частичный broadcast в нашем случае?
Уточнил сведения и выяснил, что неверно обрисовал текущую ситуацию. На самом деле одна из станций работает на 11-м релизе и оснащена платами IO2N. Сигнализация тем не менее указана N64. Указанных ранее инцидентов не регистрируется. Вот текущий конфиг:
Код
Crystal 0 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 0 | 0 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 1 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 2 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 3 | eZ32_2|---------- |ONLY OPS FILE | BAD PCMS CODE |
| 0 | 4 | GPA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 6 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 7 | IO2N|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 8 | INTOF2A|---------- | REG NOT INIT | BAD PCMS CODE |
| 0 | 9 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 10 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 11 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 12 | eZ32|---------- | REG NOT INIT | BAD PCMS CODE |
| 0 | 15 | DECT8|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 17 | INTIPA| INT-IP | IN SERVICE | BAD PCMS CODE |
| 0 | 19 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 20 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 21 | IO2N|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 22 | BRA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 24 | INTIPA| INT-IP | IN SERVICE | BAD PCMS CODE |
| 0 | 26 | RMA|---------- |ONLY MAO FILE | BAD PCMS CODE |
| 0 | 27 | INTOF2A|---------- | REG NOT INIT | BAD PCMS CODE |
+-------------------------------------------------------------------+
Другие станции на 8м и 9м релизах. Плат IO2N нет. Текущий конфиг:
Код
Cristal 0 :
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 0 | 0 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 1 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 2 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 3 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 4 | eUA32|---------- | IN SERVICE | 3BA23266AAAA04 |
| 0 | 5 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 6 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 8 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 9 | eUA32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 10 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 11 | NPRAE|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 12 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 13 | INTIPA| INT-IP | IN SERVICE | BAD PCMS CODE |
| 0 | 14 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 15 | DECT8|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 16 | NDDI2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 17 | INTIPA| INT-IP | IN SERVICE | 3BA23193ACAF06 |
| 0 | 18 | INTIPA| INT-IP | REG NOT INIT | BAD PCMS CODE |
| 0 | 20 | CPU7_STEP2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 22 | BRA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 23 | GPA2|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 24 | DECT8|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 25 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
| 0 | 26 | RMA|---------- |ONLY MAO FILE | BAD PCMS CODE |
| 0 | 27 | eZ32|---------- | IN SERVICE | BAD PCMS CODE |
+-------------------------------------------------------------------+
Сигнализация также указана N64. Именно на этих станциях валятся сообщения о переполнении IO1. Пообщался с поставщиками станции: они сказали, что на последних двух станциях IO2N не нужен, так не та абонентская емкость. А первая станция была оснащена IO2N так при формировании заказа ACTIS указал на необходимость установки данной платы. В то же время четко ответить на вопрос: где тот порог абонентской емкости, после которого целесообразна установка IO2N - не смогли, сославшись на ACTIS, мол тот сам всё знает.
Прошу разъяснить следующие моменты: 1. Насколько критичны случаи переполнения C1 и инциденты 1602, 1608? Могут некорректно работать какие-то функции? (прошу прощения, что спрашиваю второй раз. Просто вопрос остался без ответа) 2. Есть ли четкие критерии, определяющие необходимость использования IO2N? Возможно на 2-й и 3-й станции, где имеют место указанные инциденты, данные платы необходимы. 3. На станции 1 (оснащенной IO2N) сигнализация указана N64. В то же время помимо Ethernet есть возможность выбора ION2 (или как-то так). Что это? А не означает ли данный вариант именно включение в работу IO2N? 4. Читал про подключение CPU7 к коммутатору и выбор режима Ethernet. Смущает следующая приблизительная формулировка: "необходимо подключение ВСЕХ Ethernet интерфейсов к одному коммутатору". Насколько я понял, каждая CPU плата имеет 2 порта Eth, один из которых используется для взаимодействие двух CPU между собой (т.е. CPU соединяются напрямую). Проверил на нашей станции - так и есть: CPU одним проводом связана напрямую, вторыми подключены к коммутатору. Так все-таки речь идет о включении в коммутатор каждой CPU двумя или одним линком?
На форумах встречал команду actdbg, а также, как я понимаю, связанную с ней tunner +at. Что это за параметры трассировки (в документации что-то не нашел описания ключа at для tuner, и уж тем более actdbg)?
Какие есть параметры данных команд? Можно ли ими пользоваться на "живой" станции в том смысле, что не создадут ли они чрезмерной нагрузки, в результате которой станция будет проседать по производительности, перезагружаться и т.д. и т.п.
1. На одной из трех станций периодически регистрируется инцидент 3074=Careful to disk age (1160 days / 3 years) На других станциях, несмотря на то, что развернуты они гораздо раньше (правда вместо 10-го релиза используют 8 и 9-й) подобного события никогда не возникало. Правильно ли я понимаю, что событие чисто информативное. Существуют ли какие штатные процедуры по проверке диска на наличие проблем? Или пока "не гавкнется" лучше ничего с ним не делать?
2. Фиксируются события 2663=IPS Chorus err: appli CMISE oper 9 err -8 С чем связан инцидент? Насколько я понимаю, CMISE - протокол связи с OmniVista 4760. Так? Т.е. ошибка какого-то взаимодействия с OmniVista? Можно ли конкретней узнать в чем суть инцидента?
Спасибо!
Обновление ПО, Возможность обновления ПО до новой версии
Имеем несколько УПАТС Alcatel OXE. На всех разные версии ПО: 8, 9, 10. Такая ситуация сложилась в связи с тем, что станции развертывались в разное время с интервалом примерно 1-2 года. В настоящий момент оборудование находится на технической поддержке у некой организации. Хотелось бы, чтобы все станции работали на одной версии ПО. Обратился с просьбой предоставить актуальные версии ПО в техподдержку, однако мне сказали, что ПО необходимо покупать, просто так, в рамках договора техподдержки, обновление 8-ки на 10-ку получить не получится. Это действительно так? Т.е. имея 3 станции с 8,9, 10-й версиями соответственно, я должен купить ПО версии 10 в количестве 2-х штук?
Спасибо!
Аппараты DECT и адресная книга, С некоторых аппаратов нет доступа к адресной книге
Прошу помощи. С некоторых DECT-аппаратов (DECT 400) нет доступа к адресной книге: невозможно набрав имя сотрудника позвонить ему. С других аппаратов, в том числе, аналогичного типа всё отлично работает. Коллега предположил, что возможно не хватает лицензий.
1. Действительно ли доступ к каталогу с аппаратов лицензируется? Если да, то как проверить доступное кол-во лицензий? В spadmin не нашел ничего похожего на данную функцию.
По причине увольнения основного специалиста, занимавшегося телефонией в нашей организации, всё телефонное хозяйство досталось мне. Изучаю текущее положение дел и штудирую документацию. Был на курсах года три назад "System Administration and Maintanance Part 1". Многое позабылось, многое осталось не раскрытым. Поэтому прошу отнестись с нисхождением к моим, возможно не совсем корректным, вопросам.
В нашей конторе используется 3 узла OXE (ACT), соединенных гибридными линками. Версия ПО везде разная: 8, 9, 10. Обратил внимание, что на всех узлах постоянно фиксируются инциденты: 1608=No more room to store signalling message, param.: 6 11256 11256 1602=IO1 driver error, full output link 6 Я уже как-то задавал вопрос на эту тему, и мне было порекомендовано изменить параметр Signaling с Nx64 на Ethernet. Хотелось бы прояснить следующие моменты: 1. Правильно ли я понимаю, что речь идет о перегрузке C1 линка процессорных плат (у нас дублированные CPU7-2), используемого как backplane для соединения всех плат в единый кристалл? 2. Насколько критичны данные случаи переполнения? Могут некорректно работать какие-то функции? Дело в том, что с этими инцидентами живем уже 3 года и вроде ничего не случалось. 3. Насколько я понял из документации плата IO2N за счет большей мощи должна разруливать подобные перегрузки. У нас в каждой станции установлено по 2 таких платы. Получается они не работают вовсе? Как можно проверить их реальную вовлеченность в процесс обработки? И вообще, насколько я понял, до какого-то момента данные платы можно не использовать и процессоры сами будут справляться. Но после некоторого порога имеет смысл использовать эти платы. Что это за порог? 4. При изменении параметра Signaling нужно ли перезагружать станцию?
Большое спасибо!
Инциденты 276 и 275, Периодически фиксируются инциденты 275 и 276
На имеющихся станциях OXE (ПО версии 8 и 9) периодически регистрируются инциденты 275 ACCOUNTING: Appl: ACCOUNTING: feature incident 77 1 (а также, бывает, 77 0)
276 External accounting application 4760: NO RECOVERY
Почитал описание инцидентов, но не понял, чем они вызваны (прошу прощения, опыт работы со станциями не велик). Ясно лишь, что что-то не так с системой тарификации. Она действительно включена, более того, имеется станция управления с развернутым ПО OmniVista 4760.
Подскажите пожалуйста, чем вызваны инциденты и как их устранить.
Коллеги, столкнулся с обозначенной выше проблемой. Имеем две станции: на одной установлен релиз R8.0.1-g1.503-12-a-ru-c7s2 на второй - R9.1-i1.605-16-c-ru-c7s2
При настройке забора времени с NTP-сервера на телефонах 2037 год и время смещено на 1.5 часа вперед (зона GMT-4, живу по московскому времени).
Два вопроса:
1. Упомянутый здесь хотфикс Hotfix_i1.605.21_tzdata годится только для 9-го релиза? Как в таком случае быть в 8-кой?
2. Где можно взять указанный хотфикс? Работаю в бюджетной организации и станцию нам поставлял некий, назовем его, продавец. Прямого доступа к софтварным ресурсам Alcatel не имею. В партнерских отношениях не состою.
