Огромное спасибо за информацию! Завтра же проверю. Насчет софта - мы не оператор и используемый у нас Барсум не относится к сертифицированному ПО. Используем в основном для создания отчетов и сверки со счетами присылаемыми операторами (подгружаем файл присланный оператором в формате xls и сравниваем по базе барсума действительно ли такие звонки имели место).
Получение тикетов о локальных вызовах, Способы получения и ПО
Имеем две станции OXE. На каждой имеются в том числе лицензии на тарификацию локальных (внутристанционных) вызовов (Ticket Local). Для сбора тикетов используем софт Barsum Enterprise достаточно старой версии (7.5). Сбор Барсумом тикетов происходит так: станция постоянно "выплевывает" на один из COM-портов свежую информацию о вызовах, преобразователь MOXA принимает эти данные. А далее, к нему уже по IP подключен сервер Барсум. Среди получаемых тикетов не обнаруживаются те, которые содержат информацию о локальных вызовах. Позвонил нашим инсталляторам, они сообщили, что локальные тикеты можно получить только по IP, вытягивая эти данные непосредственно с самой станции (т.е. сама станция отправлять на какой-либо порт их не будет). Соответственно предложили нам обновить наш Барсум за кругленькую сумму.
Подскажите пожалуйста, действительно ли так обстоят дела с локальными тикетами. Есть ли какие-либо альтернативные решения такому ПО как Барсум (у нас есть также Omnivista с модулем тарификации, но по историческим причинам, его практически для этих целей не используем)? Может быть есть какие-то opensource продукты для работы с тарификационными данными?
Спасибо!
Запрос к БД на получение Entity и Public COS абонентов
Есть необходимость автоматизированного получения списка абонентов станции, включая параметры Entity и Public Cos. На форуме нашел команду запрос к БД на получение имен абонентов
Команда отрабатывает корректно. Вот только бы хотелось дополнить вывод обозначенными ранее параметрами для каждого абонента. Подскажите пожалуйста, как это можно сделать или хотя бы сориентируйте, в каких таблицах хранятся эти данные. Вряд ли это таблица PHONEB (телефонная книга)?
+==============================================================================+
| T R U N K S T A T E Trunk group number : 703 |
| X Trunk group name : tut-espr |
| X Number of Trunks : 2 |
+------------------------------------------------------------------------------+
| Index : 1 2 X |
| State : F F X |
+------------------------------------------------------------------------------+
| F: Free | B: Busy | Ct: busy Comp trunk | Cl: busy Comp link |
| WB: Busy Without B Channel| Cr: busy Comp trunk for RLIO inter-ACT link |
| WBD: Data Transparency without chan.| WBM: Modem transparency without chan. |
| D: Data Transparency | M: Modem transparency |
+------------------------------------------------------------------------------+
Код
+-Review/Modify: Trunk Group----------------------------------------------+
| X |
| Node Number (reserved) : 7 X |
| Trunk Group ID : 703 X |
| Instance (reserved) : 1 X |
| X |
| Trunk Group Type + T0 X |
| T2 Specification + None X |
| Public Network Ref. : ------ |
| VG for non-existent No. + YES X |
| Entity Number : 0 X |
| Supervised by Routing + NO X |
| VPN Cost Limit for Incom.Calls : 0 X |
| Immediate Trk Listening if VPNCall + YES X |
| VPN TS % : 50 X |
| CSTA-Monitored + NO X |
| Max.% of trunks out CCD : 0 X |
| Ratio analog.to ISDN cost : ------ |
| TS Distribution on Accesses + YES X |
| Quality profile for voice over IP + Profile #1 |
| IP Compression Type + Default |
| Use of volume in system + YES X |
| Announcement for dial tone + NO X |
| Announcement for Ring tone + NO X |
| Reroute Anonymous Calls to Entity + NO X |
| End-to-end dialing + NO X |
| DTMF end-to-end signal. + NO X |
| Trunk group used in DISA + NO X |
| DISA Secret Code : ---- X |
| Routing To Manager + NO X |
| Trunk COS : 19 X |
| Sending of Progress message + YES X |
| No. of digits unused (ISDN) : 0 X |
| B Channel Choice + NO X |
| Channels: Attendant Control (Rsvd) : 0 X |
| Redirection For ACD (Dissuasion) + NO X |
| DTO joining + NO X |
| Consultation Call On B Channel + NO X |
| Automated Attendant + NO X |
| Calling party Rights COS : 0 X |
| TS Overflow + YES X |
| Number To Be Added : -------- |
| Charge Calling And ADN Creation + NO X |
| Use Split Access + NO X |
| Heterogeneous Remote Network + NO X |
| COS Restrictions - Barring mode + Not Restricted / Not barred |
| ARS Class of service : 31 X |
| External Access Server + NO X |
| CSTA Tracking MCDU Trk : -------- |
| X |
+-------------------------------------------------------------------------+
Код
+-Review/Modify: Board-------------------------------------------------------+
| X |
| Node Number (reserved) : 7 X |
| Shelf Address : 0 X |
| Board Address : 0 X |
| X |
| Interface Type + BRA2 X |
| Virtual board + NO X |
| Serial number : -------------- |
| Usage State + Active X |
| Operational State + Enabled X |
| Main/Standby State + Main (Master) |
| Number Of Sets Connected : 1 X |
| Country + Default X |
| Incidents Teleservice + YES X |
| X |
| ISDN Board Layer 2 Parameters |
| X |
| Retransmission Timer : 100 X |
| TEI Identity Check Timer : 100 X |
| Polling Timer : 1000 X |
| No. Of Retransmissions : 3 X |
| Max Frame Size (Bytes) : 260 X |
| X |
| T0 ISDN Board Layer 2 Parameters |
| X |
| Window Size In Frames SAPI S T0 : 1 X |
| Window Size In Frames SAPI P T0 : 3 X |
| X |
+----------------------------------------------------------------------------+
Код
+-Review/Modify: Digital Access---------------------------------------+
| X |
| Node Number (reserved) : 7 X |
| Shelf Address : 0 X |
| Board Address : 0 X |
| T0/T2 Access No. : 0 X |
| X |
| Access Type + T0 |
| Access Board Type + BRA2 |
| Synchronization Priority : 255 |
| Network Mode + YES |
| Max No Of Used B Channels : 2 X |
| Max No. Of Compressed B Channels : 0 X |
| Tieline Mode + YES |
| Access Type S0 + YES |
| Reserved1 + YES |
| Reserved2 + NO |
| Network Date Time Update + NO |
| X |
+---------------------------------------------------------------------+
Есть подозрения, что во всем виноват B Channel Choice + NO. Может ли это являться причиной проблемы?
P.S. К сожалению, пока поменять на YES и проверить не могу, т.к. УАТС находится в другом городе. Планирую туда выезд в ближайшее время. Хотелось бы приехать туда во всеоружии.
Спасибо!
Barring внутри сети, Ограничить возможность дозвона до некоторых внутренних абонентов
Проверил механизм Connection Cos. Все работает - пользователи жестко рубятся, получая сообщение Feature Rejected.
Хотелось бы немного смягчить схему таким образом, чтобы при наборе запрещенного номера абоненты либо переадресовывались на helpdesk, либо на автоответчик с инструкциями о том, что "по таким-то причинам вызов не может быть установлен, обращайтесь туда-то".
Это возможно?
Большое спасибо!
Barring внутри сети, Ограничить возможность дозвона до некоторых внутренних абонентов
vad пишет: Что вы понимаете под словами НЕ ДОЛЖНЫ дозваниваться? Самое простое - не набираемые номера - типа А2000 и т.п. Через DID и прочими способами можно туда вызов направить, а набрать нельзя (если только не запрограммировать на аппарате кнопку А).
Имею в виду, что нужно выделить номера IT-персонала в специальную группу. Другие пользователи не должны иметь возможности звонка напрямую (либо просто отбой, либо, что еще лучше, переадресация на helpdesk). При этом сам IT-персонал должен иметь возможность совершения звонков как между собой, так и остальным пользователям. Видимо, ненабираемые номера здесь не помогут.
В связи с организацией helpdesk в конторе встал вопрос о технической организации единой точки входа таким образом, чтобы внутренние абоненты были лишены возможности дозвона до специалистов 2-й линии тех.поддержки напрямую. На текущий момент все абоненты распределены по двум Entity, определяющими через какую из двух публичных ТГ выходить в город.
Сориентируйте пожалуйста, как можно добиться поставленной цели. Каков порядок вкратце? Подозреваю, что нужно разбить абонентов на Entity и как-то поиграться с Cos, но конкретики, к сожалению не знаю. Тем более, неясно, как быть с уже использующимся разбиением по Entity для использования разных каналов выхода в город.
Прошу помочь советом. Подключили к OXE систему транкинговой радиосвязи по BRI. При звонке с рации транкинговой системы на абонента OXE идет отбой. Трассировка показывает, что УАТС принимает SETUP, но в ответ шлет отбой со статусом No Circuits available.
Транк-группа настроена, доступы добавлены. При trkstat показывает оба канала как F (FREE).
Что еще может влиять на возникновение указанного статуса?
Большое спасибо!
Ремонт eZ32. Case 2, После перезагрузки станции перестала работать плата
А не могли бы Вы сориентировать, где этот блочок питания расположен?
По поводу АКБ - дело в том, что у нас такого тумблера, к сожалению нет. Видимо, когда производился монтаж станции, подрядчики просто его не установили. Поэтому получается, что у нас нет возможности корректного отключения станции - только методом откидывания клеммы с АКБ. Видимо, имеет смысл обратиться к подрядчикам с требованием сделать так как надо.
Ремонт eZ32. Case 2, После перезагрузки станции перестала работать плата
Обращаюсь с похожим вопросом относительно ремонта eZ32. Вчера меняли АКБ на станции. Предварительно выключили оба процессора, выключили блок питания, после чего станция перешла на питание на старые батареи. Заменили батареи на новые. Включили станцию и обнаружили, что одна плата eZ32 не грузится - нет индикации на плате, в config 0 пишет REG NOT INIT. Меняли плату местами с другой, работающей платой - проблема именно в данной конкретной плате. Конденсаторы на плате не вспухшие.
Помогите пожалуйста советом: 1. Что является наиболее уязвимым местом в платах данного типа? Что можно попробовать заменить для восстановления работоспособности?
2. Есть подозрение, что плата могла выйти из строя именно в результате замены АКБ. В ходе отключения старых батарей, в момент отключения клемм проскочила искра, что наверняка привело к кратковременному выбросу тока. Вообще, насколько корректно отключение АКБ наживую (CPU отключены, но на всех платах имеется питание)?
Спасибо!
Использование ресурсов INTIP несколькими транк-группами
Может я чего-то не понимаю. Поясните, если так. Насчет деления INTIP между несколькими TG задумался не с точки зрения кодеков, avaya и прочих упомянутых... Дело в том, что на текущий момент в центральных узлах (2шт.) установлено по 2 INTIP платы. Эти два узла связаны между собой, а также с другими региональными узлами через гибридные линки в одну сеть. При этом на центальных узлах под данные IP транк-группы назначены ресурсы (доступы) обеих плат, по 30 доступов с каждой платы. Т.е. все ресурсы отданы под эти TG. Используются доступы обеих плат с точки зрения повышения отказоустойчивости, для устранения единых точек отказа. Платы воткнуты в разные коммутаторы уровня распределения-ядра. Таким образом, при выходе из строя одной из плат INTIP, или коммутатора, система продолжает работать на другой плате INTIP. Недавно возникла задача сопряжения УАТС по H.323 с системами: 1. Корпоративной видео-конференцсвязи, построенной на основе Radvision: необходимо иметь возможность в ходе конференции подключать внутреннего абонента станции. В части голоса система работает по H.323. 2. Спутниковой передачи данных, содержащей в своем составе голосовой шлюз H.323.
Соответственно, возник вопрос, как этого добиться в рамках текущей аппаратной платформы. Насколько я монимаю, использовать существующую TG гибридных линков под H.323 нужды нельзя по причине разной сигнализации. В то же время разбивать существующую связку INTIP не хотелось бы по причине снижения надежности.
Вот и возник вопрос: можно ли "откусить" по половине доступов каждой платы от существующей транк-группы и выделить их под H323 TG. В этом случае удалось бы при сохранении надежности решить поставленную задачу.
Если что-то неправильно понимаю, прошу дать понять.
Спасибо!
Использование ресурсов INTIP несколькими транк-группами
Прошу прощения за долгое молчание. Хотелось бы вернуться к вопросу. Сеть действительно IP ISDN со звонками через VPN overflow. Необходимость использования еще одной (или нескольких) TG на одной плате имеется по следующим причинам. В настоящее время в станции установлено две платы INTIP. Ресурсы обеих плат присвоены IP ISDN транк-группе. Возникла потребность подключения по IP H.323 другой системы. Причем желательно, чтобы также обеспечивалась аппаратная отказоустойчивость.
Конечно, можно сейчас исключить одну из плат из ISDN TG и отдать эту плату под новую задачу, но, во-первых, в будущем возможно придется подключать по IP к станции что-нибудь еще и аналогичный вопрос все равно возникнет. Во-вторых, такая разбивка уже не будет обеспечивать первоначальную степень отказоустойчивости системы, так как возникнет две точки отказа.
Предполагал поделить ресурсы каждой платы пополам под созданные ТГ.
Цитата
vad пишет: Если они разные (разная маршрутизация, АОН и т.п.) - как вы по ВХОДУ отличите в какую TG пришел звонок? По PRI понятно, там тайм-слот есть, в IP нет.
Согласен, тут есть загвоздка. Разрешима ли она в том случае если по обоим входам трансляция номера не требуется. Будут ли работать входящие?
Спасибо!
Взаимодействие CPU через внешний Ethernet, Странная перезагрузка
Перевел режим взаимодействия CPU обратно с Ethernet на C1 (4x64). В этом случае механизм IP redundancy отрабаотывает нормально. При отключении сетевого линка до основного процессора примерно через 20-30 секунд резервный берет работу на себя. При этом бывший основной продолжает работать, не перезагружается, но телефония на нем умирает, так что требуется принудительный рестарт.
Возникает соответственно другая проблема. После того как вернул работу на C1 опять стали сыпаться инциденты о переполнении этого линка. Хотелось бы понять, чем вызвано это переполнение. Конфигурация на станции так часто не меняется, на других узлах ABC сети тоже практически все спокойно. Есть подозрение, что линк переполняется данными тарификации. Если это так, можно ли как-то добиться того, чтобы тарификационные данные не пересылались по C1 линку? Если все же переполнение связано с чем-то другим, уважительно прошу пояснить чем конкретно и поддается ли это какому-то управлению?
Спасибо!
Инциденты 3660 в большом количестве, Постоянно с периодичностью чаще одного раза в минуту регистрируются события
Хотелось бы вновь поднять тему. Дело в том, что выяснились некоторые обстоятельства. Во-первых, было выяснено, что при отключении потока PRI ГТС, откуда мы принимаем синхронизацию через наше же SDH оборудование, инциденты пропадают. Т.е. качество потока E1 похоже действительно страдает.
К сожалению, пока неясно кто виновник. Поток ГТС в виде интерфейса E1 мы принимает от Ростелекома. На его площадке установлено наше оборудование Cisco ONS15305, которое отображает принимаемые E1 на кадр SDH и далее по нашим оптическим линиям передается на основной наш объект, где установлен такой же Cisco ONS15305. Из него вынимаем E1 и подаем в УАТС. Т.е. возможно страдает принимаемый от оператора поток, а возможно нестабильность вносится нашими мультиплексорами.
Обращался в тех.поддержку обслуживающую данные мультиплексоры. Приезжал технический специалист с приборами для измерения качества потоков E1 - Metrotek Berkut-E1. Выполнили часть тестов:
1. На стороне оператора воткнули в мультиплектор прибор в режиме генерации тестовой последовательности, а на стороне станции, в максимально близкой к ней точке (включая всю пассивку в виде кроссов и плинтов) сделали физический заворот. BER по нулям в течение времени измерения 15 минут. Были кодовые ошибки, которые как выяснилось позже были связаны с тем, что прибор был настроен на тестирование неструктурированного потока, тогда как на мультиплексорах порты настроены в режиме структурированных.
2. Попросили оператора сделать петлю на их стороне и произвели аналогичные замеры. Тоже все по нулям.
3. В связи с не совсем корректными замерами на этапе 1 провели повторный тест: на стороне оператора установили физическую петлю в порту E1 мультиплексора, на нашем объекте прибором сняли замеры в режиме структурированного потока. Оказалось, что в этом режиме прибор измеряет другие, наиболее, как мне кажется, интересные параметры, в том числе максимальное значение частотной девиации.
Результат последнего измерения сейчас не помню, подрядчик обещал скинуть в ближайшее время. Пока есть следующие вопросы:
1. Когда говорят о том, что INTOF критична к качеству потока ГТС, от которого синхронизируется полка, есть ли какие-то явные числовые параметры в диапазоне которых указанных проблем с выносом не должно быть? Т.е. документировано ли где-то необходимое качество сигнала синхронизации? Например, джиттер не выше такого-то значения, девиация частоты такая-то и т.д.
2. Есть желание измерить качество принимаемого от оператора потока до нашего SDH оборудования. Спросил у подрядчика - можно ли производить замеры не тестовой последовательности с установкой петли, а воткнут в прибор поаваемый от оператора рабочий поток. Он сообщил, что нет. Но есть у меня некоторые сомнения на этот счет. Ведь служебные тайм-слоты никто не отменял, и, наверное, даже в рабочем потоке, прибор должен уметь разбирать эту служебную информацию. Так ли это?
