Тема: выдают ли станции TDE и NCP по SNMP информацию, касающуюся телефонной части?
Ваша постановка задачи неправильная. Ибо программа TAPI отслеживает только те события, которые будут после её запуска. И стартует она довольно медленно.
эээ подождите.. т.е. вы хотите сказать, что по TAPI невозможно получить количество занятых внешних линий на момент запуска?
что же тогда показывает эта программа??
Вы хотите каждый раз запускать мониторинг заново, а потом его разрывать. И через некоторое время опять запускать мониторинг?
Система мониторинга будет каждые 30 сек. запускать программу, которая возвращает значение и завершается.
Проблему медленного старта, как вы сказали, можно решить, если указать мониторить только диапазон внешних линий.
Если вы запустите программу, когда соединение установлено, то при разрыве их будет отрицательное значение. Т.к. система событийная.
Вы меня совсем запутали.. Т.е. то, что я вижу в окне и заголовке этой программы, не имеет отношения к реальному положению вещей, а представляет собой некую дельту от стартового состояния, которое неизвестно? Но тогда смысла в программе ноль!
эээ подождите.. т.е. вы хотите сказать, что по TAPI невозможно получить количество занятых внешних линий на момент запуска?
Нет. Система событийная. TAPI в реале посылает уведомление о звонке на конкретной линии и изменении её состояния.
А программа по этим событиям “рисует” табличку на экране и по этим событиям изменяет её.
Система мониторинга будет каждые 30 сек. запускать программу, которая возвращает значение и завершается.
Проблему медленного старта, как вы сказали, можно решить, если указать мониторить только диапазон внешних линий.
Ещё раз повторяю АТС не хранит, не считает и не выдаёт информацию о количестве линий. Она выдаёт лишь уведомление в момент возникновения события! А мониторинг заключается лишь в подписке на эти уведомления на конкретных линиях.
Т.е. то, что я вижу в окне и заголовке этой программы, не имеет отношения к реальному положению вещей, а представляет собой некую дельту от стартового состояния, которое неизвестно? Но тогда смысла в программе ноль!
Так задумано Panasonicoм и многими производителями АТС. Ибо TAPI используется многими.
Ну вот, после четырех страниц и выяснили, что с АТС Panasonic невозможно получить информацию о загрузке внешних линий ни по SNMP, ни по TAPI, ни как либо ещё.
Замечательная АТС!
Ну вот, после четырех страниц и выяснили, что с АТС Panasonic невозможно получить информацию о загрузке внешних линий ни по SNMP, ни по TAPI, ни как либо ещё.
Замечательная АТС!
А вы знаете другую, которая это позволяет?
Ну вот, после четырех страниц и выяснили, что с АТС Panasonic невозможно получить информацию о загрузке внешних линий
Купите винтариф и не выносите людям мозг
винтариф может провести анализ загрузки линий
Можно же впринципе в самой программе жёстко задать диапазоны линий по типам и вести учёт по типам
Вы имеете ввиду, при запуске программы указывать диапазон СО, которые она будет опрашивать? В принципе можно, но это неудобный костыль, т.к. получается жесткая привязка к конкретной конфигурации конкретной АТС.
Вы можете сделать консольную версию программы, которая будет возвращать значение, а в качестве входного параметра будет диапазон СО? (если нет, то можете ли выложить исходники текущей версии программы?)Сколько же у Вас линий, если не секрет?
Тут дело не в количестве внешних линий, а в том, что разные типы линий используются под разные задачи. Например PRI - обычная телефония, LCOT - старая обычная телефония, VSIPGW - межгород voip, VIPGW - соединение с другой АТС в другом офисе.
Как ИТ-шник со стажем должен заметить, что нам, ИТ-шникам свойственно абсолютизировать технические решения. Я неспроста спросил про количество линий. У меня порядка 30 разномастных линий. Поток, город, VOIP, транки, GSM-шлюзы... В принципе, проблема нехватки линий не стоит. По двум причинам. 1. Если пользователи будут получать отлуп при попытке занять линию - тут же прибегут ко мне. 2. У меня на системнике все линии выведены на кнопочки и распределены на группы. Если где-то будет шкалить - я увижу. Вот и все. Если линий до 84 - DT 333+консоль справятся. Вот Вам и количество занятых линий Online 😊
Обсуждаемая прога позволяет видеть занятые линии практически в онлайне, при маленьком количестве линий этого тоже вполне достаточно, чтобы на лету оценить ситуацию. Пусть не в точности, но хотя бы качественно. А чтобы посчитать максимальную загрузку точно - можно вытащить данные, скажем, из любой читалки SMDR, загнать их в Эксель и издеваться над ними сколько душе угодно 😊. Кстати, мысль. eSmdr кладет данные в любую базу. Дальше их можно на лету брать оттуда по ODBC куда угодно, в тот же Эксель, и, опять же, делать с ними что душа пожелает.
Кстати, заметил еще один баг - иногда в заголовке показывает отрицательные значения (например CO:-1, CO:-2, CO:-3), и вообще несовпадения значения СО: в заголовке и количества СО в окне программы.
Кстати, мысль. eSmdr кладет данные в любую базу. Дальше их можно брать оттуда по ODBC куда угодно, в тот же Эксель, и, опять же, делать с ними что душа пожелает.
Последняя версия может сразу складывать данные в csv файлы, которые открываются экселем без лишних телодвижений.
А вы знаете другую, которая это позволяет?
не имел дела с другой, поэтому не могу ничего сказать.
Купите винтариф и не выносите людям мозг
а он что, получает данные от атс через астрал? судя по ссылке, он не может выдавать информацию в realtime, а делает отчеты из накопленных данных. Т.е. это скорее всего сбор данных через SMDR и их последующий анализ. Т.е. это не удастся прикрутить ни к одной системе сетевого мониторинга.
В принципе, проблема нехватки линий не стоит. По двум причинам. 1. Если пользователи будут получать отлуп при попытке занять линию - тут же прибегут ко мне. 2. У меня на системнике все линии выведены на кнопочки и распределены на группы. Если где-то будет шкалить - я увижу. Вот и все. Если линий до 84 - DT 333+консоль справятся. Вот Вам и количество занятых линий Online
то что вы описали, абсолютно несерьёзно. Вы сервера по такому же принципу мониторите?
Обсуждаемая прога позволяет видеть занятые линии практически в онлайне, при маленьком количестве линий этого тоже вполне достаточно, чтобы на лету оценить ситуацию. Пусть не в точности, но хотя бы качественно.
Ну вроде бы выяснили, что к реальности её показания имеют весьма отдаленное отношение.
Кстати, мысль. eSmdr кладет данные в любую базу. Дальше их можно на лету брать оттуда по ODBC куда угодно, в тот же Эксель, и, опять же, делать с ними что душа пожелает.
видимо да, остается только анализ логов SMDR. а это, как я уже написал, отсутствие realtime и невозможность использования совместно с существующими системами сетевого мониторинга.
Ну вот, после четырех страниц и выяснили, что с АТС Panasonic невозможно получить информацию о загрузке внешних линий ни по SNMP, ни по TAPI, ни как либо ещё.
Замечательная АТС!
Господа - не парьте друг другу мозг...
Тапи Вам покажет какие СО линии заняты, а какие свободны - это если нужна мгновенная статистика...
Но если нужна статистика использования линий во времени, то этим занимаются тарификаторы на основе SMDR информации....
maa1 - Вы начали за здравие, а кончили за упокой... начали с мгноменной занятости линий, а в итоге пришли к накопительной...
Пример мгновенной статистики - это кнопки на системном телефоне. Если кнопка светится, значит СО занята. Тапи это тоже видит.
Вы начали за здравие, а кончили за упокой… начали с мгноменной занятости линий, а в итоге пришли к накопительной
вы что-то путаете, мне как раз нужна мгновенная.
Тапи Вам покажет какие СО линии заняты, а какие свободны - это если нужна мгновенная статистика…
вы тему читали? оказывается не покажет
Тапи Вам покажет какие СО линии заняты, а какие свободны - это если нужна мгновенная статистика…
вы тему читали? оказывается не покажет
Почему не покажет? Покажет. Только не сразу после запуска. А спустя некоторое время. Глюк в подсчёте СО в заголовке я постараюсь исправить. Но он от TAPI не зависит.
а он что, получает данные от атс через астрал? судя по ссылке, он не может выдавать информацию в realtime, а делает отчеты из накопленных данных. Т.е. это скорее всего сбор данных через SMDR и их последующий анализ. Т.е. это не удастся прикрутить ни к одной системе сетевого мониторинга.
Какой астрал? Какие отчеты из накопленных данных? Какое отношение загрузка линий имеет к SNMP?
Запустите CallMonitor и убедитесь, что все отображается в реальном времени.
В принципе, проблема нехватки линий не стоит. По двум причинам. 1. Если пользователи будут получать отлуп при попытке занять линию - тут же прибегут ко мне. 2. У меня на системнике все линии выведены на кнопочки и распределены на группы. Если где-то будет шкалить - я увижу. Вот и все. Если линий до 84 - DT 333+консоль справятся. Вот Вам и количество занятых линий Online
то что вы описали, абсолютно несерьёзно. Вы сервера по такому же принципу мониторите?
😊. Несерьезно во всем полагаться на технические системы по одной банальной причине - железки, в отличие от нас с Вами, думать не умеют.
А если серьезно - Вы в МЧС или Скорой помощи работаете? Там нехватка линий, действительно, критична. Но там обычно денег на линии не жалеют. Городская линия в потоке - 250 руб в месяц. Это деньги для конторы? Свободно можно держать двойной или даже тройной резерв. В большинстве других систем достаточно словить пару-другую отказов по причине нехватки линий постфактум, по логам, и добавить пару-другую линий. В этом есть смысл. В мгновенном понимании того, что у Вас не хватает линий, смысла нет - Вы же все равно мгновенно количество линий не увеличите. Я к тому, что для принятия решения в этом вопросе, на мой несерьезный 😉 взгляд нужна статистика. Сколько линий не хватало, каких, когда не хватало, кому, в конце концов, не хватало. Может, они им и нафиг не нужны 😊 В этом случае есть достаточная подготовка для принятия решения.
По сути я пытаюсь до Вас донести мысль, что в большинстве нормальных организаций нехватка линий не есть критичная ошибка, требующая немедленного вмешательства. А требующая либо упреждающих действий, то есть наличия избытка линий, либо нормальных взвешенных решений по итогам анализа логов.
Кстати, сервера и АТС-ку я мониторю, действительно, по этому же принципу. Есть критические ошибки, о которых немедленно приходят СМС-ки и сообщения в почту. А есть чтение и анализ логов, которым мои админы и я занимаются ежедневно. Чтобы знать, что там реально происходит.
видимо да, остается только анализ логов SMDR. а это, как я уже написал, отсутствие realtime и невозможность использования совместно с существующими системами сетевого мониторинга.
Не ясно, какие системы сетевого мониторинга имеются в виду, и в чем конкретно заключается невозможность. Прикрутите eSMDR - и вешайте оповещения на какие хотите ошибки. А по оповещению анализируйте логи и принимайте решение. Вот Вам и весь мониторинг.
Кстати, посмотрите, в конце концов, какая инфа реально передается по SMDR. Многое прояснится 😊. И покрутите, для примера, Rander, который работает по TAPI и распрекрасно показывает в онлайне занятые линии, как внешние, так и внутренние.
Cyril
Почему не покажет? Покажет.
вы меня совсем запутали. то нет, то да.
Только не сразу после запуска. А спустя некоторое время.
через сколько времени?
Cyril
Почему не покажет? Покажет.
вы меня совсем запутали. то нет, то да.Только не сразу после запуска. А спустя некоторое время.
через сколько времени?
Объясняю, как это работает:
Сначала программа подписывается на события с каждой линии.
В момент поднятия трубки или появления звонка возникает событие NewCall (звонку приcваивается новый идентификатор ID).
Звонок отображается в программе.
При изменении статуса звонка происходит событие OnCallStateChanged. Приходит идентификатор ID звонка и
Новое состояние вызова, одна из констант:
Offering – пришел входящий вызов
Dialtone – поднята трубка, ожидание набора номера
Dialing – исходящий вызов, состояние набора номера
Proceeding – исходящий вызов, набор номера завершен, номер передан в телефонную сеть
Ringback – исходящий вызов, ожидание ответа абонента, КПВ
Connected – соединение установлено
Busy - занято
OnHold – вызов помещен на удержание
Conferenced – вызов добавлен в конференцию
Disconnected – вызов разъединен
Idle – вызов неактивен (завершен)
При Idle звонок удаляется из списка программы.
При изменении информации звонка происходит событие OnCallInfoChanged, Приходит идентификатор ID звонка и
Строка, в которой через запятую перечислены изменившие значение параметры вызова.
(В программе проверяет эту строку только на наличие параметра callerid.)
Вот и вся математика.
Если вы запустили программу когда у вас линии уже были в работе, то на них естественно не придёт событие NewCall, и они в программе не отобразятся. Будут отображаться только новые звонки. Но рано или поздно эти старые линии освободятся. И с этого момента состояние отображения будет актуальным.
