ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Автообзвон

Есть задачи реализация которых возможна через автоматический обзвон. Например ?

Например вы сис.админ, у вас есть локальная сеть и куча оборудования в ней, но вы же не 24/7 на работе, а раз так, то в сети может что то произойти, например событие в системе мониторинга, а вас нет на рабочем месте. Конечно можно отправлять себе SMS, если такая вожможность есть, а имея сервер Asterisk можно и позвонить и самому себе рассказать что же случилось 😉

Или вам необходима система callback, что бы позвонив на номер заведенный на Asterisk, вы могли получить с него обратный звонок и набрать другой номер.

Итак, считаем что у вас у уже есть установленный и настроенный сервер Asterisk, который имеет выход в город.

Что бы совершить автоматический звонок нам потребуется следующие вещи:

  • сформировать call файл
  • иметь в диалплане (dialplan (определяется в /usr/local/etc/asterisk/extensions.conf)) контекст (context) со списком действий

Начнем с call файла, его основной синтаксис:

  • Channel: <channel> — Какой канал использовать для звонка
  • CallerID: «name» <number> — Установить Caller ID, проще сказать тут мы можем выставить АОН (номер с которого мы звоним).
  • MaxRetries: <number> — Максимальное кол-во попыток дозвониться, по умолчанию 0, что является одной попыткой.
  • RetryTime: <number> — Время в секундах между попытками дозвона, по умолчанию 300 (5 минут).
  • WaitTime: <number> — Сколько секунд ожидаем поднятия трубки, по умолчанию 45.
  • Context: <context-name> — Какой контекст используем из extensions.conf
  • Extension: <ext> — Какой экстеншн используем в выбранном контексте (так же в extensions.conf).
  • Priority: <priority> — С какого приоритета начинаем.

Я привел не полный список, полный список доступен тут. Лично я, для каждого номера, создаю свой контекст в extensions.conf.

Соответственно зная синтаксис мы теперь сможем сформировать call файл, на примере звонка через SIP канал:

Channel: SIP/89161112233@sip-provider
Callerid: 9998877
MaxRetries: 2
RetryTime: 20
WaitTime: 60
Context: outgoing_to_89161112233
Extension: s
Priority: 1

Для тех кто в танке 🙂 разберем call файл построчно:

  • позвонить на SIP номер 89161112233 через провайдера sip-provider (имя из /usr/local/etc/asterisk/sip.conf для выхода в город)
  • использовать АОН 9998877
  • Максимальное кол-во попыток дозвона 2
  • Пауза между попытками 20 секунд
  • Ожидать поднятия трубки 60 секунд
  • Использовать контекст (context) с именем outgoing_to_89161112233
  • Начинать с экстеншена (ext) s
  • И начинать с приоритета 1 в экстеншене s

Сформировав call файл, его необходимо положить в папку:  /var/spool/asterisk/outgoing/ сервер Asterisk обнаружив в этой папке файл сразу же попытается отработать его.

Сразу скажу, что можно и задержать обработку файла, т.е. задержать исх. звонок и отложить его на определенное вами время.

Сервер Asterisk смотрит на дату создания call файла и если изменить дату создания на дату в будущем, то Asterisk не будет отрабатывать call файл, пока не наступит эта самая дата.

Как это сделать ? Очень просто, для этого воспользуемся командой touch, которая есть во всех unix системах.

После того как создали сам call файл берем и меняем дату его создания, шаблон даты такой:

ГОДМЕСЯЦДЕНЬЧАСЫМИНУТЫ.СЕКУНДЫ (внимание: перед секундами стоит символ точки, это так и нужно, а не опечатка).

Для примера выставим дату в будущем, скажем это 09.07.2010 19:18:55:

/usr/bin/touch -t 1007091918.55 /path/to/call/file.call

Дата создания call файла изменится и если переместить файл в /var/spool/asterisk/outgoing/, то соответственно Asterisk его не обработает до тех пор пока не наступит выставленная дата.

Совет: генерить call файл лучше в какой то tmp директории, выполнять над ними все необходимые и действия и затем мувить (переносить) в /var/spool/asterisk/outgoing/.

Теперь посмотрим на сам контекст (context), для системы мониторинга он может быть таким:

[outgoing_to_89161112233]
exten => s,1,Answer
exten => s,n,Wait(1)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/welcome)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/Down)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/provider-a)
exten => s,n,Background(/usr/local/share/asterisk/sounds/monitoring/bye)
exten => s,n,hangup

Исходя из данного контекста Asterisk дозвонившись до 89161112233 (человек взял трубку) выполнит следущее:

  • поднимет трубку со своей стороны
  • секунду подождет
  • проиграет записанные вами звуковые файлы (полные пути к файлам указаны)
  • повесит трубку

Как записать голосовые файлы (то что вы будете проигрывать) вы можете узнать из этой статьи.

После того как Asterisk полностью отработает call файл, он его удаляет из директории /var/spool/asterisk/outgoing/.

Специальный экстеншен ‘failed
Если на вызов не ответили, и существует стандартный экстеншен с именем failed и команда с приоритетом 1 в заданном (в .call файле) контексте, управление будет передано этой команде.

exten => failed,1,Set(NumberDialed=${CUT(PassedInfo,,1)})
exten => failed,n,SetCDRUserField(${NumberDialed})

[Добавлено 11.02.2011]

Может появится ещё одна задача, а именно: если при автодозвоне трубку так и не подняли, то сразу набрать другой номер. Пример такой конструкции:

  • сначала набираем внутренний SIP  номер (6003) человека
  • если внутренний SIP номер не отвечает/занят/недоступен — набираем мобильный номер

Кажется, ну что может быть проще, написать:

exten => failed,1,Dial(SIP/89161112233@sip-provider)

А вот тут то и выяснилось, что не все так просто. На такое действо вы в консоле (выставив core set verbose 3) увидите подобное сообщение:

— Executing [failed@dialsip:1] Dial(«OutgoingSpoolFailed», «SIP/6003») in new stack
[Feb 11 16:57:44] WARNING[94371]: channel.c:3441 ast_request: No translator path exists for channel type SIP (native 65535) to 0
[Feb 11 16:57:44] WARNING[94371]: app_dial.c:1296 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 58 — Bearer capability not available)
== Everyone is busy/congested at this time (1:0/0/1)
== Auto fallthrough, channel ‘OutgoingSpoolFailed’ status is ‘CHANUNAVAIL’
[Feb 11 16:57:54] NOTICE[94371]: pbx_spool.c:356 attempt_thread: Call failed to go through, reason (8) Congestion (circuits busy)

Усе… приехали…. Лазая по результатам поиска в гугле я натыкался на сообщения:

Канал получается OutgoingSpoolFailed и именно в него пытается звонить и Dial и играть Playback. Как мне находясь в failed сделать звонок на SIP и проиграть сообщение?

Собственно точно такой же вопрос задавал себе и я сам, но ответа на него ни в Инете ни у меня не было.

Так же как и я народ пытался реализовать подобное через failed c Goto, System и т.п., но результат получался таким же — никаким 🙁

Получается из starndart extention failed сделать набор (Dial) другого номера не получится…..

Я уже было подумал, что не судьба и мне придется ловить DIALSTATUS, передавать его AGI скрипту (который ещё и писать придется) и тот уже будет решать что с этим делать (создавать новый call файл или ещё что то), но тут родился ещё один вариант:

core*CLI> core show channeltypes
Type        Description                              Devicestate  Indications  Transfer
----------  -----------                              -----------  -----------  --------
Skinny      Skinny Client Control Protocol (Skinny)  no           yes          no
SIP         Session Initiation Protocol (SIP)        yes          yes          yes
Console     OSS Console Channel Driver               no           yes          no
MGCP        Media Gateway Control Protocol (MGCP)    yes          yes          no
Local       Local Proxy Channel Driver               yes          yes          no
Zap         DAHDI Telephony Driver w/PRI             no           yes          no
Agent       Call Agent Proxy Channel                 yes          yes          no
----------
7 channel drivers registered

core*CLI> core show channeltype Local
-- Info about channel driver: Local --
Device State: yes
Indication: yes
Transfer : no
Capabilities: -1
Digit Begin: yes
Digit End: yes
Send HTML : yes
Image Support: no
Text Support: yes
core*CLI>

Создаем call-файл уже чуть другого содержания:

Channel: Local/1@autocaller
Callerid: 9998877
Context: outgoing_to_89161112233
Extension: s
Priority: 1

Где autocaller это название контекста, а 1-ца это приоритет в этом контексте. Соответственно делаем в extensions.conf этот контекст:

[autocaller]
exten => 1,1,Macro(call6003user,6003)

Тем самым мы как бы набираем уже не номер, а конкретный exten  в контексте и в нем передаем вызов в макро, создаем и макро, которое используется в этом контексте:

[macro-call6003user]
exten => s,1,Dial(SIP/${ARG1},15,t)
exten => s,n,Goto(s-${DIALSTATUS},1)
exten => s-NOANSWER,1,Dial(SIP/89161112233@sip-provider)
exten => s-NOANSWER,n,VoiceMail(${ARG1},u)
exten => s-NOANSWER,n,Hangup()
exten => s-BUSY,1,VoiceMail(${ARG1},b)
exten => s-BUSY,n,Hangup()
exten => _s-.,1,Goto(s-NOANSWER,1)

Собственно этот макро дает нам возможность уже управлять куда и в каком случае пойдет вызов. Пример конечно «грубый», но главное ведь принцип, а дальше уже ваше творчество 😉

И вот таким образом мы получаем искомый результат.

[Конец добавленного 11.02.2011]

Callback

Он работает по тому же принципу, что и описанный выше автообзвон, за некоторыми исключениеми:

  • генерация call файла происходит при звонке человека на номер выделенный под callback.
  • в контексте (context) мы не просто проигрываем звуковые, а предлагаем пользователю ввести номер, на который он хочет позвонить

Что нам потребуется в этом случае:

  • выделить номер для callback и создать контекст (context) под него в  extensions.conf.
  • «передать»  звонок в AGI скрипт, который проверит АОН звонящего на предмет разрешен ли этому номеру callback
  • если  callback разрешен, то сформирует call файл.

AGI — это Asterisk Gateway Interface.
Asterisk Gateway Interface это возможность расширить функционал Asterisk`а с помощью использования скриптов на многих языках программирования. Например Perl, PHP, C, Pascal, Bourne Shell.

Начнем с номера, допустим это будет гор. номер 84955556677. Добавим в extensions.conf в контекст (context) куда поступают все входящие звонки:

exten => 84955556677,1,AGI(sms-callback.php)
exten => 84955556677,n,Hangup()

Т.е. звонок на экстеншн (ext) 84955556677 будет передан AGI скрипту callback.php, а затем звонок будет сразу же завершен.

AGI скрипты для Asterisk располагаются в директории  /usr/local/share/asterisk/agi-bin/.

Почему скрипт на PHP ? PHP был выбран для AGI, т.к. callback является неотъемлимой частью проекта написанного на PHP + MySQL, потому решили и AGI пусть на PHP будет.
Сам скрипт: http://subnets.ru/files/callback.php.txt

Что происходит с скрипте ?

  • определяем необходимые переменные
  • получаем данные от Asterisk`а.
  • логи, куда же без них. В лог мы поместим все то, то получил AGI скрипт от Asterisk`а, это для дебага, потом можно выключить логирование.
  • проверяем номер (АОН) звонящего на доступ к callback
  • смотрим нет ли уже call файла для  данного номера, если нет, то создаем его

В переменной $agivar[‘agi_callerid’] и содержится АОН (телефонный номер) звонящего переданного нам Asterisk`ом, что в других передаваемых переменных вы сможете увидеть в log файле.
Если установить $debug в ноль, то тем самым выключите логирование.
В массиве  $permit_num содержатся номера для которых разрешен callback.

Ну и осталось дело за малым, а именно что бы был контекст (context) под звонящий номер в extensions.conf.

Допустим наш callback номер 84955556677 набрали с мобильного 89105647899 и ему разрешен callback (номер84955556677 указан в массиве  $permit_num в скрипте), то его контекст может выглядеть вот так:

[outgoing_to_89105647899]
exten => s,1,Set(CallbackNumTries=0)
exten => s,n,Set(CALLERID(num)="9998877")
exten => s,n(start),Background(vo-vvedite-ton-num-abonent)
exten => s,n,WaitExten(10)
exten => 100,1,Dial(SIP/8495${EXTEN}@sip-provider,120)
exten => _XXXXXXX,1,Dial(SIP/8495${EXTEN}@sip-provider,120)
exten => _8X.,1,Dial(SIP/${EXTEN}@sip-provider,120)
exten => i,1,Set(CallbackNumTries=$[${CallbackNumTries} + 1])
exten => i,n,Playback(vo-nomer-nabran-ne-verno)
exten => i,n,GotoIf($["${CallbackNumTries}" < "3"]?s|start)
exten => i,n,Playback(vo-dosvidaniya)
exten => t,1,Set(CallbackNumTries=$[${CallbackNumTries} + 1])
exten => t,n,GotoIf($["${CallbackNumTries}" < "3"]?s|start)
exten => t,n,Playback(vo-dosvidaniya)
exten => t,n,Hangup()
  • устанавливаем число попыток в ноль
  • выставляем АОН (под исх. звонок)
  • проигрываем записанный текст: «переведите ваш телефон в тональный набор…. бла… бла.. бла…»
  • 10 сек. ждем от человека набора номера
  • указываем возможный набор номеров: 100 (узнать время ;)), 7-ми значный номер, 8-рка и далее сколько угодно цифр
  • даем человеку три попытки на набор номера, если истек таймаут набора номера или номер был набран не верно, то человеку это озвучивается и кол-во попыток увеличивается на 1-цу и наше мини голосовое меню начинается сначала (возврат к метке start)
  • если кол-во попыток исчерпано, то Asterisk вешает трубку

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 19, среднее: 4,95 из 5)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Нам недавно пришлось реализовывать «кабельный тестер» на PHP. В Инете нашлась статья, спасибо автору большое, которую я и приведу, прежде чем переходить к кодингу:

В коммутаторы DES-3526 и DES-3550 (возможно DES-3028 и DES-3052) встроен кабельный тестер который позволяет определять (уточнить точность измерений) длину кабеля.

Использование из CLI

Комманда не требует админских полномочий (повторяющиеся строки удалены):

DES3526:user#cable_diag ports 1-24
Command: cable_diag ports 1-24

Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  1     FE      Link Down      OK                             -
  2     FE      Link Down      No Cable                       -
...
  10    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M
  11    FE      Link Down      Pair1 Open      at 25  M       -
                               Pair2 Open      at 25  M
  12    FE      Link Down      Pair1 Open      at 88  M       -
                               Pair2 Open      at 88  M
  14    FE      Link Up        OK                             40
  15    FE      Link Down      Pair1 Open      at 18  M       -
                               Pair2 Open      at 18  M
  16    FE      Link Up        OK                             69
  18    FE      Link Down      Pair1 Open      at 4   M       -
                               Pair2 Open      at 4   M
  19    FE      Link Up        OK                             34
  20    FE      Link Down      OK                             -
  21    FE      Link Up        OK                             40
  22    FE      Link Down      Pair1 Open      at 29  M       -
                               Pair2 Open      at 29  M
  24    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M

Возможные значения:

  • Pair Open — обрыв на растоянии ХХ метров
  • Link Up, длинна ХХ метров
  • Link Down, OK — нельзя измерить длинну кабеля (но нагрузка есть)
  • Link Down, No Cable — нет кабеля

Описание OID-ов:

1.3.6.1.4.1.171.12.58.1.1.1.2 -
swEtherCableDiagPortType OBJECT-TYPE
  SYNTAX INTEGER {
    fastEthernet(0),
    gigaEthernet(1),
    other(2)
  }

# snmpwalk -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.2
SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.1 = INTEGER: 0

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.25 = INTEGER: 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.26 = INTEGER: 1
Имеем, порты 1-24 поддерживают нужный функционал. Проверить состояние линков:

1.3.6.1.4.1.171.12.58.1.1.1.3 -
swEtherCableDiagLinkStatus OBJECT-TYPE
  SYNTAX INTEGER {
    link-down(0),
    link-up(1),
    other(2)
  }

# snmpwalk -v2c -c public 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.1 = INTEGER: 0

Все OID с результатом имеют валидные значения только после выполнения теста. Далее — OIDы для состояния пар:

  • 1.3.6.1.4.1.171.12.58.1.1.1.4 — cтатус первой пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.5 — cтатус второй пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.6 — cтатус третьей пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.7 — cтатус четвертой пары

Возможные значения:

  • ok(0)
  • open(1)
  • short(2)
  • open-short(3)
  • crosstalk(4)
  • unknown(5)
  • count(6)
  • no-cable(7)
  • other(8)

И, соответственно, длины пар: 1.3.6.1.4.1.171.12.58.1.1.1.8 — длинна первой пары 1.3.6.1.4.1.171.12.58.1.1.1.11 — длинна четвертой пары OID, предназначенный для запуска теста:

1.3.6.1.4.1.171.12.58.1.1.1.12

Это единственный OID предназначенный как для чтения так и для записи.

  • action(1)
  • processing(2)
  • other(3)

Тестирование

Работа с кабельным тестером в целом совершенно стандартна (что есть несомненный плюс)

Общий подход:

  • Запустить тест (запись нужного значения в соответвующий OID
  • Дождаться завершения (проверить стением OID со статусом)
  • Считать интересующие значения.

Попробую проверить работу этой ф-и на портах с различными длинами и состоянием кабеля.

Линк есть, работающий абонент:

DES3526:user#cable_diag ports 21
Command: cable_diag ports 21

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  21    FE      Link Up        OK                             40

Запустить тест:

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 1

Проверить что он завершился (cтатус != 2):

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 3

Проверить состояние линка (1 — есть линк)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.21 = INTEGER: 1

Проверить состояние 1-й пары (0 — ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.21 = INTEGER: 0

Проверить состояние 2-й пары (0 — ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.5.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.5.21 = INTEGER: 0

Проверить состояние 3-й пары (8 — Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.6.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.21 = INTEGER: 8

Проверить состояние 4-й пары (8 — Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.7.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.7.21 = INTEGER: 8

Определить длинну 1-й пары (40 метров) # snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 2-й пары (40 метров, что логично, т.к. пары одинаковые)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 3-й пары (0 метров, фактически — не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.10.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.10.21 = INTEGER: 0

Определить длинну 4-й пары (0 метров, фактически — не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.11.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.11.21 = INTEGER: 0

Кабель не подключен:

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2
 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      No Cable                       -

Запустить тест, убедиться что при запросе ответе — «нет кабеля» (8)

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.2 = INTEGER: 8

Кабель есть, отключен

Подключаю 2-х метровый патч-корд к коммутатору (второй конец висит в воздухе):

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      Pair1 Open      at 3   M       -
                               Pair2 Open      at 2   M

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

Кабель имеет статус open:

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.2 = INTEGER: 1

«Обрыв» (в реальности — просто конец кабеля) на расстоянии 3 метра по одной и 2 метра по другой паре.

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.8.2 = INTEGER: 3

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.2 = INTEGER: 2

Насколько я могу судить, точности измерения вполне достаточня (плюс-минус метр).

Короткое на нескольких парах Сделал тестовый кабель с «коротким» на первой и третьей парах. Коммутатор показал правильные результаты для используемых пар:

DES3526:user#cable_diag ports 3
Command: cable_diag ports 3

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  3     FE      Link Down      Pair1 Short     at 3   M       -
                               Pair2 Open      at 3   M

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

Ссылка на оригинал статьи: http://wiki.sirmax.noname.com.ua/index.php/Dlink_Cable_Tester

Спасибо автору за труд, ну а мы перейдем к реализации этого безобразия на PHP.

PHP

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

Так как код в блоге выглядит не айс, то выкладываю файликом: http://subnets.ru/saved/dlink_cable_tester.php.txt

В моем рабочем варианте я ессно использую MySQL и все данные о свичах, OID`ах и значениях беру из БД.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Задача

Показывать график по трафику от/к одного BGP пира при условии того, что сессия с ним устанавливается в одном vlan с другими BGP сессиями до других BGP пиров.

Отрисовать график загрузки по интерфейсу не выход, т.к. помимо нужного трафика будет присутствовать еще и трафик с другими BGP пирами.

Решение

В недрах гугла нашлось упоминание про mac accounting.

Суть данной технологии  — ведение учета трафика в байтах и фреймах, ушедшего/пришедшего с определенного мак адреса.

Как по итогу оказалось сделать это нет так сложно.

Имеем Juniper M7i,  для включения на физическом интерфейсе достаточно сделать следующее:

Войдем в режим конфигурации:
root@juniper> configure

Добавим в конфигурацию:

[edit]
root@juniper#
set interfaces ge-0/0/1 gigether-options ethernet-switch-profile mac-learn-enable

после чего в конфигурации интерфейса появится новая секция, посмотрим:
[edit]
root@juniper.#
show interfaces ge-0/0/1

ge-0/0/1 {
    ...................
    gigether-options {
          ethernet-switch-profile {
                 mac-learn-enable;
          }
    }
    ....................
}

Перед коммитом проверим все ли в порядке:
[edit]
root@juniper#
commit check

Если все в порядке и ошибок нет, то можно применять:

[edit]
root@juniper#
commit comment «Enabling mac accounting»


Примечание:
mac accounting нельзя включить на встроенном гигабитном интерфейсе M7i и 10-портовом гигабитном контроллере.


На этом конфигурация Juniper закончена. Что дальше ? А дальше нам нужно как то получить данные для MRTG, те данные по которым и будет строиться график.
Это и оказалось сложнее всего, а именно нахождение необходимых OID’ов где можно забрать нужные нам данные.

Вот алгоритм их нахождения:

1. Получаем номер SNMP-индекса интерфейса (это может быть как сам физический интерфейс так и vlan (802.1q) на этом физическом интерфейсе), получаем на основе прописанного на интерфейсе IP-адреса, например 1.1.1.1 (в нашем случае IP-адрес находится на vlan):

.1.3.6.1.2.1.4.20.1.2.1.1.1.1 = INTEGER: 208

2. Получаем мак-адрес нужного нам BGP пира, например с IP-адресом 1.1.1.2, зная индекс интерфеса (исходя из п.1 это 208):

.1.3.6.1.2.1.4.22.1.2.208.1.1.1.2 = STRING: 0:e0:81:b6:3c:1b

Он нам понадобится далее, но в десятичном виде: 0.224.129.182.60.27

3. Теперь нам нужен номер vlan за которым находится BGP пир. Мы ессно его знаем исходя из конфига девайса и можем посмотреть так (зная номера его индекса исходя из п.1 это 208):

.1.3.6.1.2.1.2.2.1.2.208 = STRING: ge-0/0/1.994

Т.к. на физическом интерфейсе у нас действительно присутствует vlan с id 994 на котором висит IP-адрес 1.1.1.1.

4. после чего нам нужно будет получить SNMP-индекс физического ge-0/0/1, например вот так в тупую:

snmpwalk -v2c -c RO-Community JUNIPER_CONTROL_IP .1.3.6.1.2.1.2.2.1.2 | grep 'ge-0/0/1$'

Видим:

.1.3.6.1.2.1.2.2.1.2.180 = STRING: ge-0/0/1

5. И вот теперь, на основе всех полученных данных, мы можем составить финальные OID’ы для построение графика MRTG:

Первый OID это входящий трафик (HCInOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27 = Counter64: 174250

Второй OID это исходящий трафик (HCOutOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27 = Counter64: 86433120

После чего мы уже можем сделать конфиг для MRTG:

Title[peer_m7i]: 1.1.1.2 BGP peer
MaxBytes[peer_m7i]: 125000000
Target[peer_m7i]: .1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27&.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27:RO-Community@JUNIPER_CONTROL_IP

З.Ы. На Juniper серии MX mac accounting включается немного по другому:

[edit]
protocols {
    l2-learning {
        mac-statistics;
    }
}

Ссылки

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Панфилов Алексей (lehis(at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 3,00 из 5)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Назрел вопрос о реконфигурации AS5350, являющейся пограничным VoIP-шлюзом для существующей скромной (до 100 пиров) VoIP-сети.

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

Задачи

  1. Прием входящего трафика на свою номерную емкость через потоки Е1 от разных операторов.
  2. Пропуск исходящего трафика на Е1 разных операторов (например, в зависимости от ценовой политики).
  3. Формирование АОНа на основе префикса, подставленного перед набираемым номером, присланным из IP сети.
  4. Блокировка исходящих звонков с АОНами, не прописанными на AS5350.
  5. Блокировка входящих звонков на номера, не прописанные на AS5350.

Немного теории

Звонок, с точки зрения AS5350, состоит из двух частей (legs) — voip и pots. Если при поступлении звонка на AS5350 не находятся диалпиры, под которые могут попасть voip и pots части звонка, то будут использоваться системные диалпиры, отображаемые под номером ноль. Ниже приведены две схемы порядка прохождения звонков:

Входящий звонок из Е1

Входящий звонок из Е1

Исходящий звонок на Е1

Посмотреть распределение активных leg-ов по диалпирам можно командой:

show voice call status

CallID     CID  ccVdb      Port             DSP/Ch  Called #   Codec    Dial-peers
0x2B       12F1 0x6640CB84 3/0:D.30         1/3:1  *0007536    14400     66/2
0x32       1256 0x6640CB84 3/1:D.31         1/3:4  *0000579536 g711alaw  0/3

Раз так, то поехали перенастраивать железку. Я буду описывать настройку только наших вышеперечисленных требований.

Настройка

pots-диалпир для входящего трафика из потоков Е1:

dial-peer voice 7 pots
description INBOUND-CALLS-VIA-E1
huntstop                                             //Нашли подходящий диалпир и останавливаем "охоту" на остальных :)
preference 10
incoming called-number .T        //Благодаря этой строке (.Т – любые набираемые номера) этот
//диалпир выбирается в качестве наиболее подходящего для входящего звонка из Е1
direct-inward-dial
no register e164

Замечание: в этом диалпире нет смысла указывать порт потока Е1 как и делать несколько подобных диалпиров под каждый поток, т.к. при входящем через потоки Е1 трафике на вашу номерную емкость всегда будет выбираться диалпир с наименьшим номером.

pots-диалпир для пропуска исходящего МГ/МН трафика (начинающегося с 8-ки: 8.Т) в поток Е1 (3/1) первого провайдера:

dial-peer voice 2 pots
description OUTBOUND-MGMN-CALL-VIA-E1-1
huntstop
destination-pattern 8.T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/1:D
no register e164

pots-диалпир для пропуска оставшегося исходящего трафика в поток Е1 (3/0) второго провайдера:

dial-peer voice 3 pots

description OUTBOUND-REMAINING-CALLS-VIA-E1-0
huntstop
preference 8
destination-pattern .T
progress_ind setup enable 3
progress_ind progress enable 8
direct-inward-dial
port 3/0:D
no register e164

Замечание:

Преференс этого диалпира должен быть больше, чем pots-диалпира 1001 (описание которого будет дано ниже), иначе входящие со стороны Е1 звонки будут пытаться выйти через Е1 3/0 (и получим мы isdn-switching, который в данном случае никому не нужен).

Тааакс… с pots-leg’ами разобрались, продолжим с voip-leg’ами.

voip-диалпир для «приема» входящего из IP-сети номера с префиксом 009901 перед набранным номером:

dial-peer voice 94 voip
description inbound_peer_4_380-00-01
translation-profile incoming CUT-PREFIX
codec g711alaw
incoming called-number 009901.T

Создадим профиль преобразования АОНа и набираемого номера:

voice translation-profile CUT-PREFIX
translate calling 121
translate called 120

Создадим правило преобразования набираемого (called) номера – «отрежем» лидирующий префикс 009901:

voice translation-rule 120
rule 8 /^009901\(.*\)/ /\1/ type any unknown

Создадим правило преобразования АОНа — заменим любой присланный АОН на нужный нам 380-00-01:

voice translation-rule 121
rule 12 /^.*/ /3800001/

Пример типичного voip-диалпира:

dial-peer voice 78 voip
description TYPICAL-VOIP-PEER
max-conn 2
answer-address 84953800000     // answer-address служит для выбора диалпира в качестве наиболее
// подходящего на основе АОНа звонка, пришедшего из IP-сети.
//В данном случае у нас АОН будет 89453800000
destination-pattern 3800000       // destination-pattern служит для выбора диалпира в качестве
//наиболее подходящего на основе набранного номера звонка, пришедшего из Е1.
session protocol sipv2
session target ipv4:192.168.68.6
dtmf-relay rtp-nte
codec g711alaw
no vad

Все, что нужно мы разрешили-описали, осталась блокировка «левых» звонков, т.е. тех звонков, что не подходят ни под один dial-peer описанные выше, для чего создадим voip-диалпир:

dial-peer voice 1001 voip
description BAD-AON-AND-CALLED-NUM
call-block translation-profile incoming BLOCK    //блокируем звонок из IP сети
huntstop
preference 7
destination-pattern .T
codec g711alaw
session target ipv4:10.10.10.10

По итогу отправляем входящий звонок из Е1 на адрес 10.10.10.10, который маршрутизируется в никуда.
М.б. кто-то предложит лучшее решение ? С удовольствием послушаем.

Маршрутизируем адрес в «/dev/null»:

ip route 10.10.10.10 255.255.255.255 Null0

Создадим профиль и правило трансляции для блокировки «левых» АОНов:

voice translation-profile BLOCK
translate calling 42
!
voice translation-rule 42
rule 1 reject /^.*/

Для понимания, как и какие диалпиры участвуют в «выборах» при звонке и кто из них «победил» вам поможет команда:

debug voice dialpeer all

Будьте аккуратны – ее вывод может быть очень объемным !

В «отслеживании» звонков в/из IP-сети вам поможет команда:

debug ccsip calls

В трассировке звонка через ISDN вам поможет команда:

debug isdn q931

Увидеть логирование отработки правил трансляции номеров вам поможет команда:

debug voice translation

Замечание:

не забывайте давать команду:

terminal monitor

для того, чтобы вывод дебага отображался у вас в консоли (если вы сидите на циске через telnet), иначе он будет тихо складироваться в буфер логов AS5350 и все 🙂

Выражаю благодарность за помощь в написании статьи Сергею Бабичеву ( ака zaikini )

Ссылки

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftgwrepg.html

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Панфилов Алексей (lehis (at) subnets.ru)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 11, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено

Статья: Asterisk: автообзвон (auto-dial out) и обратный звонок (callback) с использованием AGI

Проблема

При организации функции callback на Asterisk`е, когда Asterisk перезванивает и ты пытаешься ввести тоном номер, то нажатые тобой цифры начинают задваиваться, а то и затраиваться.

Причем это могло происходить не всегда и не зависело от аппарата, на котором набирали тоном.

Так же после многочисленных тестов стало точно понятно, что когда идет звонок из «города» на Asterisk, то подобных проблем не возникает, только если сам Asterisk звонит в «город».

VoIP соединение идет так:

E1 <—> Cisco AS5350 (c5350-js-mz.124-15.T11.bin) <—> Asterisk (версия 1.4.29_2)

Попробую более менее внятно рассказать о процессе нашего разбора с этой проблемой и последовательности действий, а вдруг кому ещё пригодится кроме меня, если я захочу освежить память по этому вопросу через какое то время.

Начали разбор полетов

Для того что бы выявить проблему стало понятно, что нужно подебажить DTMF на самом Asterisk. Как это сделать ?

Пока опыт работы с Asterisk не такой большой как хотелось бы, посему прибегнули к помощи гугла, через минут пять выяснили:

Открываем файл  logger.conf и там ищем строчку:

console => notice,warning,error

В нее дописывем dtmf, получаем:

console => notice,warning,error,dtmf

Сохраняем файл, входим в консоль Asterisk`а:

asterisk -r

И в консоле даем команду:

asterisk*CLI> logger reload

После чего, в той же консоле, задаем уровень дебага, я делал так:

asterisk*CLI> core set debug 3

Далее, для того что бы потестить нажатие кнопок, я внес нехитрые изменения в dialplan:

[dtmf_test]
exten => s,1,Answer()
exten => s,n,Wait(1)
exten => s,n(collect),Read(digito,,11)
exten => s,n,SayDigits(${digito})
exten => s,n,GoTo(collect)
exten => s,n,Hangup

Т.е. поднимаем трубку, ждем ввода 11-ти цифр, а затем проговариваем все что набрали, собственно в этот контекст я перенаправил callback вызовы.

Подготовились, значит можно начинать.

Делаю callback на свою мобилку, начинаю давить цифири на мобиле, в консоле Астериска вижу:

[ДАТА] DTMF[5031]: channel.c:2351 __ast_read: DTMF begin '9' received on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2355 __ast_read: DTMF begin ignored '9' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2283 __ast_read: DTMF end '9' received on SIP/gt-00000015, duration 352 ms
[ДАТА] DTMF[5031]: channel.c:2336 __ast_read: DTMF end passthrough '9' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2351 __ast_read: DTMF begin '8' received on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2355 __ast_read: DTMF begin ignored '8' on SIP/gt-00000015
[ДАТА] DTMF[5031]: channel.c:2283 __ast_read: DTMF end '8' received on SIP/gt-00000015, duration 376 ms
[ДАТА] DTMF[5031]: channel.c:2336 __ast_read: DTMF end passthrough '8' on SIP/gt-00000015

и т.д. Во, то что надо, дебаг нажатия кнопок есть.

На одно нажатие в дебаге 4-ре строки. Чем дальше я смотрел в дебаг тем больше понимал, что я нажимаю цифирь один раз, а в дебаге она могла появиться и 2 и 3 раза (т.к. после одного нажатия появлялось более 4-х строк).

Смотрим что вообще мы можем «потрогать» в Астериске на тему DTMF.

Открываем файл sip.conf:

relaxdtmf=yes ; Relax dtmf handling
dtmfmode = rfc2833 ; Set default dtmfmode for sending DTMF. Default: rfc2833
 ; Other options:
 ; info : SIP INFO messages
 ; inband : Inband audio (requires 64 kbit codec -alaw, ulaw)
 ; auto : Use rfc2833 if offered, inband otherwise

Это глобальные настройки, кроме них так же можно указать dtmfmode и для конкретного пира в его контексте.

Меняли режимы, ситуация не изменялась. Как работало через раз, так и продолжало работать.

Раз так, то смотреть нужно с обоих сторон, т.е. в какой то момент привлекли и девайс Cisco.

Смотрим что же у нас указано в dial-peer:

dial-peer voice 23 voip
 description 4_outgoing_asterisk
 translation-profile incoming fake_aon
 answer-address 0010.....
 session protocol sipv2
 voice-class codec 20
 dtmf-relay rtp-nte  h245-signal h245-alphanumeric
 no vad

В voice-class перечислены кодеки:

voice class codec 20
 codec preference 1 g723r53
 codec preference 2 g723ar53
 codec preference 3 g723r63
 codec preference 4 g723ar63
 codec preference 5 g729r8
 codec preference 6 g729br8
 codec preference 7 gsmfr
 codec preference 8 g726r16
 codec preference 9 g726r24
 codec preference 10 g726r32
 codec preference 11 g711alaw
 codec preference 12 g711ulaw

Решили ужать выбор кодеков до alaw и ulaw, т.к. тот же режим inband работет только с этими кодеками.

Тоже самое сделали и на Asterisk, запретив использование всех кодеков кроме этих двух, для этого в sip.conf, в настройках peer`а, который смотрит на Cisco, указали:

disallow=all
allow = alaw
allow = ulaw

Снова стали менять режимы в sip.conf, пробовать звонить, пофиг, все как было так и осталось.

Полезли на Cisco.com -> Configuring SIP DTMF Features, в частности интересовали предлагаемый самой циской debug:

Verifying SIP DTMF Support

To verify SIP DTMF support, perform the following steps as appropriate (commands are listed in alphabetical order).

SUMMARY STEPS

1. show running-config
2. show sip-ua retry
3. show sip-ua statistics
4. show sip-ua status
5. show sip-ua timers
6. show voip rtp connections
7. show sip-ua calls

Благодаря команде show sip-ua calls видно какой режим DTMF выбран в данный момент:

Call 1
SIP Call ID                : 12abb76a79d610df282e2b237177bfe5@XX.XXX.XXX.XXX
   State of the call       : STATE_SENT_ALERTING (14)
   Substate of the call    : SUBSTATE_NONE (0)
   Calling Number          : 001000119
   Called Number           : 8916XXXXXXX
   Bit Flags               : 0xC0001C 0x100 0x404
   CC Call ID              : 22371
   Source IP Address (Sig ): XXX.XXX.XXX.XXX
   Destn SIP Req Addr:Port : XXX.XXX.XXX.XXX:5060
   Destn SIP Resp Addr:Port: XXX.XXX.XXX.XXX:5060
   Destination Name        : XXX.XXX.XXX.XXX
   Number of Media Streams : 1
   Number of Active Streams: 0
   RTP Fork Object         : 0x0
   Media Mode              : flow-through
   Media Stream 1
     State of the stream      : STREAM_ADDING
     Stream Call ID           : -1
     Stream Type              : voice+dtmf (1)
     Negotiated Codec         : g711alaw (160 bytes)
     Codec Payload Type       : 8
     Negotiated Dtmf-relay    : rtp-nte
     Dtmf-relay Payload Type  : 101
     Media Source IP Addr:Port: XXX.XXX.XXX.XXX:18936
     Media Dest IP Addr:Port  : XXX.XXX.XXX.XXX:14328
     Orig Media Dest IP Addr:Port : 0.0.0.0:0

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

В Инете (в частности на www.voip-info.org/wiki/view/Asterisk+DTMF) иногда народ советовал прям в dialplan указывать режим DTMF перед набором чего-либо, сделать это можно командой SIPdtmfmode:

SIPDtmfMode(inband|info|rfc2833)

Но это как то тоже не очень спасало. После многочасовых разборок решили глянуть, а что у Asterisk`а на тему vad есть.

Решение

В файле codecs.conf:

; voice activity detection [true / false]
; reduces bitrate when no voice detected, used only for CBR
; (implicit in VBR/ABR)
vad => true

Таксссс.. опять же народ в Инете, при разборках с DTMF, советует с первую очередь гасить vad к чертям, делаем это:

vad => false

Далее была обнаружена вот эта статья «Changing DTMF tone frequency in Asterisk«:

Changing the DTMF tones
The Asterisk module dsp.c contains the definitions for DTMF tones. Just look for a part of the source code that says:

static float dtmf_row[] =
{
    697.0,  770.0,  852.0,  941.0
};
static float dtmf_col[] =
{
    1209.0, 1336.0, 1477.0, 1633.0
};

And change that to:

static float dtmf_row[] =
{
        732.0,  809.0,  894.0, 988.0
        /* 697.0,  770.0,  852.0,  941.0 */
};
static float dtmf_col[] =
{
        1270.0, 1404.0, 1551.0, 1715.0
        /* 1209.0, 1336.0, 1477.0, 1633.0 */
};

This will raise all detected DTMF codes by some 40Hz, enough for Asterisk to become completely tone-blind to existing DTMF codes.


Once you made the change, you must recompile Asterisk by:

  • 1. Stopping Asterisk
  • 2. Go to your Asterisk source directory
  • 3. Enter make clean
  • 4. Enter make
  • 5. Enter make install

Note that you still can send Asterisk DTMF codes to transfer the call, start monitoring or what else — as long as you use the new DTMF tone matrix you just input. This is pretty easy to do with most industrial-grade call handling equipment.

«Ну что ж, не грех попробовать»  — сказали мы и выполнили как написано.

Диалпир на циске был приведен к виду:

dial-peer voice 23 voip
 description 4_outgoing_asterisk
 translation-profile incoming fake_aon
 answer-address 0010.....
 session protocol sipv2
 codec g711alaw
 dtmf-relay rtp-nte
 no vad

Наконец то оно заработало, заработало как надо. По крайней мере, после многочасовых тестов, ни одного сбоя в наборе тоном не было. Надеемся что и далее не будет проблем.

Я решил написать все это для того, что бы если кто-то тоже заморочится с этой темой и не будет знать как к этому подступиться, ну и если я вернусь к этому вопросу позднее, чтобы не вспоминать что уже было сделано :).

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы:  Панфилов Алексей (lehis (at) subnets.ru), Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту
    Не найдено