А я же писал, что проверял как звонком по короткому номеру, так и через выход на ГТС. Так что не грош.


Проверил. Действительно в этих кодах отличие. Когда звоню с ГТС, код 90 90 a3, а когда через ez32 - 80 90 a3. А что это вообще обозначает, уж прошу прощения за глупый вопрос? И что можно подкрутить?

Да, эксперимент проводил на одном ноутбуке. В одном случае включал просто в городскую сеть - всё ок. Во втором - на внутренний номер станции. Причем в этом случае при звонке по короткому номеру (к примеру, 1000) и при выходе на городскую линию через префикс с возвратом на тот же модемный пул (9 721000 - 9 - выход на город, 721000 транслируется в 1000) один и тот же негативный результат.

После эксперимента задействовал другой компьютер с внешним модемом. Проделал те же эксперименты с аналогичным результатом.

Обращался в тех.поддержку в одну из москвоских организаций. Сказали, что пробема с аналого-цифровым преобразованием на платах ez32, а причина, возможно, связана с некорректным параметрами, отвечающими за усиление-ослабление аналогового сигнала. Якобы, при сильном усиление срезаются вершины и как следствие происходит некорректное преобразование в цифровой вид. Где эти параметры - они не сказали. Вообще может быть такое? Если да, то где их искать?


Да, нашел этот параметр. Обязательно попробую. Но разве этот параметр может влиять на АНАЛОГОВОГО пользователя? Я думал, все что связано с ISDN это цифровые аппараты.

Кстати, пробовал менять такое свойство как Analog Type. Ставил MODEM, FAX - не помогает.

Спасибо!

Именно так. Может, конечно, поможет перезагрузка всей станции (этого я пока не делал). Но может есть какая-то закономерная причина?

Здравствуйте!

Столкнулись со странной ситуацией. Станция OXE подключена двумя транками ISDN PRI (одним - к ГТС, вторым к узлу доступа Cisco с модемным пулом). При подключении модемом из города соединение устанавливается на нормальной скорости 56к. Если же внутренний абонент, подключенный к аналоговой плате ez32, пытается установить соединение по короткому номеру (соответствующему номеру пула), вызов устанавливается только на скорости 9200 бс. Проблема проявилась не сразу - достаточно долго все работало нормально. Пробовали перезагружать плату ez32, проверяли работу на другой аналоговой плате - бесполезно. Есть подозрения, что проблема появилась после перевода процессора на резерв (двухпроцессорная система CPU7-2).

Подскажите пожалуйста, с чем может быть связана данная проблема и как ее можно решить?

Спасибо!

Здравствуйте!

Имеется станция OXE с дублированными CPU, двумя платами INTIPA. В настоящее время все подсоединено к одному коммутатору уровня доступа. Для построения ABCF over IP, подключения одного IP-выноса и подключения IP-телефонов используется только одна из плат (доступы созданы только для одной INTIP платы). Вторая, видимо (до конца не уверен), не используется, хотя IP адрес на ней прописан.

Есть желание разнести процессоры и платы по разным коммутаторам уровня распределения-ядра, повысив в целом отказоустойчивость платформы.

Включен взаимодействие процессоров по Ethernet вместо C1. Планирую отключить embedded ethernet и переключить физически процессоры на разные коммутаторы. Ознакомился с разделом IP Redundancy документации Alcatel. Не пойму, какие должны быть предварительные настройки второй IP платы, чтобы она могла на себя брать функционирование, в случае отключения первой платы? Должен ли я помимо IP адресов еще что-то настраивать? Например, для IP транк-группы создавать и указывать доступы для второй платы?

Большое спасибо!

Здравствуйте!

Съездил на место. Выяснилось, что с линией все нормально - при отключении станции и подключении простого телефона он работает в обе стороны. При подключении телефона просто в параллель (при включенной станции) телефон работает, однако при звонке на этот номер и снятия трубки на телефоне в первые секунды разговора также слышатся эти сигналы (3 коротких гудка - длинная пауза), повторяясь раз 5, потом разговор продолжается без помех.

Также есть некоторые странные моменты. Станцию разворачивали подрядчики, и я, к сожалению, участия не принимал. В текущей настройке каждую CO-линию они настроили в виде отдельной транк-группы (возможно, просто для наглядности, чтобы по trkvisu было видно по полю Name описание данной линии, например, номер ГТС). Однако, trkstat для всех транк-групп показывает hs. Причем, как для данной нерабочей транк-группы, так и для тех, которые работают, и жалоб от пользователей не поступает.

Еще один странный момент. Проверил настройки платы. Бросилось в глаза, что в Shelf->Board в параметрах платы Main/Standby State значится Standby(Slave). Сравнил с другой станцией - на той все нормально - Main(Master). К сожалению, изменить этот параметр не получается, видимо он неизменяемый и надо то ли плату пересоздавать, то ли какие-то другие манипуляции проделывать.

Прошу Вашего совета относительно текущей проблемы.

Спасибо!

Перезагружать барсум пробовал - не помогло. На ком-порт вставал ноутбуком - CDR-ки валятся. Хочу задать несколько уточняющих вопросов:
1. Корректно ли подключать MOXA к ком-порту станции прямым кабелем, а не нуль-модемом?
2. Критична ли настройка на станции Terminal Type TTY вместо привычного VTY100?
3. Имеет ли смысл ставить контроль управления потоком типа RTS/CTS вместо его отсутствия (где-то видел такую рекомендацию)?
4. Можно ли как-то, не перезагружая станция, "обновить" состояние ком-порта для выдачи тарификации? Где-то попадалась тема, что после отключения кабеля от ком-порта станция как-то запоминает текущее состояние и перестает слать в этот порт CDR-ки. Может ее надо потом как-то "разбудить"?

Спасибо!

Попробую. Видимо, все-таки придется выезжать на место. Офис этот расположен достаточно далеко - в другом городе. А народу, который может хоть как-то помочь там нет. Поэтому и хотел по возможности исключить варианты просто некорректной настройки станции. А не подскажете ли, можно ли как-то проверить по аналогии с трассировками mtracer, что вызов поступает на аналоговый порт платы NDDI? Или же для данных портов никакой диагностики в принципе не существует?

Спасибо!

Здравствуйте!

После временного отключения от станции OXE MOXA и последующего подключения в первоначальное состояние (спустя несколько дней) перестала сниматься тарификация со станции. Используется следующая структура

OXE (ttyS2) -> CBRMA (Port C) -> (COM Port 1) MOXA (Ethernet) -> LAN-IP -> Server (Barsum Enterprise)

В параметрах Accounting сказано собирать RealTime tickets через V24. В параметрах V24 (System -> V24 port) следующие данные

Dynamic - False, Parity - None, 8bits, Stop - 1, Terminal - TTY, RTS/CTS - False, Terminal Speed - 9600.

На MOXA выставлены аналогичные параметры. Проверял выдачу CDR-тикетов подключением с помощью нуль-модемного кабеля напрямую к порту C CBRMA ноутбука - записи выдаются. Для подключения станции к MOXA использую кабель прямого типа. В мониторинге MOXA показывает неизменяющееся нулевое значение входящих данных. С выхода MOXA по IP тоже естественно ничего нет. В IP-сети MOXA настроена как TCP-сервер, а сервер тарификации как TCP-клиент.

Подскажите пожалуйста, в чем может таиться причина проблемы.

Большое спасибо!

Здравствуйте!

Одна из станций в удаленном филиале подключена к ГТС через NDDI2. При звонке на один из номеров слышу в ответ три очень коротких гудка затем паузу (т.е. 1я секунда - три гудка, 2я секунда пауза). При этом телефон абонента не звонит. Сопряжение транк-группы для данной линии с аппаратом абонента реализовано через группы искания hunt-groups, т.е. в параметрах транк-группы сказано звонить на номер HG, в составе которой состоит один абонент.
Первоначально думал, что просто зависла плата. Пробовал ее перезагружать - бесполезно. На место еще пока не выезжал, саму линию до ГТС не тестировал, но возможно придется.

Подскажите пожалуйста, есть ли какие-то данные относительно указанного типа КПВ. Может ли (и если может, то что именно) некорректная настройка станции являться причиной данного КПВ?

Большое спасибо!

Здравствуйте!

Иногда, при возникновении каких-нибудь "глюков" с аппаратами используем простую процедуру пересоздания абонента. Проблема в том, что некоторые абоненты, типа секретарей, имеют очень большой перечень настроенных клавиш.

Можно ли как-то сохранить эту конфигурацию и применить ее затем на вновь созданного абонента? Можно ли это сделать средствами mgr? Можно ли это сделать средствами OmniVista 4760? И самое главное как (в двух словах)?

Большое спасибо!

У нас тоже все нормально. Воспользовались советом коллеги: указали Кувейт.

Понял, спасибо. Завтра же попробую поставить Кувейт.
А еще подскажите пожалуйста:
- в настройках временных зон есть такая галка - Hardware clock set to GMT. У нас она установлена. На что она вообще влияет?
- не очень понимаю, есть ли какая-либо связь между настройками времени в swinst и непосредственно в linux. Ясно, что нужно править настройки swinst. Но все-таки, эти настройки как-то связаны непосредственно с настройками linux? Т.е. можно ли задать время и зоны с помощью линуксовой команды date? (насколько я помню, этот фокус не работает, но вот почему - неясно)

Спасибо!

Здравствуйте, Коллеги!

Подскажите, кто что будет делать в этом плане? Может есть какие патчи?
Дело в том, что у нас несколько станций и релизы рознятся от 8-й до 11 версий.

Планируем по-старинке изменить зону Etc-4 на Etc-3 (живем по московскому времени). Подрядчик-же не рекомендовал настройки типа Etc, сославшись на возможные "косяки", сказал, что желательно ставить зону Moscow. Но, я так понимаю, в наших условиях с этой настройкой будет полная чехорда: какие-то станции будут автоматически переводить время на летнее-зимнее два раза в год, какие-то останутся на летнем и т.д.

Нужно добавить, что станции берут временные метки по NTP.

Какие у Вас планы на ближайшие выходные в этой связи?

Спасибо!

Коллеги, испробовал все варианты с перезагрузками:
-перезагрузил INTIPB плату 3-го кристалла
-перезагрузил обе INTOFB платы 2-го кристалла
-сделал dectrestart (правда, ожидал, что на время поотрубаются все трубки, но процесс прошел незаметно: трубки работали, лишь только в логе было сообщение о реинициализации)
-сделал dectview synibs

К сожалению, инциденты продолжаются сыпаться в том же количестве. Стоит отметить, что после dectview syncibs появилось сообщение


После syncibs ничего больше не делал. Может по-новому все поперезапускать?

Также хочу отметить еще один странный инцидент, наверное, связанный с первым. Обратил внимание, что сегодня, среди вороха событий 8KFS проскочило событие



Есть какие-нибудь мысли по данному поводу?

Спасибо!