В случае, если сервер ECSS-10 стал недоступен в сети, то необходимо предпринять следующие действия:
ping <IP-адрес ПК управления>. Если ping не проходит, то необходимо проверить сетевые настройки и состояние работы коммутатора.Если вызывная нагрузка обрабатывается нормально, а только недоступны сервисы управления, следует проверить:
Сначала нужно быть уверенным, что логин и пароль вводятся правильные(раскладка, Capslock..)
Проверить статус сервиса mysql
Пример:
sasha@ecss1:~$ systemctl status mysql.service
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/mysql.service.d
└─override.conf
Active: active (running) since Thu 2022-07-21 22:21:42 +07; 2 weeks 6 days ago
Main PID: 1920 (mysqld)
Tasks: 80 (limit: 4915)
CGroup: /system.slice/mysql.service
└─1920 /usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid
Jul 21 22:21:41 ecss1 systemd[1]: Starting MySQL Community Server...
Jul 21 22:21:42 ecss1 systemd[1]: Started MySQL Community Server.
|
Если сервис неактивен, попробовать перезапустить.
Проверить наличие пользователя в базе ecss_audit, например:
sasha@ecss1:~$ mysql -uaudit -p -D ecss_audit -e 'select * from ecss_users;' Enter password: +--------------+--------------------------+-----------+-------------------------+------------+ | login | pass | role_name | pass_changed | properties | +--------------+--------------------------+-----------+-------------------------+------------+ | admin | X03MO1qnZdYdgyfeuILPmQ== | NULL | 2022-02-21 03:47:09.938 | NULL | | bsk_security | M4F7QU9JbGKfuibaldXvTA== | NULL | 2022-03-28 03:45:14.447 | NULL | | support | J1cULCERuL00oNG3GPWcDA== | NULL | 2022-02-21 03:47:09.940 | NULL | | tech | QzMUb8qdMeZOafKpG/1xdQ== | NULL | 2022-08-03 00:46:31.464 | NULL | | test | xMpCOKC5I4INzFCab3WEmw== | NULL | 2022-04-08 04:01:14.899 | NULL | +--------------+--------------------------+-----------+-------------------------+------------+ |
Убедиться, что пользователь существует. Если по каким либо причинам он был удален из базы, зайти под другим логином и создать нужного пользователя заново.
Если нет доступа только в Web-конфигуратор, нужно убедится активном статусе сервисов ecss-web-conf, nginx. При необходимости рестартовать их.
Также следует проверить, что запущен сервис http-terminal из cocon:
admin@mycelium1@ecss1:/$ node/md1@ecss1/service http-terminal info Service 'http-terminal' is started at 6:57:20 25.7.2022 UTC Previous known service status: stopped Service status report: HTTP Terminal service started: true |
Проверить запущены ли все сервисы ECSS-10 можно командой:
sudo systemctl status <service name> |
где <service name> может принимать следующие значения:
Результат выполнения команды для сервиса должен показать Active, например:
sasha@ecss1:~$ systemctl status ecss-core.service
● ecss-core.service - daemon ecss-core-14.12.181 of ecss-10
Loaded: loaded (/lib/systemd/system/ecss-core.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-07-25 13:57:01 +07; 2 weeks 3 days ago
Main PID: 27138 (beam.smp)
Tasks: 34 (limit: 4915)
CGroup: /ecss.slice/ecss-core.service
├─26718 inet_gethost 4
├─27138 ecss-core -pc unicode -K true -A 2 -e 65536 -P 4194304 -sfwi 500 -scl false -zdbbl 64MB -- -root /usr/lib/ecss/ecss-core -progname erl -- -home /var/lib/ecss/home -- -noshell -noinput -mo
├─27545 erl_child_setup 1024
├─27666 inet_gethost 4
├─27667 inet_gethost 4
├─27714 inet_gethost 4
├─27715 inet_gethost 4
├─27717 sh -s disksup
└─27718 /usr/lib/erlang/lib/os_mon-2.4.7/priv/bin/memsup
|
Дополнительно можно посмотреть состояние процесса и потребляемые ресурсы системы сервисом:
ps aux | grep <service name> |
Если при выполнении команды systemctl status <service name> получили результат:
* <service name> is not running
То следует попытаться запустить сервис вручную:
sudo systemctl start <service name>
Причин по которой сервис или сервисы ECSS-10 не запускаются много.
Пример: Все или часть сервисов не запущены и не запускаются.
Следует проверить объем свободного пространства на накопителе:
df -h
Возможно корневой раздел( "/") заполнен и ECSS-10 не может запуститься.
Решение данной проблемы следующее:
Для остановки и запуска всех сервисов необходимо выполнить команды:
sudo systemctl stop ecss.service sudo systemctl start ecss.service
Подключившись к командной оболочке CoCon можно просмотреть состояние сервисов, например:
admin@mycelium1@ecss1:/$ node/check-services
Nodes:
core1@ecss1 core1@ecss2
ds1@ecss1 ds1@ecss2
md1@ecss1 md1@ecss2
mycelium1@ecss1 mycelium1@ecss2
sip1@ecss1 sip1@ecss2
All services are started |
или
admin@ds1@ecss1:/$ system-status Checking... ┌─┬───────────────┬───────────────────────────┬───────────────────────────────┬─────────────────────┬──────┐ │ │ Node │ Release │ Erlang nodes │ Mnesia nodes │Uptime│ ├─┼───────────────┼───────────────────────────┼───────────────────────────────┼─────────────────────┼──────┤ │ │core1@ecss1 │ecss-core-3.14.10.562 │core1@ecss1,core1@ecss2 │not running │15h 4m│ │ │core1@ecss2 │ecss-core-3.14.10.562 │core1@ecss1,core1@ecss2 │not running │2m 5s │ │ │ds1@ecss1 │ecss-ds-3.14.10.562 │ds1@ecss1,ds1@ecss2 │ds1@ecss1,ds1@ecss2 │15h 4m│ │ │ds1@ecss2 │ecss-ds-3.14.10.562 │ds1@ecss1,ds1@ecss2 │ds1@ecss1,ds1@ecss2 │2m 5s │ │ │md1@ecss1 │ecss-mediator-3.14.10.562 │md1@ecss1,md1@ecss2 │md1@ecss1,md1@ecss2 │15h 3m│ │ │md1@ecss2 │ecss-mediator-3.14.10.562 │md1@ecss1,md1@ecss2 │md1@ecss1,md1@ecss2 │2m 5s │ │ │mycelium1@ecss1│ecss-mycelium-3.14.10.562 │mycelium1@ecss1,mycelium1@ecss2│not running │15h 4m│ │ │mycelium1@ecss2│ecss-mycelium-3.14.10.562 │mycelium1@ecss1,mycelium1@ecss2│not running │2m 5s │ │ │sip1@ecss1 │ecss-pa-sip-3.14.10.562 │sip1@ecss1,sip1@ecss2 │sip1@ecss1,sip1@ecss2│15h 3m│ │ │sip1@ecss2 │ecss-pa-sip-3.14.10.562 │sip1@ecss1,sip1@ecss2 │sip1@ecss1,sip1@ecss2│2m 5s │ └─┴───────────────┴───────────────────────────┴───────────────────────────────┴─────────────────────┴──────┘ All services are started. Active media resource selected list specific: ┌─────────────┬───────┬────────────┬───────────┬───────────┐ │ Node │ MSR │ MSR │ Cc-status │ Cc-uptime │ │ │ │ version │ │ │ ├─────────────┼───────┼────────────┼───────────┼───────────┤ │ core1@ecss1 │ msr_1 │ 3.14.10.24 │ connected │ 15:03:43 │ │ │ msr_2 │ 3.14.10.24 │ connected │ 00:01:49 │ │ core1@ecss2 │ msr_1 │ 3.14.10.24 │ connected │ 00:01:27 │ │ │ msr_2 │ 3.14.10.24 │ connected │ 00:01:26 │ └─────────────┴───────┴────────────┴───────────┴───────────┘ |
Первым этапом анализа проблем является просмотр активных предупреждений в системе 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 |
Описание предупреждений и действий, необходимых для решения, приведены в разделе Аварийные сообщения и меры по их устранению.
При получении жалоб от абонентов системы ECSS-10 необходимо получить от них следующую информацию:
Устранение любого отказа следует начинать со сбора информации. Источниками информации об отказе, могут быть:
После получения общей информации о предупреждении, можно классифицировать неисправность по срочности и предварительно определить ответственные узлы системы. После необходимо получить детальные сведения события.
Приложение Web-конфигуратора "Список предупреждений (Alarm list)" предоставляет следующую информацию:
Подробнее в разделе Описание структуры предупреждения.
По уровню важности предупреждения делятся на:
По типу предупреждения делятся на:
В большинстве случаев информации, полученной в панели предупреждений, достаточно для того, чтобы локализовать неисправность. Сложность представляют те случаи, при которых наблюдается отказ, но в панели предупреждений нет об этом записи. В такой ситуации следует собирать дополнительную информацию. Для точной локализации неисправности, необходимо знать путь прохождения вызова.
Любой вызов, совершаемый через систему, можно разбить на три участка:
|
Если отказы наблюдаются только на оном или нескольких абонентов, первым этапом нужно посмотреть в истории вызовов причину отказа. Это можно увидеть в приложении Web-конфигуратора "История вызовов" или с помощью команды CLI //domain/<DOMAIN>/calls/list.
По полю "Internal cause" можно предварительно определить, в каком направлении дальше искать причину.
Например:
admin@mycelium1@ecss1:/$ domain/biysk.local/calls/list ┌──────────────────┬───────────────────┬──────────────────────┬──────────┬────────────┬────────────┬────────────┬────────────┬─┬─────────┬─────────────┬─────┬──┬─────────────────────────────────┬─┬──┐ │ Call ID │ CallRef │ Start │ Stage │ Original │ Original │ CgPN │ CdPN │T│Duration │ Internal │ISUP │RI│ Release │A│SS│ │ │ │ │ │ CgPN │ CdPN │ │ │ │ │ cause │cause│ │ description │ │ │ ├──────────────────┼───────────────────┼──────────────────────┼──────────┼────────────┼────────────┼────────────┼────────────┼─┼─────────┼─────────────┼─────┼──┼─────────────────────────────────┼─┼──┤ ... │067b96fd371849c0 │ 4106686374│ 04.08.2022 20:07:31 │ released │ 9647678947│ 240533│ 9647678947│ 240533│n│ 0s│notReachable │ 20 │S │ │N│ │ │067b99412678e63d │ 75919816│ 04.08.2022 22:42:10 │ released │ 9913699011│ 240003│ 9913699011│ 240003│n│ 0s│terminationDe│ 21 │S │ │N│ │ │ │ │ │ │ │ │ │ │ │ │ nied │ │ │ │ │ │ └──────────────────┴───────────────────┴──────────────────────┴──────────┴────────────┴────────────┴────────────┴────────────┴─┴─────────┴─────────────┴─────┴──┴─────────────────────────────────┴─┴──┘ |
Здесь видно, вызов на 240533 завершился с причиной "notReachable". Это скорее всего означает, что он не зарегистрирован.
Вызов на 240003 завершился с причиной "terminationDenied" - это значит, что вызов отклонен принимающей стороной. Возможно вызываемый абонент включил услугу DND или сработал "черный список". Также нужно проверить, не включены ли какие-то блокировки. Все "Internal cause" описаны в разделе "Приложение В. Описание внутренних причин разъединения".
Далее приведены примеры определения причины отказа на участках прохождения вызова касающихся системы ECSS-10: В случае если об отказе нет записи в панели предупреждений, локализацию неисправности следует производить методом последовательной проверки всех участков прохождения вызовов:
При локализации проблемы необходимо учитывать следующие ситуации:
Если наблюдаются сбои в прохождении трафика VoIP или управления, следует проверить сетевой трафик на наличие шторма на сети. Инструменты могут быть любые - tspdump, ntop, tshark и т.п. Главное - определить интерфейс, где наблюдается резкий подъем трафика. Если возможно, для локализации проблемы - отключить данный сетевой интерфейс и понаблюдать, не исчезла ли проблема. В целом, источники сетевого шторма довольно трудно локализовать. Лучше обратиться к администраторам своей сети, чтобы согласовать настройки коммутаторов.
Набор требуемой детальной информации зависит от шага Локализация неисправности. Так например, если отказ был локализован в ядре ECSS-10, то дополнительно необходимо будет снять log-файлы ядра необходимых сервисов. Список log-файлов, которые необходимо снять, сообщат сотрудники сервисного центра (См. Включение и отключение систем логирования служб).
Алгоритм проверки в случае непрохождения вызова:
В системе ECSS-10 каждая нода имеет в своём составе определенный набор служб, ответственных за те или иные процессы. Также имеет набор заранее определенных правил, которые определяют в каком виде записывать log-файлы и для отдельных служб. Большинство правил по умолчанию отключено, так как в не аварийном состоянии системы они не нужны. В процессе определения причины отказа может потребоваться включить те или иные правила.
Просмотр настройки:
/node/<node name>/log/config show
Активация правила логирования для определённой ноды:
node/<node_name>/log/config rule <rule_name> on
где:
| Существуют правила с постфиксом _bin, что означает что запись будет вестись в бинарном формате, перекодировать в текстовый можно с помощью утилиты binarylog2text из пакета ecss-utils |
После активации, соответствующий этому правилу файл будет наполнятся записями, и находится он по следующему пути:
/var/log/ecss/<node_name>/<date>/<rule_name>
Деактивация правила выполняется командой:
node/<node_name>/log/config rule <rule_name> off
Просмотр статуса и настроек правил логирования для определенной ноды:
node/<node_name>/log/config show
В первом столбце указано состояние правила: "+" — правило включено, "-" — правило выключено.
| Правила можно создавать самостоятельно, но в подавляющем большинстве случаев этого не требуется, так как необходимые правила уже присутствуют. |
| Список служб для которых необходимо включить логирование нужно получить у инженеров сервис центра. |
Пакет ecss-utils включает в себя следующие скрипты:
После установки пакета скрипты будут находиться в каталоге /usr/bin/.
Синтаксис запуска:
binarylog2text <каталог/имя исходного файла бинарного лога > <каталог/имя текстового файла>
binaryfold2text <каталог с файлами бинарных логов> <каталог назначения для сконвертированных файлов>
Примеры использования:
sasha@ecss1:~$ binarylog2text /var/log/ecss/mediator/md1@ecss1/info.log.bin md1_info.log sasha@ecss1:~$ binaryfold2text /var/log/ecss/mediator/md1@ecss1/ logs/ Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin because it has a zero size. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin to logs//info.log... done. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.1 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.2 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.3 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.4 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.5 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.6 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.7 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.8 because it has a zero size. Skip /var/log/ecss/mediator/md1@ecss1//default.log.bin.9 because it has a zero size. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.1 to logs//info.log.1... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.2 to logs//info.log.2... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.3 to logs//info.log.3... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.4 to logs//info.log.4... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.5 to logs//info.log.5... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.6 to logs//info.log.6... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.7 to logs//info.log.7... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.8 to logs//info.log.8... done. Convert /var/log/ecss/mediator/md1@ecss1//info.log.bin.9 to logs//info.log.9... done. |
Для сбора логов удобно воспользоваться встроенной утилитой ecss-control.
Проверить прослушиваются ли используемые для сигнализации порты можно при помощи команды 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:
Пример:
admin@mycelium1@ecss1:/$ domain/biysk.local/trace/list --limit 3
┌────────┬──────────┬───────────────────┬────────┬──────────┬────────┬──────────┬──────┬─┬────────┬─────────────────┬───────┬─┐
│Short ID│ CallRef │ Start │ Stage │ Original │Original│ CgPN │ CdPN │M│Duration│ Release │ ISUP │F│
│ │ │ │ │ CgPN │ CdPN │ │ │ │ │ │release│ │
├────────┼──────────┼───────────────────┼────────┼──────────┼────────┼──────────┼──────┼─┼────────┼─────────────────┼───────┼─┤
│100ce335│2353005827│15.08.2022 11:36:01│released│4950096484│ 240807│4950096484│ 507│n│ 0s│normal │ 88/3 │ │
│060d4ff8│3557163473│15.08.2022 11:40:48│released│ 240244│ 240466│ 240244│240466│n│ 0s│terminationDenied│ 21/0 │ │
│c62300f3│3607500448│15.08.2022 11:41:00│released│ 240244│ 416977│3854240244│416977│n│ 28s│normal │ 16/0 │ │
└────────┴──────────┴───────────────────┴────────┴──────────┴────────┴──────────┴──────┴─┴────────┴─────────────────┴───────┴─┘
Legend:
M - mode
i - internal
n - normal
c - callback
s - supervise
a - acd
m - message
r - refer
F - flag show is call-process failed or not
* - call-procss failed
[empty] - call-procss active or successfully finished
Total call processes' records: 6
Selected call processes' records: 3
[exec at: 15.08.2022 11:41:46, exec time: 16ms, nodes: core1@ecss1 v.3.14.12.230] |
Для просмотра трассировки определенного вызова необходимо найти этот вызов используя значения следующих столбцов:
В первом столбце таблице указывается Short ID, по значению которого можно вывести трассировку для этого вызова.
| Стоит обратить внимание на последний столбец "F", отметка в данном столбце означает что вызов был завершен по причине падения ядра ESCC-10. |
Вывод трассировки выполняется командой show:
Пример:
admin@mycelium1@ecss1:/$ domain/biysk.local/trace/show --Te 060d4ff8
Trace release: 3.14.12.230
Current release: 3.14.12.230
Trace id: <<"067c8375060d4ff8">>
First message time: 2022/08/15 11:40:48
1. 19219 04:40:48: 163473 i SetupInd 240244@biysk.local A:240244,B:240466,sdp_o
2. 19219 04:40:48: n Notification {branch_next,main}
3. 19219 04:40:48: 163473 o SetupIndAck 240244@biysk.local
4. 19219 04:40:48: n Notification {{leg,o},call_id,<<"4010439451@192.168.1.201">>}
5. 19219 04:40:48: n Notification {{leg,o},{zone,"default"},{site,"local"},{profile,"default"}}
6. 19219 04:40:48: n Notification o dtmf transmit type: transit
7. 19219 04:40:48: n Notification o dtmf receive type: auto
8. 19219 04:40:48: n Notification {branch_next,release_t}
9. 19219 04:40:48: n Notification cfc play: http://system.restfs.ecss:9990/system/sounds/ai_notaccess.wav
10. 19219 04:40:48: n Notification {{leg,o},contact,"bond1.2@192.168.2.21?22abcd"}
11. 19219 04:40:48: n Notification {{leg,o},invite_answer}
12. 19219 04:40:48: 163473 o CallProgressReq 240244@biysk.local terminationDenied,sdp_a,inBand,system,21,[release]
13. 19219 04:40:50: n Notification {{leg,o},bye}
14. 19219 04:40:50: 163473 o ReleaseReq 240244@biysk.local terminationDenied,21,system,"B has no access to be called from "private" subscribers (B access_type: admin1, ISUP Cause: <<128,149>>)" |
Для более подробного вывода используется аргумент --payload.
Анализ трассировки требует определенной подготовки. Для начала анализа необходимо найти сообщение "ReleaseReq" и посмотреть причину. Далее искать решение проблемы в зависимости от причины разъединения.
Пример сообщения "ReleaseReq":
admin@mycelium1@ecss1:/$ domain/biysk.local/trace/show --Te 060d4ff8 --payload
<<<<<<<<<<<<<<<<<<<<<<<
...
>>>>>>>>>>>>>>>>>>>>>>>
14. out/transaction_list/ct_service_cp: 19219 04:40:50:741 (2022/08/15 11:40:50.741)
body:
{'AcpMessage',<<"240244@biysk.local">>,3557163473,
{'ReleaseReq',
{'ReleaseType',terminationDenied,system,
"B has no access to be called from \"private\" subscribers (B access_type: admin1, ISUP Cause: <<128,149>>)",
"240466",
{'CalledPartyNumber',subscriberNumber,local,false,routingToInternalNumberAllowed,isdnTelephony,
presentationAllowed,0,"240466",undefined,undefined,undefined,undefined},
<<128,149>>,
undefined,
[{[language],undefined},{['support-encoding'],utf8}],
undefined,false,
{'ConnectedNumber',subscriberNumber,local,isdnTelephony,presentationAllowed,"240466",
{'CallerDisplayInformation',true,undefined,undefined,true,"240466",false,undefined},
undefined,undefined},
{1660,538450,721181}}}}
--------------------------------------------
ct_service_cp -> out
|
Поле "B has no access to be called from \"private\" subscribers (B access_type: admin1, ISUP Cause: <<128,149>>)" указывает на то, что вызов был завершен по причине административной блокировки вызываемого абонента.
Если возникли вопросы по анализу лога "core_cp_trace", рекомендуется обратиться в техническую поддержку компании Элтекс.
| При анализе log-файла необходимо помнить, что существует возможность сопоставить log-файл ядра с TCP dump. В log-файл ядра присутствует параметр "Сall ref", используемый уровнем SIP-адаптера (секция AdditionalInfo). |
Для сохранения трассировок в файл используется команда save-trace, аргументами которой являются:
admin@mycelium1@ecss1:/$ domain/biysk.local/trace/save-trace --Te 060d4ff8 --dets --file ecss1 2022_08_15/11-00/067c83060d4ff8.dets ok |
Найти сохранённый файл можно в директории /var/lib/ecss/cp/<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 и т.д.
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.
Пример запуска трассировки на SIP-адаптере из 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. Приведем пример для снятия 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-utils.
Перевести siptrace.bin в текстовый siptrace.log можно командой:
cd /var/log/ecss/pa_sipt/YYYY_MM_DD_hh_mm_ss_sip1@<hostname>/ binarylog2text siptrace.bin siptrace.log |
В то время как binaryfold2text конвертирует все файлы в каталоге в *.log , если конвертация прошла успешно, то изначальные *.bin будут удалены.
Есть возможность сохранять трассировку 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 |
В Web-конфигураторе для захвата трафика есть приложение Менеджер PCAP трассировки (PCAP trace manager).
Для захвата и анализа трафика можно также использовать другие приложения, например sngrep, tshark, ngrep, sipgrep и подобные. Для постоянного мониторинга и сбора статистики удобно использовать voipmonitor, pcapsipdump, sipcapture и другие. Документацию по использованию можно найти на страницах соответствующих проектов.
На запрос 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>
где
Посмотреть логины и пароли у всех SIP-абонентов ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info * *
Посмотреть логины и пароли у определенного SIP-абонента в системе ECSS-10 можно командой:
/domain/<DOMAIN>/sip/user/info <GROUP> <INTERFACE>
где
Необходимо проверить соответствует ли контекст маршрутизации на сервере файлам, импортированным в базу данных ECSS-10.
| Контексты маршрутизации не импортируются автоматически. После внесения изменений в контекст маршрутизации необходимо заново импортировать контекст маршрутизации в базу данных ECSS-10. |
Контексты маршрутизации расположены на сервере по следующему пути: /var/lib/ecss/routing/ctx/src/<DOMAIN>.
Посмотреть контекст маршрутизации в ОС 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-ов по UDP, следует раскомментировать следующие строки (/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 |