Основные этапы обработки отказа:
Устранение любого отказа следует начинать со сбора информации. Источниками информации об отказе, могут быть:
/cluster/mediator/md1/alarms/list);Первые два источника информации являются более достоверными. Источники 4, 5, и 6 являются косвенными источниками информации о неисправности.
После получения общей информации о предупреждении, можно классифицировать неисправность по срочности и предварительно определить ответственные узлы системы. После необходимо получить детальные сведения события.
Источник "Панель предупреждений" является наиболее достоверным и предоставляет следующую информацию:
Подробнее в разделе Описание структуры предупреждения.
По уровню важности предупреждения делятся на:
По типу предупреждения делятся на:
В большинстве случаев информации, полученной в панели предупреждений, достаточно для того, чтобы локализовать неисправность. Сложность представляют те случаи, при которых наблюдается отказ, но в панели предупреждений нет об этом записи. В такой ситуации следует собирать дополнительную информацию. Для точной локализации неисправности, необходимо знать путь прохождения вызова.
Любой вызов, совершаемый через систему, можно разбить на три участка:
|
Протокол адаптер ECSS (pa-sip, megaco);Далее приведены примеры определения причины отказа на участках прохождения вызова касающихся системы ECSS-10:В случае если об отказе нет записи в панели предупреждений, локализацию неисправности следует производить методом последовательной проверки всех участков прохождения вызовов.Протокол адаптер ECSS (pa-sip, megaco) <--> сетевой стек оп. системы <--> линия связи <--> сетевой стек оп. системы <--> ПО шлюза или телефона
При локализации проблемы необходимо учитывать следующие ситуации:
Набор требуемой детальной информации зависит от шага Локализация неисправности. Так например, если отказ был локализован в ядре ECSS-10, то дополнительно необходимо будет снять log-файлы ядра необходимых сервисов. Список log-файлов, которые необходимо снять, сообщат сотрудники сервисного центра (См. Включение и отключение систем логирования служб).
Алгоритм проверки в случае непрохождения вызова:
Локализировав отказ и собрав необходимую информацию (log-файлы, трассировки, дампы) возможно определить причину неисправности. Если квалификации персонала обслуживающего ECSS-10 недостаточно, то полученные сведения необходимо передать для анализа в сервисный центр.
Устранить отказ можно после того как выполнен пункт Определение причины отказа.
Для проверки действий по устранению отказа можно использовать:
Если отказ не был устранён, то следует повторно выполнить этапы 3, 4, 5.
Первым этапом анализа проблем является просмотр активных предупреждений в системе ECSS-10.
Для оперативной реакции обслуживающего персонала на возникшие предупреждения реализован следующий функционал: при возникновении аварий (major и/или critical) prompt в консоли CoCon-а будет подсвечиваться в желтый (major) или красный (critical) цвет:
Когда все major и critical аварии будут зачищены — отобразится надпись No more active alarms", и Prompt примет обычный цвет.
Prompt поменяет цвет только при следующей отрисовке (по факту, когда будет нажат Enter). |
В web-конфигураторе также есть панель "Системная информация":
Она не закрывается, не скрывается (хотя и может быть перекрыта другим окном). Кроме того, на web в случае возникновении аварии звучит аварийная сигнализация. В стандартном режиме web-конфигуратора в футтере есть информация об авариях в системе.
Просмотреть список предупреждений можно через интерфейс командной строки CLI или web-конфигуратор. В web-конфигураторе список приводится в приложении Список предупреждений (Alarm list).
Список текущих предупреждений в командной консоли CLI отображается при помощи следующих команд:
/system-status
— информация о состоянии нод, медиасерверов и список активных аварий;
/cluster/mediator/<CLUSTER>/alarms/list all
— просмотр всех предупреждений в системе. Команда доступна администратору системы ECSS-10.
/domain/<DOMAIN>/alarms/list all
— просмотр предупреждения виртуальной АТС с именем <DOMAIN>. Команда доступна администратору виртуальной АТС.где:
| По умолчанию выводится 25 последних предупреждений. |
Подробное описание команд CLI системы сбора и отображения предупреждений приведено в разделе Команды управления аварийной сигнализацией.
Для просмотра описания по сбору и отображению предупреждений можно подключиться к командной консоли управления операционной системы CoCon и воспользоваться командой man:
man cluster/mediator/md1/alarms/list all man domain/<DOMAIN>/alarms/list all |
Описание предупреждений и действий, необходимых для решения, приведены в разделе Действия при возникновении предупреждений.
| Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
21.12 14:09:11 | critical | softwareError | host::applicati | slapd | Application "slapd" is not running |
Данное предупреждение обозначает, что приложение slapd не запущено. В базе данных LDAP хранится информация о логинах и паролях SIP-абонентов ECSS-10. Из-за данной проблемы будет невозможна авторизация SIP-абонентов
Решение:
Указанные команды выполняются из командной консоли управления операционной системы Linux (shell). |
Запустить приложение slapd командой:
sudo systemctl start slapd.service |
Просмотреть состояние работы приложения slapd командой:
sudo ps aux | grep slapd sudo systemctl status slapd.service |
Если приложение slapd снова завершит свою работу, то необходимо обратиться за помощью в сервисный центр (СЦ) компании Элтекс. |
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
21.12 20:06:13 | critical | lanError | hw::interfaces | bond1:2 | Network interface "bond1:2" is down |
Авария сетевого интерфейса bond1:2 является критической. Если данный интерфейс используется для работы VoIP-телефонии и в системе нет резервных интерфейсов, то система ECSS-10 не сможет обслуживать вызовы.
Все SIP-направления и абоненты не смогут совершать вызовы.
Решение:
Указанные команды выполняются из командной консоли управления операционной системы Linux (shell). |
Система с резервированием:
Произведите перезапуск службы keepalived командами:
sudo systemctl stop keepalived.service sudo systemctl start keepalived.service |
Проверить:
sudo systemctl status keepalived.service |
Система без резервирования:
Произведите перезапуск сетевой службы командами:
sudo systemctl restart systemd-networkd.service |
Log-файл работы сетевой службы хранится в файле syslog. Путь к файлу: /var/log/syslog.
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
21.12 20:41:44 | major | outOfService | ecss::cluster::node | core1@ecss1 | Node core1@ecss1 of "core1" cluster is down |
Предупреждение о падении ноды является критической аварией. Если система без резервирования и нет возможности перезапустить приложение, система ECSS-10 не сможет оказывать услуги.
Решение:
По умолчанию работа сервисов контролируется системным менеджером systemd, который следит за работой служб ecss и в случае их не штатного завершения автоматически перезапускает.
Нужно проверить статус работы ноды командной (команда выполняется через интерфейс командной строки CLI):
/node/<NODE>/service |
где <NODE> — имя ноды.
В результате выполнения команды на экране появится таблица, напротив всех нод должен стоять символ ”+”.
Если напротив всех служб стоит символ “+” перейдите к пункту С.
Запустить ноды в ручном режиме можно при помощи команды (команда выполняется в shell linux):
sudo systemctl start ecss-<node_name> |
Для поиска причины аварийного завершения работы приложения и устранения проблем нужно передать log-файл работы ноды в сервис-центр компании ЭЛТЕКС.
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
29.04 15:09:26 | major | softwareError | ecss::pa::sip:: | temp_voip-rsw-med | Response 500 Server error |
Завершение обслуживания вызова, выдача ответа 500 от SIP-адаптера.
Предупреждение может возникнуть вследствие причин:
Решение:
В данной ситуации необходимо снять TCP dump, core cp лог, лог SIP-адаптера и ядра. Передать данную информацию для разбора причины проблемы в сервис-центре компании ЭЛТЕКС.
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
28.08 17:55:28 | major | softwareError | ecss::cluster::core::cp | pa.sip-t->32343034-6338-3531-3437-623761663333 | Call process down. Reason: anormal_terminate |
Не штатное завершение вызова.
Предупреждение может возникнуть вследствие следующих причин:
В данной ситуации необходимо снять TCP dump, core cp лог, лог SIP-адаптера и ядра. Передать данную информацию для разбора причины проблемы в сервис-центре компании ЭЛТЕКС.
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
24.04 10:07:59 | major | softwareError | ecss::pa::sip:: | 8612001057@krasno | Wrong authentication |
Попытка аутентификации завершилась неудачно.
Предупреждение может возникнуть вследствие причин:
Решение:
В данной ситуации необходимо сравнить настройки SIP-абонента и учетной записи клиента в ECSS-10. Если попытки зарегистрироваться выполняются от неизвестного пользователя, необходимо предпринять меры для ограничения данного злоумышленника к SIP-адаптеру.
Возможные действия:
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
20.08 17:20:00 | major | storageCapacityProblem | HW::Disks | /var/log/ecss | Disk almost full: 97 % |
Переполнен раздел с логами ECSS-10.
Решение:
Необходимо удалить отладочную информацию в разделе /var/log/ecss/.
Date | Severity | Cause | Class | Instance | Message |
|---|---|---|---|---|---|
02.01 09:09:35 | warning | outOfService | ecss::licence | lab_303 (2012/09/19 01:34:50) | The licence "lab_303 (2012/09/19 01:34:50)" will be expired at 2013/02/01 02:02:02. |
Лицензия ECSS-10 истекает 2013/02/01, после истечения срока действия система перейдет на лицензии с активным сроком или на заводскую лицензию.
В заводской лицензии максимальная длительность вызова ровна одной минуте, отключена запись CDR-файлов и функция СОРМ, база данных останавливается через каждые 5 минут.
Для продления лицензии необходимо обратиться в коммерческий отдел компании ЭЛТЕКС и проинсталлировать новые лицензии. Подробное описание приведено в разделе Начальное конфигурирование системы.
При получении жалоб от абонентов системы ECSS-10 необходимо получить от них следующую информацию:
В системе ECSS-10 каждая нода имеет в своём составе определенный набор служб, ответственных за те или иные процессы. Также имеет набор заранее определенных правил, которые определяют в каком виде записывать log-файлы и для отдельных служб. Большинство правил по умолчанию отключено, так как в не аварийном состоянии системы они не нужны. В процессе определения причины отказа может потребоваться включить те или иные правила.
Просмотр настройки:
/node/<node name>/log/config show
Активация правила логирования для определённой ноды:
node/<node_name>/log/config rule <rule_name> on
где:
| Существуют правила с постфиксом _bin, что означает что запись будет вестись в бинарном формате, перекодировать в текстовый можно с помощью утилиты binarylog2text. |
После активации, соответствующий этому правилу файл будет наполнятся записями, и находится он по следующему пути:
/var/log/ecss/<node_name>/<date>/<rule_name>
Деактивация правила выполняется командой:
node/<node_name>/log/config rule <rule_name> off
Просмотр статуса и настроек правил логирования для определенной ноды:
node/<node_name>/log/config show
В первом столбце указано состояние правила: "+" — правило включено, "-" — правило выключено.
| Правила можно создавать самостоятельно, но в подавляющем большинстве случаев этого не требуется, так как необходимые правила уже присутствуют. |
| Список служб для которых необходимо включить логирование нужно получить у инженеров сервис центра. |
Проверить запущены ли все сервисы ECSS-10 можно командой:
sudo systemctl status <service name>
где <service name> может принимать следующие значения:
Результат выполнения команды для всех сервисов должен быть:
● ecss-core.service - daemon ecss-core of ecss-10. Loaded: loaded (/lib/systemd/system/ecss-core.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-02-23 17:13:42 +07; 1 day 17h ago |
Дополнительно можно посмотреть состояние процесса и потребляемые ресурсы системы сервисом:
ps aux | grep <service name>
Если при выполнении команды sudo service <service name> status получили результат:
* <service name> is not running
То следует попытаться запустить сервис вручную:
sudo systemctl start <service name>
Причин по которой сервис или сервисы ECSS-10 не запускаются много.
Пример: Все сервисы не запущены и не запускаются, и log-файлы не пишутся.
Следует проверить объем свободного пространства на накопителе:
df -h |
Возможно раздел с точкой монтирования /var/log/ecss заполнен и ECSS-10 не может запуститься.
Решение данной проблемы следующее:
Проверить прослушиваются ли используемые для сигнализации порты можно при помощи команды netstat. Команда выполняется из командной консоли управления операционной системы Linux (shell).
Пример. Проверка порта 5060
netstat -na | grep 5060 udp 0 0 192.168.18.111:5060 0.0.0.0:* udp 0 0 192.168.18.113:5060 0.0.0.0:* |
Команда показывает, что на данном сервере порт 5060 открыт на двух интерфейсах. Данная ситуация возможна если на сервере установлено несколько приложений, использующих порт 5060 на разных интерфейсах. Важно, чтобы порты были открыты на интерфейсе, который использует SIP-адаптер системы ECSS-10.
Причины, по которым порт не открыт:
Проверить настройки SIP-адаптера можно следующей командой:
/domain/<DOMAIN>/sip/network/info
Необходимо обратить внимание на корректность следующих параметров:
Задать параметры можно в командной консоли CLI, при помощи команды sip/network/set.
Пример:
/domain/<DOMAIN>/sip/network/set listen_ports list [5081] |
Подробное описание приведено в разделе Описание работы SIP-адаптера.
В данном разделе описан способ проверки доступности направлений А и Б.
| Необходимо проверять сетевые интерфейсы, используемые для VoIP-телефонии. |
Для проверки доступности встречного направления нужно выполнить ping-запрос на IP-адрес тестируемого устройства. Команда выполняется из командной консоли управления операционной системы Linux (shell):
ping x.x.x.x |
где x.x.x.x — IP-адрес устройства, до которого нужно проверить доступ.
Если устройство доступно, будет отображаться время, в течение которого был получен ответ на запрос.
ssw@ecss1:~$ ping 192.168.18.9 PING 192.168.18.9 (192.168.18.9) 56(84) bytes of data. 64 bytes from 192.168.18.9: icmp_req=1 ttl=128 time=0.162 ms 64 bytes from 192.168.18.9: icmp_req=2 ttl=128 time=0.136 ms ... |
Если все сетевые участвующие в вызове устройства доступны, необходимо проверить сетевые порты.
Core_cp_trace — отладочный log-файл ядра, в котором хранится история обмена сообщениями между приложениями ECSS-10. Данный log-файл позволяет рассмотреть историю обслуживания вызова и проанализировать причины разъединения.
| По умолчанию ведение данного log-файла отключено. Не рекомендуется оставлять core_cp_trace постоянно включенным в системе, которая находится в коммерческой эксплуатации. |
Для активации функции снятия трассировок необходимо ввести команду set mode:
domain/test_domain/trace/properties/set mode full_compressed |
| Указанные команды выполняются через интерфейс командной строки CLI. |
Режимы трассировок описаны в Команды настройки подсистемы трассировки вызовов.
Для отключения core_cp_trace необходимо выполнить следующие команды:
domain/<DOMAIN>/trace/properties/set mode disabled |
Для просмотра списка трассировок используется команда list:
domain/test_domain/trace/list |
Пример вывода списка трассировок:
Short ID | Start | Stage | Original CgPN | Original CdPN | CgPN | CdPN | M | Duration | Release | ISUP release | F |
|---|---|---|---|---|---|---|---|---|---|---|---|
45cc5735 | 28.07.2016 10:51:58 | released | 1000 | 1005 | 1000 | 1005 | n | 9s | normal | 16/0 |
Для просмотра трассировки определенного вызова необходимо найти этот вызов используя значения следующих столбцов:
В первом столбце таблице указывается Short ID, по значению которого можно вывести трассировку для этого вызова.
| Стоит обратить внимание на последний столбец "F", отметка в данном столбце означает что вызов был завершен по причине падения ядра ESCC-10. В данном случае необходимо будет передать в техническую поддержку Элтекс дамп падения. |
Вывод трассировки выполняется командой show:
domain/test_domain/trace/show --Te 45cc5735 |
Для более подробного вывода используется аргумент --payload, если необходимо вывести на экран только одно сообщение то команда show дополняется аргументом --desired N, где N — это номер сообщения. Например, команда domain/test_domain/trace/show --Te 45cc5735 выведет трассировку вызова с Short ID равным 45cc5735.
Анализ данного log-файла требует определенной подготовки. Для начала анализа log-файла необходимо найти сообщение "ReleaseReq" и посмотреть причину. Далее искать решение проблемы в зависимости от причины разъединения.
Пример сообщения "ReleaseReq":
13. out/amqp/<<"8004dc055d1b4dcb">>: 0 00:00:02.889 (2013/05/06 11:45:01.882506): 7130/62877
---------------------
Type: cast ref
Mandatory: false
Cmd: {'message.transfer',"ecss.call.data.ex",0,0}
Payload:
{'AcpMessage',<<"111@192.168.18.113">>,3502537240920379,
{'ReleaseReq',
{'ReleaseType',invalidNumber,system,"799",
<<128,156>>,
[{causeDescription,
{'AdditionalCauseDescription',undefined,
"Rule \"default_no_route\" finished with no route (isup cause: undefined)"}}],
undefined,undefined,undefined,false,
{1367,815501,870065}}}}
App ID: acp
Rk: ecss.pa.sip-t.pa_sip1.pa.sip-t->34333034-6463-3035-3563-656631373934.rk
TTL: 30000
Reply ex: ecss.call.data.ex
Reply rk: core.cp.core1.7.3.rk
sid: pa.sip-t->34333034-6463-3035-3563-656631373934
Result: {<0.2021.0>,#Ref<0.0.57.164013>}
>>>>>>>>>>>>>>>>>>>>> |
Поле "_causeDescription, {'AdditionalCauseDescription',undefined, "Rule \"default_no_route\" finished with no route (isup cause: undefined)"}"_ указывает на то, что вызов был завершен по причине отсутствия маршрута до вызываемого абонента.
Если возникли вопросы по анализу лога "core_cp_trace", рекомендуется обратиться в техническую поддержку компании Элтекс.
| При анализе log-файла необходимо помнить, что существует возможность сопоставить log-файл ядра с TCP dump. В log-файл ядра присутствует параметр "Сall ref", используемый уровнем SIP-адаптера (секция AdditionalInfo). |
Для сохранения трассировок в файл используется команда save-trace, аргументами которой являются:
domain/test_domain/trace/save-trace --Te 45cc5735 --text --filename trace_45cc5735 |
Найти сохранённый файл можно в директории /var/lib/ecss/cp/test_domain/traces/.
В системе ECSS-10 возможно снять log-файл TCP dump следующими способами:
При решении проблем, связанных с "потерей" сообщений, рекомендуется снять TCP dump на ECSS-10 и удаленной стороне.
SIP-адаптер позволяет снять дамп обмена сообщениями двумя способами:
TCP dump — log-файл, содержащий в себе обмен сетевыми пакетами и позволяющий произвести анализ сетевого трафика, проходящего через сервер, на котором работает система ECSS-10. Таким образом кроме сигнальных сообщений можно проверить работу RTP.
Log-файл SIP-адаптера — лог siptrace, содержащий сообщения протокола SIP, которые были получены портом SIP-адаптера, частично протранслированы на предмет соответствия протоколу. Если на SIP-адаптере происходят ошибки работы с сокетами или в настройках маршрутизации на хосте есть ошибка, то в TCP dump будут входящие запросы, а в логе SIP-адаптера — нет (и наоборот для исходящих). Если в TCP dump есть сообщения, а в логе SIP-адаптера нет и при этом в логе "errors" также нет сообщений, то необходимо проверить сетевые настройки хоста на наличие ошибок в конфигурации keepalive или vrrp.
Анализ причины непрохождения вызова необходимо начать с рассмотрения обмена сообщениями в плече А. Если проблема не обнаружена, необходимо рассмотреть обмен сообщениями в плече Б. Для детального анализа логов необходимо обратиться к рекомендациям, описывающим взаимодействие по протоколам SIP, Megaco (H.248), RTCP и т.д.
Запуск трассировки внешних сообщений из CLI CoCon:
cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8 port = 5060 |
где:
В данном случае будет захватываться трафик с 5060 порта. Если необходимо захватить весь трафик, то тогда команда будет выглядеть:
cluster/adapter/sip1/pcap-trace/start sip1@ecss1 bond0.8 |
Снятые дампы сохраняются в директории /var/log/ecss/.
Более подробно о запуске tcpdump см. раздел Команды трассировки.
Для снятия сетевых дампов рекомендуется использовать утилиту tcpdump. Приведем пример для снятия sip трафика между ESCC-10 и узлом сети 192.168.8.207.
sudo tcpdump -i bond0.8 -w sipdump.pcap port 5060 and host 192.168.8.207 |
где:
Сохранённый дамп можно посмотреть в консоле с помощью tcpdump:
sudo tcpdump -v -r sipdump.pcap |
Полученный дамп можно также открыть с помощью Wireshark.
Путь к логу SIP-адаптера: /var/log/ecss/pa_sip/.
SIP-адаптер автоматически записывает все входящие и исходящие сообщения протокола SIP. Данный файл хранится в бинарном виде. Данный бинарный файл можно перевести в текстовой с помощью утилиты binarylog2text, которая входит в состав ECSS-10.
Перевести siptrace.bin в текстовый siptrace.log можно командой:
cd /var/log/ecss/pa_sipt/YYYY_MM_DD_hh_mm_ss_sip1@<hostname>/ binarylog2text siptrace.bin siptrace.log |
Есть возможность сохранять трассировку siptrace сразу в текстовом виде, для этого в файле /etc/ecss/ нужно найти следующую запись:
,{siptrace, [{file, "siptrace.bin", binary}
%%,{udp, {"192.168.23.23", 5090}, binary}
]} |
и поменять её на:
,{siptrace, [{file, "siptrace.log"}
%%,{udp, {"192.168.23.23", 5090}}
]} |
При возникновении проблем полученные трассировки дают необходимую информацию для устранения проблемы.
При получении заголовка Warning в SIP-сообщении можно определить внутреннюю системную причину разъединения, подробнее см. Приложение Г. Описание внутренних причин разъединения.
Также в трассировке SIP-адаптера (TCP dump или файле с логом siptrace.bin) в заголовке P-Eltex-Info содержится ссылка на внутренний Call Ref, по которой можно определить Call ID вызова. В сообщении, содержащем заголовок P-Eltex-Info с нужным Call Ref, будет присутствовать заголовок Call ID, по которому можно найти все сообщения, относящиеся к данному вызову.
При завершении вызова, в ответе о невозможности установить соединение или запросе о разрушении соединения указана причина согласно рекомендации Q.850.
Например:
Reason: Q.850;cause=16;text="Normal call clearing" |
или
Reason: Q.850;cause=21;text="Call rejected" |
Значения кодов ответов согласно Q.850.
Также в ответах протокола SIP может содержатся заголовок Warning. Расшифровка заголовка приведена в Приложение Г. Описание внутренних причин разъединения.
Например при получении ответа с заголовком:
Warning: 399 ecss "system: Call is rejected by destination's leg" |
| Внутренняя причина (external_acp_causes) | calledPartyRejected |
| Значение причины согласно рекомендации Q.850 | 21 |
| isup cause | <<128,21>> |
| Информатор | undefined |
| Описание | вызов к абоненту запрещен, например, анонимный вызов на абонента с активным сервисом ACB |
| Заголовок Warning | Call is rejected by destination's leg |
На запрос REGISTER от шлюза А система ECSS-10 отправляет ответ 401 Unauthorized, шлюз повторно отправляет запрос REGISTER с данными авторизации, на что система ECSS-10 передает ответ 403 Forbidden с внутренней причиной отбоя от SIP-адаптера Error-Info: <Unknown uri>. Данное сообщение указывает на некорректный логин и пароль, с которыми абонент А пытается зарегистрироваться на ECSS-10.
| При регистрации SIP-абонента с некорректным логином и паролем SIP-адаптер может не отправить ответ 403, если в настройках SIP-адаптера параметр "silent-mode" установлен в значение "true" и при этом в системе активны соответствующие аварии. |
На запрос INVITE приходит ответ с кодом 500 и содержащим следующие заголовки:
Reason: Q.850;cause=127;text="Interworking unspecified"
P-Eltex-Info: Internal system error: systemFailure by core
P-Eltex-Info: test_domain 1005@test_domain/- 2878128063 sip1@ecss1 <0.736.0>/3 incoming
Warning: 399 ecss "system: Internal error"
Warning: 399 ecss "system: Release from MSR" |
Заголовок Reason: сообщает нам Q.850 cause=127 это Interworking, unspecified, под данным кодом может быть описано множество неопределенных ошибок.
Дополнительно присутствуют заголовки Warning в которых присутствует следующая информация
399 ecss "system: Internal error" — 399 это код ошибки
где
system — автор сообщения ядро
Internal error — внутренняя ошибка
Release from MSR — освобождения канала от медиасервера
Причиной данной ошибки является медиасервер, первым делом необходимо убедится в том, что он запущен и правильно сконфигурирован. Проверить статус медиа сервера можно командой:
sudo systemctl status ecss-media-server |
Запустить командой:
sudo systemctl start ecss-media-server |
Нужно проверить зарегистрированы ли абоненты. Если абоненты не зарегистрированы, то проблема, из-за которой абоненты не могут зарегистрироваться, возможно, связана с неправильной конфигурацией. При неуспешной аутентификации нужно сравнить настройки авторизации SIP-абонентов в системе ECSS-10 и на шлюзе.
Указанные команды выполняются через интерфейс командной строки CLI.
Просмотреть зарегистрированных SIP-абонентов на ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/registered <GROUP> <INTERFACE>
где
Просмотреть информацию о всех SIP-абонентах ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info * *
Просмотреть подробную информацию об определенном SIP-абоненте в системе ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE> --complete
где
Посмотреть логины и пароли у всех SIP-абонентов ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info * * --ldap-account
/domain/<DOMAIN>/sip/user/authentication *
Посмотреть логины и пароли у определенного SIP-абонента в системе ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE> --ldap-account
/domain/<DOMAIN>/sip/user/authentication <GROUP> <INTERFACE>
где
В текущей версии ПО кроме сервера LDAP параметры аутентификации (логин, пароль) могут хранится на DS. В этом случае ключ "--ldap-account" не предлагается для ввода, так как не нужен дополнительный запрос на сервер.
Необходимо проверить соответствует ли контекст маршрутизации на сервере файлам, импортированным в базу данных ECSS-10.
| Контексты маршрутизации не импортируются автоматически. После внесения изменений в контекст маршрутизации необходимо заново импортировать контекст маршрутизации в базу данных ECSS-10. |
Контексты маршрутизации расположены на сервере по следующему пути: /var/lib/ecss/routing/ctx/src.
Посмотреть контекст маршрутизации в ОС Linux можно командой cat.
Посмотреть контекст маршрутизации в командной консоли ECSS-10 можно при помощи команды show.
/domain/<DOMAIN>/routing/show <CONTEXT>
где
Если контексты не соответствуют, необходимо импортировать контекст маршрутизации в базу данных ECSS-10.
Импорт контекстов маршрутизации выполняется при помощи команды import.
/domain/<DOMAIN>/routing/import <HOST> <FILE>
где
Если контексты маршрутизации соответствуют, необходимо проверить возможность маршрутизации вызова с такими же параметрами, что и в неуспешном вызове. Трассировка вызова выполняется при помощи команды trace.
/domain/<DOMAIN>/routing/trace iface=<INTERFACE> cdpn.<PARAM>=value [<OPT1>=<VALUE1> [ ... [<OPTN>=<VALUEN>]]]
где
В итоге выполнения команды для входных данных вызова (интерфейс абонента А, контекст абонента А, время суток, день недели, номер абонента А, номер абонента Б) на выходе будут получены следующие данные: интерфейс абонента А, домен абонента А, контекст абонента А, номер абонента А (возможно модифицированный), номер абонента Б (возможно модифицированный), интерфейс абонента Б.
Пример
/domain/test.domain/routing/trace cgpn.digits=5000 cdpn.digits=700 mode=enblock |
Возможны следующие результаты маршрутизации:
Для того чтобы включить поддержку принятия syslog-ов по UPD, следует раскомментировать следующие строки (/etc/rsyslog.conf — в случае использования rsyslogd):
module(load="imudp") input(type="imudp" port="514"). |
Для того чтобы в выводе сообщения отображались миллисекунды, нужно определить новый шаблон в /etc/rsyslog.conf:
$ActionFileDefaultTemplate TraditionalFileFormat $template TraditionalFileFormat,"%TIMESTAMP%.%timestamp:::date-subseconds%%HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg:::drop-last-lf%\n" |
Для приложения chronica включить правило:
{cocon_audit, "cocon_audit_exec|cocon_audit_session|cocon_audit_apply", trace, [syslog], on} |
Возможные теги для записей: * cocon_audit_exec — выполнение команды через ssh shell; * cocon_audit_session — login/logout пользователя; * cocon_audit_apply — выполнение команды со стороны web-configurator; * cocon_audit_result — результат выполнения команды; * cocon_audit — все остальные.
Для того чтобы отображались все записи, в качестве тега следует указывать: cocon_audit*
Для того чтобы задать IP адрес куда будут направляться записи, нужно переопределить имя хоста «syslog.ecss» в /etc/dnsmasq.d/ecss-syslog. По умолчанию используется адрес 127.0.0.1.
При установке пакета ecss-security, автоматически создается папка /var/log/ecss/security/, в которой будет храниться вся история команд и подключений к серверу.
Перечень выполняемых функций:
Создаваемые лог файлы не возможно удалить или отредактировать, они доступны только для просмотра. Все старые лог файлы сжимаются и перемещаются в каталог /var/log/ecss-security/<год>-<месяц>/.
Пример:
Dec 6 15:04:35 ecss1 ecss-security[6124]: tester : TTY=pts/1 ; PWD=/home/tester ; USER=tester; RETURN=0 ; COMMAND=ssh admin@localhost -p8023 Dec 6 15:04:36 ecss1 ecss-security[6124]: tester : TTY=pts/1 ; PWD=/home/tester ; USER=tester; RETURN=0 ; COMMAND=ssh admin@localhost -p8023 Dec 6 15:05:16 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root; RETURN=0 ; COMMAND=sudo apt update Dec 6 15:05:16 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root; RETURN=0 ; COMMAND=sudo apt update Dec 6 15:05:24 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cd /var/log/ecss/pa-sip/sip1@ecss1/ Dec 6 15:05:25 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cat error.log Dec 6 15:05:26 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=l Dec 6 15:05:32 ecss1 ecss-security[6023]: tester : TTY=pts/0 ; PWD=/var/log/ecss/pa-sip/sip1@ecss1 ; USER=tester; RETURN=0 ; COMMAND=cat restart.log |
Ecss-captraf — скрипт для захвата сетевого трафика и его записи. Используется для записи служебного трафика (либо всего, либо только по voip: http/sip/rtp).
Осуществляет запись трафика пользователя с перезаписью файлов в зависимости от заданных параметров:
При превышении максимального количества файлов начинается перезапись с первого файла. Запись в новый файл начинается либо при превышении максимального размера, либо при превышении времени записи.
Запись осуществляется в директорию, указанную в конфигурации. При отсутствии директории происходит её создание.
Для работы необходимо задать имя сетевого интерфейса (одного или нескольких), с которого будет осуществляться захват трафика, либо any, обозначающее любой интерфейс.
При указании нескольких сетевых интерфейсов для каждого из них будет запущен свой экземпляр tcpdump. При этом ротация файлов производится в рамках каждого экземпляра, а их максимально допустимое количество делится между всеми экземплярами.
Скрипт может работать в двух режимах:
В режиме voip для захвата HTTP трафика используется фильтр непустых tcp-пакетов с порта tcp 80.
SIP трафик: фильтр udp-пакетов с порта udp 5060;
RTP трафик: фильтр udp-пакетов с чётными номерами портов, в которых первые два бита "полезных данных" соответствуют корректному номеру версии RTP (2 версия). Однако, под этот фильтр могут попадать не только RTP-пакеты. Также в фильтре исключается трафик с 53 порта (DNS).
Кроме того, в обоих режимах исключается SSH-трафик (22 порт) и cisco-net-mgmt/irdmi (8023 порт).
Параметры для настройки находятся в файле конфигурации /etc/ecss/ecss-captraf.conf, в котором заданы следующие значения:
Имена дампов содержат название хоста, на котором запущен сервис, название интерфейса и время начала записи в файл (при условии, что задано ограничение по времени записи).
Запуск осуществляется через systemd сервис — ecss-captraf.service.